Tianocore/edk2-platforms.git/Platform/RaspberryPi/Drivers/FdtDxe, branch CodeCleanup

Platform/RaspberryPi: Update PCIe MMIO window for DT

2024-03-11T14:22:46+00:00

Since we are updating the DT memory map and telling it how we have configured the PCIe, there isn't a reason for moving the MMIO window. In fact this appears to fix OpenBSD+DT as well as it makes the linux XHCI reset sequence happier. Signed-off-by: Jeremy Linton Reviewed-by: Ard Biesheuvel

Platform/RaspberryPi: Give the user control over the XHCI mailbox

2024-03-11T14:18:22+00:00

It's a complete tossup whether removing the mailbox call after we have set up the XHCI works for a given kernel+distro in DT mode. So lets give users who want to try DT the option of flipping this on/off. Users that don't want to have to deal with DT, can use ACPI. Signed-off-by: Jeremy Linton Reviewed-by: Ard Biesheuvel

Platform/RaspberryPi: fix pci DT node address in SyncPcie()

2022-10-10T09:14:17+00:00

To make sure the XHCI controller does not get reset by Linux in DT mode, we remove its pci parent node from the device tree. However, the pci node address has been updated in the Raspberry Pi 4 device tree [1] and no longer matches the one we are trying to remove in SyncPcie(). This results in the XHCI controller actually being reset by Linux, which leads to errors during USB initialization: [ 3.563963] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 3.569538] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1 [ 3.577452] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000040000000890 [ 3.587725] xhci_hcd 0000:01:00.0: xHCI Host Controller [ 3.593115] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2 [ 3.600693] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed [ 3.608106] hub 1-0:1.0: USB hub found [ 3.612026] hub 1-0:1.0: 1 port detected [ 3.616819] hub 2-0:1.0: USB hub found [ 3.620726] hub 2-0:1.0: 4 ports detected [ 3.875902] usb 1-1: new high-speed USB device number 2 using xhci_hcd [ 4.008123] usb 1-1: device descriptor read/64, error -71 [ 4.256088] usb 1-1: device descriptor read/64, error -71 [ 4.495882] usb 1-1: new high-speed USB device number 3 using xhci_hcd [ 4.628111] usb 1-1: device descriptor read/64, error -71 [ 4.872083] usb 1-1: device descriptor read/64, error -71 [ 5.407888] usb 1-1: new high-speed USB device number 4 using xhci_hcd [ 6.023964] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1. [ 6.239977] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1. This patch allows matching any address for the pci node, thus working with both legacy and new device trees. [1] https://lore.kernel.org/all/20210831125843.1233488-1-nsaenzju@redhat.com/ Fixes: efff29cdcdb7 ("Platform/RaspberryPi: Always use non translating DMA in DT mode") Signed-off-by: Adrien Thierry Reviewed-by: Jeremy Linton Tested-by: Jeremy Linton

Platform/RaspberryPi: Always use non translating DMA in DT mode

2021-10-19T07:22:05+00:00

One of the many issues with the PCIe on this platform is its inbound DMA is either constrained to the lower 3G, or on later SOC's a translation may be used. That translation is problematic with some of the OS's expected to boot on this platform. So, across the board a 3G DMA limit is enforced during boot when in ACPI mode. This itself causes problems because the later boards removed the SPI EEPROM used by the onboard XHCI controller, instead favoring using a block of RAM to load its firmware. Hence it is the lower level firmware's responsibility via a mailbox call, to read the bridge translation/configuration before telling the XHCI controller where it can find its firmware. Everything is great in ACPI land. Now it appears that Linux after reprogramming the bridge to match the DT (when using a translation) can't actually get the XHCI/quirk/reset to function. Apparently, because the firmware only reads the bridge configuration the first time its called(?), or the kernel reset sequence isn't correct. Worse, with just the DMA ranges corrected, the XHCI/QUIRK itself then causes the controller to start having what appear to be DMA issues. Lets simplify the situation and make all DT's provided by this firmware have a 3G DMA limit on the PCIe bus. Then remove the ability for Linux/etc to trigger the quirk by remove the DT node attaching the reset controller to the XHCI. The latter seems somewhat questionable, since the DT/PCIe host bridge driver is doing what appears to be a PERST which might then require a firmware reload, but at the moment seems to work without. The first part of this patch also appears to fix a problem with OpenBSD which interprets the DT as describing how the firmware has configured the device, and makes no attempt to reconfigure it. Hence the newer SOC's implementing a translation fail to boot since the DT being passed to the OS doesn't match the translation the firmware has setup. Signed-off-by: Jeremy Linton Acked-by: Ard Biesheuvel

