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.sinha89@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