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 not.
//Peter