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

Jordan Crouse jordan.crouse at amd.com
Tue Apr 8 04:52:27 CEST 2008


On 08/04/08 02:36 +0200, Peter Stuge wrote:
> On Mon, Apr 07, 2008 at 06:14:01PM -0600, Jordan Crouse wrote:
> > > The libpayload stuff for geode is nice, but there is similar code
> > > for ATI cards in linuxbios, and there is option rom based init in
> > > another place. 
> > > This is very scattered and I don't really see the reason for
> > > that, nor believe it makes sense.
> > 
> > My opinion is - during PCI init, if you have an optionROM, you
> > should run it.   If we start deciding to run some optionROMs and
> > not others, then we'll get confused fast.

> My opinion is that option ROMs should not be needed, and that we have
> code for basic init for all supported hardware in coreboot. (Set a
> graphics mode or init a SCSI controller, but not spin up disks.)

Is it really worth supporting dozens upon dozens of cards when
all those cards already come with their own code free of charge?  
I know that optionROMs are proprietary and closed and scary but they
work.

> 
> > My other opinion is that native graphics drivers should run in the
> > payload, We should lose the ATI card stuff in coreboot.  That
> > consolidates the code by type - native code in the payload,
> > optionROM in coreboot, and we can ignore what actual device either
> > mechanism runs.
> 
> Short term (a few years or so) I pretty much agree.
> Long term I think I would like to set a graphics mode in coreboot.

What value would such a thing have, other then putting up a 
splashscreen?  We won't have callbacks, so payloads couldn't use it.
It would only be able to communicate the coreboot boot progress and
if we play our cards right coreboot will boot so fast that we'll be
in the payload before the screen even syncs.  In the large collection
of things that coreboot doesn't need, I think video and NIC cards are
number one on the hit parade.

Jordan

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





More information about the coreboot mailing list