Random comments on LinuxBIOS

[ollie lho]

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.

-- 
ollie lho <ollie at sis.com.tw>