This thread might be interesting to others. Kevin fixed CD detection for me in SeaBIOS. The timeout wasn't long enough for the drive to detect the media, so I couldn't boot a CD.
The other interesting problem I have is that when I cold boot into SeaBIOS, the drives aren't detected. If I restart the machine after this happens, it won't boot fully into Linux until I boot the factory BIOS. This doesn't happen if I stop the boot process by holding reset until the drives spin up on cold boot.
On Fri, Feb 13, 2009 at 12:11:11PM -0700, Myles Watson wrote:
Looking at the code, I noticed that the cdrom booting code doesn't
use
real timers and the ata code was recently updated to use less delays.
Yes. I had these troubles when I updated the Bochs BIOS for ADLO
before
SeaBIOS was around. The delays don't matter in the simulator, so they
get
ignored.
The latest git does a better job of timing the cdrom capacity/media sensing. Can you do a "git pull" and retry?
I can boot from CD again. There are a lot of error messages (~550 more than before), but it works. Thanks.
Great! Yeah, looks like the IDE code is responding to failures much faster than it was before. We could put an msleep() in the cdrom detect loop just to reduce the warnings, but tweaking the debugging level might be simpler.
Hrmm. If you cold boot into SeaBIOS, and then hit ctrl+alt+delete, does it detect your drives during the reboot?
I don't know. I'll try that. It doesn't work with the reset button
if I
let it go that far.
It didn't work for me that way. It still works for me to use the reset
button.
Hrmm. That's weird. Can you send a SeaBIOS log of a run where you boot up until failure, press ctrl+alt+delete, and then go to the failure again?
Sure. From what I've been able to tell, there's nothing significant there. SeaBIOS detects the drives the second time, but when Linux tries to boot it gets confused when it tries to load the SATA drivers and hangs. I don't think I was clear on that before. It could be related to the interrupt routing problems, or something that's not getting reset correctly by Coreboot.
It's symptomatically the same as booting into Linux with ACPI enabled and my broken (so far) tables. It hangs and won't boot correctly again until I boot the factory BIOS, sometimes only a cold boot with the factory BIOS works.
Thanks, Myles
On Fri, Feb 13, 2009 at 09:26:43PM -0700, Myles Watson wrote:
It didn't work for me that way. It still works for me to use the reset button.
Hrmm. That's weird. Can you send a SeaBIOS log of a run where you boot up until failure, press ctrl+alt+delete, and then go to the failure again?
Sure. From what I've been able to tell, there's nothing significant there. SeaBIOS detects the drives the second time
Oh - I was only looking to see if SeaBIOS could detect the drives the second time. Can you see if the patch below fixes the problem for you?
, but when Linux tries to boot it gets confused when it tries to load the SATA drivers and hangs. I don't think I was clear on that before. It could be related to the interrupt routing problems, or something that's not getting reset correctly by Coreboot.
On ctrl+alt+delete, coreboot isn't called. I've seen problems with SeaBIOS booting after a soft-reboot, but I don't know why. It looks like SeaBIOS is doing a full internal reset correctly..
If you send the full log, maybe it will help diagnose that problem.
-Kevin
--- a/src/ata.c +++ b/src/ata.c @@ -753,7 +753,9 @@ ata_detect() break;
// Look for device + await_not_bsy(iobase1); outb(slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0, iobase1+ATA_CB_DH); + await_not_bsy(iobase1); outb(0x55, iobase1+ATA_CB_SC); outb(0xaa, iobase1+ATA_CB_SN); outb(0xaa, iobase1+ATA_CB_SC);
On Sat, Feb 14, 2009 at 2:02 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Fri, Feb 13, 2009 at 09:26:43PM -0700, Myles Watson wrote:
It didn't work for me that way. It still works for me to use the reset button.
Hrmm. That's weird. Can you send a SeaBIOS log of a run where you boot up until failure, press ctrl+alt+delete, and then go to the failure again?
Sure. From what I've been able to tell, there's nothing significant there. SeaBIOS detects the drives the second time
Oh - I was only looking to see if SeaBIOS could detect the drives the second time. Can you see if the patch below fixes the problem for you?
, but when Linux tries to boot it gets confused when it tries to load the SATA drivers and hangs. I don't think I was clear on that before. It could be related to the interrupt routing problems, or something that's not getting reset correctly by Coreboot.
On ctrl+alt+delete, coreboot isn't called. I've seen problems with SeaBIOS booting after a soft-reboot, but I don't know why. It looks like SeaBIOS is doing a full internal reset correctly..
If you send the full log, maybe it will help diagnose that problem.
I've attached 3 logs. booted is from cold boot and was successful. ctrl-alt-del and ctrl-alt-del2 were my attempts to reboot during SeaBIOS. One time it hung the machine, the other time it didn't seem to do much. When it fails, the SeaBIOS part looks the same, but I get this at boot time, sometimes followed by kernel a panic.
[ 6.832316] ata5.00: ATAPI: _NEC DVD_RW ND-3540A, 1.01, max UDMA/33 [ 11.836055] ata5.01: qc timeout (cmd 0xf8) [ 11.840036] ata5.01: failed to read native max address (err_mask=0x4) [ 22.008055] ata5.01: qc timeout (cmd 0xf8) [ 22.012036] ata5.01: failed to read native max address (err_mask=0x4) [ 22.016034] ata5.01: revalidation failed (errno=-5) [ 32.184057] ata5.01: qc timeout (cmd 0xf8) [ 32.188036] ata5.01: failed to read native max address (err_mask=0x4) [ 32.192033] ata5.01: revalidation failed (errno=-5) [ 32.196033] ata5.01: disabled [ 32.200038] ata5.00: failed to IDENTIFY (I/O error, err_mask=0x40) [ 32.208032] ata5.00: revalidation failed (errno=-5) [ 32.376331] ata5: nv_mode_filter: 0x739f&0xfffff->0x739f, BIOS=0x0 (0x0) ACPI=0x0 [ 32.400263] ata5.00: configured for UDMA/33 [ 38.068062] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 38.072039] ata5.00: cmd a0/00:00:00:24:00/00:00:00:00:00/a0 tag 0 pio 36 in [ 38.072041] cdb 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 [ 38.072042] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 38.076033] ata5.00: status: { DRDY } [ 38.080053] ata5: soft resetting link [ 38.244318] ata5: nv_mode_filter: 0x739f&0xfffff->0x739f, BIOS=0x0 (0x0) ACPI=0x0 [ 38.264247] ata5.00: configured for UDMA/33 [ 38.268043] ata5: EH complete [ 43.768043] ata5.00: limiting speed to UDMA/25:PIO4 [ 43.772034] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 43.776036] ata5.00: cmd a0/00:00:00:24:00/00:00:00:00:00/a0 tag 0 pio 36 in [ 43.776038] cdb 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 [ 43.776039] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 43.780033] ata5.00: status: { DRDY } [ 43.784043] ata5: soft resetting link [ 43.952316] ata5: nv_mode_filter: 0x339f&0xfffff->0x339f, BIOS=0x0 (0x0) ACPI=0x0 [ 43.972246] ata5.00: configured for UDMA/25 [ 43.976035] ata5: EH complete [ 49.476041] ata5.00: limiting speed to PIO4 [ 49.480033] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 49.484036] ata5.00: cmd a0/00:00:00:24:00/00:00:00:00:00/a0 tag 0 pio 36 in [ 49.484038] cdb 12 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 [ 49.484039] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 49.488032] ata5.00: status: { DRDY }
Thanks, Myles
-Kevin
--- a/src/ata.c +++ b/src/ata.c @@ -753,7 +753,9 @@ ata_detect() break;
// Look for device
await_not_bsy(iobase1); outb(slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0, iobase1+ATA_CB_DH);await_not_bsy(iobase1); outb(0x55, iobase1+ATA_CB_SC); outb(0xaa, iobase1+ATA_CB_SN); outb(0xaa, iobase1+ATA_CB_SC);
This patch makes it wait for the controllers to initialize. It works sometimes from cold boot now!
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
During only SeaBIOS reset I see out of memory condition. Windows will not boot at all claiming bios is not ACPI 2.0 compatible.
Did not investigate any further yet.
Rudolf
On Tue, Feb 17, 2009 at 09:50:02AM -0700, Myles Watson wrote:
If you send the full log, maybe it will help diagnose that problem.
I've attached 3 logs. booted is from cold boot and was successful. ctrl-alt-del and ctrl-alt-del2 were my attempts to reboot during SeaBIOS. One time it hung the machine, the other time it didn't seem to do much. When it fails, the SeaBIOS part looks the same, but I get this at boot time, sometimes followed by kernel a panic.
[ 6.832316] ata5.00: ATAPI: _NEC DVD_RW ND-3540A, 1.01, max UDMA/33 [ 11.836055] ata5.01: qc timeout (cmd 0xf8)
What version of SeaBIOS did you try? Over the weekend, I commited f358759fb which fixed a problem with the RTC not being reset during ctrl+alt+delete. Your ctrl-alt-del2 log is similar to what I was seeing.
The other two logs look like drive failures. I suppose your drives could be getting seriously confused when SeaBIOS tries to read/write to them while they are reporting BSY. Were these failures before you applied the await_not_bsy(iobase1) patch?
// Look for device
await_not_bsy(iobase1); outb(slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0, iobase1+ATA_CB_DH);await_not_bsy(iobase1);
This patch makes it wait for the controllers to initialize. It works sometimes from cold boot now!
Does it work consistently? If it still fails sometimes I'm confused on what it could be.
-Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Tuesday, February 17, 2009 5:41 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] slow load times
On Tue, Feb 17, 2009 at 09:50:02AM -0700, Myles Watson wrote:
If you send the full log, maybe it will help diagnose that problem.
I've attached 3 logs. booted is from cold boot and was successful. ctrl-alt-del and ctrl-alt-del2 were my attempts to reboot during SeaBIOS. One time it hung the machine, the other time it didn't seem to do much. When it fails, the SeaBIOS part looks the same, but I get this at boot time, sometimes followed by kernel a panic.
[ 6.832316] ata5.00: ATAPI: _NEC DVD_RW ND-3540A, 1.01, max UDMA/33 [ 11.836055] ata5.01: qc timeout (cmd 0xf8)
What version of SeaBIOS did you try? Over the weekend, I commited f358759fb which fixed a problem with the RTC not being reset during ctrl+alt+delete. Your ctrl-alt-del2 log is similar to what I was seeing.
I didn't realize that you updated it. I'll try getting the latest.
The other two logs look like drive failures. I suppose your drives could be getting seriously confused when SeaBIOS tries to read/write to them while they are reporting BSY. Were these failures before you applied the await_not_bsy(iobase1) patch?
No, they were after.
// Look for device
await_not_bsy(iobase1); outb(slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0,iobase1+ATA_CB_DH);
await_not_bsy(iobase1);This patch makes it wait for the controllers to initialize. It works sometimes from cold boot now!
Does it work consistently? If it still fails sometimes I'm confused on what it could be.
I'm not sure either. It's strange that SeaBIOS can load grub, but the kernel is confused later. Once it gets to the confused state, the factory kernel has to be loaded. A cold reboot isn't sufficient.
Thanks, Myles
On Tue, Feb 17, 2009 at 07:51:46PM -0700, Myles Watson wrote:
Does it work consistently? If it still fails sometimes I'm confused on what it could be.
I'm not sure either. It's strange that SeaBIOS can load grub, but the kernel is confused later. Once it gets to the confused state, the factory kernel has to be loaded. A cold reboot isn't sufficient.
Hrmm. So SeaBIOS can consistently see the drives, but Linux can't?
One more thing you can try - pull the latest SeaBIOS git and apply the patch below. This will dump all of the drive's identify information.
-Kevin
--- a/src/ata.c +++ b/src/ata.c @@ -615,7 +615,7 @@ setup_translation(int driveid) static void extract_identify(int driveid, u16 *buffer) { - dprintf(3, "Identify w0=%x w2=%x\n", buffer[0], buffer[2]); + hexdump(buffer, 512);
// Read model name char *model = ATA.devices[driveid].model; @@ -753,7 +753,9 @@ ata_detect() break;
// Look for device + await_not_bsy(iobase1); outb(slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0, iobase1+ATA_CB_DH); + await_not_bsy(iobase1); outb(0x55, iobase1+ATA_CB_SC); outb(0xaa, iobase1+ATA_CB_SN); outb(0xaa, iobase1+ATA_CB_SC);
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Tuesday, February 17, 2009 9:23 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] slow load times
On Tue, Feb 17, 2009 at 07:51:46PM -0700, Myles Watson wrote:
Does it work consistently? If it still fails sometimes I'm confused on what it could be.
I'm not sure either. It's strange that SeaBIOS can load grub, but the kernel is confused later. Once it gets to the confused state, the
factory
kernel has to be loaded. A cold reboot isn't sufficient.
Hrmm. So SeaBIOS can consistently see the drives, but Linux can't?
I haven't dug into the driver enough to know the real answer. Linux can read things from the drive, modules get loaded, but it gets stuck continually trying to reset the drive when that driver is loaded. It may have something to do with a mode switch.
One more thing you can try - pull the latest SeaBIOS git and apply the patch below. This will dump all of the drive's identify information.
Sure. I expect that to be fine, since it seems fine when SeaBIOS comes up and reports the drives it finds, but no harm trying.
Thanks, Myles
-Kevin
--- a/src/ata.c +++ b/src/ata.c @@ -615,7 +615,7 @@ setup_translation(int driveid) static void extract_identify(int driveid, u16 *buffer) {
- dprintf(3, "Identify w0=%x w2=%x\n", buffer[0], buffer[2]);
hexdump(buffer, 512);
// Read model name char *model = ATA.devices[driveid].model;
@@ -753,7 +753,9 @@ ata_detect() break;
// Look for device
await_not_bsy(iobase1); outb(slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0, iobase1+ATA_CB_DH);await_not_bsy(iobase1); outb(0x55, iobase1+ATA_CB_SC); outb(0xaa, iobase1+ATA_CB_SN); outb(0xaa, iobase1+ATA_CB_SC);
On Tue, Feb 17, 2009 at 09:50:02AM -0700, Myles Watson wrote:
On Sat, Feb 14, 2009 at 2:02 AM, Kevin O'Connor kevin@koconnor.net wrote:
If you send the full log, maybe it will help diagnose that problem.
I've attached 3 logs.
Looking a little closer at the logs..
[...]
Wrote the mp table end at: 00000020 - 0000065c Wrote the mp table end at: 7fff0c10 - 7fff124c move mptable from 0x20 to 0xf0c00, size 0x63c
This looks like it is putting multiple mptables in ram. I'd advise against that - it's okay to put it in 0xf0000 and 0x7fff0000, but you don't want it also at 0x20.
[...]
Copying PIR from 7fff0000 to 000f9d90 Copying ACPI RSDP from 7fff0400 to 000f9de0 Copying MPTABLE from 7fff0c00 to 000f9e00
[...]
Copying PIR from 000f9d90 to 000f9d90 Copying ACPI RSDP from 000f9de0 to 000f9de0 Copying MPTABLE from 000f9e00 to 000f9e00 Copying MPTABLE from 7fff0c00 to 000f9e10
Okay - that's wrong. Latest SeaBIOS git should fix that.
[...]
Scan for VGA option rom Running option rom at 0000c000:00000003 Turning on vga console
[...]
Scan for VGA option rom Found option rom with bad checksum: loc=000c0000 len=60928 sum=000000ff
On reboots, the VGA rom isn't being reset - this will be a problem. I recommend having SeaBIOS do the rom copying - modify SeaBIOS' config.h and set:
#define CONFIG_OPTIONROMS_DEPLOYED 0
If you have to include a vgabios in the rom, then also set something like:
#define OPTIONROM_BDF_1 pci_to_bdf(0x02, 0x00, 0) // pci 02:00.0 #define OPTIONROM_MEM_1 0xfffc0000 // rom address of option rom
-Kevin
Kevin O'Connor wrote:
I recommend having SeaBIOS do the rom copying - modify SeaBIOS' config.h and set:
#define CONFIG_OPTIONROMS_DEPLOYED 0
If you have to include a vgabios in the rom, then also set something like:
#define OPTIONROM_BDF_1 pci_to_bdf(0x02, 0x00, 0) // pci 02:00.0 #define OPTIONROM_MEM_1 0xfffc0000 // rom address of option rom
It would be awesome if these things could be controlled by a tool after build time.
//Peter
On Wed, Feb 18, 2009 at 12:00:52PM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
I recommend having SeaBIOS do the rom copying - modify SeaBIOS' config.h and set:
#define CONFIG_OPTIONROMS_DEPLOYED 0
If you have to include a vgabios in the rom, then also set something like:
#define OPTIONROM_BDF_1 pci_to_bdf(0x02, 0x00, 0) // pci 02:00.0 #define OPTIONROM_MEM_1 0xfffc0000 // rom address of option rom
It would be awesome if these things could be controlled by a tool after build time.
I'd really like to see further use of the LAR format. With a LAR, SeaBIOS could just scan for the option roms itself.
-Kevin
On Wed, Feb 18, 2009 at 5:47 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Wed, Feb 18, 2009 at 12:00:52PM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
I recommend having SeaBIOS do the rom copying - modify SeaBIOS' config.h and set:
#define CONFIG_OPTIONROMS_DEPLOYED 0
If you have to include a vgabios in the rom, then also set something like:
#define OPTIONROM_BDF_1 pci_to_bdf(0x02, 0x00, 0) // pci 02:00.0 #define OPTIONROM_MEM_1 0xfffc0000 // rom address of option rom
It would be awesome if these things could be controlled by a tool after build time.
I'd really like to see further use of the LAR format. With a LAR, SeaBIOS could just scan for the option roms itself.
yes, that's what we do in v3; use the lar for this type of thing.
Usually, over-reliance on cpp magic is a warning signal.
ron
Kevin O'Connor wrote:
#define OPTIONROM_BDF_1 pci_to_bdf(0x02, 0x00, 0) // pci 02:00.0 #define OPTIONROM_MEM_1 0xfffc0000 // rom address of option rom
It would be awesome if these things could be controlled by a tool after build time.
I'd really like to see further use of the LAR format. With a LAR, SeaBIOS could just scan for the option roms itself.
Me too, but I don't think we'll ever use LAR for v2, which is what SeaBIOS is probably used the most with at this point.
//Peter
On Tue, Feb 17, 2009 at 9:16 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Tue, Feb 17, 2009 at 09:50:02AM -0700, Myles Watson wrote:
On Sat, Feb 14, 2009 at 2:02 AM, Kevin O'Connor kevin@koconnor.net wrote:
If you send the full log, maybe it will help diagnose that problem.
I've attached 3 logs.
Looking a little closer at the logs..
[...]
Wrote the mp table end at: 00000020 - 0000065c Wrote the mp table end at: 7fff0c10 - 7fff124c move mptable from 0x20 to 0xf0c00, size 0x63c
This looks like it is putting multiple mptables in ram. I'd advise against that - it's okay to put it in 0xf0000 and 0x7fff0000, but you don't want it also at 0x20.
That looked funny to me too. I set HAVE_LOW_TABLES=0.
[...]
Copying PIR from 7fff0000 to 000f9d90 Copying ACPI RSDP from 7fff0400 to 000f9de0 Copying MPTABLE from 7fff0c00 to 000f9e00
[...]
Copying PIR from 000f9d90 to 000f9d90 Copying ACPI RSDP from 000f9de0 to 000f9de0 Copying MPTABLE from 000f9e00 to 000f9e00 Copying MPTABLE from 7fff0c00 to 000f9e10
Okay - that's wrong. Latest SeaBIOS git should fix that.
[...]
Scan for VGA option rom Running option rom at 0000c000:00000003 Turning on vga console
[...]
Scan for VGA option rom Found option rom with bad checksum: loc=000c0000 len=60928 sum=000000ff
On reboots, the VGA rom isn't being reset - this will be a problem. I recommend having SeaBIOS do the rom copying - modify SeaBIOS' config.h and set:
#define CONFIG_OPTIONROMS_DEPLOYED 0
I've done that. SeaBIOS doesn't find my SATA card because it's plugged into a slot that's not reachable from bus 0. Have you thought about multiple root buses?
I've attached the latest log. I reset it and it looks like it reinitializes the VGA, copies the tables correctly, etc.
Thanks, Myles
On Wed, Feb 18, 2009 at 09:43:04AM -0700, Myles Watson wrote:
On Tue, Feb 17, 2009 at 9:16 PM, Kevin O'Connor kevin@koconnor.net wrote:
On reboots, the VGA rom isn't being reset - this will be a problem. I recommend having SeaBIOS do the rom copying - modify SeaBIOS' config.h and set:
#define CONFIG_OPTIONROMS_DEPLOYED 0
I've done that. SeaBIOS doesn't find my SATA card because it's plugged into a slot that's not reachable from bus 0. Have you thought about multiple root buses?
I programmed the SeaBIOS PCI code based on the suggestions I received by other coreboot developers. It scans at least bus 0, and it also extends its search should it find any bridge or cardbus devices. It was my understanding that coreboot, filo, and libpayload were doing something similar.
The current code is in src/pci.h in the foreachpci macro and in src/pci.c in the pci_next() function. If there is a better way to scan, please let me know.
I've attached the latest log. I reset it and it looks like it reinitializes the VGA, copies the tables correctly, etc.
So, is it working now?
-Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Wednesday, February 18, 2009 6:04 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] slow load times
On Wed, Feb 18, 2009 at 09:43:04AM -0700, Myles Watson wrote:
On Tue, Feb 17, 2009 at 9:16 PM, Kevin O'Connor kevin@koconnor.net
wrote:
On reboots, the VGA rom isn't being reset - this will be a problem. I recommend having SeaBIOS do the rom copying - modify SeaBIOS' config.h and set:
#define CONFIG_OPTIONROMS_DEPLOYED 0
Maybe we should modify buildrom so that this is the default when using SeaBIOS.
I've done that. SeaBIOS doesn't find my SATA card because it's plugged into a slot that's not reachable from bus 0. Have you thought about multiple root buses?
I programmed the SeaBIOS PCI code based on the suggestions I received by other coreboot developers. It scans at least bus 0, and it also extends its search should it find any bridge or cardbus devices. It was my understanding that coreboot, filo, and libpayload were doing something similar.
I'm not complaining. It's just the next feature request :)
The current code is in src/pci.h in the foreachpci macro and in src/pci.c in the pci_next() function. If there is a better way to scan, please let me know.
It's a fine way to scan. The problem is that there is no logical connection from bus 0 to bus 0x40 on my machine. It happens because there are multiple links on the Opterons. For desktop machines, many times there is only one link that goes to the chipset, but servers and workstations sometimes have more.
Without Opteron-specific code or ACPI I don't know how you could do it. I was just wondering if you'd thought about it.
I guess you could
#define PCI_ROOT_1 PCI_BDF(Bus,Dev,FN) #define PCI_ROOT_2 PCI_BDF(Bus,Dev,FN)
and use them if they're non-zero.
I've attached the latest log. I reset it and it looks like it reinitializes the VGA, copies the tables correctly, etc.
So, is it working now?
I'm still having ACPI troubles, so I'm not booting into Windows yet. That's where I'm trying to get. At this point it's not SeaBIOS's fault, though. So yes, as far as I can tell right now it's working perfectly. Thanks for all the help.
Thanks, Myles
On Wed, Feb 18, 2009 at 07:51:33PM -0700, Myles Watson wrote:
#define CONFIG_OPTIONROMS_DEPLOYED 0
Maybe we should modify buildrom so that this is the default when using SeaBIOS.
I think we should.
The current code is in src/pci.h in the foreachpci macro and in src/pci.c in the pci_next() function. If there is a better way to scan, please let me know.
It's a fine way to scan. The problem is that there is no logical connection from bus 0 to bus 0x40 on my machine. It happens because there are multiple links on the Opterons. For desktop machines, many times there is only one link that goes to the chipset, but servers and workstations sometimes have more.
Well, that's a pain. I'm surprised they didn't just put a dummy bridge entry on bus 0 that points to bus 0x40 -- it'd make scanning easier.
You could change the pciforeach macro from:
for (MAX=0x0100, BDF=pci_next(0, &MAX) \
to:
for (MAX=0x4000, BDF=pci_next(0, &MAX) \
that would cause it to pull in your second bridge. It will do a bit more scanning, but that may be inevitable.
So, is it working now?
I'm still having ACPI troubles, so I'm not booting into Windows yet. That's where I'm trying to get. At this point it's not SeaBIOS's fault, though. So yes, as far as I can tell right now it's working perfectly. Thanks for all the help.
No problem - I'm glad you're making progress. :-)
-Kevin
On Wed, Feb 18, 2009 at 10:30:38PM -0500, Kevin O'Connor wrote:
You could change the pciforeach macro from:
for (MAX=0x0100, BDF=pci_next(0, &MAX) \to:
for (MAX=0x4000, BDF=pci_next(0, &MAX) \
that should read:
for (MAX=0x4100, BDF=pci_next(0, &MAX) \
-Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Wednesday, February 18, 2009 8:31 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] slow load times
On Wed, Feb 18, 2009 at 07:51:33PM -0700, Myles Watson wrote:
#define CONFIG_OPTIONROMS_DEPLOYED 0
Maybe we should modify buildrom so that this is the default when using SeaBIOS.
I think we should.
The current code is in src/pci.h in the foreachpci macro and in src/pci.c in the pci_next() function. If there is a better way to scan, please let me know.
It's a fine way to scan. The problem is that there is no logical
connection
from bus 0 to bus 0x40 on my machine. It happens because there are
multiple
links on the Opterons. For desktop machines, many times there is only
one
link that goes to the chipset, but servers and workstations sometimes
have
more.
Well, that's a pain.
Yes.
I'm surprised they didn't just put a dummy bridge entry on bus 0 that points to bus 0x40 -- it'd make scanning easier.
Part of the problem is that some of the buses are there only when the second Opteron is installed. Nothing can be simple :)
You can read the Opteron's registers to know which other buses there are, and the Opterons are always on bus 0. It's just not a general solution.
You could change the pciforeach macro from:
for (MAX=0x0100, BDF=pci_next(0, &MAX) \to:
for (MAX=0x4000, BDF=pci_next(0, &MAX) \
For my own use I can hard code something pretty easily. The general case is much harder.
Thanks, Myles
On Wed, Feb 18, 2009 at 08:42:04PM -0700, Myles Watson wrote:
for (MAX=0x4000, BDF=pci_next(0, &MAX) \For my own use I can hard code something pretty easily. The general case is much harder.
We can add a CONFIG_PCI_MAX_ROOT_BUS setting to SeaBIOS' config.h file.
If we don't want to compile in a max, and it's not reasonable to autodetect it, then I guess we could have coreboot pass in the max to SeaBIOS via the coreboot table.
Finally, I suppose SeaBIOS could just scan all 256 buses. (Does anyone know if a bus is guaranteed to have a device 0? If so, that would speed the scan significantly.)
-Kevin
If we don't want to compile in a max, and it's not reasonable to autodetect it, then I guess we could have coreboot pass in the max to SeaBIOS via the coreboot table.
I like the PCI roots better. It seems like there will always be a small number of root buses.
Finally, I suppose SeaBIOS could just scan all 256 buses. (Does anyone know if a bus is guaranteed to have a device 0? If so, that would speed the scan significantly.)
The AMD Serengeti board doesn't. The 8111 has a base device number of 6.
Thanks, Myles
On Wed, Feb 18, 2009 at 09:47:29PM -0700, Myles Watson wrote:
Finally, I suppose SeaBIOS could just scan all 256 buses. (Does anyone know if a bus is guaranteed to have a device 0? If so, that would speed the scan significantly.)
The AMD Serengeti board doesn't. The 8111 has a base device number of 6.
<grasp straw> Any idea if "root buses" will always have a device 0? (That is, if SeaBIOS did its normal bridge/cardbus detection, could it find all the remaining root buses by just scanning for device 0s?)
-Kevin
<grasp straw> Any idea if "root buses" will always have a device 0?
Not always imho. Btw what about to look to MP-table for another busses? If we agree that coreboot will always provide the table, it can be just used for this...
Also there is some special entries for multiple busses
4.4 Extended MP Configuration Table Entries
Rudolf
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Thursday, February 19, 2009 6:36 AM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] slow load times
On Wed, Feb 18, 2009 at 09:47:29PM -0700, Myles Watson wrote:
Finally, I suppose SeaBIOS could just scan all 256 buses. (Does anyone know if a bus is guaranteed to have a device 0? If so, that would speed the scan significantly.)
The AMD Serengeti board doesn't. The 8111 has a base device number of
<grasp straw>
:)
Any idea if "root buses" will always have a device 0? (That is, if SeaBIOS did its normal bridge/cardbus detection, could it find all the remaining root buses by just scanning for device 0s?)
No. In this case, the 8111 is the first device on bus 0, bus 0x40, or whatever bus it's on. The Opteron provides the root bus, and it is always reachable, but besides reading from the Opteron's registers...
Thanks, Myles
On Thu, Feb 19, 2009 at 9:02 AM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Thursday, February 19, 2009 6:36 AM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] slow load times
On Wed, Feb 18, 2009 at 09:47:29PM -0700, Myles Watson wrote:
Finally, I suppose SeaBIOS could just scan all 256 buses. (Does anyone know if a bus is guaranteed to have a device 0? If so, that would speed the scan significantly.)
The AMD Serengeti board doesn't. The 8111 has a base device number of
<grasp straw>
:)
Any idea if "root buses" will always have a device 0? (That is, if SeaBIOS did its normal bridge/cardbus detection, could it find all the remaining root buses by just scanning for device 0s?)
No. In this case, the 8111 is the first device on bus 0, bus 0x40, or whatever bus it's on. The Opteron provides the root bus, and it is always reachable, but besides reading from the Opteron's registers...
For the benefit of searchers, this patch is for SeaBIOS for multiple root PCI buses.
Until there's a better solution, this one works for me. My SATA card initializes correctly.
The patch makes pci_next jump to the next root when it would have been done scanning if there are more roots defined. If you set them to 0, there is no change in functionality.
Thanks, Myles
On Mon, Feb 23, 2009 at 02:00:32PM -0700, Myles Watson wrote:
For the benefit of searchers, this patch is for SeaBIOS for multiple root PCI buses.
Until there's a better solution, this one works for me. My SATA card initializes correctly.
The patch makes pci_next jump to the next root when it would have been done scanning if there are more roots defined. If you set them to 0, there is no change in functionality.
Hi Myles,
I'm okay with commiting this to SeaBIOS as long as it is disabled by default. Is it okay if I commit this?
-Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Friday, February 27, 2009 6:36 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] slow load times
On Mon, Feb 23, 2009 at 02:00:32PM -0700, Myles Watson wrote:
For the benefit of searchers, this patch is for SeaBIOS for multiple root PCI buses.
Until there's a better solution, this one works for me. My SATA card initializes correctly.
The patch makes pci_next jump to the next root when it would have been done scanning if there are more roots defined. If you set them to 0, there is no change in functionality.
Hi Myles,
I'm okay with commiting this to SeaBIOS as long as it is disabled by default. Is it okay if I commit this?
Sure. It's been working for me so far :)
Thanks, Myles
On Sat, Feb 28, 2009 at 08:58:30AM -0700, Myles Watson wrote:
I'm okay with commiting this to SeaBIOS as long as it is disabled by default. Is it okay if I commit this?
Sure. It's been working for me so far :)
I committed a patch based on your work. (I did make a few changes.) Let me know if it works on your machine.
Thanks, -Kevin
On Sat, Feb 28, 2009 at 10:39 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Sat, Feb 28, 2009 at 08:58:30AM -0700, Myles Watson wrote:
I'm okay with commiting this to SeaBIOS as long as it is disabled by default. Is it okay if I commit this?
Sure. It's been working for me so far :)
I committed a patch based on your work. (I did make a few changes.) Let me know if it works on your machine.
Good idea to make it a bus number instead of a BDF. It still works.
Thanks, Myles
Kevin O'Connor wrote:
On Wed, Feb 18, 2009 at 08:42:04PM -0700, Myles Watson wrote:
for (MAX=0x4000, BDF=pci_next(0, &MAX) \For my own use I can hard code something pretty easily. The general case is much harder.
We can add a CONFIG_PCI_MAX_ROOT_BUS setting to SeaBIOS' config.h file.
If we don't want to compile in a max, and it's not reasonable to autodetect it, then I guess we could have coreboot pass in the max to SeaBIOS via the coreboot table.
Maybe coreboot should pass its complete device tree in the coreboot table, so SeaBIOS and others can do more queries if needed? (And, for example, scan the buses that are known to exist instead of just going for a max.)
Finally, I suppose SeaBIOS could just scan all 256 buses. (Does anyone know if a bus is guaranteed to have a device 0? If so, that would speed the scan significantly.)
I think to remember the PCI specification suggests so. In practice I have seen many cards, bridges, systems where this is not the case though.
Stefan
On Thu, Feb 19, 2009 at 12:32:31PM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
If we don't want to compile in a max, and it's not reasonable to autodetect it, then I guess we could have coreboot pass in the max to SeaBIOS via the coreboot table.
Maybe coreboot should pass its complete device tree in the coreboot table, so SeaBIOS and others can do more queries if needed? (And, for example, scan the buses that are known to exist instead of just going for a max.)
What makes this interesting for SeaBIOS is that it needs to support non-coreboot environments as well. (Further, on qemu/kvm/bochs, SeaBIOS can't write to global variables until it unlocks the f-segment, and it needs to do a pci scan to unlock the f-segment.)
I'd prefer not to have two different sets of pci scanning code - one for coreboot and one for the emulators. That is why I've been hoping a simple optimization (like max bus) could be found - something that can easily work in both environments.
That aside, I do like the idea of coreboot publishing more info. I think Peter is a fan of the PPC Linux "device tree" format.
-Kevin
On Fri, Feb 13, 2009 at 8:26 PM, Myles Watson mylesgw@gmail.com wrote:
The other interesting problem I have is that when I cold boot into SeaBIOS, the drives aren't detected. If I restart the machine after this happens, it won't boot fully into Linux until I boot the factory BIOS. This doesn't happen if I stop the boot process by holding reset until the drives spin up on cold boot.
Isn't this the classic problem where coreboot/seabios are ready before the drives are? If so it's a 10 year old problem, which we have fixed several times in other places. I note kevin now has a fix in :-)
ron
On Sun, Feb 15, 2009 at 02:39:14PM -0800, ron minnich wrote:
On Fri, Feb 13, 2009 at 8:26 PM, Myles Watson mylesgw@gmail.com wrote:
The other interesting problem I have is that when I cold boot into SeaBIOS, the drives aren't detected. If I restart the machine after this happens, it won't boot fully into Linux until I boot the factory BIOS. This doesn't happen if I stop the boot process by holding reset until the drives spin up on cold boot.
Isn't this the classic problem where coreboot/seabios are ready before the drives are?
I think so.
If so it's a 10 year old problem, which we have fixed several times in other places. I note kevin now has a fix in :-)
I haven't fixed it yet. The patch in my previous email was just to confirm if the above is Myles' issue.
Looks like SeaBIOS should wait for the drive to be !BSY before testing the registers - the only problem is if BSY is set on a non-existent drive. That would cause SeaBIOS to wait until a timeout (30 seconds). The filo code seems to suggest a straight forward solution - wait for !BSY, but only if status is not 0xff.
-Kevin
On Sun, Feb 15, 2009 at 3:39 PM, ron minnich rminnich@gmail.com wrote:
On Fri, Feb 13, 2009 at 8:26 PM, Myles Watson mylesgw@gmail.com wrote:
The other interesting problem I have is that when I cold boot into SeaBIOS, the drives aren't detected. If I restart the machine after this happens, it won't boot fully into Linux until I boot the factory BIOS. This doesn't happen if I stop the boot process by holding reset until the drives spin up on cold boot.
Isn't this the classic problem where coreboot/seabios are ready before the drives are? If so it's a 10 year old problem, which we have fixed several times in other places. I note kevin now has a fix in :-)
Yes. The interesting part was that Linux won't boot when reset after a failure. I was wondering what was getting misconfigured. It's strange for grub to be able to load the kernel, but then not have the kernel be able to configure the drives.
Thanks, Myles
-
Kevin O'Connor -
Myles Watson -
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer