Tianocore/edk2-platforms.git/Platform/RaspberryPi/Drivers, 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: Cleanup menu visibility

2024-03-11T14:16:23+00:00

Lets allow some of these options to change when the system is in ACPI+DT mode. Plus the fan temp should be disabled when ACPI isn't enabled. 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: Add 'clock-frequency' property for miniuart

2022-02-08T16:54:47+00:00

Describe the miniuart clock frequency in a _DSD property, so that it can be read from the Linux driver [1] The miniuart clock frequency is the core clock frequency on the Raspberry Pi. It can be modified by the user using the 'core_freq' property in the config.txt file. So, we fetch it from the underlying Raspberry Pi firmware. [1] https://lore.kernel.org/all/20220207232129.402882-1-athierry@redhat.com/ Signed-off-by: Adrien Thierry Reviewed-by: Ard Biesheuvel

Platform/RaspberryPi: Normal memory should not be marked as uncached

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

The EFI spec seems to indicate that the EFI uncacheable attribute should be mapped to device memory rather than normal-nc. This means that the UEFI mem attribute for the >3G ram doesn't match the remainder of the RAM in the machine. So, lets remove the uncacheable attribute to make it more consistent. Signed-off-by: Jeremy Linton Reviewed-by: Ard Biesheuvel

Platform/RaspberryPi: Expand locking to cover return data

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

It appears that the locking for many of the mailbox commands is incorrect. All UEFI firmware calls to the RPi mailbox share a single mDmaBuffer. That buffer is used to fill out the command passed to the vc firmware, and record its response. The buffer is protected by mMailboxLock, yet in many cases the mailbox response is copied from the buffer after the lock has been released. This doesn't currently appear to be causing any problems, but should be fixed anyway. There are a couple other minor tweaks in this patch that are hard to justify on their own, one is a bit of whitespace cleanup, and the other is the addition of a debug message to print the returned clock rate for the requested clock. This latter print would have immediatly shown that the vc firmware was returning 0 as the emmc clock rate rather than something reasonable. Signed-off-by: Jeremy Linton Reviewed-by: Andrei Warkentin

Platform/RaspberryPi: Fix vfr warning caused by two defaults

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

The build has been tossing a warning about having two defaults for a while now, lets fix it. Signed-off-by: Jeremy Linton Reviewed-by: Andrei Warkentin

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

Platform/RaspberryPi: Add PCIe SSDT

2021-08-22T13:54:45+00:00

Since we plan on toggling between XHCI and PCI the PCI root needs to be in its own SSDT. This is all thats needed of UEFI. The SMC conduit is provided directly to the running OS. When the OS detects this PCIe port on a machine without a MCFG it attempts to connect to the SMC conduit. The RPi definition doesn't have any power mgmt, and only provides a description of the root port. Signed-off-by: Jeremy Linton Tested-by: Jared McNeill