[coreboot] GSoC project(SCSI boot)__status report

[Kevin O'Connor]

On Wed, Jun 18, 2008 at 01:04:49AM +0200, Stefan Reinauer wrote:
> Kevin O'Connor wrote:
> > The latest code I've written (I'll call in LegacyBIOS) produces an elf
> > file with a 32bit entry point.  It works as a standard payload with
> > coreboot.
> >   
> How will this work? Is there a piece of 32bit code that will copy the
> rest of LegacyBIOS to 0xf0000?

The LegacyBIOS elf file expects to be loaded into the 0xf0000 area:

$ objdump -x out/bios.bin.elf
[...]
start address 0x000f66a0

Program Header:
    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
         filesz 0x00010000 memsz 0x00010000 flags rw-

Currently all of the 16bit and 32bit code fits in the 64K segment at
0xf0000.  Just load the elf into that area and jump to it.

> Is there a way to produce a "bios.bin" image that can be copied to
> 0xe0000 or 0xf0000 and still has all the coreboot stuff in it?

The elf file (bios.bin.elf) is just a wrapper around a 64K blob
(bios.bin) with a specified entry point.  So, if one wants the blob
and not the elf then the file bios.bin can be used.

> > This code initializes the BDA and EBDA memory areas - including the
> > idt table.  However, the last part of "post" will attempt to boot the
> > system (by calling int19).  If you want to "post" without booting,
> > you'd need to extend LegacyBIOS to return to coreboot somehow.
> >   
> Ok. what would be the best way to do this? create a well known entry
> point, similar to the reset vector?

I wouldn't want to hardcode an address, but we can certainly create a
returnable coreboot entry point and have the build process export the
address somehow.  Effectively, the build process today is exporting
the current 32bit entry point by building an elf around bios.bin and
setting the elf "start address".

To return to coreboot, however, one also needs to restore the stack,
idt, and gdt..

> > Is there a particular reason you'd want to return to coreboot?
[...]
> The current option rom handling in post() may not be sufficient to
> initialize all option roms in a system, as the current coreboot v3 code
> is able to load an option rom for a given device from the "lar" archive,
> copy it to the option rom area and execute it from there. This way we
> can easily support an arbitrary number of onboard devices with option
> roms.

So, why not have coreboot load all the option roms from the lar into
ram and then launch LegacyBIOS?

>But when jumping into LegacyBIOS, not all option roms may be
> visible in the address space at the same time.

This is surprising.  If all the option roms don't fit, how would a
normal BIOS boot the system?  If one were to swap out an option rom,
how could one be sure the option rom didn't "hook" a 16bit int
handler?

> I guess what I am suggesting is to split the bootmenu + OS loader
> (int19) part from the init part.

I have no issue with doing this - it's trivial to implement multiple
entry points.  One need only implement a "__start2" type function that
called a subset of the init code.

I do think it is conceptually simpler if coreboot did its thing and
then launched LegacyBIOS as a payload.  Then LegacyBIOS could do its
thing and then launch the OS.

> This way we can still provide the option rom initialization via
> LegacyBIOS' intXX callbacks but do not force the user to also use its
> int19 boot code, but can instead jump into another payload - for example
> UEFI or GRUB2 in flash.

I think it would be cool to teach LegacyBIOS how to read the lar.
That way one could boot floppy, cdrom, hard drive, or lar payload.
Something like LegacyBIOS+Bayou.

I'm not tied to anything though - whatever works.

> > What I'm currently doing is having coreboot build the tables somewhere
> > high in memory, and then having LegacyBIOS move the tables that need
> > to be in 0xf0000 down to that area.
> >   
> Do you have a list of tables that need to live at 0xf0000? I know at
> least a lot of ACPI can live pretty high up.
> coreboot table currently resides at 0x530 or 0x500 but it is not very
> well placed there.

I know of only PIR (generally 32-160 bytes), ACPI RSDP (20-36 bytes),
SMBIOS Structure Table Entry Point (31 bytes), and mptable Floating
Pointer Structure (16 bytes).  (Note that SMBIOS is just a newer
definition of DMI - DMI's equivalent entry point is 15 bytes.)

It's straight forward to relocate these tables.  I changed coreboot-v2
code in write_tables() (arch/i386/boot/tables.c) to use a high memory
location instead of 0xf0000.  Coreboot-v2 automatically exported the
new location in the coreboot table.  I then had LegacyBIOS scan those
memory areas marked as CB_MEM_TABLE for the standard bios table
signatures.  See:

http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob;f=src/coreboot.c;h=635c2f683d699ff3a3f318bc5a4bb95538d95345;hb=f54c150090ff38a73ef64a5d20fdfa0d9c403972#l13

-Kevin