IDE hard drive. insw too fast?

IDE hard drive. insw too fast?

Post by crypto_sto » Sat, 19 Feb 2005 00:13:35


Hello,

I recently started writting a IDE hard drive driver.

I dump the stuff on screen to see it live ( I'm still in the testing
phase )

Nothing fancy, I can spinup the drive, spinit down, recalibrate.

I can also read sectors. Right now I set it up to reading 2 sectors
(1024 bytes). I dont have the code under my eyes right now but it looks
something like this.

INSW does something like this.

movl $200, %ecx
movw $0x1F0, %dx
movl $BUFFER, %edi
rep insw

: CHS 2 1F2 OUTB ( Read 2 sectors )
1F3 OUTB ( Set start sector )
1F6 A0 OR OUTB ( Set head )
DUP 1F4 OUTB ( Set low cylinder )
2/ 2/ 2/ 2/ 2/ 2/ 2/ 2/
1F5 OUTB ; ( Set high cylinder )

: READ 20 1F7 OUTB ( Send read command )
UNTIL-READY ( Wait until the drive is ready )
INSW ; ( Read the 1024 bytes dumping them to
screen)

0 0 1 CHS READ

I was wondering if it was possible for insw to be too fast for the port
to follow.

Most of the time I can read the 1024 bytes alright, but every now and
then the last word in the 1024 bytes is not there or is different than
what is expected from previous reads.

Ideas?
Thanks

Regards
Stonelock
 
 
 

IDE hard drive. insw too fast?

Post by Andreas Ko » Sat, 19 Feb 2005 01:36:29

Are you working on a PC architecture?
Have you tried two INSBs instead?

Cheers, Andreas

http://www.yqcomputer.com/

 
 
 

IDE hard drive. insw too fast?

Post by crypto_sto » Sat, 19 Feb 2005 01:58:38


Yep, I'm on a inspiron 600m DELL laptop. Pentium-M processor.
I guess I'll have to try reading ports different ways. I should try
INSD also I suppose. If insw and company fail, i'll probably end up
doing a slow as rain FORTH loop with a INB and manual dispatch to
buffer in it ( that would be sad ).

I'm sure there's a solution though. Maybe I'm just coding wrong out of
not understanding things right.

Regards
Stonelock
 
 
 

IDE hard drive. insw too fast?

Post by Brad Ecker » Sat, 19 Feb 2005 03:39:17


port
than
Maybe UNTIL-READY is exiting after the read operation is started but
before the DMA transfer has been completed. Is there more than one
status flag you can check?

Brad
 
 
 

IDE hard drive. insw too fast?

Post by Coos Haa » Sat, 19 Feb 2005 04:55:01

Op 17 Feb 2005 08:58:38 -0800 schreef XXXX@XXXXX.COM :



I've looked into Ralf Brown's Interrupt List and that describes
the ports 01F0-01F7 as byte-sized ports.

