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

Peter Stuge peter at stuge.se
Tue Apr 8 05:12:57 CEST 2008

On Mon, Apr 07, 2008 at 08:52:27PM -0600, Jordan Crouse wrote:
> > My opinion is that option ROMs should not be needed, and that we
> > have code for basic init for all supported hardware in coreboot.
> Is it really worth supporting dozens upon dozens of cards when
> all those cards already come with their own code free of charge?

Long term, yes I think so. The common open source driver rhetoric
applies, vendors probably don't really like that code. Pushing it
outside their organization should be beneficial both for them and
users. (Though I expect the transition to be a little bumpy because
of differing work environments, habits and standards.)

> I know that optionROMs are proprietary and closed and scary but
> they work.

They are also machine specific and sometimes painfully slow.

We can work around the first part with x86emu, which is a cool trick,
but not so elegant. :)

> > 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.

They could use it if it was left in a defined state.

> 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.

Agree for coreboot itself, but the point would be to do enough in
order to make them usable.

The console is a little special since that is where the user is, and
while coreboot should work without user intervention, payloads may


More information about the coreboot mailing list