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.