Ronald G Minnich <[EMAIL PROTECTED]> writes: > On Thursday 03 January 2002 22:34, Eric W. Biederman wrote: > > > > Currently I have code looking for my tables between 0xf0000 and > > 0x100000, the last 64K before 1MB. > > do you mean that you are implementing native linuxbios tables and passing > them to linux?
Essentially. A big observation when I specced out elf booting is that passing the data from linuxbios to the bootloader, and from the bootloader to linux is the wrong way to do things. Life becomes much simpler if you can just scan through memory for the table. And more importantly it lets bootloaders just concentrate on booting the appropriate image. Plus it is a simple enough idea that it should be hard to get patches into the 2.4 series kernel. As far as table data, my gut reaction is that in the general case doing our native tables is better than rely on something some else specced, out. Because then we can put in the information that make sense from a linuxBIOS standpoint. Longterm I'd like to have the current irq tables generated by reading the native linuxBIOS tables and just writing them out. Having table entries for the ring-buffer if compiled in would probably be useful as well. > > So far where linuxBIOS lives in memory is not something we have been > > at all consistent at between ports, and instead have simply made > > it configurable and it probably time to start a discussion about what > > we can do if anyone else is interested. > > if we have DoC, making linuxbios live at 0xf0000 is going to always require > enabling bios shadowing in the chipset. That could be trouble. Perhaps. For 0xf0000 - 0x100000 I was just thinking making the rom live there. Generally I haven't seen a problem with enabling RAM in that region, but I gues if you ever do a far jump in 16 bit assembly it is an issue. > > The tables or at least a pointer to them need to be in the low always > > present part of memory, because amoung other things they contain the > > memory size. > > what about physical page 0? Just wondering. Is that used? it certainly gets > turned off totally at some point. It gets touched, to verify that a20 is working, so there is a small amount of code that we might need to fix but otherwise it sounds good. It will be interesting reserving physical address 0 and saying don't use this... So the ideal location is address 0. It is always present and is at the very top of memory, as much out of the way as you can get. But we do have some small issues with people doing things with the legacy 16 bit interrupt table. So a classic x86bios would have trouble putting it there. Address 0xf0000 is second best. It is almost always always possible to use as ram. But it has issues with being needed by 16bit assembly code. For now I will have my code try both locations at 16 byte intervals for 64K. If Anyone who additional gotchas please tell me. Eric
