Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: <pcib1 memory window> request" leads to panic

[Added at bottom: EDK2 notes referencing the non-ECAM compliant
PCie in the BCM2711.]

On Feb 14, 2024, at 10:23, John Baldwin <jhb@freebsd.org> wrote:

> On 2/14/24 10:16 AM, Mark Millard wrote:
>> Top posting a related but separate item:
>> I looked up some old (2022-Dec-17) lspci -v output from
>> a Linux boot. Note the "Memory at" value 600000000 (in
>> the 35 bit BCM2711 address space) and the "(64-bit,
>> non-prefetchable)" (and "[size=4K]").
>> 01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01) (prog-if 30 [XHCI])
>>         Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller
>>         Device tree node: /sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0/usb@0,0
>>         Flags: bus master, fast devsel, latency 0, IRQ 51
>>         Memory at 600000000 (64-bit, non-prefetchable) [size=4K]
>>         Capabilities: [80] Power Management version 3
>>         Capabilities: [90] MSI: Enable+ Count=1/4 Maskable- 64bit+
>>         Capabilities: [c4] Express Endpoint, MSI 00
>>         Capabilities: [100] Advanced Error Reporting
>>         Kernel driver in use: xhci_hcd
>> "Memory at 600000000 (64-bit, non-prefetchable)":
>> Violation of a PCIe standard?
> 
> No, this is a device BAR which can be 64-bit (memory BARs can either
> be 32-bits or 64-bits).  However, the "window" in a PCI _bridge_ for
> memory is only defined to be 32-bits.  Windows in PCI-PCI bridges
> are a special type of BAR that defines the address ranges that the
> bridge decodes on the parent side and passes down to child devices.
> The prefetchable window in PCI-PCI bridges can optionally be 64-bit.
> 
> BAR == a range of memory or I/O port addresses decoded by a device,
> usually mapped to a register bank, but sometimes mapped to internal
> memory (e.g. a framebuffer)
> 
> Window == a range of memory or I/O port addresses decoded by a bridge
> for which transactions are passed across the bridge to be handled by
> a child device.

Good to know. Thanks.

FYI:

From: https://github.com/tianocore/edk2-non-osi/commit/c1075e9ddd647fa7f7cb17b312f6bf8246952e09

There are these notes that indicate the non-standard ECAM status:
(Other details are just for reference. EDK2 UEFI/ACPI is not
the official usage context.)

QUOTE
The RPi4 has a single nonstandard PCI config region. It is broken into two
pieces, the root port config registers and a window to a single device's
config space which can move between devices. However there isn't (yet) an
authoritative public document on this since the available BCM2711 reference
notes that there is a PCIe root port in the memory map but doesn't describe
it.

Considering that it's not ECAM compliant, yet relatively simple, it is
however possible to make use of the newly introduced PCI SMCCC interface
that was added for the RPi4 platform as part of the TF-A 2.6 release.

As a result, we update the RPi4 TF-A to the 2.6 release version, and, for
good measure, the RPi3 also, using binaries that were built in an open and
verifiable manner through the GitHub Actions build script located at
https://github.com/pftf/pitf.

For more details on the SMCCC interface, see DEN0115 available from:
https://developer.arm.com/documentation/den0115/latest
END QUOTE


Other notes:

I remember, FreeBSD supports the SMCCC interfacing in question. By
contrast, Linux refused to add such support.

The default RPi4B EDK2 configuration avoids exposing the PCIe but
there is an option that uses the SMCCC technique to expose it.


===
Mark Millard
marklmi at yahoo.com