On Wed, May 21, 2008 at 03:50:52PM -0600, Myles Watson wrote:
On Wed, May 21, 2008 at 3:32 PM, Stefan Reinauer stepan@coresystems.de wrote:
How much of the F segment is actually used by legacybios?
All of it. The callback entry points are at fixed locations, and the rest of the code lives there too.
The payload is currently 64KiB in size - so deploying the payload today will overwrite the entire F segment.
However, it isn't necessary to use the full F segment. The fixed entry points are entirely in the last 8K of the segment. (The first hardcoded entry point is "post" at 0xfe05b.) The remaining 56K is then used for C code. We're currently using about 43K for both 16bit and 32bit C code (although with coreboot, we turn off a bunch of stuff and are really at about 36K). This leaves another 13K for future C code growth.
So, we could place the C code 1K in from the start of the F segment and then use the first 1K for tables. Another option is to use the 1936 bytes from 0xff0b0 to 0xff840 - this is an unused area in the middle of the fixed offset area of the bios - it is unusable for C code and otherwise empty. This is where I currently place tables generated by "legacybios".
Of course, this assumes we only place the headers of tables in the F segment and then place the rest of the tables in a reserved memory area (usually at the top of memory). If we do this, it would require setting up an e820 map that ensured that the top of memory didn't get zapped by an OS. Where this reserved memory is located and how much of it is reserved would be one more thing to pass to "legacybios" so that it can handle e820 requests.
Should we put that stuff into the lbtable as an option and have legacy relocate it? Or is there a safe place where we can put them to begin with..?
Right - if coreboot creates the tables, we either have legacybios copy them around, or work out some way to ensure that legacybios doesn't overwrite them when it gets deployed.
From my point of view, the latter is easiest. However, the former is
likely more flexible.
-Kevin