Ray, thanks for your answer. This makes sense to me, but I still see some inconsistency in regard to specification.
UEFI spec says: > Address Range Minimum. Starting address of a BAR. and then > Address Translation Offset. Offset to apply to the Starting address of a > BAR to convert it to a PCI address. If it's needed to apply AddrTranslationOffset to AddrRangeMin to convert it *to a PCI address*, how can it be a PCI (device) address already? To me it seems like a discrepancy between UEFI specification and what industry does. Please let me know what is your understanding of the snippets above, if this is a mistake in spec it would be great to agree on that and request appropriate correction. Best regards, Bartosz PS – I wrote PciIoGetAttributes in last mail instead of PciIoGetBarAttributes, sorry for the mistake. 2017-09-05 9:07 GMT+02:00 Ni, Ruiyu <[email protected]>: > Bartosz, > > > > Based on your findings, the AddrRangeMin has to be a device addressJ > > > > As far as I can remember, this history is: > > In the very beginning, Spec owner assumes the device address equals to CPU > address. > > The implementation of GetBarAttributes() directly returns the address read > from the BAR. > > But later we found device address doesn’t equal to CPU address, especially > in ARM platform. > > So in order to expose the offset of the two addresses, the > AddressTranslationOffset field was used. > > To avoid breaking the existing consumers, GetBarAttributes() remains to > return the BAR address. > > > > Anyone please correct me if I am wrong. > > > > Thanks, > > Ray > > > > *From:* Bartosz Szczepanek [mailto:[email protected]] > *Sent:* Monday, September 4, 2017 7:43 PM > *To:* [email protected] > *Cc:* Ni, Ruiyu <[email protected]> > *Subject:* [edk2] CPU/PCI addressing in PciIoGetAttributes > > > > Hi guys, > > > > I have some doubt about PciIoGetAttributes behaviour on aarch64 platform > with non-uniform CPU:PCI address space mapping. I'll be grateful if you > verify my understanding. > > > > According to UEFI specification, AddrRangeMin in QWORD Address Space > Descriptor returned by PciIoGetAttributes() should be a CPU address, at > least that's what I conclude from: > > > Address Translation Offset. Offset to apply to the Starting address of a > > > BAR *to convert it to a PCI address*. This value is zero unless the > > > HostAddress and DeviceAddress for the BAR are different. > > This mentions "Starting address", which I suppose refers to AddrRangeMin. > It needs to be converted to PCI address, so as-is it should be in CPU > address space. > > > > On the other hand, the AddrRangeMin is assigned BaseAddress value obtained > directly from PciBar: > > > Descriptor->AddrRangeMin = PciIoDevice->PciBar[BarIndex].BaseAddress; > > > > PciBar is filled in PciParseBar() using original BAR content (thus > BaseAddress is not translated, PCI address). This way value that refers to > PCI space is returned from PciIoGetBarAttributes as CPU address. > > > > Shouldn't there be translation of it somewhere on the way? Or is my > understanding flawed? Either way, please let me know. > > > > Best regards, > > Bartosz > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
