On Sat, Nov 10, 2012 at 8:25 AM, Thorsten Glaser tg@mirbsd.de 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