IDEA: Linux kernel and pcbios compatibility...
Eric W. Biederman
ebiederman at lnxi.com
Fri Dec 19 06:49:01 CET 2003
Takeshi Sone <ts1 at tsn.or.jp> writes:
> On Fri, Dec 19, 2003 at 12:49:42AM -0700, Eric W. Biederman wrote:
> > Adam Sulmicki <adam at cfar.umd.edu> writes:
> > > you mean just like dosemu runs under linux ???
> > Right but for BSD and early versions of windows the dependencies
> > were worse. I don't know which services matter though.
> Last time I saw the source code of FreeBSD, its _bootloader_ has its
> own vm86 monitor (in assembly), works in protected mode,
> and calls all the BIOS calls (video, keyboard, disk,...) in
> vm86 mode. Also the kernel calls E820, APM, VESA, etc in vm86.
> Also I saw a recent version of Windows calls BIOS services in vm86.
> Maybe we can modify FreeBSD, and have work-around for Windows,
> but at least I don't think it's the way to go.
Thanks. I knew this was the biggest danger, and from the description
it looks like no half measures will do.
> My conclusion then was that PCBIOS had to work in real mode.
If that is the case the PCBIOS has hit an evolutionary dead,
as the code size cannot increase, there is very little
room for change remaining. This explains ACPI. And
it makes EFI look much more attractive.
I think I see one way out of this pickle, implement the firmware
in System Management mode. System calls will be slow and we will
need an interrupt reflector but this does allow us to escape the
bounds of vm86 mode, and the legacy limitations. And our
OS will even have some protection from ``user mode''.
System Management mode is essentially big real mode. So
code would need to be compiled with .code16gcc, but there is
a full 4G available. I know with amd's processors I can switch to
32bit or 64bit protected mode inside of smm mode, Intel's
documentation is not clear on that point, so I don't know what
we can do there. Depending on what works it may make sense
simply to build an smm mode trampoline to get out of vm86 mode.
> Maybe we can code it with GCC and .code16gcc hack.
> If 64KB is not enough, maybe 0xE000 segment can be used
> so that we have 64KB code and 64KB data segments.
> And all the "POST" code can be outside the real mode space.
> So it's not impossible or hard at all.
For just PCBIOS compatibility I agree. Primarily I want
that layer to exist as an add-on and an after thought. Something
that gives backwards compatibility but allows us to do something
With only 256KB of room, there simply is not enough room to
implement drivers of interesting hardware. Nor is there enough
room to implement interesting protocol stacks. And it limits
what we can do in the future.
More information about the coreboot