[coreboot] SeaBIOS question and cross compilation fix.
Stefan Reinauer
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?
>>>
>> 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.
--
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
mailing list