[SeaBIOS] Running out of space in e/f-segments

[Gleb Natapov]

On Sun, Aug 22, 2010 at 01:37:48PM +0300, Avi Kivity wrote:
>  On 08/21/2010 09:41 PM, Kevin O'Connor wrote:
> >SeaBIOS is coming close to exceeding 128K in size.  Right now, it's
> >approximately 107K on qemu with default options and 120K with
> >full debugging and all options enabled.
> >
> >SeaBIOS currently contends with option roms for space.  Every byte
> >that SeaBIOS uses is one less byte available for option roms.  It's
> >technically possible for SeaBIOS to exceed 128K, but it's likely that
> >we'll start seeing option roms not fitting around that point.
> >
> >It would also be nice to be able to do malloc_low allocations from the
> >e-segment.  This too requires freeing up space that SeaBIOS is
> >currently using to store code.
> >
> >I've been thinking of a few different ways to free up space.  The most
> >promising approach seems to be to relocate all or part of SeaBIOS'
> >32bit "flat" code.  This 32bit code is larger than the segmented code
> >(67K vs 40K) and it's the area that has been growing the most.
> >
> >To relocate the code, the build can store a list of code that depends
> >on a fixed address and then at runtime SeaBIOS can modify the code
> >with the new address.
> >
> >Some different permutations of this idea that I've come up with are:
> >
> >1 - On boot, have SeaBIOS relocate all of it's 32bit code to permanent
> >     high ram.
> >
> >     CONS: Reserves memory that then can't be used by the OS (67K
> >     today).
> >
> >     CONS: SeaBIOS code is still limited to 256K size (c+d+e+f
> >     segments)
> >
> >2 - Have the build separate out the POST code from other 32bit code
> >     (eg, boot&  resume) and store the POST code in a separate
> >     CBFS/fw_cfg "file".  During boot SeaBIOS would extract the
> >     separate POST code blob into temporary high ram and run it.
> >     Currently, the POST code is the bulk of the 32bit "flat" code (57K
> >     vs 10K).
> >
> >     CONS: It adds complexity during deployment as both the main
> >     SeaBIOS blob and the CBFS/fw_cfg POST blob would need to be
> >     copied.
> >
> >3 - On boot, relocate only POST code to temporary high ram, and have
> >     SeaBIOS reset the machine if the POST code is ever rerun.
> >
> >     CONS: Requires a reliable way of resetting the machine.
> >
> >     CONS: SeaBIOS code is still limited to 256K size (c+d+e+f
> >     segments)
> >
> 
> 4 - Have the entry points switch immediately to 32-bit mode and call
> 32-bit unpaged code in 4G-2M+.  Everything, for example the INT 13
> code, would run in 32-bit mode from high memory.
> 
IIRC this was discussed already. Some applications call BIOS from vm16
mode so switch to 32-bin is impossible.

> PRO - unlimited memory
> PRO - less restrictions from .code16gcc, can easily handle far
> pointers (a single function will covert a far pointer to a real
> pointer)
> PRO - smaller code (since .code16gcc uses 32-bit code with lots of prefixes)
> PRO - easier to debug, since the tools are geared towards flat
> memory models (except for the thunk code)
> CON - slightly slower due to mode switching
> CON - a lot of work (but can make it incremental)
> 
> 
> -- 
> error compiling committee.c: too many arguments to function
> 
> 
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS at seabios.org
> http://www.seabios.org/mailman/listinfo/seabios

--
			Gleb.