pyro at linuxlabs.com
Mon Nov 25 09:57:00 CET 2002
I was thinking of locating the function table somewhere in ram. Perhaps it
and the code itself could go in the 64 K at 0x100000 and A20 could be
turned on to access that small highmem area with the segment register set
at 0xffff. I hadn't considered that this would be Real mode (though I
should have, more coffee needed!). That implys the approach of personality
module compiled from LinuxBIOS source rather than direct dispatch into
On Mon, 25 Nov 2002, Adam Sulmicki wrote:
> 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:
> > Greetings,
> > 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
> > itself.
> > 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.
> > G'day,
> > sjames
> > 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.
> > >
> > >
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
More information about the coreboot