On Feb 1, 2013, at 7:44 AM, David Woodhouse <dw...@infradead.org> wrote:
> On Fri, 2013-02-01 at 03:57 -0800, Andrew Fish wrote: >> >> Kevin, >> >> This was all a long time ago, and my memory is fuzzy on things >> 16-bits .... >> >> It looks like generic CSM code locks the 0xC0000 - 0xFFFFF region >> prior to boot, and I seem to remember that this was the common >> practice at the time. I'm not sure what old programs you are talking >> about, but I think they would not run on lots of PCs from the last >> decade+. > > I'm also hearing reports that some video BIOSes are failing when we use > the CSM on real hardware too; they also need the UMB region to be > writeable. > Thats why legacy BIOS has all those user friendly BIOS setup options.... >> All the OVMF does is abstract the 440 PAM registers via the >> EFI_LEGACY_REGION2_PROTOCOL. While it is not an ideal solution this >> code could be updated to lie and not lock a range that the SeaBIOS >> could use. > > Ick. Let's just fix the spec to allow the CSM to tell us what range it > needs to be unlocked, really :) > It might be cleaner to add some PCD values to the LegacyBiosDxe to configure an unlocked area after the Legacy Region Protocol BootLock() is called. > It's an Intel in-house spec, so that shouldn't involve too much pain. Well it did not get standardized because there was not interest in standardizing it. I think in the real world a customized LegacyBiosDxe is constructed that matches 16-bit code BIOS code base. > Hopefully. And there are other things which really *do* need fixing > (like the BBS_TABLE not having any field for LUN or anything like that, > so you can't distinguish between the various devices hanging off a > single PCI controller. Is the problem a lack of a good product name string in the PnP expansion header? > Even IDE master/slave on primary/secondary bus is > only distinguishable by a nasty dirty evil implementation-specific > knowledge right now (knowing that it actually puts primary master in > BBS_TABLE[1], slave in BBS_TABLE[2] etc.). > > I'd really like to fix things *properly* if we can, and resort to dirty > hacks only if we can't do that. I don't really want special-purpose > hacks on either side. > Knock your self out. > -- > dwmw2 > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