"
01F0 RW data register
01F1 R- error register (see #P0512)
01F1 -W WPC/4 (Write Precompensation Cylinder divided by 4)
01F2 RW sector count
01F3 RW sector number (CHS mode)
logical block address, bits 0-7 (LBA mode)
01F4 RW cylinder low (CHS mode)
logical block address, bits 15-8 (LBA mode)
01F5 RW cylinder high (CHS mode)
logical block address, bits 23-16 (LBA mode)
01F6 RW drive/head (see #P0513)
01F7 R- status register (see #P0514)
01F7 -W command register (see #P0515)
"

So there is no reason to access them as being 16 bit.
Perhaps accessing them as W or D isn't even supported.
Why would reading two or four bytes be _that_ much slower than
once or twice 16 bits or once 32 bit? The wait loops are much
more time consuming.

--
Coos
 
 
 

IDE hard drive. insw too fast?

Post by Roger Ivi » Sat, 19 Feb 2005 05:57:55


The data register is a word port. It *must* be accessed as a word.

Unless you're dealing with CompactFlash, which allows the data register
to be a byte port. Although this used to be an option for disks, I think
that option was retired many, many years ago (and even then, you had to
really look to find a disk that supported it).
--
Roger Ivie
XXXX@XXXXX.COM
http://www.yqcomputer.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++
------END GEEK CODE BLOCK------
 
 
 

IDE hard drive. insw too fast?

Post by Coos Haa » Sat, 19 Feb 2005 07:31:14

Op Thu, 17 Feb 2005 20:57:55 GMT schreef Roger Ivie:



I thought that R means read-enabled and W write-enabled.
01F1 is the error register, read-only. I can be wrong however ;-)

Coos
--
CHForth, 16 bit DOS
home.hccnet.nl/j.j.haak
 
 
 

IDE hard drive. insw too fast?

Post by rickma » Sat, 19 Feb 2005 09:39:42


I went hunting and found this in the ATA-2 spec...


5.2.11 IOCS16- (Device 16-bit I/O)
During PIO transfer modes 0, 1 or 2, IOCS16- indicates to the host
system that the 16-bit data port has been addressed and that the device
is prepared to send or receive a 16-bit data word. This shall be an open
collector output.
- When transferring in any PIO mode and accessing any register except
the data port, transfers shall be 8-bit using DD0-7;
- When transferring in PIO modes 0, 1 or 2, if IOCS16- is not asserted,
transfers shall be 8-bit using DD0-7;
- When transferring in PIO modes 0, 1 or 2, if IOCS16- is asserted,
transfers shall be 16-bit using DD0-15;
- When transferring in PIO modes 3 or 4, IOCS16- shall not be used by
the host, and all transfers shall be 16-bit using DD0-15, except for
bytes beyond the 512th byte for READ LONG and WRITE LONG commands which
shall be 8-bit using DD0-7;
- When transferring in DMA mode, the host shall use a 16-bit DMA channel
and IOCS16- shall not be asserted.


Sounds pretty complex to me. Is this clear to anyone?

I think it is saying that in all PIO modes, registers other than 0, the
data register, are 8 bits. But the data register can be either 8 or 16
bits depending on the state of the IOCS16 signal the drive returns.

But the first rule and the fourth rule sound to me like they conflict.
 
 
 

IDE hard drive. insw too fast?

Post by Roger Ivi » Sat, 19 Feb 2005 11:15:40


Sounds like it to me, as well. Point being that an 8-bit transfer to the
data register on a drive expecting to return 16-bits won't work.
However, a 16-bit transfer to a drive expecting to return 8 bits WILL,
because the motherboard examines IOCS16 and and will break the
transfer into two 8-bit transfers if required. This was done for
compatibility with the original PC when the PC/AT came out.

In other words, 16-bit transfers always work. 8-bit transfers MIGHT work
IF you know the drive is an 8-bit drive. But it's pretty unlikely that
the drive will be an 8-bit drive, unless it's CompactFlash in 8-bit mode.

I'm pretty certain that the fourth rule is speaking only about the data
register, which is specifically excluded from the first rule, but the
wording of the fourth rule doesn't make that clear. Perhaps you dropped a
"data" between "transferring" and "in"? I don't have a copy of the spec
handy.

Essentially, rule 4 says that the 8-bit data register option has been
dropped by PIO modes 3 or 4. The data register is always 16 bits in
those modes. Since a 16-bit data register is also valid in PIO modes 0,
1, or 2, I think it's unlikely that a recent drive will support 8-bit
data when operating in those modes (does the drive even know what the PIO
mode is?); somebody would have had to go pretty far out of their way to
make it happen.
--
Roger Ivie
XXXX@XXXXX.COM
http://www.yqcomputer.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++
------END GEEK CODE BLOCK------
 
 
 

IDE hard drive. insw too fast?

Post by Albert van » Sat, 19 Feb 2005 18:47:01

In article < XXXX@XXXXX.COM >,



I would rather say, that this is a 8/16 bit problem.
Reading 16 bits from the last address would balk, because part
of the data is unavailable, then it would bust the other half.
Just a wild guess.

--
Groetjes Albert
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.
 
 
 

IDE hard drive. insw too fast?

Post by Tim Clac » Sat, 19 Feb 2005 20:46:22


:

The protocol should look like this:

1. Wait for 'not BSY'
2. Send command

3. Wait for 'DRQ'
4. Transfer data

Of course, at stage (3), you should check STATUS to see whether the command
aborted or data can actually bee transferred.
 
 
 

IDE hard drive. insw too fast?

Post by Tim Clac » Sat, 19 Feb 2005 21:13:23


...also, you must read out the two sectors separately like this:

1. Wait for 'not BSY'
2. Send command

3. Wait for 'DRQ'
4. Transfer data (one sector)

5. Wait for 'DRQ'
6. Transfer data (one sector)

:

You can read out multiple sectors in one operation, but that would require
the 'read multiple sector command'.

NOTE: This could be your problem; your reading out a block of 1024 bytes
instead of two blocks of 512 bytes. You might well be reading the second
block before it's ready.
 
 
 

IDE hard drive. insw too fast?

Post by Andy Valen » Sun, 20 Feb 2005 03:54:25


No, it's pretty much required to support rep insw... it was the most
efficient way to move the data (until DMA for IDE was available).

I was going to caution you to make sure the 16-bit prefix got emitted in
the assembled bytes... I had a portability problem with an assembler that
didn't (in 32-bit mode insw is insl with a 16-bit opcode prefix). It
worked with most PC's, but then I ran into one which actually handed back
the full 32 bits.

But since you're always getting almost the whole buffer correctly, that
doesn't sound right. Are you absolutely sure your host environment isn't
touching your controller behind your back?

Andy Valencia
 
 
 

IDE hard drive. insw too fast?

Post by crypto_sto » Sun, 20 Feb 2005 08:42:14


port
in
that
back
that

Yeah, the problem only occurs when I read 2 secotors (1024 bytes). When
I only ready 1 sector (512 bytes), I dont get any problems and all the
information is there. This perticular assembler ( AT&T syntax for those
who are unfamiliar with it ) gives me 16-bits.

Are you absolutely sure your host environment isn't

Hehe 100% garanteed. My forth is standalone and I haven't touched the
controler yet ;-).

Stonelock
 
 
 

IDE hard drive. insw too fast?

Post by crypto_sto » Sun, 20 Feb 2005 08:45:20

Ahhh!!! Now this is important news. I'll try making sure the second
block is ready before reading it. This looks like it might solve
everything.

It does actually make alot of sense. Looking at the IDE driver source
code Charles Moore wrote it exactly that way. He makes sure the disk is
ready before reading each sector.

Thanks for the info!

Regards
Stonelock