[coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

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