On Fri, 2013-01-18 at 02:59 +0000, Li, Elvin wrote: > Hi David: > CSM framework has mentioned the side effect that "all EFI > drivers are disconnected and must be reconnected for proper EFI > functioning". So if you call the legacy bios protocol interface > LegacyBiosShadowAllLegacyOproms which calls PciShadowRoms internally, > you need reconnect all EFI drivers.
Hi Elvin, thanks for the quick response. I wouldn't really say that *I* called PciShadowRoms(); all I did was build a stock version of OVMF with -D CSM_ENABLE. I'm running qemu with no drives configured; there's *nothing* to boot so it just ends up in the EFI shell. But first it *attempts* to do a legacy boot (and EFI boot) from the empty floppy and CD-ROM drives that qemu has by default. The keyboard driver is unbound when it tries to do a legacy boot from either drive, even though my Legacy16Boot function correctly(?) returns to indicate that no bootable media were found, and GenericLegacyBoot() thus returns EFI_DEVICE_UNSUPPORTED. Is this just a bug? At the end of GenericLegacyBoot() if it *does* actually return from the Legacy16Boot call into the CSM, should it be re-attaching the drivers that it detached? Or at that point does the CSM have irrevocable control of the hardware and we *then* have to bind the BiosKeyboard and other drivers? Including even the EFI driver to thunk into INT 13h, because the BIOS now owns the hard drives too? The specification refers to this as an 'exceptional condition' but I'm not entirely sure why. We *often* have machines configured to boot from a removable drive (CD/floppy) as top priority, and no medium in that drive. If it matters, bear in mind that most of my CSM calls for now are just dummies that do almost nothing except return success. The only thing my CSM really does is populate the interrupt vectors (INT 15h is needed even to *return* from the Legacy16InitializeYourself call), and a proper implementation of Legacy16GetTableAddress. Then all the other Legacy16 calls just print some debug output and returns success. The other thing that confuses me is that the LegacyBiosPrepareToBootEfi function is never called — even when I put a CD in the drive and it *does* boot an EFI OS from it. Is that expected? > So if you already calls LegacyBiosShadowAllLegacyOproms interface, > you can try to reconnect all EFI drivers to make keyboard work again. > For why BIosKeyboard does not work in OVMF, I am not clear, > you need trace the reason. My question is more about what *should* be happening. Are we expected to use the BiosKeyboard driver after a LegacyBoot has failed? If so, I can get on with debugging that (and provide a patch to actually build it in when CSM_ENABLE is defined). Or is EFI supposed to re-register its own drivers before continuing? So far, it's been extremely helpful that all this stuff "Just Works™" on the OVMF side, because the behaviour of the code has served to clarify what it says in the spec. But when it comes to "who should do what with the keyboard", that doesn't seem to have worked out so well for me :) This is all just a legacy PS/2 keyboard. USB will come later... and then I'll have to try to properly understand §2.5.2.5 of the specification, which says that the Compatibility16 BIOS doesn't take over USB emulation until later, and that "INT16 requests must be converted into EFI requests". -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
