ADLO committed

steven james pyro at
Mon Nov 25 09:31:00 CET 2002


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.

-------------------------steven james, director of research, linux labs
... ........ ..... ....                     230 peachtree st nw ste 701
the original linux labs                    30303
      -since 1995                    
                                   office 404.577.7747 fax 404.577.7743

More information about the coreboot mailing list