On the way back to EFI from the very first InitializeYourself() call into CSM, the thunk code makes an INT 15h AX=0x2401 call to enable A20.
This confused me a little since it meant that my extremely simple 'Hello World' implementation didn't work; it crashed *after* returning to the EFI 16-bit thunk code. So I made my code *actually* initialise itself, at least as far as the INT 15h handler, and now things are working significantly better. I haven't looked hard at the details of how SeaBIOS attempts to toggle the A20 gate; I only care that it didn't crash. I'm working through implementing the CSM Compatibility16 calls in the order that OVMF calls them, and now I've got as far as UpdateBbs()... and I see that this is where the 16-bit actually gets told *how* to switch A20 on and off, in the LEGACY_DEVICE_FLAGS structure which is part of the boot table. So... what is the 16-bit code supposed to do on the way back from the InitializeYourself() call, before it's told which method to use? Does it even need to do *anything*? If we're calling into dedicated 16-bit CSM code and nothing else, why not just leave A20 enabled and trust that the CSM code won't try to use magic overflowing pointers? -- 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_122712
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
