Tianocore/edk2-platforms.git/Silicon/Broadcom, branch CodeCleanup

Silicon/Broadcom/BcmGenetDxe: Suppress some bogus compiler warnings

2024-03-11T14:15:27+00:00

Some recent GCC revisions will throw warnings about values being used before being initialized. But in the case where the lack of initialization is the result of the called function returning error status the EFI_ERROR() macro/error seems to confuse the compiler about the fact that the value is then never used. So, while the code appears to be fine, lets just zero the variables anyway to make the compiler happy. Signed-off-by: Jeremy Linton Reviewed-by: Ard Biesheuvel

Silicon/Broadcom/Bcm27xx: Move linkup check into the cfg accessor

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

The existing code fails to create/finish configuring the pcie subsystem if it fails to get a linkup. This is reasonable on the RPi4 because it generally won't happen, and the OS could not see the root port. Now that the OS can see the root port, its a bit odd if it only shows up when something is plugged into the first slot. Lets move the link up check into the config accessor where it will be used to restrict sending CFG TLP's out the port when nothing is plugged in. Thus avoiding a SERROR during probe. Signed-off-by: Jeremy Linton Reviewed-by: Andrei Warkentin Tested-by: Jared McNeill

Silicon/Broadcom/Bcm27xx: Relax PCIe device restriction

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

The CM4 has an actual PCIe slot, so the device filtering need to be a little less restrictive WRT busses with more than 1 device given that switches can now appear in the topology. Since it is possible to start numbering the busses with a non-zero value, the bus restriction should be based on the secondary side of the root port. This isn't likely but its better than hard-coding the limit. Suggested-by: René Treffer Signed-off-by: Jeremy Linton Reviewed-by: Andrei Warkentin Tested-by: Jared McNeill

Silicon/Broadcom/BcmGenetDxe: Delay for linkup in transmit

2021-08-16T07:21:14+00:00

Under normal circumstances GenetSimpleNetworkTransmit won't be called unless the rest of the network stack detects the link is up. So, during normal operation when the adapter is initialized the link naturally transitions to link up, and then is ready for activity later in the boot sequence. If that hasn't happened by the time PXE runs then it will itself wait for the link. OTOH, the normal distro PXE sequence involves PXE loading shim which in turn loads grub, which tries to read machine specific configs, modules, and grub.cfg in order to prepare the boot menu. Then, once a grub selection is picked, it might try to load the kernel+initrd. In this sequence the network stack is shutdown and restarted multiple times. Grub though, starts up, notices its been network booted, reads saved network parameters and immediately tries to transmit data assuming the link is still up. When that happens grub will print "couldn't send network packet" and if that lasts long enough it fails to load grub.cfg and the user gets dropped to the grub prompt because no one in the path bothers to assure the link state has transitioned back up. For reference: https://github.com/pftf/RPi4/issues/113 This patch fixes that by polling the link state via GenericPhyUpdateConfig() for ten seconds in the transmit path when the link is down. If the link recovers within this timeout the state machine is transitioned and we continue data transmission. If the 10 seconds expires without the link resuming we will fail as before. While full link negotiation can be fast, it frequently can take a second or two, or longer depending on the remote peer on the other end of the Ethernet cable. It seems auto MDX can slow this down, and certain vendors products seem to be slower than the norm. Ten seconds may not cover some of these possibilities, but the user should validate cabling and the switch/peer's port configuration if resuming the link is taking > 10 seconds. Picking a longer timeout is a tradeoff between the machine appearing to hang for extended periods of time (due to grub retries) if the link is actually down vs generally providing enough time for most endpoints to complete the negotiation. Signed-off-by: Jeremy Linton Reviewed-by: Jared McNeill Reviewed-by: Andrei Warkentin

Silicon/Broadcom/Bcm283x: Clean up GpioPinSet function

2021-06-12T20:03:39+00:00

Make the changes below for making it clearer. - Rename GpioPinSet() to GpioPinConfigure() - Rename parameter Val to Config and change its type to BOOLEAN Signed-off-by: Sunny Wang Reviewed-by: Pete Batard Tested-by: Pete Batard

Platform/Raspberrypi: Update DMA constants based on SOC revision

2021-05-12T12:21:02+00:00

The newer BCM2711 SoC's don't have a DMA constraint on the emmc2 controller. So we don't need to do the 1G translation. Lets allow the AML to detect the SoC revision and return a different _DMA resource. Signed-off-by: Jeremy Linton Reviewed-by: Pete Batard

Platform/RaspberryPi: Split MMC register definitions

2021-01-08T09:42:36+00:00

The current MMC (really SDHCI) definitions are tied to the Arasan controller. As we intend to reuse the definitions lets make the base address configurable when the driver loads. This assumes we won't ever want to run both the eMMC2 and Arasan SDHCI controller at the same time. Signed-off-by: Jeremy Linton Reviewed-by: Andrei Warkentin Reviewed-by: Philippe Mathieu-Daude

Platform/RaspberryPi4: Add a basic thermal zone

2020-09-01T11:48:18+00:00

Rather than exporting the temp sensor or mailbox in ACPI land we can wrap them in AML and use the default ACPI drivers provided by the OS. This enables the use of "sensors" in linux to report the SOC temp. As a first pass add a basic passive cooling ACPI thermalzone with trip points for passive cooling (throttling) handled by the vc firmware, hibernate and critical shutdown. The vc apparently kicks in at ~80C, so the hibernate and critical set points are set at +5 and +10 of that. In the future CPPC should be able to monitor the thermal throttling. Signed-off-by: Jeremy Linton Reviewed-by: Pete Batard

Platforms/RaspberryPi: Fix BcmGenetDxe ComponentName2 error checking

2020-08-17T13:52:32+00:00

Fix input param error checking for the BcmGenetDxe ComponentName2 protocol. This fixes https://github.com/pftf/RPi4/issues/85 Signed-off-by: Samer El-Haj-Mahmoud Reviewed-by: Pete Batard

Silicon/BcmGenetDxe: don't consume RX buffer until it's actually copied

2020-07-14T14:46:05+00:00

This was originally a bit sloppy, and could hypothetically under heavy load result in a buffer being overwritten by hardware before the received buffer is copied. Signed-off-by: Andrei Warkentin Reviewed-by: Pete Batard Reviewed-by: Leif Lindholm