legacybios update

[Kevin O'Connor]

Hi,

I've just pushed a new elf payload to:

http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080518

This version should be free of qemu dependencies.  In particular, it
no longer relies on parameters passed in nvram.  The code will still
access CMOS_RESET_CODE (0x0f), CMOS_FLOPPY_DRIVE_TYPE (0x10), and
CMOS_CENTURY (0x32).  However, I think these nvram locations are
pretty standard and basically harmless.

The above payload will not populate PIR, MPTABLE, SMBIOS, or ACPI
tables.  Also, just to facilitate testing, I've hardcoded the memory
to 128Megs, and I've hardcoded a standard boot order (floppy, cdrom,
then hard drive).

I've tested the payload with coreboot-v3 and qemu.  The above payload
plugs into the standard coreboot-v3 elf payload config.  I did not
customize the coreboot code at all - however, I did disable "Execute
PCI Option ROMs" in the coreboot config.  It looks like I'll need to
acquire some real hardware to test on.  Any suggestions?

Anyone willing to try the above on real hardware?  :-)

-Kevin

[Rudolf Marek]

> Anyone willing to try the above on real hardware?  :-)

Please pack source of snapshot too. I can try on monday on my Desktop system 
where I use Coreboot. I need to get booting from sata working so perhaps I need 
to hack the IO ports so it boots ;)

(my sata controller is legacy compatible so everything I need is to adjust IO 
base of IDE controller in sata)

Rudolf

[Kevin O'Connor]

On Sun, May 18, 2008 at 09:36:32AM +0200, Rudolf Marek wrote:
> > Anyone willing to try the above on real hardware?  :-)
>
> Please pack source of snapshot too. I can try on monday on my
> Desktop system where I use Coreboot. I need to get booting from sata
> working so perhaps I need to hack the IO ports so it boots ;)

Thanks Rudolf.

The easiest way to get the snapshot is via git:

git clone git://git.linuxtogo.org/home/kevin/legacybios

If you compile from source, you'll need to change some settings in
config.h:

#define CONFIG_COREBOOT 1
#define CONFIG_DEBUG_SERIAL 1
#define CONFIG_PCIBIOS 0

(The last line is needed to disable PIR table generation.)

-Kevin

