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:eug...@hp.com] > Sent: Tuesday, June 02, 2015 7:20 PM > To: edk2-devel@lists.sourceforge.net > Cc: olivier.mar...@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:shav...@freescale.com] > Sent: Tuesday, June 02, 2015 1:20 AM > To: > edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> > Cc: olivier.mar...@arm.com<mailto:olivier.mar...@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-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> > Cc: Leekha Shaveta-B20052 > Subject: RE: Query UEFI : PCIE Driver for Armv8 platform > > Thanks for the pointers, Olivier. > > Regards, > Bhupesh > > From: Olivier Martin [mailto:olivier.mar...@arm.com] > Sent: Wednesday, May 13, 2015 8:10 PM > To: > edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> > 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:shav...@freescale.com] > Sent: 13 May 2015 13:09 > To: > edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> > 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, wp...@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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
