I just found my old WD Caviar drive. It was in an unused PC. It's 1.2GB, WDC AC31200F. And the problem Steve reported is reproduced here. I'll see if I can fix this.
On Fri, Oct 24, 2003 at 05:13:23AM +0900, SONE Takeshi wrote:
I just found my old WD Caviar drive. It was in an unused PC. It's 1.2GB, WDC AC31200F. And the problem Steve reported is reproduced here. I'll see if I can fix this.
The old IDE driver (in LinuxBIOS) does a lot of commands to initialize the drive, while the current driver (in FILO at least) just does IDENTIFY command.
IDE_CMD_GET_INFO IDE_CMD_DRIVE_DIAG (soft reset) IDE_CMD_RECALIBRATE IDE_CMD_SET_PARAMS IDE_CMD_SET_MULTIMODE IDE_CMD_SET_PARAMS
Maybe some of them are needed to start Caviar up.
On Fri, Oct 24, 2003 at 05:34:16AM +0900, ts1 wrote:
On Fri, Oct 24, 2003 at 05:13:23AM +0900, SONE Takeshi wrote:
I just found my old WD Caviar drive. It was in an unused PC. It's 1.2GB, WDC AC31200F. And the problem Steve reported is reproduced here. I'll see if I can fix this.
The old IDE driver (in LinuxBIOS) does a lot of commands to initialize the drive, while the current driver (in FILO at least) just does IDENTIFY command.
IDE_CMD_GET_INFO IDE_CMD_DRIVE_DIAG (soft reset) IDE_CMD_RECALIBRATE IDE_CMD_SET_PARAMS IDE_CMD_SET_MULTIMODE IDE_CMD_SET_PARAMS
Added all of these, but it doesn't work yet..
Also added ERR bit checking after PIO commands. None of the above causes ERR, but the first READ_SECTORS command does. (error register = 0x4, ABORT error)
I noticed this Caviar drive works just fine under Linux (both 2.4 and 2.6-test), regardless of whether FILO touched it or not.
Added all of these, but it doesn't work yet..
Also added ERR bit checking after PIO commands. None of the above causes ERR, but the first READ_SECTORS command does. (error register = 0x4, ABORT error)
I noticed this Caviar drive works just fine under Linux (both 2.4 and 2.6-test), regardless of whether FILO touched it or not.
Takeshi-
I tried the same thing and I got the same result, and I also noticed the error bit is set. What is going on is very strange, but it does seem to be related to initialization and startup. I don't think it is the read commands or status loops; I tried modifying these to match the old code but got the same result.
-Steve
Steve Gehlbach wrote:
Also added ERR bit checking after PIO commands. None of the above causes ERR, but the first READ_SECTORS command does. (error register = 0x4, ABORT error)
I noticed this Caviar drive works just fine under Linux (both 2.4 and 2.6-test), regardless of whether FILO touched it or not.
Takeshi-
I tried the same thing and I got the same result, and I also noticed the error bit is set. What is going on is very strange, but it does seem to be related to initialization and startup. I don't think it is the read commands or status loops; I tried modifying these to match the old code but got the same result.
Perhaps some startup timeing requirement is being violated? HD drives do lots of self calibration stuff when you boot or reset them. I remember some older drives were really flaky. Not playing well with other drives and such. Perhaps you are tring to access it while its still in temp comp or head drift cal and not ready to do a seek.
A previous COTS bios that I used had a startup delay parameter just for HD delay before the first access to the drive. I never needed it since a CF is ready almost instantly.
On Fri, Oct 24, 2003 at 04:00:10PM -0500, Richard Smith wrote:
Steve Gehlbach wrote:
Also added ERR bit checking after PIO commands. None of the above causes ERR, but the first READ_SECTORS command does. (error register = 0x4, ABORT error)
I noticed this Caviar drive works just fine under Linux (both 2.4 and 2.6-test), regardless of whether FILO touched it or not.
Takeshi-
I tried the same thing and I got the same result, and I also noticed the error bit is set. What is going on is very strange, but it does seem to be related to initialization and startup. I don't think it is the read commands or status loops; I tried modifying these to match the old code but got the same result.
I have tried all other differences I could see. READ_MULTI instead of READ_SECTORS, outb_p instead of outb, setting feature (precomp) register to 0xff, checking BSY (and DRDY) bit just before writing command register, etc.. but still unsuccessfull.
Maybe we are missing stupidly minor difference.
Perhaps some startup timeing requirement is being violated? HD drives do lots of self calibration stuff when you boot or reset them. I remember some older drives were really flaky. Not playing well with other drives and such. Perhaps you are tring to access it while its still in temp comp or head drift cal and not ready to do a seek.
Indeed, this drive takes longer on spin-up (but BSY is low and IDENTIFY takes time) and device diagnostic command, as compared to recent drives. But our driver properly waits for these to be done using status bits.
A previous COTS bios that I used had a startup delay parameter just for HD delay before the first access to the drive. I never needed it since a CF is ready almost instantly.
Hardcoded delay is needed if the drive doesn't assert BSY bit while spin-up.
On Sun, Oct 26, 2003 at 04:13:18AM +0900, ts1 wrote:
I have tried all other differences I could see. READ_MULTI instead of READ_SECTORS, outb_p instead of outb, setting feature (precomp) register to 0xff, checking BSY (and DRDY) bit just before writing command register, etc.. but still unsuccessfull.
Maybe we are missing stupidly minor difference.
A bit of progress..
I ported the old driver to FILO - it worked. Removed the excessive initialization part (besides IDENTIFY) - still worked. Removed ERROR bit checking in status loop - STOPPED WORKING!!
I thought ERROR bit checking (reading status port) acts like a delay, so I added a 400ns delay after pio_set_registers of the new driver. The new driver finally worked.
BUT, it doesn't work in the cold boot case.. It works when once Linux is booted then reboot into FILO.
Maybe I have to re-enable some commands in the initialization procedure. But I've made too many modifications to the new driver, I'm not sure which is really needed.
This thing is tough..
I thought ERROR bit checking (reading status port) acts like a delay, so I added a 400ns delay after pio_set_registers of the new driver. The new driver finally worked.
It works when once Linux is booted then reboot into FILO.
Maybe I have to re-enable some commands in the initialization procedure. But I've made too many modifications to the new driver, I'm not sure which is really needed.
Takeshi,
The fact that you can boot linux and then reboot into FILO and it works really suggests to me that you are working with a some sort of flaky IDE interface. So don't expect anything to be logical. I've worked with lots of embedded type devices that exhibit this symptom. They just take a while to come out of a cold boot or even from a warm reset.
Hard drives have a special problem in that they must calibrate for both mechanical head drift and ambient temperature before they access the disk _and_ its got to be pretty precise. I'm always amazed at the precision required by a HD.
What happens if you just do a 5 second delay on cold boot before you access the drive? My guess is that it will work. If so then you just need to find out what the minimum delay is before you can access the drive.
You might lark onto a special init sequence that works but I suspect it will be drive specific. Your best bet to come up with a universial solution is probally a user configurable delay for drives that don't handle the BSY flag properly.
On Tue, Oct 28, 2003 at 11:14:24AM -0600, Richard Smith wrote:
I thought ERROR bit checking (reading status port) acts like a delay, so I added a 400ns delay after pio_set_registers of the new driver. The new driver finally worked.
It works when once Linux is booted then reboot into FILO.
Maybe I have to re-enable some commands in the initialization procedure.
I got it work just now, both for cold boot and warm boot cases. The missing command was INITIALIZE PARAMETERS. I wasted many hours to realize that I had done it wrong. :)
But I've made too many modifications to the new driver, I'm not sure which is really needed.
This work is to be done. I'll release 0.4.1 (bugfix-only release) when it's done.
The fact that you can boot linux and then reboot into FILO and it works really suggests to me that you are working with a some sort of flaky IDE interface. So don't expect anything to be logical. I've worked with lots of embedded type devices that exhibit this symptom. They just take a while to come out of a cold boot or even from a warm reset.
I suspected everything and did whatever I could do. In this case, after all, it was me that was flaky, not the drive or IF.
One thing I'll have to examine is the delay I had to insert between issuing command and reading status. It might be requirement of ATA spec.
Hard drives have a special problem in that they must calibrate for both mechanical head drift and ambient temperature before they access the disk _and_ its got to be pretty precise. I'm always amazed at the precision required by a HD.
What happens if you just do a 5 second delay on cold boot before you access the drive? My guess is that it will work. If so then you just need to find out what the minimum delay is before you can access the drive.
Did it. I access to the drive from the command prompt, so I can make any delay before hitting Enter key. Once I waited for the drive to become quiet completely, but it still failed, so I decided some initialization was missing.
You might lark onto a special init sequence that works but I suspect it will be drive specific. Your best bet to come up with a universial solution is probally a user configurable delay for drives that don't handle the BSY flag properly.
Eric had already added the delay option (#ifdef) to (the ancestor of) the driver, though it is hardcoded 31 sec (following ATA spec).
SONE Takeshi wrote:
I got it work just now, both for cold boot and warm boot cases. The missing command was INITIALIZE PARAMETERS. I wasted many hours to realize that I had done it wrong. :)
Cool. Good sluthing. Funny how it worked on lots of other drives without the init command.
Eric had already added the delay option (#ifdef) to (the ancestor of) the driver, though it is hardcoded 31 sec (following ATA spec).
Isn't that delay the max delay that a master can wait for a slave to become ready?
On Tue, Oct 28, 2003 at 01:26:22PM -0600, Richard Smith wrote:
Cool. Good sluthing. Funny how it worked on lots of other drives without the init command.
It is an obsolete command (disappeared in ATA-6) but old drives may need it.
Eric had already added the delay option (#ifdef) to (the ancestor of) the driver, though it is hardcoded 31 sec (following ATA spec).
Isn't that delay the max delay that a master can wait for a slave to become ready?
Maybe, but I think I've seen this number a lot of other places in the spec. ATA spec is huge, and sometimes I have to refer to old versions (I mainly use ATA-1, ATA-2 and ATA-6), it's hard to look through them.
SONE Takeshi ts1@tsn.or.jp writes:
On Tue, Oct 28, 2003 at 01:26:22PM -0600, Richard Smith wrote:
Cool. Good sluthing. Funny how it worked on lots of other drives without the init command.
It is an obsolete command (disappeared in ATA-6) but old drives may need it.
Eric had already added the delay option (#ifdef) to (the ancestor of) the driver, though it is hardcoded 31 sec (following ATA spec).
Isn't that delay the max delay that a master can wait for a slave to become ready?
Maybe, but I think I've seen this number a lot of other places in the spec. ATA spec is huge, and sometimes I have to refer to old versions (I mainly use ATA-1, ATA-2 and ATA-6), it's hard to look through them.
When I surveyed the ATA spec 31 seconds was the longest amount of time a drive was allowed to assert the BUSY bit for any command. So if you wait 32 seconds and your drives is not ready then the drive is definitely out of spec.
Eric
On Wed, Oct 29, 2003 at 02:55:56AM +0900, ts1 wrote:
I'll release 0.4.1 (bugfix-only release) when it's done.
I put it at the usual place: http://te.to/~ts1/filo/ This contains small bugfixes only.
Version 0.4.1 ts1 2003-10-30 * Fixed IDE driver for older hard disks (such as WD Caviar 1.2G) * Fixed wrong sector number in the disk read error message * Fixed inaccurate display of hard disk capacity * Fixed behavior of word erase (^W) for one character * Updated README and FAQ
-
ebiederman＠lnxi.com -
Richard Smith -
SONE Takeshi -
Steve Gehlbach