> On Jun 5, 2015, at 4:23 AM, Leekha Shaveta <***@freescale.com> wrote:
>
> Thanks Andrew!
>
> Few more Doubts :
> How ACPI is defining PCI resources?
> What are these PCI resources and their functions? Are these resources are like some regions in "PCI Express space”
Leekha you need to think about it from the hardware point of view….
The PCI root bridge sits on the CPU bus and it produces PCI. So that PCI root bridge has to be configured to forward transactions.
From the firmware point of view you are configuring the chip to decode memory addresses and resources to forward them to PCI.
From an OS (or generic PCI bus driver) you are defining the resource pool that is available to config PCI devices. So assign bus numbers, and populate BARs.
> ?
>
> As I was referring ArmJunoPkg for PCI Host Bridge implementation. And found this ACPI configuration used:
>>
>> RESOURCE_CONFIGURATION Configuration = {
>> {{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_IO , 0, 0, 0, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0, 32, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6, 32, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0, 64, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6, 64, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_BUS, 0, 0, 0, 0, 255, 0, 255}},
>> {ACPI_END_TAG_DESCRIPTOR, 0}
>> };
>>
>> Hi Olivier,
>> Can you please help in understanding this resource configuration ?
>> Here you seem to be specifying one IO, 4 Mem and 1 Bus space. Why 6 of them and how do they differ?
>
> On which basis 6 resources are given here?
>
These are the basic resource types supported by PCI.
I/O so the inb outb instructions on X86 (IO BAR)
32-bit Prefetch and non-Prefetch memory (Memory BAR)
64-bit Prefetch and non-Prefetch memory (Memory BAR)
PCI Bus numbers. (Bus Number)
Thanks,
Andrew Fish
> Thanks and Regards,
> Shaveta
>
>
> -----Original Message-----
> From: Andrew Fish [mailto:***@apple.com]
> Sent: Thursday, June 04, 2015 12:37 PM
> To: edk2-***@lists.sourceforge.net
> Cc: ***@arm.com
> Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
>
>
>> On Jun 3, 2015, at 11:57 PM, Leekha Shaveta <***@freescale.com> wrote:
>>
>> Thanks Bill for such an elaborated reply !!
>>
>> Few doubts left:
>> (1) In "StartBusEnumeration" function of PCI_HOST_BRIDGE, it
>> // Fill an ACPI descriptor table with the Bus Number Range. This
>> // information will be used by the PCI Bus driver
>> // to set bus numbers to PCI-to-PCI bridge.
>>
>> Is PCI bus implementation is ACPI based only?
>>
>
> No while PCI is defined by a specification how a PCI Host Bridge hooks into a system is not defined. Thus the Firmware and the OS have no idea how a PCI Host Bridge works. The Firmware can carry a driver for the host bridge and generally the OS uses ACPI to abstract the PCI Host Bridge hardware and contains drivers that follow the PCI specifications. Given it was likely on a lot of systems that this would be true we decided to use ACPI resource descriptors to abstract the resources, we could have made up something new, but we figured the person writing the PCI Host Bridge driver would also likely have to write the ACPI AML to get the chip working, and would be familiar with this concept. We also figured if the firmware and the OS used the same description technique there would be less chance for error. It also seemed to us that ACPI had already solved this problem (describing resources), so why invent a new way to do it.
>
> Thanks,
>
> Andrew Fish
>
>> (2) I was referring ArmJunoPkg for PCI Host Bridge implementation. And found this ACPI configuration used:
>>
>> RESOURCE_CONFIGURATION Configuration = {
>> {{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_IO , 0, 0, 0, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0, 32, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6, 32, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0, 64, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6, 64, 0, 0, 0, 0},
>> {ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_BUS, 0, 0, 0, 0, 255, 0, 255}},
>> {ACPI_END_TAG_DESCRIPTOR, 0}
>> };
>>
>> Hi Olivier,
>> Can you please help in understanding this resource configuration ?
>> Here you seem to be specifying one IO, 4 Mem and 1 Bus space. Why 6 of them and how do they differ?
>>
>> (3) What exactly this "case EfiPciHostBridgeAllocateResources" of NotifyPhase does?
>> Is it allocate resources in sync with the ACPI configuration given?
>>
>> (4) Is there some PCI NIC card or E1000 driver (PCI device driver) written on top of PCI bus driver, any references?
>>
>> Thanks and Regards,
>> Shaveta
>>
>> -----Original Message-----
>> From: Bill Paul [mailto:***@windriver.com]
>> Sent: Wednesday, June 03, 2015 9:40 AM
>> To: edk2-***@lists.sourceforge.net
>> Cc: Leekha Shaveta-B20052; ***@arm.com
>> Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
>>
>> Of all the gin joints in all the towns in all the world, Leekha Shaveta had to walk into mine at 20:41:11 on Tuesday 02 June 2015 and say:
>>
>>> Thanks Eugene!
>>>
>>> Few more doubts:
>>>
>>>
>>> (1) What exactly this "case EfiPciHostBridgeAllocateResources" of
>>> NotifyPhase does?
>>>
>>> (2) In "StartBusEnumeration" function of PCI_HOST_BRIDGE, it
>>> / Fill an ACPI descriptor table with the Bus Number Range. This
>>> information will be used by the PCI Bus driver
>>>
>>> // to set bus numbers to PCI-to-PCI bridge.
>>>
>>> Is PCI bus implementation is ACPI based only?
>>>
>>> (3) The PCI controller i am programming, does iATU (Internal address
>>> translation unit) programming for accessing PCI IO, Mem and config space.
>>> When this programming should happen? During RootBridge init time?
>>
>> I think the answer to this question is yes (this is local to the PCIe controller, so the driver for this controller should initialize it).
>>
>>> (4) The RootBridge protocol functions like : PciIoRead/PciIoWrite,
>>> PciMemRead/PciMemWrite, PciPciRead/PciPciWrite
>>>
>>> They all use MmioRead/MmioWrite internally.
>>
>> Maybe for your particular implementation they do, but this is not true for all PCIe root complexes and/or host bridges.
>>
>>> Also PCI controller registers
>>> are already memory mapped.
>>>
>>> So what is the significance of:
>>>
>>> "Reading/Writing PCI controller registers in the PCI root bridge I/O space"
>>>
>>> "Reading/Writing PCI controller registers in the PCI root bridge
>>> Memory space"
>>
>> A device on the PCI bus may have both memory mapped and I/O space BARs. On the Intel x86 architecture, I/O BARs are not memory mapped: I/O space accesses are performed using special CPU instructions: inb/outb, inw/outw, inl/outl.
>> (Normally these are privileged instructions which can only be executed
>> in supervisor mode.) This dates back to the original PC design when
>> you only have ISA bus devices: when PCI came along, I/O space BARs
>> were implemented by PCI devices for compatibility reasons. (In theory
>> you could take an existing ISA bus device and slap a PCI front end on
>> it, and recycle most of your existing driver code.)
>>
>> On the PCI bus, I/O space and memory mapped access are implemented with separate transaction codes. How they translate to the host system is platform- dependent.
>>
>> On any platform other than Intel x86 (PPC, ARM, MIPS, SPARC, etc...), both I/O space BARs and memory mapped BARs are memory mapped. This is probably why you're questioning why you need two different methods. In your case, technically speaking, you don't. If it turns out that a device has the same register layout for both BARs, then you just end up with a second copy (alias) of the device's registers, which is a bit redundant.
>>
>> However not all devices work that way. One other limiting factor of the original PC design was that there was only 64KB total of I/O space (the inX/outX instructions only accept a 16-bit offset value), so devices usually had very few registers. This has changed over the years. For example, the Intel PRO/1000 ethernet MAC can have 256KB or even 512KB of MMIO register space. This exceeds the total I/O space range available on the x86 platform.
>> To mitigate this, the I/O space BAR on an Intel PRO/1000 device is just large enough to provide a set of offset and data "keyhole" registers and you use them to indirectly access the total available register space.
>>
>> (As to why you would ever need this, some older PRO/1000 devices had a
>> chip erratum that could cause the device to trigger a PCI protocol
>> violation if you used the memory-mapped command register to perform a
>> device reset. The workaround documented by Intel was to perform the
>> reset using the I/O space BAR instead of the MMIO BAR.)
>>
>> Since it is permitted to bridge legacy PCI devices to a PCIe bus, it's usually a good idea to implement both memory mapped and I/O space BAR support correctly, otherwise some legacy devices might not be usable. That is, if the PCIe controller hardware permits. (Apparently the Xilinx Zynq7K PCIe controller implementation doesn't support I/O space read/write transactions.
>> I'm not sure if this is an overall defect in the design or if it's a
>> question of getting the right bitstream file.)
>>
>>> "Reading/Writing PCI controller registers in the PCI root bridge
>>> Configuration space"
>>
>> With the advent of extended configuration space (4KB per device vs. 256 bytes per device), it's common for PCIe controllers to implement memory-mapped access mechanisms on the host side. (This is how it works on the Intel x86 platform too.) However some PCIe controllers still use the address/data "keyhole" register scheme instead.
>>
>> Long story short: your particular controller may be implementing PCI I/O, MMIO and config space reads using memory mapped registers, but that's not always how it works, hence separate methods are provided for each case.
>>
>> -Bill
>>
>>>
>>> Thanks and Regards,
>>> Shaveta
>>>
>>>
>>>
>>> From: Cohen, Eugene [mailto:***@hp.com]
>>> Sent: Tuesday, June 02, 2015 7:20 PM
>>> To: edk2-***@lists.sourceforge.net
>>> Cc: ***@arm.com
>>> Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
>>>
>>>
>>> ? Is all of the following functions have platform specific code, or
>>> they can be re-used from any of the PCI code like ARmJunoPkg etc? Are
>>> all these functions definitions mendatory?
>>>
>>> You have to implement the host bridge and root bridge protocols.
>>> When you implement a protocol you must implement the functions. Some
>>> of the functions don't have to do anything (like some of the
>>> NotifyPhase case statements).
>>>
>>>
>>> ? Should "PCI bus scan for devices" kind of code be written as part
>>> of PCI Root Bridge code or it should be re-used from
>>>
>>> ? MdeModulePkg/Bus/Pci/ code as it is?
>>>
>>> The PCI bus driver already does a scan and enumeration. All you need
>>> to do is support the root/host bridge (provide config cycle
>>> generation, provide address ranges for mapping into memory spaces, etc).
>>>
>>>
>>> From: Leekha Shaveta [mailto:***@freescale.com]
>>> Sent: Tuesday, June 02, 2015 1:20 AM
>>> To:
>>> edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.
>>> n
>>> et>
>>> Cc: ***@arm.com<mailto:***@arm.com>
>>> Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
>>>
>>> Hi,
>>>
>>> I am writing a PCI driver(Host Bridge) code for ARM platform with
>>> real devices like e1000 NIC card on PCI bus.
>>>
>>> I have written a part of PCI Root Complex Initialization code, but
>>> have few doubts :
>>>
>>> (1) Is all of the following functions have platform specific code, or
>>> they can be re-used from any of the PCI code like ARmJunoPkg etc? Are
>>> all these functions definitions mendatory?
>>>
>>> * PciHbRaNotifyPhase, // ResAlloc.NotifyPhase
>>>
>>> * PciHbRaGetNextRootBridge, // ResAlloc.GetNextRootBridge
>>>
>>> * PciHbRaGetAllocAttributes, // ResAlloc.GetAllocAttributes
>>>
>>> * PciHbRaStartBusEnumeration, // ResAlloc.StartBusEnumeration
>>>
>>> * PciHbRaSetBusNumbers, // ResAlloc.SetBusNumbers
>>>
>>> * PciHbRaSubmitResources, // ResAlloc.SubmitResources
>>>
>>> * PciHbRaGetProposedResources, // ResAlloc.GetProposedResources
>>>
>>> * PciHbRaPreprocessController
>>>
>>>
>>>
>>> (2) Should "PCI bus scan for devices" kind of code be written as part of
>>> PCI Root Bridge code or it should be re-used from
>>> MdeModulePkg/Bus/Pci/ code as it is?
>>>
>>> (3) As I want to write e1000 PCI NIC card driver over it, is there any
>>> existing code for the same?
>>>
>>> Thanks and Regards,
>>> Shaveta
>>>
>>> From: Sharma Bhupesh-B45370
>>> Sent: Wednesday, May 13, 2015 8:20 PM
>>> To:
>>> edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.
>>> n
>>> et>
>>> Cc: Leekha Shaveta-B20052
>>> Subject: RE: Query UEFI : PCIE Driver for Armv8 platform
>>>
>>> Thanks for the pointers, Olivier.
>>>
>>> Regards,
>>> Bhupesh
>>>
>>> From: Olivier Martin [mailto:***@arm.com]
>>> Sent: Wednesday, May 13, 2015 8:10 PM
>>> To:
>>> edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.
>>> n
>>> et>
>>> Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
>>>
>>> Are lucky because I actually pushed the PCI Root Complex source code
>>> for ARM Juno development board R1 (Revision 1) yesterday in EDK2. You
>>> should be able to find the code under
>>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe I am guessing what
>>> you name 'ATU' is the logic to translate AXI bus <-> PCI bus. As far
>>> as I have seen so far, this logic is vendor specific. You can see
>>> this initialization of the translation block for this PCI Root
>>> Complex in this
>>> file:
>>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>>>
>>> From: Leekha Shaveta [mailto:***@freescale.com]
>>> Sent: 13 May 2015 13:09
>>> To:
>>> edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.
>>> n
>>> et>
>>> Subject: [edk2] Query UEFI : PCIE Driver for Armv8 platform
>>>
>>> Hi,
>>>
>>> I was looking for PCIE driver/Root Bridge implementation for ARMv8
>>> kind of platforms and have referred some code in files:
>>>
>>> *
>>> ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciRootBridgeIo.
>>> c
>>>
>>> *
>>> ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
>>>
>>> But I couldn't see ATU programming code in this implementation, AFAIK
>>> ATU programming is required for any outbound and inbound transaction of PCI.
>>> How the IO translation is being done in this?
>>> Also what is the context of "aperture" used in this code?
>>>
>>> Kindly help in clearing these doubts.
>>>
>>> Regards,
>>> Shaveta
>>>
>>>
>>> -- IMPORTANT NOTICE: The contents of this email and any attachments
>>> are confidential and may also be privileged. If you are not the
>>> intended recipient, please notify the sender immediately and do not
>>> disclose the contents to any other person, use it for any purpose, or
>>> store or copy the information in any medium. Thank you.
>>>
>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>>> Registered in England & Wales, Company No: 2557590 ARM Holdings plc,
>>> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
>>> England & Wales, Company No: 2548782
>>
>> --
>> =============================================================================
>> -Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
>> ***@windriver.com | Master of Unix-Fu - Wind River Systems =============================================================================
>> "I put a dollar in a change machine. Nothing changed." - George
>> Carlin
>> ======================================================================
>> =======
>>
>> ----------------------------------------------------------------------
>> -------- _______________________________________________
>> edk2-devel mailing list
>> edk2-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> edk2-devel mailing list
> edk2-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------