[coreboot] passing EFI-console-like info to payloads

[Jordan Crouse]

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

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.