[Kevin O'Connor]

On Sun, May 18, 2008 at 03:14:22AM -0400, Kevin O'Connor wrote:
> Hi,
>
> I've just pushed a new elf payload to:
>
> http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080518
>
> This version should be free of qemu dependencies.

Just wanted to give an update.  On Sunday, Uwe was able to run some
tests with "legacybios".  What was found:

* coreboot-v2 can run legacybios.  It does require disabling
  valid_area() check in in src/boot/elfboot.c

* legacybios will start up on real hardware (tested with coreboot-v2),
  but there were some issues with kbd init, ide init, and usleep.
  This prevented booting a real OS.  Latest "legacybios" git should
  address kbd init and usleep.

* A more detailed analysis of filo shows that it has a more advanced
  ide init (it does a pci scan for ide controllers and it has
  "floating bus detection").  I'm going to work on advancing the
  "legacybios" code to also do this.

Uwe also put together a wiki page at:

http://www.coreboot.org/LegacyBIOS

-Kevin

[Joseph Smith]

On Mon, 19 May 2008 20:02:13 -0400, Kevin O'Connor 
wrote:
> On Sun, May 18, 2008 at 03:14:22AM -0400, Kevin O'Connor wrote:
> > Hi,
> >
> > I've just pushed a new elf payload to:
> >
> > http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080518
> >
> > This version should be free of qemu dependencies.
>
> Just wanted to give an update.  On Sunday, Uwe was able to run some
> tests with "legacybios".  What was found:
>
> coreboot-v2 can run legacybios.  It does require disabling
> valid_area() check in in src/boot/elfboot.c
>
> legacybios will start up on real hardware (tested with coreboot-v2),
> but there were some issues with kbd init, ide init, and usleep.
> This prevented booting a real OS.  Latest "legacybios" git should
> address kbd init and usleep.
>
> A more detailed analysis of filo shows that it has a more advanced
> ide init (it does a pci scan for ide controllers and it has
> "floating bus detection").  I'm going to work on advancing the
> "legacybios" code to also do this.
>
> Uwe also put together a wiki page at:
>
> http://www.coreboot.org/LegacyBIOS

Great work Kevin and Uwe!
When you say the ide init is more advanced than filo...
Does it do cable detection (40 conducter vs 80 conductor needed for
ATA/66/100/133)?
That is one of my biggest gripes about filo...well that and UHCI/EHCI.

[Kevin O'Connor]

On Mon, May 19, 2008 at 11:13:34PM -0400, Joseph Smith wrote:
> On Mon, 19 May 2008 20:02:13 -0400, Kevin O'Connor 
> wrote:
> > A more detailed analysis of filo shows that it has a more advanced
> > ide init (it does a pci scan for ide controllers and it has
> > "floating bus detection").  I'm going to work on advancing the
> > "legacybios" code to also do this.
>
> When you say the ide init is more advanced than filo...

I think you misunderstood me - filo ide code is more advanced than the
"legacybios" code.
> Does it do cable detection (40 conducter vs 80 conductor needed for
> ATA/66/100/133)?

I'm not all that familiar with low level ata details.  Both filo and
"legacybios" use PIO mode - I didn't think cable detection mattered.

-Kevin

[Myles Watson]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Kevin O'Connor
> Sent: Monday, May 19, 2008 6:02 PM
> To: [e-mail]
> Subject: Re: [coreboot] legacybios update
>
> On Sun, May 18, 2008 at 03:14:22AM -0400, Kevin O'Connor wrote:
> > Hi,
> >
> > I've just pushed a new elf payload to:
> >
> > http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080518
> >
> > This version should be free of qemu dependencies.
>
> Just wanted to give an update.  On Sunday, Uwe was able to run some
> tests with "legacybios".  What was found:
>
> coreboot-v2 can run legacybios.  It does require disabling
> valid_area() check in in src/boot/elfboot.c
>
> legacybios will start up on real hardware (tested with coreboot-v2),
> but there were some issues with kbd init, ide init, and usleep.
> This prevented booting a real OS.  Latest "legacybios" git should
> address kbd init and usleep.
>
> A more detailed analysis of filo shows that it has a more advanced
> ide init (it does a pci scan for ide controllers and it has
> "floating bus detection").  I'm going to work on advancing the
> "legacybios" code to also do this.

Could coreboot pass the information for the IDE controllers to "legacybios"
when it passes memory size etc?

Thanks,
Myles

[Kevin O'Connor]

On Tue, May 20, 2008 at 08:19:55AM -0600, Myles Watson wrote:
> > A more detailed analysis of filo shows that it has a more advanced
> > ide init (it does a pci scan for ide controllers and it has
> > "floating bus detection").  I'm going to work on advancing the
> > "legacybios" code to also do this.
>
> Could coreboot pass the information for the IDE controllers to "legacybios"
> when it passes memory size etc?

The pci scan code is straight forward.  I don't think we need to
extend core boot to avoid it.

-Kevin

[Myles Watson]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Kevin O'Connor
> Sent: Monday, May 19, 2008 6:02 PM
> To: [e-mail]
> Subject: Re: [coreboot] legacybios update
>
> On Sun, May 18, 2008 at 03:14:22AM -0400, Kevin O'Connor wrote:
> > Hi,
> >
> > I've just pushed a new elf payload to:
> >
> > http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080518
> >
> > This version should be free of qemu dependencies.
>
> Just wanted to give an update.  On Sunday, Uwe was able to run some
> tests with "legacybios".  What was found:
> coreboot-v2 can run legacybios.  It does require disabling
> valid_area() check in in src/boot/elfboot.c

Coreboot writes the PIRQ and ACPI tables in this area.  Right now it doesn't
matter since legacybios doesn't use this information, but eventually we
might want to change this.

Thanks,
Myles
> legacybios will start up on real hardware (tested with coreboot-v2),
> but there were some issues with kbd init, ide init, and usleep.
> This prevented booting a real OS.  Latest "legacybios" git should
> address kbd init and usleep.
>
> A more detailed analysis of filo shows that it has a more advanced
> ide init (it does a pci scan for ide controllers and it has
> "floating bus detection").  I'm going to work on advancing the
> "legacybios" code to also do this.
>
> Uwe also put together a wiki page at:
>
> http://www.coreboot.org/LegacyBIOS
>
> -Kevin

legacybios updat

[Stefan Reinauer]

Myles Watson wrote:
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Kevin O'Connor
> > Sent: Monday, May 19, 2008 6:02 PM
> > To: [e-mail]
> > Subject: Re: [coreboot] legacybios update
> >
> > On Sun, May 18, 2008 at 03:14:22AM -0400, Kevin O'Connor wrote:
> > > Hi,
> > >
> > > I've just pushed a new elf payload to:
> > >
> > > http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080518
> > >
> > > This version should be free of qemu dependencies.
> >
> > Just wanted to give an update.  On Sunday, Uwe was able to run some
> > tests with "legacybios".  What was found:
> > coreboot-v2 can run legacybios.  It does require disabling
> > valid_area() check in in src/boot/elfboot.c
>
> Coreboot writes the PIRQ and ACPI tables in this area.  Right now it doesn't
> matter since legacybios doesn't use this information, but eventually we
> might want to change this.

Also, DMI is going there, too, in my implementation that I hope to
publish soon.

I wonder what we do with those tables..  normal bios puts a bunch of
them at the end of memory. We have limited locations to put them at,
because the OS has to find them.

How much of the F segment is actually used by legacybios? Should we put
that stuff into the lbtable as an option and have legacy relocate it? Or
is there a safe place where we can put them to begin with..?

Stefan

legacybios updat

[Myles Watson]

On Wed, May 21, 2008 at 3:32 PM, Stefan Reinauer  wrote:
> Myles Watson wrote:
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > On Behalf Of Kevin O'Connor
> > > Sent: Monday, May 19, 2008 6:02 PM
> > > To: [e-mail]
> > > Subject: Re: [coreboot] legacybios update
> > >
> > > On Sun, May 18, 2008 at 03:14:22AM -0400, Kevin O'Connor wrote:
> > > > Hi,
> > > >
> > > > I've just pushed a new elf payload to:
> > > >
> > > > http://linuxtogo.org/~kevin/legacybios/bios.bin.elf-20080518
> > > >
> > > > This version should be free of qemu dependencies.
> > >
> > > Just wanted to give an update.  On Sunday, Uwe was able to run some
> > > tests with "legacybios".  What was found:
> > > coreboot-v2 can run legacybios.  It does require disabling
> > > valid_area() check in in src/boot/elfboot.c
> >
> > Coreboot writes the PIRQ and ACPI tables in this area.  Right now it doesn't
> > matter since legacybios doesn't use this information, but eventually we
> > might want to change this.
>
> Also, DMI is going there, too, in my implementation that I hope to
>  publish soon.
>
> I wonder what we do with those tables..  normal bios puts a bunch of
>  them at the end of memory. We have limited locations to put them at,
>  because the OS has to find them.
>
> How much of the F segment is actually used by legacybios?

All of it.  The callback entry points are at fixed locations, and the
rest of the code lives there too.
> Should we put
>  that stuff into the lbtable as an option and have legacy relocate it? Or
>  is there a safe place where we can put them to begin with..?

I'm not sure.

Thanks,
Myles
> Stefan

legacybios updat

[Kevin O'Connor]

On Wed, May 21, 2008 at 03:50:52PM -0600, Myles Watson wrote:
> On Wed, May 21, 2008 at 3:32 PM, Stefan Reinauer  wrote:
> > How much of the F segment is actually used by legacybios?
>
> All of it.  The callback entry points are at fixed locations, and the
> rest of the code lives there too.

The payload is currently 64KiB in size - so deploying the payload
today will overwrite the entire F segment.

However, it isn't necessary to use the full F segment.  The fixed
entry points are entirely in the last 8K of the segment.  (The first
hardcoded entry point is "post" at 0xfe05b.)  The remaining 56K is
then used for C code.  We're currently using about 43K for both 16bit
and 32bit C code (although with coreboot, we turn off a bunch of stuff
and are really at about 36K).  This leaves another 13K for future C
code growth.

So, we could place the C code 1K in from the start of the F segment
and then use the first 1K for tables.  Another option is to use the
1936 bytes from 0xff0b0 to 0xff840 - this is an unused area in the
middle of the fixed offset area of the bios - it is unusable for C
code and otherwise empty.  This is where I currently place tables
generated by "legacybios".

Of course, this assumes we only place the headers of tables in the F
segment and then place the rest of the tables in a reserved memory
area (usually at the top of memory).  If we do this, it would require
setting up an e820 map that ensured that the top of memory didn't get
zapped by an OS.  Where this reserved memory is located and how much
of it is reserved would be one more thing to pass to "legacybios" so
that it can handle e820 requests.
> > Should we put
> >  that stuff into the lbtable as an option and have legacy relocate it? Or
> >  is there a safe place where we can put them to begin with..?

Right - if coreboot creates the tables, we either have legacybios copy
them around, or work out some way to ensure that legacybios doesn't
overwrite them when it gets deployed.
> From my point of view, the latter is easiest.  However, the former is

likely more flexible.

-Kevin