[SeaBIOS] Running out of space in e/f-segments
Gleb Natapov
gleb at redhat.com
Sun Aug 22 13:15:58 CEST 2010
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.
More information about the SeaBIOS
mailing list