Supporting extension ROMs and beyond...

Stefan Reinauer stepan at
Sat Aug 9 14:10:01 CEST 2003

* SONE Takeshi <ts1 at> [030809 19:40]:
> On Fri, Aug 08, 2003 at 03:23:42PM -0600, ron minnich wrote:
> > Bochs is neat, but not simple. Maybe, however, we can make it simpler. I
> > really don't want to write x86 asm at this point, however. If I do this I
> > want to do it by building on the VGA BIOS stuff I wrote for 1.0.
> That's what I'm intersted in doing.
> Also I felt that doing this in LinuxBIOS core could be wrong direction
> for the project, so I posted the first question.
> I think Ron's src/extension idea makes a lot of sense.

going all the way to the end this could mean that the elf loader goes
to the extensions directory as well, reducing the LinuxBIOS kernel to 
three parts: 
* Assembler starter: switching to protected mode
* romcc code: initializing ram controller and starting 
  LinuxBIOS C payload
* gcc code: initializing static and dynamic devices so that
  they can be used by the extensions

Extensions could be "stackable" and configurable for certain
application goals:
* legacy emulation for VGA and SCSI init
* elf loader
* openbios kernel

My OpenBIOS multiboot kernel is currently 6.6k big, implementing all
forth primitives needed to build an Open Firmware implementation on top
of it. It includes a small console implementation for serial and vga.

The extensions idea could integrate this kernel sanely and even reduce 
the code as the interface to LinuxBIOS and the console code could be

> > The VGA BIOS code in 1.0 has proven to be pretty easy to use for people,
> > it's 32-bit code, and it's pretty easy to fix. Also, like the rest of 
> > LinuxBIOS, it has a very small assembly bit and the rest is C. 
> Yes, that is why I like this code. This can be easily and cleanly
> extended, unlike Bochs BIOS.
> As Eric pointed out, this approach has drawbacks, with regard to
> full compatibility, it still has many advantages over the way
> Bochs doing.

On the other hand, it has certain advantages as well, the code can
probably easier integrate an x86 emulation, like milo/srm do on alpha
and some free ARM firmware implementation does as well..


More information about the coreboot mailing list