[coreboot] elf payload legacybios - boots on v3 in qemu

[Myles Watson]

> On Tue, May 13, 2008 at 08:48:59AM -0600, Myles Watson wrote:
> > Could we do something simple like not use the CMOS for Coreboot, but
> > use a place in the EBDA to be "CMOS"?  I realize that we won't be able
> > to set it permanently like real CMOS, but we could configure it from a
> > libpayload payload.  If we put the cmos section above the ata_s
> > structure it would be in a fixed place, which would probably help.
> 
> The inb/outb_cmos functions are used for other functions besides
> accessing nvram.  Redirecting these functions would cause the clock
> functions to cease working.

I'm surprised.  It seems like as long as we redirect them to storage that's
initialized correctly the BIOS wouldn't care where it was stored.

> Most of the uses of nvram in "legacybios" is as a mechanism to pass
> data from the emulator to the guest.
> 
> There are only two nvram variables that are read and written by
> "legacybios":
> 
> CMOS_RESET_CODE (0x0f) - this is used to implement some sort of
>     "resume" functionality.  However, since the bios doesn't implement
>     the corresponding "suspend", I'm not sure it's really useful.
> 
> CMOS_CENTURY (0x32) - this stores part of the date that doesn't fit in
>     the rtc - the '20' in 2008.  I suppose we could hard code this if
>     we really didn't want to store it in the nvram.
> 
> There are several nvram values that are only read by "legacybios":
> 
> CMOS_FLOPPY_DRIVE_TYPE (0x10) - this appears to be a standard - even
>     linux uses it.
> 
> CMOS_EQUIPMENT_INFO (0x14) - I think we can remove this dependency -
>     almost everything in it is already auto-detected.
> 
> CMOS_BIOS_DISKTRANSFLAG (0x39) - This controls how the bios maps disk
>     CHS calls to LBA.  I think this may be auto-detected - if not, it
>     can be passed in via coreboot.
> 
> CMOS_DISK_DATA (0x12)
> hd geometry (0x19 - 0x2c) - These settings can and should be
>     auto-detected from the ide drive.
> 
> CMOS_MEM_EXTMEM_LOW   (0x30)
> CMOS_MEM_EXTMEM_HIGH  (0x31)
> CMOS_MEM_EXTMEM2_LOW  (0x34)
> CMOS_MEM_EXTMEM2_HIGH (0x35)
>     - These are used as a mechanism for passing system memory size.
> 
> CMOS_BIOS_BOOTFLAG1 (0x38)
> CMOS_BIOS_BOOTFLAG2 (0x3d)
>     - These are used to control boot flags and boot order.

Great summary, thanks.

 
> So, I think "legacybios" should have a simple test at startup - when
> in bochs/qemu mode read the above nvram variables and store them in
> internal storage; when in coreboot mode gather the info from coreboot
> and store them in internal storage and avoid using nvram.

Yes.

Have you looked at libpayload at all?  I was looking at coreinfo, and it
seems to have access to all the information we need.

Thanks,
Myles