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

[Avi Kivity]

  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.

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