Random comments on LinuxBIOS

[Eric W. Biederman]

Steve Gehlbach <steve at nexpath.com> writes:

> Eric W. Biederman wrote:
> 
> > For LPC flash parts the address line count is not a real issue, new boards
> > have them and they current are up to 8Mbit in size, but do not have a
> theoretical
> 
> > limit.
> 
> 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).

The CPU starts at: CS = 0xFFFF0000 IP=0xFFF0  So you have an entire
64K to work with.
 
> 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.

WP caching??  We should cache it certainly but note
that WP caching != Write Protect in the normal sense.

Except for the location the 16->32bit transition this is pretty much
what the code currently does.  And for our ``normal'' images when
we have 2 copies of LinuxBIOS the start up is entirely 32bit.

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

There are other reasons for keeping the BIOS image small so a 64K
restriction has not been a big deal.  That is the reason it has not
changed up to this point.  But thank you for the reminder.  This is
something that is worth looking at the development branch along with 
removing the estimates of LinuxBIOS size that we currently use.

> Maybe there is a good reason for this but it escapes me.

Mostly it is one of those we started with it and have not
yet found it to be a real limitation.

Eric