I've made some progress on using SeaBIOS as a CSM, to the point where I've got it successfully booting Linux and Windows. There's plenty more to do to make it work *right*, and some of what I have done needs cleaning up, but it's a good start.
The main issue I have on the OVMF side is that it locks the entire memory region from 0xC0000-0xFFFFF to be read-only, right before invoking the Legacy16Boot method. This upsets SeaBIOS, which puts a stack in the E0000 segment for use during hardware interrupts and other calls which may otherwise overflow a caller's stack. There isn't anywhere *else* it could put this stack, easily. We're contemplating a hack where its Legacy16PrepareToBoot method sets a flag that tells the IRQ handler *not* to switch to its own stack, and we'll just assume the stack provided by OVMF is big enough. And then the Boot method will re-enable writes to the 0xE0000 segment before clearing that flag again. The implementation of this would be horrid, and it's made even more horrid by the fact that it would then have to do the platform-specific unlocking in its Legacy16Boot method, before re-enabling the normal stack-swapping code. And the CSM isn't really supposed to do that kind of platform-specific stuff. Commenting out the ->LegacyRegion->Lock() call in GenericLegacyBoot() obviously makes this problem go away for now, but that's obviously not the right answer in the general case. It would be nice if there was a field in the EFI_COMPATIBILITY16_TABLE which let the CSM code indicate how much it wants locked. Then we could lock just the option roms and the bit that the CSM asks us to lock, while leaving RAM in between. How feasible would it be to add change the spec to add such a field? If OVMF were to protect just the option roms and the region into which it loaded the CSM image, leaving the RAM in between writeable, that would conform to the existing spec, wouldn't it? If we can do *that*, then potentially I could do something evil like compressing the CSM code so that it fits into 64KiB, then having it decompress itself. So OVMF only locks the region from 0xF0000-0xFFFFF into which it actually loaded code, leaving the range age 0xE0000 onwards writeable as RAM. Any better suggestions? -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
