[coreboot] SeaBIOS question and cross compilation fix.
stepan at coresystems.de
Fri Nov 7 02:18:34 CET 2008
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?
>> 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
>> * 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:
> 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
> * 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.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
More information about the coreboot