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
Sure, many want that. But some don't. I'm looking into how to make everyone happy;
- 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.
For example, I'd really very much prefer if coreboot stays the active instance for option rom execution for my application case.
Because otherwise I'd have to re-implement a lot of stuff in SeaBIOS that already is in coreboot. As you suggest, too.
My approach is to drop code from coreboot instead, because SeaBIOS does a good job there.
- Teach seabios to be able to launch a payload from flash in addition to floppy, hd, cdrom, etc..
That's pretty much re-inventing the wheel, or growing three legs just to cut one off. Why would one go such a complicated way instead of just returning from seabios after init?
SeaBIOS really does a lot of stuff betweeen setting up interrupts and running the OS that don't belong in a "we just want VGA on" scenario.
Also, I think, SeaBIOS does not need to know about LAR.
Let's try to make both projects simple, not both projects complicated.
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).
Oh, but that works nicely with my approach, too. I reduced real-mode code in coreboot by 90% during my experiments.
and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
We do have to worry about that in all scenarios though.
Just assuming it's ok for SeaBIOS to overwrite memory that coreboot filled is not good enough.