[U-Boot] PCI issues for bringing up ACPI support on QEMU and Minnowmax target

[Bin Meng]

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