Kevin O'Connor wrote:
On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Simple:
a) I don't want to maintain my own bios emulation in coreboot v3 b) I still want graphics initialized (and possibly more) c) I don't want to use int19 booting / I don't want to use seabios as a payload.
- because I might be running in an emulator or not
- because I am running other payloads and I want to spend as little
time in seabios as possible
- because I think this is the only possible way to do a soft
transition of the code that is in coreboot these days and what we might see some day in the future.
That said, I must have missed the mail you are talking about.
I was thinking of the chain of emails at:
http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html
My (new) thinking is that we could:
Continue to have seabios be a coreboot payload
Have seabios find, copy, and run options roms on pci cards. Have it scan the lar for pci devices with option roms embedded in flash.
Teach seabios to be able to launch a payload from flash in addition to floppy, hd, cdrom, etc..
The main gain to the above is is that we can keep all the legacy x86 real mode crud (including option roms) in one place (seabios), and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
My main concern is that if seabios becomes a defacto mandatory payload for coreboot, then having two separate projects to put together will be an undue burden on the builders. My thinking has always been that at the time when something becomes essential to the operation of coreboot, it should be merged into coreboot.
Jordan