date:20150912

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Andrew Fish

> On Sep 12, 2015, at 11:34 AM, Leekha Shaveta  wrote:
> 
> Thanks Andrew.
> 
> Replies inlined.
> 
> Regards, Shaveta
> 
> -Original Message-
> From: af...@apple.com  [mailto:af...@apple.com 
> ] 
> Sent: Saturday, September 12, 2015 11:51 PM
> To: Leekha Shaveta-B20052  >
> Cc: Benjamin Herrenschmidt  >; edk2-devel@lists.01.org 
> ; Tian, Feng  >
> Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge 
> IOMap and IoAllocateBuffer)
> 
> 
>> On Sep 12, 2015, at 11:04 AM, Leekha Shaveta  wrote:
>> 
>> 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__ (40 
>> bit addressable) And its mapping on PCI bus is like:
>>  50__ => _ (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?
>> 
> 
> That is platform dependent. These buffers are for doing DMA. On x86 normal 
> memory just works, for ARM you needed an uncached buffer, and you have to do 
> some cache management to maintain coherency. 
> 
> [Shaveta] yes, I am working on an ARM platform. On ARM, "AllocateBuffer" 
> function should return uncached buffer area? 

Yes it has to be a buffer that works for DMA. 

> From where this area need to be allocated? I mean from system memory or from 
> PCI space?

System memory,  it is the memory the PCI card DMA’s data into, or out of. 

> DDR/DRAM is DDR_ATTRIBUTES_CACHED
> PCI space is " ARM_MEMORY_REGION_ATTRIBUTE_DEVICE”
> 

Look at 13.2 PCI Root Bridge I/O Protocol in the UEFI 2.5 spec. It explains the 
sequences for DMA. 

DMA Bus Master Read Operation
• Call Map() for EfiPciOperationBusMasterRead or EfiPciOperationBusMasterRead64.
• Program the DMA Bus Master with the DeviceAddress returned by Map().
• Start the DMA Bus Master.
• Wait for DMA Bus Master to complete the read operation.
• Call Unmap().
DMA Bus Master Write Operation
• Call Map() for EfiPciOperationBusMasterWrite or 
EfiPciOperationBusMasterRead64.
• Program the DMA Bus Master with the DeviceAddress returned by Map().
• Start the DMA Bus Master.
• Wait for DMA Bus Master to complete the write operation.
• Perform a PCI controller specific read transaction to flush all PCI write 
buffers (See PCI Specification Section 3.2.5.2) .
• Call Flush().
• Call Unmap().
DMA Bus Master Common Buffer Operation
• Call AllocateBuffer() to allocate a common buffer.
• Call Map() for EfiPciOperationBusMasterCommonBuffer or 
EfiPciOperationBusMasterCommonBuffer64.
• Program the DMA Bus Master with the DeviceAddress returned by Map().
• The common buffer can now be accessed equally by the processor and the DMA 
bus master.
• Call Unmap().
• Call FreeBuffer().

Map() lets you know both CPU and PCI address of the memory, in case they are 
different.

You should search the edk2 tree for producers of the PCI Root bridge protocol, 
there are reference ARM platforms that probably do a lot of what you need to do 
for your driver. 

Thanks,

Andrew Fish

> Thanks,
> Shaveta
> 
> Thanks,
> 
> Andrew Fish
> 
>> 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 ; Andrew Fish 
>> 
>> Cc: edk2-devel@lists.01.org ; Tian, Feng 
>> 
>> 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:

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Leekha Shaveta

Thanks Andrew.

Replies inlined.

Regards, Shaveta

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Saturday, September 12, 2015 11:51 PM
To: Leekha Shaveta-B20052 
Cc: Benjamin Herrenschmidt ; edk2-devel@lists.01.org; 
Tian, Feng 
Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge 
IOMap and IoAllocateBuffer)


> On Sep 12, 2015, at 11:04 AM, Leekha Shaveta  wrote:
> 
> 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__ (40 
> bit addressable) And its mapping on PCI bus is like:
>   50__ => _ (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?
> 

That is platform dependent. These buffers are for doing DMA. On x86 normal 
memory just works, for ARM you needed an uncached buffer, and you have to do 
some cache management to maintain coherency. 

[Shaveta] yes, I am working on an ARM platform. On ARM, "AllocateBuffer" 
function should return uncached buffer area? 
>From where this area need to be allocated? I mean from system memory or from 
>PCI space?
DDR/DRAM is DDR_ATTRIBUTES_CACHED
PCI space is " ARM_MEMORY_REGION_ATTRIBUTE_DEVICE"

Thanks,
Shaveta

Thanks,

Andrew Fish

> 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 ; Andrew Fish 
> 
> Cc: edk2-devel@lists.01.org ; Tian, Feng 
> 
> 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
>> 
>>>

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Benjamin Herrenschmidt

On Sat, 2015-09-12 at 11:20 -0700, Andrew Fish wrote:
> That is platform dependent. These buffers are for doing DMA. On x86
> normal memory just works, for ARM you needed an uncached buffer, and
> you have to do some cache management to maintain coherency. 

On *some* ARM :-) It's my undertsanding that ARM has been getting
better in recent years and some SoC actually support proper cache
coherent DMA, no ?

Cheers,
Ben.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Benjamin Herrenschmidt

On Sat, 2015-09-12 at 18:04 +, Leekha Shaveta wrote:
> 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__
> (40 bit addressable)
> And its mapping on PCI bus is like:
>   50__ => _ (32 bit)

Is the above the mapping of MMIO or DMA ? Because AllocateBuffer/IoMap
are all about DMA, not MMIO ...

Note that regarding the issue of non-1:1 mappings vs.
GetBarAttributes(), I have patches to fix that in the core by enabling
us to use the mTranslationOffset field of the ACPI descriptor. I will
be able to post these some time next week.

> > 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?

Well, it depends if the mapping you provided above is an MMIO mapping
or a DMA mapping ... I to looks like MMIO to me in which case it has
strictly nothing to do with IoMap/AllocateBuffer

Cheers,
Ben

> 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 ; Andrew Fish <
> af...@apple.com>
> Cc: edk2-devel@lists.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

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Andrew Fish


> On Sep 12, 2015, at 11:04 AM, Leekha Shaveta  wrote:
> 
> 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__ (40 bit 
> addressable)
> And its mapping on PCI bus is like:
>   50__ => _ (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?
> 

That is platform dependent. These buffers are for doing DMA. On x86 normal 
memory just works, for ARM you needed an uncached buffer, and you have to do 
some cache management to maintain coherency. 

Thanks,

Andrew Fish

> 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 ; Andrew Fish 
> 
> Cc: edk2-devel@lists.01.org ; Tian, Feng 
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQIFAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=SgribtiFHqEaQjC-hIDt8ynXkA8Fw9MOHGQkwpbUfps=nwxTDk5_x1Mo8wkHYw-MisFUGLmVTlYqzOzQL7_QZCg=
>  
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQIFAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=SgribtiFHqEaQjC-hIDt8ynXkA8Fw9MOHGQkwpbUfps=nwxTDk5_x1Mo8wkHYw-MisFUGLmVTlYqzOzQL7_QZCg=
>  

___

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Leekha Shaveta

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__ (40 bit 
addressable)
And its mapping on PCI bus is like:
50__ => _ (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 ; Andrew Fish 

Cc: edk2-devel@lists.01.org ; Tian, Feng 

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

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

6 matches

Site Navigation

Mail list logo

Footer information