ADLO committed

[steven james]

Greetings,

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
LinuxBIOS.

G'day,
sjames



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
> RAM.
> 
> 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
-----------------------------------------------------------------------