adam at cfar.umd.edu
Mon Nov 25 09:38:00 CET 2002
One of the big issues is that for compatibility reasons we have to have
our bios at 0xF0000 and video bios at 0xC0000.
However it occured to me that while we keep our bios in RAM, the LinuxBIOS
is still out there in the ROM. So perhaps BIOS function could switch
on/off some 16kb area in RAM to ROM and get the needed data from there and
switch back. (sort of like EMS in DOS days.)
It still does not answer how to do chipset independent control of shadow
On Mon, 25 Nov 2002, steven james wrote:
> I've been looking at the issue of LinuxBIOS functions as well. The
> baremetal toolkit is about 90% code drawn from LinuxBIOS
> itself. Currently, it is standalone and does not address chipset specifics
> One approach I've given some thought to is a simple function
> table. Another is to use the symbol table somehow. I want to keep that as
> simple as possable or better yet, figure a way to avoid it alltogether
> since I agree w/ Ron that we don't really want LinuxBIOS to turn into a
> mini OS.
> It may be that the most versatile approach might be a sort of personality
> module with a function dispatch table that can be built from the chipset
> and board specific elements of LinuxBIOS so that at least it is not part
> of LinuxBIOS itself.
> All of that also implys a new memory type description for the LinuxBIOS
> table, memory that is RAM but shouldn't be overwritten unless there is no
> intent to return to the previous layer or use it's functions. The bounce
> buffer and possable future personality module would be located in such an
> area. The final OS would be free to overwrite all of that since it
> wouldn't likely return anyway.
> On Sun, 24 Nov 2002, Adam Sulmicki wrote:
> > > Is this the recommended way to boot a Linux kernel from CompactFlash or
> > > should I continue trying to figure out why elfboot won't look at IDE
> > > with option BOOT_IDE=1?
> > maybe someone else can answer this.
> > I'll just add that when ADLO is used an plain linux kernel without any
> > modifications can be used. Ie no need to patch it.
> > > The Bochs BIOS is built around the BX chipset IIRC, which isn't far at all
> > > from the TX chipset.
> > I think it is mostly the Bochs "hardware" not the BIOS itself that's build
> > about the BX chipset. The BIOS itself is fairly generic and pretty
> > adapable for our needs (the big issues related to it is somewhat
> > simplistic hardware model. ex : no delay loops (ATA) or incomlete
> > emulation of hardware (KBD,PIRQ) ).
> > What's most chipset dependant in our project is the loader it self
> > (loader.s). It must do some preparatory work before it can start bochs
> > bios. One of the key issues is that the address at 0xF0000 has to be ram
> > mapped and it got to be Read/Write.
> > We still are not sure what's the best way to interface the LinuxBIOS and
> > BOCHS BIOS. There's need for some information to be passed between the
> > two. Those include: Mem size, E820, PIRQ, how to manipulate shadow ram,
> > how to reset chipset (reboot). Of above first 3 are data scrutures, last 2
> > are functions. If we can do this, we can keep BOCHS BIOS (and ADLO)
> > generic and leave all chipset specific stuff to LinuxBIOS.
http://www.eax.com The Supreme Headquarters of the 32 bit registers
More information about the coreboot