I've been experimenting with SeaBIOS, and I like what I'm seeing a lot. Great work Kevin!
I think I found one bug, and I have a feature request.
Feature request: I'd really like a serial console for SeaBIOS. I 'd like serial to just mirror the VGA console so that either could be used for viewing and input. Right now, it seems only sending debug output to the console is supported.
Bug: I have grub configured to pause 5 seconds while giving the user to select either serial or VGA console for input. This is done with these lines in menu.lst:
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console
This does not appear to go over well. The symptoms I see are:
a) the 'Press any key to continue' is only printed on the VGA console, not on serial b) it takes way more than 1 second between the 'Press any key to continue' lines - presumably because writing to serial is somehow failing c) while this is happening, keyboard nor serial console input works
If I press enough keys before I get to grub and/or during this serial/console detection, I can sometimes get it to show the menu on the VGA console (it defaults to serial). If I get to that point, the keyboard usually works just fine.
Also, the keyboard works fine before I get to grub, but it's hard to catch the F12 keypress as everything goes pretty fast.
I've tried with and without CONFIG_DEBUG_SERIAL set in src/config.h. It does not seem to make a difference. CONFIG_SERIAL is set to 1.
Suggestions?
Thanks, Ward.
On Wed, Apr 29, 2009 at 03:10:23PM -0400, Ward Vandewege wrote:
I've been experimenting with SeaBIOS, and I like what I'm seeing a lot. Great work Kevin!
Thanks!
Feature request: I'd really like a serial console for SeaBIOS. I 'd like serial to just mirror the VGA console so that either could be used for viewing and input. Right now, it seems only sending debug output to the console is supported.
I think you're looking for sgabios: http://code.google.com/p/sgabios/
It's a bit of a hack to launch both it and a vga bios with SeaBIOS. Add sgabios.bin to the CBFS system using a PCI vendor:device of a device in your system that doesn't already have an option rom and isn't a vga or ide device. This will cause SeaBIOS to load your vgabios first and then load sgabios after it.
I tested this on qemu by doing:
./cbfstool ./coreboot.rom add ../sgabios/sgabios.bin pci8086,7113.rom
(8086:7113 is just a random qemu device - the acpi bridge.)
Bug: I have grub configured to pause 5 seconds while giving the user to select either serial or VGA console for input. This is done with these lines in menu.lst:
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console
The only thing I can think of is that SeaBIOS may be setting the serial port settings to something that grub doesn't like. You can try disabling the code in debug_serial_setup() in src/output.c. However, if you've already tried disabling CONFIG_DEBUG_SERIAL, then I don't think this will do much. It could be a conflict with coreboot serial setup and grub I suppose.
Also, the keyboard works fine before I get to grub, but it's hard to catch the F12 keypress as everything goes pretty fast.
Latest SeaBIOS git has an option CONFIG_BOOTMENU_WAIT that you can use to change the menu wait time (default is 2.5 seconds).
I've tried with and without CONFIG_DEBUG_SERIAL set in src/config.h. It does not seem to make a difference. CONFIG_SERIAL is set to 1.
I don't think CONFIG_SERIAL (which control support for old bios int 0x14 calls) is related to this issue.
-Kevin
On Wed, Apr 29, 2009 at 10:08:22PM -0400, Kevin O'Connor wrote:
On Wed, Apr 29, 2009 at 03:10:23PM -0400, Ward Vandewege wrote:
I've been experimenting with SeaBIOS, and I like what I'm seeing a lot. Great work Kevin!
Thanks!
Feature request: I'd really like a serial console for SeaBIOS. I 'd like serial to just mirror the VGA console so that either could be used for viewing and input. Right now, it seems only sending debug output to the console is supported.
I think you're looking for sgabios: http://code.google.com/p/sgabios/
It's a bit of a hack to launch both it and a vga bios with SeaBIOS. Add sgabios.bin to the CBFS system using a PCI vendor:device of a device in your system that doesn't already have an option rom and isn't a vga or ide device. This will cause SeaBIOS to load your vgabios first and then load sgabios after it.
I tested this on qemu by doing:
./cbfstool ./coreboot.rom add ../sgabios/sgabios.bin pci8086,7113.rom
(8086:7113 is just a random qemu device - the acpi bridge.)
I tried exactly that today (gmta ;), but that didn't seem to work for me - and SeaBIOS complained about an option rom checksum mismatch on the sgabios.bin option rom.
Since every other component in the boot process already does serial - how hard would it be to make SeaBIOS do serial too?
Bug: I have grub configured to pause 5 seconds while giving the user to select either serial or VGA console for input. This is done with these lines in menu.lst:
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console
The only thing I can think of is that SeaBIOS may be setting the serial port settings to something that grub doesn't like. You can try disabling the code in debug_serial_setup() in src/output.c. However, if you've already tried disabling CONFIG_DEBUG_SERIAL, then I don't think this will do much. It could be a conflict with coreboot serial setup and grub I suppose.
Hmm. Suggestions for debugging?
Also, the keyboard works fine before I get to grub, but it's hard to catch the F12 keypress as everything goes pretty fast.
Latest SeaBIOS git has an option CONFIG_BOOTMENU_WAIT that you can use to change the menu wait time (default is 2.5 seconds).
Cool.
I've tried with and without CONFIG_DEBUG_SERIAL set in src/config.h. It does not seem to make a difference. CONFIG_SERIAL is set to 1.
I don't think CONFIG_SERIAL (which control support for old bios int 0x14 calls) is related to this issue.
OK.
Thanks, Ward.
Kevin O'Connor wrote:
Add sgabios.bin to the CBFS system using a PCI vendor:device of a device in your system that doesn't already have an option rom and isn't a vga or ide device.
I think it's important to improve this situation. The PCI ids are clearly not relevant to this option ROM, so we should not require them.
I don't know how to fix it though. Does anyone have an idea?
//Peter
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Thursday, April 30, 2009 3:15 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Random extra option ROMs in CBFS
Kevin O'Connor wrote:
Add sgabios.bin to the CBFS system using a PCI vendor:device of a device in your system that doesn't already have an option rom and isn't a vga or ide device.
I think it's important to improve this situation. The PCI ids are clearly not relevant to this option ROM, so we should not require them.
I don't know how to fix it though. Does anyone have an idea?
Kevin already added an img/ path for payloads. I guess he could add a path for ROM-style images (ones that will return.) They'd have to be numbered so that they were executed in order, but that doesn't seem like too much of a problem.
Thanks, Myles
Myles Watson wrote:
I don't know how to fix it though. Does anyone have an idea?
Kevin already added an img/ path for payloads. I guess he could add a path for ROM-style images (ones that will return.) They'd have to be numbered so that they were executed in order, but that doesn't seem like too much of a problem.
I think that's a great idea!
//Peter
On Thu, Apr 30, 2009 at 02:37:14PM +0200, Peter Stuge wrote:
Myles Watson wrote:
I don't know how to fix it though. Does anyone have an idea?
Kevin already added an img/ path for payloads. I guess he could add a path for ROM-style images (ones that will return.) They'd have to be numbered so that they were executed in order, but that doesn't seem like too much of a problem.
I think that's a great idea!
Yeah, same here!
Thanks, Ward.
On 30.04.2009 15:29 Uhr, Ward Vandewege wrote:
On Thu, Apr 30, 2009 at 02:37:14PM +0200, Peter Stuge wrote:
Myles Watson wrote:
I don't know how to fix it though. Does anyone have an idea?
Kevin already added an img/ path for payloads. I guess he could add a path for ROM-style images (ones that will return.) They'd have to be numbered so that they were executed in order, but that doesn't seem like too much of a problem.
I think that's a great idea!
Yeah, same here!
With all the infrastructure in the CBFS format, I think encoding duplicate information in the file names is not an appropriate approach. Instead the existing infrastructure should be used.
Stefan
On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 30.04.2009 15:29 Uhr, Ward Vandewege wrote:
On Thu, Apr 30, 2009 at 02:37:14PM +0200, Peter Stuge wrote:
Myles Watson wrote:
I don't know how to fix it though. Does anyone have an idea?
Kevin already added an img/ path for payloads. I guess he could add a path for ROM-style images (ones that will return.) They'd have to be numbered so that they were executed in order, but that doesn't seem like too much of a problem.
I think that's a great idea!
Yeah, same here!
With all the infrastructure in the CBFS format, I think encoding duplicate information in the file names is not an appropriate approach. Instead the existing infrastructure should be used.
Care to elaborate? I don't see ordering information or whether the ROM returns in CBFS.
Thanks, Myles
Am 30.04.2009 16:03, schrieb Myles Watson:
On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauerstepan@coresystems.de wrote:
With all the infrastructure in the CBFS format, I think encoding duplicate information in the file names is not an appropriate approach. Instead the existing infrastructure should be used.
Care to elaborate? I don't see ordering information or whether the ROM returns in CBFS.
Option Rom support is, for now, incomplete (eg. no subheader). The subheader will contain at least a compression flag and vid/did fields (for faster lookup, and to free the name field for more useful purposes, eg. keeping the vendor filename which includes a version number). We could add an order field there, or pick an invalid vendor ID (0x0000 and 0xffff seem to be free, and esp. the latter likely won't be used at all, as it looks like a read in empty I/O space) and order them by device ID. coreboot or the payload would iterate PCI, then run through the device ids (with did=0 being executed first).
CBFS has rich metadata for its objects. If we don't use it, and stuff everything in the filename, we could as well use ar(1) and the system's tools (with all the trouble that brings, eg. with slightly incompatible lzma implementations and the like), and spare us the trouble of maintaining our own tool.
We're not on unix. Not everything is a file for coreboot (neither for unix, but that's a different discussions).
Patrick
On Thu, Apr 30, 2009 at 8:23 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
Am 30.04.2009 16:03, schrieb Myles Watson:
On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauerstepan@coresystems.de  wrote:
With all the infrastructure in the CBFS format, I think encoding duplicate information in the file names is not an appropriate approach. Instead the existing infrastructure should be used.
Care to elaborate? Â I don't see ordering information or whether the ROM returns in CBFS.
Option Rom support is, for now, incomplete (eg. no subheader). The subheader will contain at least a compression flag and vid/did fields (for faster lookup, and to free the name field for more useful purposes, eg. keeping the vendor filename which includes a version number). We could add an order field there, or pick an invalid vendor ID (0x0000 and 0xffff seem to be free, and esp. the latter likely won't be used at all, as it looks like a read in empty I/O space) and order them by device ID. coreboot or the payload would iterate PCI, then run through the device ids (with did=0 being executed first).
CBFS has rich metadata for its objects. If we don't use it, and stuff everything in the filename, we could as well use ar(1) and the system's tools (with all the trouble that brings, eg. with slightly incompatible lzma implementations and the like), and spare us the trouble of maintaining our own tool.
I think this is overkill. I think file names are intuitive and obvious. Just because there are problems with using system tools doesn't mean we should create new problems.
Adding special support to the Option ROM header for extra drivers that are not option ROMs is ugly.
Thanks, Myles
On Wed, Apr 29, 2009 at 11:04:32PM -0400, Ward Vandewege wrote:
I tried exactly that today (gmta ;), but that didn't seem to work for me - and SeaBIOS complained about an option rom checksum mismatch on the sgabios.bin option rom.
That's odd - it works fine for me. Can you confirm the sgabios build and then forward me the SeaBIOS log with it in CBFS?
Since every other component in the boot process already does serial - how hard would it be to make SeaBIOS do serial too?
Well, SeaBIOS does support serial. What you're looking for is the ability to forward vgabios requests over serial. SeaBIOS doesn't have any vgabios capabilities today, so it would be a bit of work. Since sgabios is already designed to do this, I'm not sure what the value would be in duplicating it in SeaBIOS.
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console
The only thing I can think of is that SeaBIOS may be setting the serial port settings to something that grub doesn't like. You can try disabling the code in debug_serial_setup() in src/output.c. However, if you've already tried disabling CONFIG_DEBUG_SERIAL, then I don't think this will do much. It could be a conflict with coreboot serial setup and grub I suppose.
Hmm. Suggestions for debugging?
You could try disabling serial in both coreboot and seabios. It seems like a "long shot" though.
You could change grub to dump the serial registers and then run it from both the proprietary bios and from coreboot/seabios - just to see if there is a serial port difference.
Maybe there is a debugging mode of grub that you could activate?
-Kevin
On Thu, Apr 30, 2009 at 09:00:59PM -0400, Kevin O'Connor wrote:
On Wed, Apr 29, 2009 at 11:04:32PM -0400, Ward Vandewege wrote:
I tried exactly that today (gmta ;), but that didn't seem to work for me - and SeaBIOS complained about an option rom checksum mismatch on the sgabios.bin option rom.
That's odd - it works fine for me. Can you confirm the sgabios build and then forward me the SeaBIOS log with it in CBFS?
Will do tomorrow.
Since every other component in the boot process already does serial - how hard would it be to make SeaBIOS do serial too?
Well, SeaBIOS does support serial. What you're looking for is the ability to forward vgabios requests over serial. SeaBIOS doesn't have any vgabios capabilities today, so it would be a bit of work. Since sgabios is already designed to do this, I'm not sure what the value would be in duplicating it in SeaBIOS.
So - here's the problem with the sgabios approach. Unless I'm misunderstanding how this works, using sgabios means that I'd have to disable serial in any payload started from grub, as well?
I'm trying to get as minimal a changeset as possible between proprietary bios/coreboot.
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console
The only thing I can think of is that SeaBIOS may be setting the serial port settings to something that grub doesn't like. You can try disabling the code in debug_serial_setup() in src/output.c. However, if you've already tried disabling CONFIG_DEBUG_SERIAL, then I don't think this will do much. It could be a conflict with coreboot serial setup and grub I suppose.
Hmm. Suggestions for debugging?
You could try disabling serial in both coreboot and seabios. It seems like a "long shot" though.
You could change grub to dump the serial registers and then run it from both the proprietary bios and from coreboot/seabios - just to see if there is a serial port difference.
Maybe there is a debugging mode of grub that you could activate?
Will investigate tomorrow...
Thanks, Ward.
On Thu, Apr 30, 2009 at 06:05:29AM -0600, Myles Watson wrote:
From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Kevin O'Connor wrote:
Add sgabios.bin to the CBFS system using a PCI vendor:device of a device in your system that doesn't already have an option rom and isn't a vga or ide device.
I think it's important to improve this situation. The PCI ids are clearly not relevant to this option ROM, so we should not require them.
Kevin already added an img/ path for payloads. I guess he could add a path for ROM-style images (ones that will return.) They'd have to be numbered so that they were executed in order, but that doesn't seem like too much of a problem.
That sounds like a good idea. Latest SeaBIOS git will launch any option rom in the CBFS directory "genroms/". For example, one can add "genroms/sgabios.rom" or the lzma compressed "genroms/sgabios.rom.lzma". The rom(s) will be run after the vga and PCI roms are run.
Adding ordering support is a bit of a pain. Lets see if it is needed.
-Kevin
On Thu, Apr 30, 2009 at 09:18:45PM -0400, Ward Vandewege wrote:
So - here's the problem with the sgabios approach. Unless I'm misunderstanding how this works, using sgabios means that I'd have to disable serial in any payload started from grub, as well?
It seems to work fine under qemu. In any case, a seabios implementation would have the same issues as sgabios - it would need to do exactly what sgabios does.
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console
I've reproduced this problem under qemu. If I boot qemu/coreboot/seabios/grub, then grub wont use the serial console. However, if I boot qemu/seabios/grub, then grub seems to work fine. The above is true regardless of whether SeaBIOS has serial port debugging on or off. I guess coreboot is initialzing the serial port in some way that grub doesn't like.
What's really odd, is that if I have sgabios on, then grub does work okay. I didn't catch this last night because I was also playing with sgabios at the same time. As a guess, sgabios is reinitializing the serial port back to a way grub is okay with. This may be specific to qemu, but it's something to look into.
-Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Thursday, April 30, 2009 7:52 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] Random extra option ROMs in CBFS
On Thu, Apr 30, 2009 at 06:05:29AM -0600, Myles Watson wrote:
From: coreboot-bounces@coreboot.org [mailto:coreboot-
bounces@coreboot.org]
On Behalf Of Peter Stuge Kevin O'Connor wrote:
Add sgabios.bin to the CBFS system using a PCI vendor:device of a device in your system that doesn't already have an option rom and isn't a vga or ide device.
I think it's important to improve this situation. The PCI ids are clearly not relevant to this option ROM, so we should not require them.
Kevin already added an img/ path for payloads. I guess he could add a path for ROM-style images (ones that will return.) They'd have to be numbered so that they were executed in order, but that doesn't seem like too much of a problem.
That sounds like a good idea. Latest SeaBIOS git will launch any option rom in the CBFS directory "genroms/". For example, one can add "genroms/sgabios.rom" or the lzma compressed "genroms/sgabios.rom.lzma". The rom(s) will be run after the vga and PCI roms are run.
That was fast!
Adding ordering support is a bit of a pain. Lets see if it is needed.
Sure. So right now they're run in the order they're found?
Thanks, Myles
On Thu, Apr 30, 2009 at 10:26:56PM -0400, Kevin O'Connor wrote:
What's really odd, is that if I have sgabios on, then grub does work okay. I didn't catch this last night because I was also playing with sgabios at the same time. As a guess, sgabios is reinitializing the serial port back to a way grub is okay with. This may be specific to qemu, but it's something to look into.
Oops - if qemu/coreboot/seabios/sgabios/grub, then sgabios forwards the grub screen over serial - grub itself still wont talk to the serial directly. (If I run qemu/seabios/sgabios/grub then I get two copies of the grub messages - one from grub serial and one from grub screen via sgabios.)
-Kevin
On Thu, Apr 30, 2009 at 8:26 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Apr 30, 2009 at 09:18:45PM -0400, Ward Vandewege wrote:
So - here's the problem with the sgabios approach. Unless I'm misunderstanding how this works, using sgabios means that I'd have to disable serial in any payload started from grub, as well?
It seems to work fine under qemu. Â In any case, a seabios implementation would have the same issues as sgabios - it would need to do exactly what sgabios does.
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 Â terminal --timeout=5 serial console
I've reproduced this problem under qemu. Â If I boot qemu/coreboot/seabios/grub, then grub wont use the serial console. However, if I boot qemu/seabios/grub, then grub seems to work fine. The above is true regardless of whether SeaBIOS has serial port debugging on or off. Â I guess coreboot is initialzing the serial port in some way that grub doesn't like.
I wonder if this is the same reason the serial console doesn't work from Linux sometimes when I do Linux-as-Bootloader kernels in the ROM. I gave up on that method because it was too hard to debug without serial output.
Thanks, Myles
On Thu, Apr 30, 2009 at 08:34:31PM -0600, Myles Watson wrote:
From: Kevin O'Connor [mailto:kevin@koconnor.net] Adding ordering support is a bit of a pain. Lets see if it is needed.
Sure. So right now they're run in the order they're found?
Yes. (And only after vga and pci roms are run.)
-Kevin
On Thu, Apr 30, 2009 at 10:39:31PM -0400, Kevin O'Connor wrote:
On Thu, Apr 30, 2009 at 10:26:56PM -0400, Kevin O'Connor wrote:
What's really odd, is that if I have sgabios on, then grub does work okay. I didn't catch this last night because I was also playing with sgabios at the same time. As a guess, sgabios is reinitializing the serial port back to a way grub is okay with. This may be specific to qemu, but it's something to look into.
Oops - if qemu/coreboot/seabios/sgabios/grub, then sgabios forwards the grub screen over serial - grub itself still wont talk to the serial directly. (If I run qemu/seabios/sgabios/grub then I get two copies of the grub messages - one from grub serial and one from grub screen via sgabios.)
Hmm. I'm not seeing that on h8dme. This is my cbfs:
./cbfstool ./coreboot.rom print coreboot.rom: 1024 kB, bootblocksize 266240, romsize 1048576, offset 0x0 Alignment: 16 bytes
Name Offset Type Size normal/payload 0x0 payload 65635 fallback/payload 0x10090 payload 65635 pci1002,515e.rom 0x20130 0x00000000 45056 genroms/sgabios.rom 0x2b170 0x00000000 3169 pci10de,0373.rom 0x2be10 0x00000000 57344
I've got a vga rom and gpxe in there, in addition to sgabios.
Here's a boot log (seabios head, coreboot r4232 + Myles' serial patch from 4241):
http://ward.vandewege.net/coreboot/h8dme/seabios20090501-sgabios-gpxe-grub-s...
And here's one without gpxe in the cbfs:
http://ward.vandewege.net/coreboot/h8dme/seabios20090501-sgabios-grub-serial...
Basically, grub's super slow, trying to write to serial, but as you can see no grub output ever appears there. Sometimes grub actually displays its menu on the vga console after the 'press any key to continue' lines (if I bang enough keys, it seems), but most of the time it just does the default, which is (nonfunctioning) serial.
Thanks, Ward.
On Thu, Apr 30, 2009 at 08:40:16PM -0600, Myles Watson wrote:
On Thu, Apr 30, 2009 at 8:26 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Apr 30, 2009 at 09:18:45PM -0400, Ward Vandewege wrote:
So - here's the problem with the sgabios approach. Unless I'm misunderstanding how this works, using sgabios means that I'd have to disable serial in any payload started from grub, as well?
It seems to work fine under qemu. Â In any case, a seabios implementation would have the same issues as sgabios - it would need to do exactly what sgabios does.
> Â serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 > Â terminal --timeout=5 serial console
I've reproduced this problem under qemu. Â If I boot qemu/coreboot/seabios/grub, then grub wont use the serial console. However, if I boot qemu/seabios/grub, then grub seems to work fine. The above is true regardless of whether SeaBIOS has serial port debugging on or off. Â I guess coreboot is initialzing the serial port in some way that grub doesn't like.
I'm seeing the exact same issue on m57sli (which is also mcp55 based, however). Has anyone else tried coreboot + SeaBIOS + grub with serial?
Thanks, Ward.
On Tue, May 12, 2009 at 08:16:47PM -0400, Ward Vandewege wrote:
I'm seeing the exact same issue on m57sli (which is also mcp55 based, however). Has anyone else tried coreboot + SeaBIOS + grub with serial?
This looks to be an issue with SeaBIOS serial port detection. Can you retry with the latest seabios git? Make sure CONFIG_SERIAL is enabled in SeaBIOS as grub relies on the serial ports being detected by the bios.
-Kevin
On Tue, May 12, 2009 at 11:04:07PM -0400, Kevin O'Connor wrote:
On Tue, May 12, 2009 at 08:16:47PM -0400, Ward Vandewege wrote:
I'm seeing the exact same issue on m57sli (which is also mcp55 based, however). Has anyone else tried coreboot + SeaBIOS + grub with serial?
This looks to be an issue with SeaBIOS serial port detection. Can you retry with the latest seabios git? Make sure CONFIG_SERIAL is enabled in SeaBIOS as grub relies on the serial ports being detected by the bios.
That was with seabios as of Monday 2009-05-11.
But - I just tried on both h8dme and m57sli with Seabios head as of today, and the bug appears to be gone! Did you change something?
The only thing that's not working for me yet is getting Seabios itself output on serial, via sgabios. I'm looking at that now.
Thanks, Ward.
On Wed, May 13, 2009 at 10:46:11AM -0400, Ward Vandewege wrote:
On Tue, May 12, 2009 at 11:04:07PM -0400, Kevin O'Connor wrote:
On Tue, May 12, 2009 at 08:16:47PM -0400, Ward Vandewege wrote:
I'm seeing the exact same issue on m57sli (which is also mcp55 based, however). Has anyone else tried coreboot + SeaBIOS + grub with serial?
This looks to be an issue with SeaBIOS serial port detection. Can you retry with the latest seabios git? Make sure CONFIG_SERIAL is enabled in SeaBIOS as grub relies on the serial ports being detected by the bios.
That was with seabios as of Monday 2009-05-11.
But - I just tried on both h8dme and m57sli with Seabios head as of today, and the bug appears to be gone! Did you change something?
OK, more information on this.
If CONFIG_DEBUG_SERIAL is set to 0, the bug is gone (i.e. grub serial works as expected), but sgabios does not work. Boot log:
http://ward.vandewege.net/coreboot/seabios/20090513-seabios-no-serial-debug....
If CONFIG_DEBUG_SERIAL is set to 1, the bug persists, but sgabios works. Boot log:
http://ward.vandewege.net/coreboot/seabios/20090513-seabios-serial-debug-gru...
Thoughts?
Thanks, Ward.
On Wed, May 13, 2009 at 10:46:11AM -0400, Ward Vandewege wrote:
On Tue, May 12, 2009 at 11:04:07PM -0400, Kevin O'Connor wrote:
This looks to be an issue with SeaBIOS serial port detection. Can you retry with the latest seabios git? Make sure CONFIG_SERIAL is enabled in SeaBIOS as grub relies on the serial ports being detected by the bios.
[...]
But - I just tried on both h8dme and m57sli with Seabios head as of today, and the bug appears to be gone! Did you change something?
Yes - I committed a fix on Tuesday just prior to sending my email.
On Wed, May 13, 2009 at 04:29:27PM -0400, Ward Vandewege wrote:
If CONFIG_DEBUG_SERIAL is set to 1, the bug persists, but sgabios works. Boot log:
http://ward.vandewege.net/coreboot/seabios/20090513-seabios-serial-debug-gru...
Thoughts?
The problem is related to this log report:
Found 0 serial ports
SeaBIOS still isn't properly detecting your serial port. Can you apply the patch below, up the debugging level to 6, and retry?
Also, unless I'm missing something, sgabios does not appear to be working. If it was working, I'd expect to see double characters - one report from seabios and one report from sgabios - for example, I have a log with:
B^MBoooott ffaaiilleedd:: CCoouulldd nnoott rreeaadd ffrroomm CCDDRROOMM ((cco oddee 00000033))
It looks like the problem is related to the log report:
Found option rom with bad checksum: loc=0x000cd000 len=3584 sum=76
which definitely looks wrong. Can you grab the latest seabios git and run "tools/checksum.py < sgabios.bin" and report the results? I get:
$ l sgabios.bin -rwxr-xr-x 1 kevin 3153 2009-04-29 21:15 sgabios.bin $ tools/checksum.py < sgabios.bin sum=4ff00
which is correct (the last two digits are 00).
-Kevin
--- a/src/serial.c +++ b/src/serial.c @@ -19,11 +19,15 @@ detect_serial(u16 port, u8 timeout, u8 count) { outb(0x02, port+SEROFF_IER); u8 ier = inb(port+SEROFF_IER); - if (ier != 0x02) + if (ier != 0x02) { + dprintf(1, "ier=%x lcr=%x\n", ier, inb(port+SEROFF_LCR)); return 0; + } u8 iir = inb(port+SEROFF_IIR); - if ((iir & 0x3f) != 0x02) + if ((iir & 0x3f) != 0x02) { + dprintf(1, "iir=%x lcr=%x\n", iir, inb(port+SEROFF_LCR)); return 0; + }
outb(0x00, port+SEROFF_IER); SET_BDA(port_com[count], port);
On Wed, May 13, 2009 at 09:07:46PM -0400, Kevin O'Connor wrote:
On Wed, May 13, 2009 at 10:46:11AM -0400, Ward Vandewege wrote:
On Tue, May 12, 2009 at 11:04:07PM -0400, Kevin O'Connor wrote:
This looks to be an issue with SeaBIOS serial port detection. Can you retry with the latest seabios git? Make sure CONFIG_SERIAL is enabled in SeaBIOS as grub relies on the serial ports being detected by the bios.
[...]
But - I just tried on both h8dme and m57sli with Seabios head as of today, and the bug appears to be gone! Did you change something?
Yes - I committed a fix on Tuesday just prior to sending my email.
On Wed, May 13, 2009 at 04:29:27PM -0400, Ward Vandewege wrote:
If CONFIG_DEBUG_SERIAL is set to 1, the bug persists, but sgabios works. Boot log:
http://ward.vandewege.net/coreboot/seabios/20090513-seabios-serial-debug-gru...
Thoughts?
The problem is related to this log report:
Found 0 serial ports
SeaBIOS still isn't properly detecting your serial port. Can you apply the patch below, up the debugging level to 6, and retry?
Will try on Friday.
Also, unless I'm missing something, sgabios does not appear to be working. If it was working, I'd expect to see double characters - one report from seabios and one report from sgabios - for example, I have a log with:
B^MBoooott ffaaiilleedd:: CCoouulldd nnoott rreeaadd ffrroomm CCDDRROOMM ((cco oddee 00000033))
Right, that's what I was expecting.
It looks like the problem is related to the log report:
Found option rom with bad checksum: loc=0x000cd000 len=3584 sum=76
which definitely looks wrong. Can you grab the latest seabios git and run "tools/checksum.py < sgabios.bin" and report the results? I get:
$ l sgabios.bin -rwxr-xr-x 1 kevin 3153 2009-04-29 21:15 sgabios.bin $ tools/checksum.py < sgabios.bin sum=4ff00
which is correct (the last two digits are 00).
Huh:
$ v ../payloads/sgabios.bin -rwxr-xr-x 1 root src 3169 2009-04-29 13:56 ../payloads/sgabios.bin* $ tools/checksum.py <../payloads/sgabios.bin sum=50b76
This was built on Debian Lenny, 64 bit, gcc-4.3 (Debian 4.3.2-1.1) 4.3.2 I believe.
Odd it still works when seabios'es serial debug output is disabled.
Thanks, Ward.
On Wed, May 13, 2009 at 11:23:52PM -0400, Ward Vandewege wrote:
which is correct (the last two digits are 00).
Huh:
$ v ../payloads/sgabios.bin -rwxr-xr-x 1 root src 3169 2009-04-29 13:56 ../payloads/sgabios.bin* $ tools/checksum.py <../payloads/sgabios.bin sum=50b76
Heh - sgabios isn't properly checksumming. It was just dumb luck that my binary summed to zero.
This is a hack, but you can use seabios' rom building tool to make it work:
tools/buildrom.py ../payloads/sgabios.bin sgabios-cksum.bin
Someone should follow up with google on this..
-Kevin
On Wed, May 13, 2009 at 09:07:46PM -0400, Kevin O'Connor wrote:
On Wed, May 13, 2009 at 04:29:27PM -0400, Ward Vandewege wrote:
If CONFIG_DEBUG_SERIAL is set to 1, the bug persists, but sgabios works. Boot log:
http://ward.vandewege.net/coreboot/seabios/20090513-seabios-serial-debug-gru...
Thoughts?
The problem is related to this log report:
Found 0 serial ports
SeaBIOS still isn't properly detecting your serial port. Can you apply the patch below, up the debugging level to 6, and retry?
Log file:
http://ward.vandewege.net/coreboot/seabios/20090515-seabios-sgabios-serial-d...
Thanks, Ward.
On Thu, May 14, 2009 at 09:19:33AM -0400, Kevin O'Connor wrote:
On Wed, May 13, 2009 at 11:23:52PM -0400, Ward Vandewege wrote:
which is correct (the last two digits are 00).
Huh:
$ v ../payloads/sgabios.bin -rwxr-xr-x 1 root src 3169 2009-04-29 13:56 ../payloads/sgabios.bin* $ tools/checksum.py <../payloads/sgabios.bin sum=50b76
Heh - sgabios isn't properly checksumming. It was just dumb luck that my binary summed to zero.
This is a hack, but you can use seabios' rom building tool to make it work:
tools/buildrom.py ../payloads/sgabios.bin sgabios-cksum.bin
Yes, that fixes the sgabios loading. Log files:
with CONFIG_DEBUG_SERIAL set:
http://ward.vandewege.net/coreboot/seabios/20090515-seabios-sgabios-serial-d...
(the seabios serial detection issue still persists)
without CONFIG_DEBUG_SERIAL set:
http://ward.vandewege.net/coreboot/seabios/20090515-seabios-sgabios-serial-d...
Now - the reason why I wanted to use sgabios, was to get the seabios console output on serial.
As you can see in the logs, sgabios is loaded too late to be much use for that (after the disk detection, and after seabios prints 'Press F12 for boot menu').
If sgabios is the way to get seabios to copy console to serial, would it be possible to load the sgabios option rom (much) earlier?
Thanks, Ward.
On Fri, May 15, 2009 at 11:27:35AM -0400, Ward Vandewege wrote:
Yes, that fixes the sgabios loading. Log files:
with CONFIG_DEBUG_SERIAL set:
http://ward.vandewege.net/coreboot/seabios/20090515-seabios-sgabios-serial-d...
(the seabios serial detection issue still persists)
The serial port was busy writing debugging info and that confused the detection code. The latest seabios git should have this fixed.
-Kevin
On Fri, May 15, 2009 at 11:27:35AM -0400, Ward Vandewege wrote:
Now - the reason why I wanted to use sgabios, was to get the seabios console output on serial.
As you can see in the logs, sgabios is loaded too late to be much use for that (after the disk detection, and after seabios prints 'Press F12 for boot menu').
If sgabios is the way to get seabios to copy console to serial, would it be possible to load the sgabios option rom (much) earlier?
Sgabios isn't a PnP rom, and it therefore doesn't get called before the boot menu. You can try the patch to sgabios below - I don't know how reliable it will be.
Nathan - BTW, it looks like sgabios is modifying itself - that's fine, but it will need to update its checksum before returning to the bios.
-Kevin
--- sgabios.S (revision 4) +++ sgabios.S (working copy) @@ -125,7 +125,7 @@ /* FIXME: **** PnP header currently disabled by PoO **** */ /* legacy entry only called once, PnP entry called multiple times */ /* The code isn't yet written to deal with multiple inits properly */ - .ascii "$PoO" /* PnP expansion header signature */ + .ascii "$PnP" /* PnP expansion header signature */ .byte 1 /* structure revision */ .byte 2 /* length in 16-byte increments */ .word 0 /* offset of next header, 0 if none */ @@ -138,7 +138,7 @@ .byte 0xe3 /* device indicators, input/display dev */ .word 0 /* boot connection vector, 0 if none */ .word 0 /* disconnect vector, 0 if none */ - .word pnp_init /* bootstrap entry vector */ + .word 0 /* bootstrap entry vector */ .word 0 /* reserved */ .word 0 /* static resource information vector */
On Fri, May 15, 2009 at 10:25:35PM -0400, Kevin O'Connor wrote:
On Fri, May 15, 2009 at 11:27:35AM -0400, Ward Vandewege wrote:
Yes, that fixes the sgabios loading. Log files:
with CONFIG_DEBUG_SERIAL set:
http://ward.vandewege.net/coreboot/seabios/20090515-seabios-sgabios-serial-d...
(the seabios serial detection issue still persists)
The serial port was busy writing debugging info and that confused the detection code. The latest seabios git should have this fixed.
Yep, confirmed. Boot log here:
http://ward.vandewege.net/coreboot/seabios/20090521-seabios-sgabios-serial-d...
Thanks, Ward.
On Fri, May 15, 2009 at 10:37:56PM -0400, Kevin O'Connor wrote:
On Fri, May 15, 2009 at 11:27:35AM -0400, Ward Vandewege wrote:
Now - the reason why I wanted to use sgabios, was to get the seabios console output on serial.
As you can see in the logs, sgabios is loaded too late to be much use for that (after the disk detection, and after seabios prints 'Press F12 for boot menu').
If sgabios is the way to get seabios to copy console to serial, would it be possible to load the sgabios option rom (much) earlier?
Sgabios isn't a PnP rom, and it therefore doesn't get called before the boot menu. You can try the patch to sgabios below - I don't know how reliable it will be.
That worked! However, the serial bug is apparently back - grub's printing 'Press any key to continue' very very slowly, and ignoring serial console input while that is happening. See boot log at:
http://ward.vandewege.net/coreboot/seabios/20090521-seabios-sgabios-serial-d...
Once grub gets to the 'press esc for menu' countdown, serial console works again.
Thanks, Ward.
On Thu, May 21, 2009 at 12:13:04PM -0400, Ward Vandewege wrote:
On Fri, May 15, 2009 at 10:37:56PM -0400, Kevin O'Connor wrote:
On Fri, May 15, 2009 at 11:27:35AM -0400, Ward Vandewege wrote:
Now - the reason why I wanted to use sgabios, was to get the seabios console output on serial.
As you can see in the logs, sgabios is loaded too late to be much use for that (after the disk detection, and after seabios prints 'Press F12 for boot menu').
If sgabios is the way to get seabios to copy console to serial, would it be possible to load the sgabios option rom (much) earlier?
Sgabios isn't a PnP rom, and it therefore doesn't get called before the boot menu. You can try the patch to sgabios below - I don't know how reliable it will be.
That worked! However, the serial bug is apparently back - grub's printing 'Press any key to continue' very very slowly, and ignoring serial console input while that is happening. See boot log at:
Disregard that. It works perfectly both with CONFIG_DEBUG_SERIAL on or off.
I was not using the seabios payload I thought I was.
Nathan - any chance that patch could be applied to sgabios?
Thanks!! Ward.
On Thu, May 21, 2009 at 12:13:04PM -0400, Ward Vandewege wrote:
On Fri, May 15, 2009 at 10:37:56PM -0400, Kevin O'Connor wrote:
On Fri, May 15, 2009 at 11:27:35AM -0400, Ward Vandewege wrote:
Now - the reason why I wanted to use sgabios, was to get the seabios console output on serial.
As you can see in the logs, sgabios is loaded too late to be much use for that (after the disk detection, and after seabios prints 'Press F12 for boot menu').
If sgabios is the way to get seabios to copy console to serial, would it be possible to load the sgabios option rom (much) earlier?
Sgabios isn't a PnP rom, and it therefore doesn't get called before the boot menu. You can try the patch to sgabios below - I don't know how reliable it will be.
That worked!
OK, I can now get to the boot menu, which is great.
Ideally though, all output starting from 'Starting Seabios' would end up on serial as well as console. So, drive detection, gpxe being loaded, any other option roms being loaded.
Is that at all possible? Perhaps seabios could treat an optionrom with name genroms/sgabios.rom as special and load it before all other option roms?
Thanks, Ward.
Ward Vandewege wrote:
Perhaps seabios could treat an optionrom with name genroms/sgabios.rom as special and load it before all other option roms?
It would be nice if there was a more generic mechanism.
SysV init script style comes to my mind immediately but that probably isn't the best way.
//Peter
On Thu, May 21, 2009 at 01:03:30PM -0400, Ward Vandewege wrote:
On Thu, May 21, 2009 at 12:13:04PM -0400, Ward Vandewege wrote:
On Fri, May 15, 2009 at 10:37:56PM -0400, Kevin O'Connor wrote:
On Fri, May 15, 2009 at 11:27:35AM -0400, Ward Vandewege wrote:
Now - the reason why I wanted to use sgabios, was to get the seabios console output on serial.
As you can see in the logs, sgabios is loaded too late to be much use for that (after the disk detection, and after seabios prints 'Press F12 for boot menu').
If sgabios is the way to get seabios to copy console to serial, would it be possible to load the sgabios option rom (much) earlier?
Sgabios isn't a PnP rom, and it therefore doesn't get called before the boot menu. You can try the patch to sgabios below - I don't know how reliable it will be.
That worked!
OK, I can now get to the boot menu, which is great.
Ideally though, all output starting from 'Starting Seabios' would end up on serial as well as console. So, drive detection, gpxe being loaded, any other option roms being loaded.
Is that at all possible? Perhaps seabios could treat an optionrom with name genroms/sgabios.rom as special and load it before all other option roms?
Perhaps somewhat related: there's a screen redrawing issue when using sgabios. After sgabios loads, it resets the cursor position to the top of the screen, which makes the rest of the output go on top of whatever was already on the screen.
I suppose that if sgabios could be loaded much earlier - before 'Starting SeaBIOS' is printed to the console, this would not be an issue.
Thanks, Ward.
On Thu, May 21, 2009 at 01:03:30PM -0400, Ward Vandewege wrote:
On Thu, May 21, 2009 at 12:13:04PM -0400, Ward Vandewege wrote:
That worked!
Great!
OK, I can now get to the boot menu, which is great.
Ideally though, all output starting from 'Starting Seabios' would end up on serial as well as console. So, drive detection, gpxe being loaded, any other option roms being loaded.
Is that at all possible? Perhaps seabios could treat an optionrom with name genroms/sgabios.rom as special and load it before all other option roms?
Sure - for example, SeaBIOS could load all roms in "vgaroms/" during the vga init phase. This gets somewhat to the point Myles raised earlier about option rom ordering - I'm not sure what the best thing to do is.
-Kevin
On Thu, May 21, 2009 at 09:19:04PM -0400, Kevin O'Connor wrote:
On Thu, May 21, 2009 at 01:03:30PM -0400, Ward Vandewege wrote:
On Thu, May 21, 2009 at 12:13:04PM -0400, Ward Vandewege wrote:
That worked!
Great!
OK, I can now get to the boot menu, which is great.
Ideally though, all output starting from 'Starting Seabios' would end up on serial as well as console. So, drive detection, gpxe being loaded, any other option roms being loaded.
Is that at all possible? Perhaps seabios could treat an optionrom with name genroms/sgabios.rom as special and load it before all other option roms?
Sure - for example, SeaBIOS could load all roms in "vgaroms/" during the vga init phase. This gets somewhat to the point Myles raised earlier about option rom ordering - I'm not sure what the best thing to do is.
Hmm. The more I think about this, the more a sysv-style system seems appealing.
A system where the loading of option roms could be ordered by whoever builds the rom image, if so desired, seems nice.
I'm not sure how that would play with the current order of loading things, which is presumably done as pci ids are enumerated?
Or maybe we could just load whatever is in "early/" before the pci probing, and "late/" after?
Thanks, Ward.
-
Kevin O'Connor -
Myles Watson -
Patrick Georgi -
Peter Stuge -
Stefan Reinauer -
Ward Vandewege