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

[Kevin O'Connor]

On Sat, Aug 21, 2010 at 09:26:30PM +0200, Rudolf Marek wrote:
> >1 - On boot, have SeaBIOS relocate all of it's 32bit code to permanent
> >     high ram.
> 
> I have done some experimental reloc code for Coreboot. I took it
> from memtest86. Check how to do that.

I've looked through that code - I think there is an even simpler way.
The linker knows exactly which parts of the code depend on a fixed
address.  (See: strip --strip-unneeded out/code32flat.o -o foo.o ;
objdump -r foo.o )  The build can store this info and then the
relocated code can be modified at runtime to live at its new address.

>The best would be to simply
> add diferent base
> to segs. You have the physmem accessors anyway so maybe way to go
> here. Check FILO. I think it uses this.

I don't think modifying the segment registers will work well for
SeaBIOS.  The 32bit code has pointers to both absolute addresses (eg,
BDA, interrupt table, malloc addresses) and relative addresses (eg,
variables, function pointers).  Having to distinguish between the two
types in code would be a pain.

> >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.
> 
> And relocation perhaps necessary because during resume you would
> need to place it in some reserved range.

The boot and resume code would not live in the POST blob, so it
shouldn't be a problem.  (Resume is technically in POST, but the
current code checks for resume very early on - I'd keep that the same
and only extract the code that is done after the resume checks.)  The
resume code is really small - the 10K number above includes both boot
and resume.

Code relocation would probably still be necessary though, as there
isn't really a safe static place to put the POST blob even during a
normal boot.

> >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)
> >
> >Any thoughts?  I kinda prefer option 3.
> 
> Yes looks good to me too (and easiest) How you deal with resume here?

As above, don't relocate the boot and resume code (or any code
reachable from it).

> 
> > Resetting the machine on a
> >rerun of POST would be a good thing to do anyway, as trying to re-post
> >the machine has never really worked well.  It does, however, make the
> >build a bit more complex.
> 
> Reseting the machine can be done in various ways:
> 
> http://lxr.linux.no/#linux+v2.6.35/arch/x86/kernel/reboot.c

Thanks.

> What about other CPUs?

Not sure what you mean here.

-Kevin