Supporting extension ROMs and beyond...

Stefan Reinauer stepan at
Tue Aug 12 10:19:00 CEST 2003

* ron minnich <rminnich at> [030812 15:33]:
> On Tue, 12 Aug 2003, Stefan Reinauer wrote:
> I'm not so sure. The emulation code supports the INT functions needed for 
> vga setup. I would actually be inclined to dump ADLO rombios.c completely 
> and replace it with real C code. 
which is what the freebios1 bioscall code and util/vgabios/testbios do
already, just in a non-complete way.

> ADLO is a great proof-of-concept but after walking the code I find too 
> much assembly in there, most of it not needed.

> It's the bochs heritage. 

definitely. they put a lot of focus on having all the fixed address bios
entries at the right place, but we hopefully dont need that to
initialize vga (at least the milo x86 emulation code never did that)
> If you look at the x86 emulator in the freebios tree, you can see it 
> supports emulation and in addition provides (in normal C, not bcc) 32-bit 
> functions for vga calls to the bios.
> >  1) x86 realmode code execution.
> >  2) legacy api emulation/implementation (pcibios, etc)
> > 
> > * LinuxBIOS1 on x86 supports 1) directly and does 2 with an emulation
> >   (pcibios.c)
> I'm not sure I agree with your definitions. 
> Emulation means (to me) emulating an x86 via software instruction decoding 
> and execution. 
I used emulation in addition when calling 32bit C code instead of a
16bit bios interrupt. Just replace this with "legacy support code" then.

> the pcibios code is not doing emulation --  it is supporting pcibios 
> functions, albeit in 32-bit mode. 
> While the x86emu will fit in with etherboot, it won't fit in with a linux 
> kernel. 

I agree, but it is still a really big step forward. When you want video
support, you either have network or a disk or a completely custom
application without linux anyways. 


More information about the coreboot mailing list