On Wed, 2015-08-26 at 07:18 +1000, Benjamin Herrenschmidt wrote: > > > I think you have it backwards. The UEFI spec abstracts PCI > > properly, > > and drivers are implemented incorrectly, but they work due to x86 > > PC > > assumptions. > > > > GetBarAttributes() returns the BAR. > > Well, the spec doesn't spell it out precisely but ... > > > That is the correct thing to do. If that Bar was accessed via> > > EFI_PCI_IO_PROTOCOL.Mem.Read()/EFI_PCI_IO_PROTOCOL.Mem.Write()//EFI > > _P > > CI_IO_PROTOCOL.CopyMem() then it is being accessed relative to the > > BAR and everything should work. Casting a pointer to the value > > returned in GetBarAttributes() is not guaranteed to work. > > Except that a lot drivers do it :-( > > For example anything using OptionRomPkg/Library/BitBltLib does it. > > So the GOP drivers in-tree in EDK2 do it, I can ask nVidia what their > EFI driver does but I woudn't be surprised if it's everywhere.
Ok, correction, this is even worse. You *cannot* implement a complete GOP driver without that assumption. A GOP driver is supposed to provide a EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE structure, which contains a FrameBufferBase which is defined to be the CPU physical address of the frame buffer. So if we stick to the definition of GetBarAttributes() only returning a BAR value, then it's impossible to implement a PCI GOP driver by following the spec. Now, there's one thing that might work, which would be to exploit the "AddressTranslationOffset" field of the ACPI resource descriptor. AFAIK, the UEFI spec doesn't do a very good job at describing how it uses these descriptors (this is an interesting "dependency" between UEFI and ACPI btw, my platform otherwise doesn't use ACPI). EDK2 hijacks that field for other means bct that should be fixable. I'll try to hop on the UEFI call tomorrow (morning my time, ie, .au) in place of the IBM rep (it's too early for Jeremy anyway) and start that discussion. As it is, there is a contradiction in the spec between PCI trying to prevent direct access to BAR regions and at least GOP requiring to pass a physical address pointing to the device (and possibly other IO protocols, I haven't looked in details). Cheers, Ben. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
