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)