On Thu, 2003-04-17 at 11:44, Steve Gehlbach wrote:
This reminds me of something I have intended to mention. Right now, linuxbios starts up in the high 4G and jumps to the start of the assy code, which is located at 0xffff0004 or 0xf0004 depending on the setting of biosbase (which sets _ROMBASE). For biosbase set to 0xffff0000, the jump is a 16-bit relative jump to 0xffff0004 and so it does a kind of wrap around I think (segment register not reloaded).
Given the large LPC flash parts are coming, and so large flash storage, it seems we should change the startup to set 32-bit mode first, then jump 32-bit to the start of the assy code. The usual way that I have done this jump relative on reset enough bytes below the reset vector, to setup a flat gdt, and go into 32-bit mode, then jump 32-bit to the flash code start. This allows one to start anywhere in flash, not just the top 64k-bytes. I also think we should default to wp cacheing for the flash region as well.
In my view anyway, the current startup jump seems clumsy, and I am not clear on why one would want to jump to 0xf0000 (the default) and run there (for those that aren't familiar 0xf0000 is normally aliased to 0xffff0000 by most if not all chipsets on startup, and doesn't become ram until you enable it). But being in 32-bit mode you could go where you want.
The very first LinuxBIOS implementation does almost this. Part of the historical reason of 16-bit code is, for DoC with only 512 IPL area, every bit counts. So the asm code for chipsets with DoC support are coded in 16-bit mode instead of 32-bit mode. Now, it seems that DoC is obselete by the non-open attitude of its manufacture and Firmware Hub, we may consider consolidating these asm code to 32-bit in the next development cycle.