> Agreed. Note that so far putting the real mode code *above* 0x90000 is
> completely untested. It *should* work with boot protocol 2.02 support; it
> almost certainly *does not* work with earlier boot protocols (due to the "move
> it back to 0x90000" braindamage.)
:)
When I got to thinking about this the biggest savings in memory usage I can
implement is having misc.c relocate it's compressed data before
decompression, instead of having it relocate the decompressed data
afterwards. Ugh more heavy lifting to do.
Running the real mode code above 0x90000 is likely to happen in one of my
test cases.
- Load the kernel under a normal BIOS.
- Enter through the 32bit entry point
- Decompress the kernel
- Realize we need to do 16bit BIOS calls
- Renter through the 16bit entry point.
Sounds like fun.
I suspect the reason I didn't consider moving the real mode address
lower is that (a) I haven't run into the problems with 0x900000 and
(b) under etherboot I can easily load the real mode code at 0x1000,
which makes it look absolutely absurd. And won't work because of the
current misc.c code.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/