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

Saket Sinha saket.sinha89 at gmail.com
Tue Sep 29 06:36:33 CEST 2015


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 Address**Also Known As**Used by**Address
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-up000E_0000h - 000E_FFFFhE_seg / E_segment1 Mbit, 2 Mbit, and 4 Mbit
BIOSalias to FFFE_0000h - FFFE_FFFFh in *some* chipset just after
power-upFFFD_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.


Regards,
Saket Sinha


More information about the U-Boot mailing list