On Sat, Nov 10, 2012 at 8:25 AM, Thorsten Glaser <[email protected]> wrote: > Kevin O'Connor dixit: >>1 - Using SeaBIOS as a CSM. The CSM spec is amazingly complex as > >>2 - Implementing in SeaBIOS a subset of the EFI OS interface so that > > Both aren’t really what I want.
It sounds like you definitely don't want 2, but you do want something similar to 1. In a UEFI+CSM system, the CSM essentially provides the environment that legacy BIOS based software can use. >>To be clear though, neither of the above paths would enable you to >>boot something like DOS on an existing UEFI system. It may be > > Yeah. I was more thinking of having SeaBIOS be an EFI “OS”, > just like the MirBSD bootloader is a Multiboot compliant “OS > kernel”, and then take over the system and load the real OS, > providing BIOS calls to it. How do you generically deal with chipset memory protection in 0xc0000-0x100000? (Ie, shadow ram that Kevin mentioned.) You may find that you need a 'chipset driver' to allow you to write these regions. UEFI has the LegacyRegion protocol for this for CSM systems, for example. But, in a non-CSM UEFI system, there is no need for the LegacyRegion protocol. It could be that in a post-CSM UEFI world that these regions will generally just be set to RAM mode, but I wouldn't bet on it. It certainly seems unlikely that you could rely on this for all UEFI systems. In OVMF we currently leave those regions in ROM mode. -Jordan _______________________________________________ SeaBIOS mailing list [email protected] http://www.seabios.org/mailman/listinfo/seabios
