[coreboot] passing EFI-console-like info to payloads
corey.osgood at gmail.com
Tue Apr 8 07:52:59 CEST 2008
On Mon, Apr 7, 2008 at 11:12 PM, Peter Stuge <peter at stuge.se> wrote:
> 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.)
Ugh. Anyone want to wager a guess as to how many different PCI (not
including AGP or PCI-E) video cards there are? I don't think we could fit
hardware init for every PCI video card out there into 4Mb. Don't get me
wrong, I love the idea, but I just don't think it's practical.
> > 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
3 things I want to throw in:
- why not have the monitor syncing while coreboot/payload are still running?
Isn't one of the benefits of coreboot to have the (entire) system in a ready
- coreboot always has/should have the option NOT to touch the video/pci
roms, and not to include the emulator, so if the user wants to put it in the
payload, they always have the option.
- if the payload fails before or during video init for some reason, not
every user has a null modem serial cable, or USB debug cable. The sooner
video is up, theoretically at least, the less that can go wrong before it
gets done, and hopefully it can provide something useful.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot