On 07/04/08 16:29 -0700, Stefan Reinauer wrote:
Jordan Crouse wrote:
As far as I am concerned, coreboot should have nothing to do with graphics
- initializing graphics is up to the individual payloads. If it
is the kernel, then it should be a framebuffer. if it is something else (say, a libpayload based payload) then that "something else" needs to handle it. Yeah, this isn't at all like how a traditional BIOS does it, but we're not designing coreboot to be a drop-in replacement for a traditional BIOS.
Are you implying that we should move the x86emu / vm86 stuff out of coreboot and into libpayload?
That would bring us a couple of advantages like being able to use the same instance of code for int13h emulation to boot off SCSI drives via option rom.
I'm not sure that SCSI will be a going concern for libpayload for some time. :)
Seriously, though - I think that optionROM handling should remain in coreboot, because I think thats the best place for it. Yes, an optionROM might start VGA, but that shouldn't mean we implicitly condone all graphics init in coreboot, just like we don't plan to spin up drives just because a RAID card optionROM is initialized.
On a slightly different topic, we want to be careful not to move much functionality from coreboot to libpayload, because libpayload won't be used in many situations - it won't be used in conjunction with grub2 for example, nor for LAB, nor for gPXE - so we don't want to limit behavior that other payloads may find useful. Libpayload is _not_ a payload to rule them all.
Jordan