SeaBIOS, serial output, and grub

[Ward Vandewege]

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.

[Kevin O'Connor]

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

[Ward Vandewege]

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]

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

[Ward Vandewege]

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.

[Kevin O'Connor]

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

[Kevin O'Connor]

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

[Ward Vandewege]

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.

[Myles Watson]

On Thu, Apr 30, 2009 at 8:26 PM, Kevin O'Connor  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

[Ward Vandewege]

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  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.

[Kevin O'Connor]

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

[Ward Vandewege]

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.

[Ward Vandewege]

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.

[Kevin O'Connor]

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);

[Ward Vandewege]

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.

[Kevin O'Connor]

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

[Ward Vandewege]

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.

[Kevin O'Connor]

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

[Ward Vandewege]

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.

[Kevin O'Connor]

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 */

[Ward Vandewege]

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.

[Ward Vandewege]

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.

[Ward Vandewege]

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.

[Peter Stuge]

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

[Ward Vandewege]

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.

[Kevin O'Connor]

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

[Ward Vandewege]

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.

[Ward Vandewege]

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.

Random extra option ROMs in CBFS

[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.

I don't know how to fix it though. Does anyone have an idea?

//Peter

Random extra option ROMs in CBFS

[Myles Watson]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Peter Stuge
> Sent: Thursday, April 30, 2009 3:15 AM
> To: [e-mail]
> 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

Random extra option ROMs in CBFS

[Peter Stuge]

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

Random extra option ROMs in CBFS

[Ward Vandewege]

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.

Random extra option ROMs in CBFS

[Stefan Reinauer]

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

Random extra option ROMs in CBFS

[Myles Watson]

On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauer  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

Random extra option ROMs in CBFS

[Patrick Georgi]

Am 30.04.2009 16:03, schrieb Myles Watson:
> On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauer  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

Random extra option ROMs in CBFS

[Myles Watson]

On Thu, Apr 30, 2009 at 8:23 AM, Patrick Georgi
 wrote:
> Am 30.04.2009 16:03, schrieb Myles Watson:
> > On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauer
> >  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

Random extra option ROMs in CBFS

[Kevin O'Connor]

On Thu, Apr 30, 2009 at 06:05:29AM -0600, Myles Watson wrote:
> > From: [e-mail] [mailto:[e-mail]]
> > 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

Random extra option ROMs in CBFS

[Myles Watson]

> -----Original Message-----
> From: Kevin O'Connor [mailto:[e-mail]]
> Sent: Thursday, April 30, 2009 7:52 PM
> To: Myles Watson
> Cc: [e-mail]
> Subject: Re: [coreboot] Random extra option ROMs in CBFS
>
> On Thu, Apr 30, 2009 at 06:05:29AM -0600, Myles Watson wrote:
> > > From: [e-mail] [mailto:coreboot-
>
> [e-mail]]
> > > 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

Random extra option ROMs in CBFS

[Kevin O'Connor]

On Thu, Apr 30, 2009 at 08:34:31PM -0600, Myles Watson wrote:
> > From: Kevin O'Connor [mailto:[e-mail]]
> > 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