RPi: allow selecting DT-only mode

2020-05-11T11:27:50+00:00

Today the Pies can be booted in a way where only ACPI is exposed, or both ACPI and DT are exposed. This adds one more mode - DT only, no ACPI. The target audience is developers. When both are exposed, it's up to the OS to decide which gets used, and that choice can differ between OSes, Note: this does _not_ change defaults. Pi 3 still defaults to ACPI + DT, while Pi 4 still defaults to ACPI only. We don't really want to remove DT + ACPI mode - it is the default on Pi 3, and removing it is bound to just annoy users - WoA and NetBSD (voa UEFI) on Pi 3 only work with ACPI, while everything else (Linux, FreeBSD) only work with DT. I'd make an analogy of MPS and ACPI being exposed for the longest time ever together on PCs. Testing: OpenBSD on Pi 4 with DT-only and ACPI-only boots. Signed-off-by: Andrei Warkentin Reviewed-by: Pete Batard

Platform/RaspberryPi: move varstore structure defs to ConfigVars.h

2020-05-11T11:27:49+00:00

To avoid hardcoding constants for non-obvious fields (e.g. enum instead of basic enable/disable), move variable structure and value definitions into a separate header, ConfigVars.h. Signed-off-by: Andrei Warkentin Reviewed-by: Pete Batard

Platform/RaspberryPi: Rip out FdtDxe logic to use internal DTB

2020-05-01T17:07:15+00:00

Initially, FdtDxe used an internal (embedded in UEFI) FDT, because it was neither understood how to consume the one loaded by the VideoCore firmware, nor understood just how important it is to use the DTB provided by config.txt. Embedding the DT was a bad idea, because: - Permanently stale - No overlays Also, on devices like the Pi 4 you _have_ to have a DT around for the start4 VPU firmware to pick up, otherwise the board is left in an inconsistent state. So we're being prescriptive now about DT use with config.txt, which means this internal DT logic is dead code. Further FdtDxe cleanups are possible and will be handled separately, specifically: - probably no need to use a separate allocation for patched DT (optimize memory used) - suspicious use of EfiBootServicesData (I filed [0] to sort out the real requirements) Testing: Booted Ubuntu 18.04 on Pi 2B (1.2). [0] https://github.com/ARM-software/ebbr/issues/45 Signed-off-by: Andrei Warkentin Reviewed-by: Pete Batard

Platform/RPi: Make Device Tree provision a runtime (BIOS setup) choice

2020-03-03T14:06:46+00:00

With this and the previous commit, ACPI_BASIC_MODE_ENABLE becomes superfluous so remove it. New option defaults to enabled on Pi 3, disabled on Pi 4. Signed-off-by: Pete Batard Reviewed-by: Ard Biesheuvel

Platforms/RPi3: Restructure platform in preparation for Pi 4

2019-10-21T14:32:32+00:00

In preparation for adding Raspberry Pi 4 support, the Pi 3 platform is restructured by factorizing all the drivers and libraries that are going to be commonly used by the two platforms. Because much of the Pi 4 SoC is an extension of the Pi 3 one this means that almost everything, except the ACPI tables, is moved up into a new common RaspberryPi/ subdirectory that will serve both platforms. The .dec is also moved to this directory, under a new RaspberryPi.dec name, and existing references to it are updated. This commit requires the edk2-non-osi in use to contain commit 243e55f622ea in order to build. Signed-off-by: Pete Batard Reviewed-by: Philippe Mathieu-Daude Reviewed-by: Leif Lindholm