Hi Saket, Changing email format to plain text, not sure if the mailing list allows HTML ..
On Tue, Sep 29, 2015 at 12:36 PM, Saket Sinha <saket.sinh...@gmail.com> wrote: > > Hi, > > This is regarding the PCI configuration issue I am facing for bringing up > ACPI Support on QEMU and Minnowmax. > > Please find below my observations for the QEMU architecture. > > I am comparing arch/x86/cpu/qemu/acpi/pci-crs.asl and > arch/x86/dts/qemu-x86_q35.dts and we find there are different ranges > been specified for PCI configuration in both the files. > > > I have found out the following things -- > > a) What does ACPI tell the OS - > > The most important chips which responsible for the BIOS code handling are the > southbridge and northbridge. > > The northbridge acts as the address forwarder, meaning: it responds to this > "special" memory address in different fashion compared to "normal" memory > address which is forwarded directly to RAM. > > The southbridge acts as the address decoder, meaning: it decodes this > "special" memory addresses into the right chip "beneath" it, such as the BIOS > chip. > > Below is an example: > Physical AddressAlso Known AsUsed byAddress Aliasing Note > 000F_0000h - 000F_FFFFhF_seg / F_segment1 Mbit, 2 MBit, and 4 Mbit BIOSalias > to FFFF_0000h - FFFF_FFFFh in all chipset just after power-up > 000E_0000h - 000E_FFFFhE_seg / E_segment1 Mbit, 2 Mbit, and 4 Mbit BIOSalias > to FFFE_0000h - FFFE_FFFFh in some chipset just after power-up > FFFD_0000h - FFFD_FFFFhD_seg / D_segment2 Mbit, and 4 Mbit BIOS- > FFFC_0000h - FFFC_FFFFhC_seg / C_segment2 Mbit, and 4 Mbit BIOS- > FFF8_0000h - FFFB_FFFFh-4 Mbit BIOS- > > > The address ranges shown above contain the BIOS code(part of the ACPI) and > pretty much system specific. Thus all this is communicated by the ACPI to the > OS. > > b) What does Device Tree tell the OS - > > From 0x80000000 to 0xe0000000 is the PCI memory space, I/O space and prefetch > space where memory mapping of the PCI bus. This is what device tree is > dictating. > > To sum up Device Tree and ACPI do NOT the same things and thus play > different values to make devices connected to PCI bus available. > > > The issue I am facing is that I am getting configuration errors with BARs. > > >> [ 0.660567] pci 0000:00:01.0: can't claim BAR 0 [mem > >> 0xd0000000-0xd0ffffff pref]: no compatible bridge window > >> [ 0.662083] pci 0000:00:01.0: can't claim BAR 2 [mem > >> 0xc0000000-0xc0000fff]: no compatible bridge window > >> [ 0.663062] pci 0000:00:02.0: can't claim BAR 0 [mem > >> 0xc0020000-0xc003ffff]: no compatible bridge window > >> [ 0.664164] pci 0000:00:1f.2: can't claim BAR 5 [mem > >> 0xc0080000-0xc0080fff]: no compatible bridge window > > BARs are part of the so-called PCI configuration register. Every PCI device > must implement the PCI configuration register dictated by the PCI > specification. > Otherwise, the device will not be regarded as a valid PCI device. > > As per my understanding for Qemu q35 (emulation of the ICH9 hostchipset) > where we have PCIe support which is made possible by PCI express enhanced > accessmechanism (ECAM). > This address is 0xe0000000 which is what I have put in > arch/x86/dts/qemu-x86_q35.dts when I am memory mapping the PCI bus. > > Any inputs regarding the issue, as to what I am doing wrong here, are welcome. > I don't quite understand what you are trying to ask in this thread. I remember I answered your confusion regarding to PCI memory-mapped space vs. ECAM in another thread before. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot