david hendriks has now built linuxbios from scratch, from the cvs tree, and it all works with graphics etc.
ide is still not working well.
ron
ron minnich wrote:
ide is still not working well.
What I think I have found on the ide is that some older drives report they are LBA but sector reads fail. Maybe that they are CHS, or, it may be the status bits are different and it is a timing thing. But a simple read of linear sector 0 got the wrong data even though all areas of the ide code thought things were fine (no errors).
-Steve
fixes welcome. This is CF that is failing. Actually it reads the data and the data is fine, but when it jumps to the payload nothing happens.
ron
Hi Ron,
fixes welcome. This is CF that is failing. Actually it reads the data and the data is fine, but when it jumps to the payload nothing happens.
Have you tried different CF? Different CF behave differently. Some CF card need more delay/timeout in the IDE driver.
-Andrew
On Tue, 23 Sep 2003, Andrew Ip wrote:
fixes welcome. This is CF that is failing. Actually it reads the data and the data is fine, but when it jumps to the payload nothing happens.
Have you tried different CF? Different CF behave differently. Some CF
actually, as near as we could tell the data was getting in to memory. But once it jumped to the payload it never came back.
ron
Hi Ron,
actually, as near as we could tell the data was getting in to memory. But once it jumped to the payload it never came back.
Interesting. What payload are u using? I have been using etherboot which is pretty stable. However, Filo will be my next target.
-Andrew
On Tue, 23 Sep 2003, Andrew Ip wrote:
actually, as near as we could tell the data was getting in to memory. But once it jumped to the payload it never came back.
Interesting. What payload are u using? I have been using etherboot which is pretty stable. However, Filo will be my next target.
etherboot we built here. We have not had much luck building etherboot, however.
ron
Hi Ron,
etherboot we built here. We have not had much luck building etherboot, however.
I have been using 5.0.6 with Adam's patch. Have you tried earlier version?
-Andrew
ron minnich wrote:
On Tue, 23 Sep 2003, Andrew Ip wrote:
actually, as near as we could tell the data was getting in to memory. But once it jumped to the payload it never came back.
Interesting. What payload are u using? I have been using etherboot which is pretty stable. However, Filo will be my next target.
Filo works very well. I am working with Takeshi to put bzImage boot into it also.
Actually, my ide problems were with filo, but the ide code is the same, I think-- it all is from etherboot AFAIK. My CF drive works (128M) but 1.2G WD Caviar fails.
-Steve
On Mon, 22 Sep 2003, Steve Gehlbach wrote:
ron minnich wrote:
On Tue, 23 Sep 2003, Andrew Ip wrote:
actually, as near as we could tell the data was getting in to memory. But once it jumped to the payload it never came back.
Interesting. What payload are u using? I have been using etherboot which is pretty stable. However, Filo will be my next target.
Filo works very well. I am working with Takeshi to put bzImage boot into it also.
Actually, my ide problems were with filo, but the ide code is the same, I think-- it all is from etherboot AFAIK. My CF drive works (128M) but 1.2G WD Caviar fails.
There are slight differences between the ide code from my etherboot patch (i believe this is where takeshi took the polled ide code from) and the polled ide code in etherboot development branches. If you're having trouble with one, it may be worth trying the other. Takeshi really did a fine job with Filo and I'd like to see if replace my etherboot patch for its admitted hackishness alone :)
- Adam Agnew
Adam Agnew agnew@cs.umd.edu writes:
On Mon, 22 Sep 2003, Steve Gehlbach wrote:
ron minnich wrote:
On Tue, 23 Sep 2003, Andrew Ip wrote:
actually, as near as we could tell the data was getting in to memory. But once it jumped to the payload it never came back.
Interesting. What payload are u using? I have been using etherboot which is pretty stable. However, Filo will be my next target.
Filo works very well. I am working with Takeshi to put bzImage boot into it also.
Actually, my ide problems were with filo, but the ide code is the same, I think-- it all is from etherboot AFAIK. My CF drive works (128M) but 1.2G WD Caviar fails.
There are slight differences between the ide code from my etherboot patch (i believe this is where takeshi took the polled ide code from) and the polled ide code in etherboot development branches.
Actually the FILO polled IDE derives most directly from etherboot 5.1.
There are a couple of small differences but nothing that looked too substantial. The biggest is the ide_bus_floating() that attempts to quickly see if an IDE cable is absent.
If you're having trouble with one, it may be worth trying the other. Takeshi really did a fine job with Filo and I'd like to see if replace my etherboot patch for its admitted hackishness alone :)
FILO does look good from what I have seen of it.
Before anyone can guess anything we need a lot more detailed bug report than what has been seen so far.
Steve how does your 1.2G Caviar fail? Is it not detected or is the problem something else?
SONE do you really have a system that with no IDE disk has the BSY bit stuck high. Or is that just what happens when you scan PIO ports that are not connected to and IDE controller. As far as I know that is the biggest difference between our drivers. You scan PIO space and I primarily scan pci space for IDE controllers.
Eric
On Tue, Sep 23, 2003 at 02:27:08AM -0600, Eric W. Biederman wrote:
Actually the FILO polled IDE derives most directly from etherboot 5.1.
There are a couple of small differences but nothing that looked too substantial. The biggest is the ide_bus_floating() that attempts to quickly see if an IDE cable is absent.
Yes, I took it from Etherboot 5.1. I added floating bus detection, and also changed the soft reset code to see if the drive asserts BSY.
FILO does look good from what I have seen of it.
I'm really glad to hear that from you.
Before anyone can guess anything we need a lot more detailed bug report than what has been seen so far.
Steve how does your 1.2G Caviar fail? Is it not detected or is the problem something else?
I think his problem is something related with geometry. Not with detection.
I thought I had a similar WD drive in my junk box, and I looked for it today, without success. Instead I've found a 250MB Conner(!) drive, and it worked perfectly with FILO!
SONE do you really have a system that with no IDE disk has the BSY bit stuck high. Or is that just what happens when you scan PIO ports that are not connected to and IDE controller.
On EPIA the BSY bit is low when drive is absent, and it is the only real hardware I run FILO. However, it helps quickly skipping the non-existent 3rd and 4th IDE controllers, as you pointed out.
SONE Takeshi ts1@tsn.or.jp writes:
On Tue, Sep 23, 2003 at 02:27:08AM -0600, Eric W. Biederman wrote:
Actually the FILO polled IDE derives most directly from etherboot 5.1.
There are a couple of small differences but nothing that looked too substantial. The biggest is the ide_bus_floating() that attempts to quickly see if an IDE cable is absent.
Yes, I took it from Etherboot 5.1. I added floating bus detection, and also changed the soft reset code to see if the drive asserts BSY.
I have seen IDE cables with a memory so I am not at all certain about the floating detection.
FILO does look good from what I have seen of it.
I'm really glad to hear that from you.
The one thing I would really like to see is it using the LinuxBIOS table to find motherboard devices. Before falling back to more conventional things like a pci scan. That way you don't need to guess where the hardware is. Right now this is a chicken and the egg problem because that information is not being exported but that is one of the next steps for the freebios2 tree.
Before anyone can guess anything we need a lot more detailed bug report than what has been seen so far.
Steve how does your 1.2G Caviar fail? Is it not detected or is the problem something else?
I think his problem is something related with geometry. Not with detection.
I thought I had a similar WD drive in my junk box, and I looked for it today, without success. Instead I've found a 250MB Conner(!) drive, and it worked perfectly with FILO!
SONE do you really have a system that with no IDE disk has the BSY bit stuck high. Or is that just what happens when you scan PIO ports that are not connected to and IDE controller.
On EPIA the BSY bit is low when drive is absent, and it is the only real hardware I run FILO. However, it helps quickly skipping the non-existent 3rd and 4th IDE controllers, as you pointed out.
Right. But if there are better ways of detecting the hardware I would rather we use that.
Eric
On Wed, Sep 24, 2003 at 10:54:02PM -0600, Eric W. Biederman wrote:
I have seen IDE cables with a memory so I am not at all certain about the floating detection.
I'm not sure about non-standard devices. I believe this is what the commercial BIOS does. Anyway FILO only touches the bus the user requests.
The one thing I would really like to see is it using the LinuxBIOS table to find motherboard devices. Before falling back to more conventional things like a pci scan. That way you don't need to guess where the hardware is. Right now this is a chicken and the egg problem because that information is not being exported but that is one of the next steps for the freebios2 tree.
It would be good. Especially for video parameters. We could fill the Linux parameters correctly, so even the vesafb would work eventually. For now FILO just assumes the devices are initialized by LB as the way FILO expects.
-- Takeshi
Eric W. Biederman wrote:
Steve how does your 1.2G Caviar fail? Is it not detected or is the problem something else?
Everything works fine, it just gets the wrong data. I put in lots of printf's, it is using ide_read_sector_lba, all results are normal AFAICT. I printed out the sector (sector 0) that it read, it had about 50 initial values, then all zeros. The real sector 0 is pretty much all filled. I grep'ed for a couple of bytes from the bogus sector and they did not appear in the real sector, so I think all of the data is bogus, not just shifted or something.
The cmd.device byte (=0xe0) (and the others in this structure) appear correct in comparing to ATA spec. Is there ever any confusion about what the first sector is (0 vs 1)? I could not find a specific statement in the ATA spec about this, but it is a long spec.
I was going to force it to use ide_read_sector_chs but did not have time.
I switched to using my CF drive and it worked fine, so I don't think it was cockpit trouble.
-Steve
Steve Gehlbach steve@nexpath.com writes:
Eric W. Biederman wrote:
Steve how does your 1.2G Caviar fail? Is it not detected or is the problem something else?
Everything works fine, it just gets the wrong data. I put in lots of printf's, it is using ide_read_sector_lba, all results are normal AFAICT. I printed out the sector (sector 0) that it read, it had about 50 initial values, then all zeros. The real sector 0 is pretty much all filled. I grep'ed for a couple of bytes from the bogus sector and they did not appear in the real sector, so I think all of the data is bogus, not just shifted or something.
The cmd.device byte (=0xe0) (and the others in this structure) appear correct in
comparing to ATA spec. Is there ever any confusion about what the first sector is (0 vs 1)? I could not find a specific statement in the ATA spec about this, but it is a long spec.
I was going to force it to use ide_read_sector_chs but did not have time.
I switched to using my CF drive and it worked fine, so I don't think it was cockpit trouble.
Right. My only other guess is that some of the lba48 support my be interacting in a strange way and causing problems. We always write the lba48 high registers but we don't set them in the lba case. It should not cause a problem.
But drives are diverse enough we might find some strange bugs.
At least we have not yet found a drive that we have spin up problems with yet.
Eric
On Wed, Sep 24, 2003 at 11:00:52PM -0600, Eric W. Biederman wrote:
Right. My only other guess is that some of the lba48 support my be interacting in a strange way and causing problems. We always write the lba48 high registers but we don't set them in the lba case. It should not cause a problem.
Do you mean something like this:
==== --- ide.c.org 2003-08-26 20:53:10.000000000 +0900 +++ ide.c 2003-09-25 17:26:34.000000000 +0900 @@ -316,13 +316,15 @@ mdelay(50); } outb(cmd->feature, IDE_REG_FEATURE(ctrl)); - outb(cmd->sector_count2, IDE_REG_SECTOR_COUNT(ctrl)); + if (cmd->command == IDE_CMD_READ_SECTORS_EXT) { + outb(cmd->sector_count2, IDE_REG_SECTOR_COUNT(ctrl)); + outb(cmd->lba_low2, IDE_REG_LBA_LOW(ctrl)); + outb(cmd->lba_mid2, IDE_REG_LBA_MID(ctrl)); + outb(cmd->lba_high2, IDE_REG_LBA_HIGH(ctrl)); + } outb(cmd->sector_count, IDE_REG_SECTOR_COUNT(ctrl)); - outb(cmd->lba_low2, IDE_REG_LBA_LOW(ctrl)); outb(cmd->lba_low, IDE_REG_LBA_LOW(ctrl)); - outb(cmd->lba_mid2, IDE_REG_LBA_MID(ctrl)); outb(cmd->lba_mid, IDE_REG_LBA_MID(ctrl)); - outb(cmd->lba_high2, IDE_REG_LBA_HIGH(ctrl)); outb(cmd->lba_high, IDE_REG_LBA_HIGH(ctrl)); outb(cmd->command, IDE_REG_COMMAND(ctrl)); } ====
-- Takeshi
Eric W. Biederman wrote:
I was going to force it to use ide_read_sector_chs but did not have time.
I switched to using my CF drive and it worked fine, so I don't think it was cockpit trouble.
Right. My only other guess is that some of the lba48 support my be interacting in a strange way and causing problems. We always write the lba48 high registers but we don't set them in the lba case. It should not cause a problem.
But drives are diverse enough we might find some strange bugs.
At least we have not yet found a drive that we have spin up problems with yet.
I did some more testing. Forcing CHS mode did not help. I looked at the older LB code, and started to cut and paste some of its init code into the new code just as an experiment. So far no help.
I noticed the busy/wait loop in the original LB code looks at the error register. I also notice in the new code the pio_data_in routine does not check the error bit, matter of fact, the error bit is never checked anywhere AFAICT. Interestingly, if you check the error bit in the status register (bit 0), it is set after the pio_set_registers() command for my 1.2G WD (in pio_data_in for READ SECTOR(S) ), but not for another drive that works (7.5G WD). I looked at the ATA-2 and ATA-5 specs and the error stuff seems to have changed a little. I have not had a chance to put in code to see just where the error bit gets set, but it seems that once it is set you cannot go on without clearing it or something.
(The original LB code looks at the error register without checking the error bit in the status register. The later ATA specs seem to indicate the error register bits are not valid unless the error bit is set in the status register.)
-Steve
Steve Gehlbach steve@nexpath.com writes:
Eric W. Biederman wrote:
I was going to force it to use ide_read_sector_chs but did not have time.
I switched to using my CF drive and it worked fine, so I don't think it was cockpit trouble.
Right. My only other guess is that some of the lba48 support my be
interacting
in a strange way and causing problems. We always write the lba48 high registers but we don't set them in the lba case. It should not cause a
problem.
But drives are diverse enough we might find some strange bugs. At least we have not yet found a drive that we have spin up problems with yet.
I did some more testing. Forcing CHS mode did not help. I looked at the older LB code, and started to cut and paste some of its init code into the new code just as an experiment. So far no help.
I noticed the busy/wait loop in the original LB code looks at the error register. I also notice in the new code the pio_data_in routine does not check the error bit, matter of fact, the error bit is never checked anywhere AFAICT. Interestingly, if you check the error bit in the status register (bit 0), it is set after the pio_set_registers() command for my 1.2G WD (in pio_data_in for READ SECTOR(S) ), but not for another drive that works (7.5G WD). I looked at the ATA-2 and ATA-5 specs and the error stuff seems to have changed a little. I
have not had a chance to put in code to see just where the error bit gets set, but it seems that once it is set you cannot go on without clearing it or something.
Possibly. I believe I was not using the error bit because things were failing in other ways so I did not need the error bit, and I don't think CF drives support it.
Eric
-
Adam Agnew -
Andrew Ip -
ebiederman＠lnxi.com -
ron minnich -
SONE Takeshi -
SONE Takeshi -
Steve Gehlbach