Hi
I was implementing PCI RootBridgeIo protocol and have some doubts in "IoMap"
and "AllocateBuffer" functions of this protocol.
In our platform, PCI space is starting form address 0x50_0000_0000 (40 bit
addressable)
And its mapping on PCI bus is like:
50_0000_0000 => 0000_0000 (32 bit)
>From where the "AllocateBuffer" function should allocate memory when asked by
>any PCI device?
What is the meaning of "Allocates pages that are suitable for an
EfiPciOperationBusMasterCommonBuffer or
EfiPciOperationBusMasterCommonBuffer64 mapping"
How to manage mapping in "RootBridgeIoMap" function?
Thanks and Regards,
Shaveta
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian,
Feng
Sent: Wednesday, August 26, 2015 7:24 AM
To: Benjamin Herrenschmidt <b...@kernel.crashing.org>; Andrew Fish
<af...@apple.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Tian, Feng
<feng.t...@intel.com>
Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
Hi, Ben & Andrew
The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors that
describe the current configuration of the BARs of the PCI controller.
What I understood is the returned value of GetBarAttributes() is a CPU address
rather than a PCI address. From the view of PciIo, nobody needs to know/use
Bar's PCI address.
Thanks
Feng
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Benjamin
Herrenschmidt
Sent: Wednesday, August 26, 2015 07:54
To: Andrew Fish
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
(Argh, I keep sending these from my IBM address which isn't the one on the
list. Sorry Andrew for the duplicates).
On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote:
>
> > 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.
Unfortunately, I am not familiar with the details of ACPI, I only have a high
level understanding of it. Our platforms have been Open Firmware based for as
far as I've been involved with them and lately, we use C -generated flat
device-tree along with a custom runtime firmwarealled a OPAL).
At this point I'm not (yet) considering a move to ACPI. I'm doing a proof of
concept ppc64 UEFI port to get a feel of the water temperature more than
anything else (though I'll be happy to contribute things back once I get the
appropriate legalese sorted internally to IBM).
> 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.
Ok. Well, it will be needed even on non-1:1 systems, we will have similar
requirements of the OS needing an early boot framebuffer etc...
and I suspect the desire to directly access BARs (at least prefetchable
ones) from the CPU isn't going away in other areas either.
So maybe we should try to address this. I'm trying to figure out how to join
the appropriate working groups etc... so I can participate in the spec side
discussion as well (which I'll need to do for other reasons anyway if we are
ever going to officially defining the ppc64 ABI in the spec).
Cheers,
Ben.
> Thanks,
>
> Andrew Fish
>
> > Cheers,
> > Ben.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
