Thanks, Andrew Fish
> On Aug 25, 2015, at 2:43 PM, Benjamin Herrenschmidt <[email protected]> wrote: > > 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. > I came to that conclusion too. > Now, there's one thing that might work, which would be to exploit the > "AddressTranslationOffset" field of the ACPI resource descriptor. > How do you represent a system like this in ACPI? It might be a good idea to solve it in a similar way. > 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). > The PCI IO was designed to not required the 1:1 mapping. The direct access to the Framebuffer came along later, as was mostly a fallback for the OS on a safe mode boot kind of thing. I think we missed passing the frame buffer out on a system that was not 1:1. Thanks, Andrew Fish > Cheers, > Ben. > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
