[coreboot] [RFC] port bochs-bios to gcc

Peter Stuge peter at stuge.se
Tue Feb 26 03:33:20 CET 2008


On Mon, Feb 25, 2008 at 07:29:15PM -0500, Kevin O'Connor wrote:
> > If by "table" you mean code the answer is that coreboot does not
> > like callbacks by design.
> 
> Well, it wouldn't be coreboot that got the callbacks, it would be
> that binary blob at 0xf0000.
..
> Seriously though, I don't think implementing the real-mode irq
> handlers is that technically challenging

No, certainly not. However, I think that coreboot being legacy-free
is a very important, if not the most important, feature.

Yes, there is a transition period where some systems need a legacy
layer in order to start up, but I really want that to be distinct
from coreboot.


> So, I'd look at it as coreboot initializing and loading another
> "table" at a certain area of memory.

I draw the line at code (hence my dislike for ACPI and VSA) and had
this in fact been nothing but a table I would not mind, but since it
is code I think it should never be closer to coreboot than being a
payload.


> Some OSs will make use of it - others wont.  I don't see a lot of
> down sides to deploying it.

It would always be present, regardless of whether an OS does make
use of it or not. It would waste resources and be generally unclean.
Worst-case it would cause conflicts or confusion.


> The big upside is that, with the proper handlers, all modern OSes
> will load out of the box.  This will be a big selling point to
> hardware vendors - especially those that want to deploy a single
> solution for both mass-market and niche markets.

I consider the BIOS interface to be useless for new systems and I
don't want to further expanded BIOS use in any way.

Your point is crystal clear, and I completely agree that at present
there simply must be a way to get these legacy interfaces.

I certainly appreciate you reviving ADLO and your effort with
bochs-bios, but I do not want it included and always-on.


//Peter




More information about the coreboot mailing list