starfive-tech/u-boot.git/arch/arm, branch rtthread_AMP

Merge tag 'rpi-next-2021.10.2' of https://source.denx.de/u-boot/custodians/u-boot-raspberrypi

2021-09-29T19:13:35+00:00

- fix usb stopt; usb start; bug - update Nicolas email address

arm: rpi: perform XHCI firmware upload only once

2021-09-29T13:44:16+00:00

XHCI firmware upload must be performed only once after initializing the PCI bridge. This fixes USB stack initialization after calling "usb stop; usb start" on Raspberry Pi 4B. Signed-off-by: Marek Szyprowski Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Matthias Brugger

arm: dts: armada8040: Fix CP0 eMMC/SDIO support

2021-09-29T05:13:27+00:00

During the migration to a single DTSI for the CP110-s specific pinctrl compatibles were moved to the SoC DTSI as CP0 and CP1 have some specifics. Namely, CP0 eMMC/SDIO support depends on the mvebu-pinctrl driver setting the BIT(0) in eMMC PHY IO Control 0 Register to 0 in order for the connect the eMMC/SDIO PHY to the controller and not use it as a MPP pin multiplexor. So, the mvebu-pinctrl driver check specifically for the "marvell,armada-8k-cpm-pinctrl" compatible to clear the that bit. Issue is that compatibles in the 8040 DTSI were set to "marvell,8k-cpm-pinctrl" for CP0 and "marvell,8k-cps-pinctrl" for the CP1. This is obviously incorrect as the pinctrl driver does not know about these. So fix the regression by applying correct compatibles to the DTSI. Regression found and tested on the Puzzle M801 board. Fixes: a0ba97e5 ("arm: armada: dts: Use a single dtsi for cp110 die description") Signed-off-by: Robert Marko Reviewed-by: Stefan Roese

imx: imx7d-sdb: fix ethernet, sync .dts with linux

2021-09-28T16:03:21+00:00

Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0 (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Also sync device tree with v5.5-rc1", but in the linux tree, these gpios have always been GPIO_ACTIVE_HIGH ever since this node was introduced around v4.13 (linux commit 184f39b5). I'm guessing that the reason for the GPIO_ACTIVE_LOW was to work around the behaviour of the soft-spi driver back then, which effectively defaulted to spi-mode 3 and not 0. That was arguably a bug in the soft-spi driver, which then got fixed in 0e146993bb3 (spi: add support for all spi modes with soft spi), but that commit then broke ethernet on this board. Fix it by setting the gpios as active high, which as a bonus actually brings us in sync with the .dts in the linux source tree. Without this, one gets Net: Could not get PHY for FEC0: addr 0 No ethernet found. With this, ethernet (at least ping and tftp) works as expected from the U-Boot shell. Cc: Fabio Estevam Cc: Joris Offouga Cc: "Christian Bräuner Sørensen" Signed-off-by: Rasmus Villemoes

arm: socfpga: vining: Fix UDC controller phandle in DT

2021-09-22T19:30:39+00:00

The USB peripheral controller is the DWC2 controller 1, not 0. Update the phandle to fix UDC support on this board. Signed-off-by: Marek Vasut Cc: Siew Chin Lim Cc: Simon Goldschmidt Cc: Tien Fong Chee

arm: socfpga: vining: Un-disable WDT in DT

2021-09-22T19:30:39+00:00

The WDT on this system should be enabled, make it so. Signed-off-by: Marek Vasut Cc: Siew Chin Lim Cc: Simon Goldschmidt Cc: Tien Fong Chee

arm: dts: stm32mp1: use ssbl partition name for U-Boot

2021-09-21T07:22:01+00:00

Continue to use the "ssbl" name for GPT partition of secondary boot stage = U-Boot for basic boot with SPL to avoid to disturb existing user. The "fip" partition name is only used for TFA_BOOT with FIP, it is a TF-A BL2 requirement; it the default configuration for STMicroelectronics boards. Fixes: b73e8bf453f8 ("arm: stm32mp: add defconfig for trusted boot with FIP") Signed-off-by: Patrick Delaunay Reviewed-by: Patrice Chotard

arm: mach-k3: common: Make sure firmware sections are loaded prior to armv8 startup

2021-09-17T18:48:53+00:00

With Device Manager firmware in an elf file form, we cannot load the FIT image to the exact same address as any of the executable sections of the elf file itself is located. However, the device tree descriptions for the ARMV8 bootloader/OS includes DDR regions only the final sections in DDR where the Device Manager firmware is actually executing out of. As the R5 uC is usually operating at a slower rate than an ARMv8 MPU, by starting the Armv8 ahead of parsing the elf and copying the correct sections to the required memories creates a race condition where the ARMv8 could overwrite the elf image loaded from the FIT image prior to the R5 completing parsing and putting the correct sections of elf in the required memory locations. OR create rather obscure debug conditions where data in the section is being modified by ARMV8 OS while the elf copy is in progress. To prevent all these conditions, lets make sure that the elf parse and copy operations are completed ahead of ARMv8 being released to execute. We will pay a penalty of elf copy time, but that is a valid tradeoff in comparison to debug of alternate scenarios. Signed-off-by: Nishanth Menon

arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge

2021-09-17T18:47:03+00:00

NB0 is bridge to SRAM and NB1 is bridge to DDR. To ensure that SRAM transfers are not stalled due to delays during DDR refreshes, SRAM traffic should be higher priority (threadmap=2) than DDR traffic (threadmap=0). This fixup is critical to provide deterministic access latency to MSMC from ICSSG, it applies to all AM65 silicon revisions and is due to incorrect reset values (has no erratum id) and statically setting things up should be done independent of usecases and board. This specific style of Northbridge configuration is specific only to AM65x devices, follow-on K3 devices have different data prioritization schemes (ASEL and the like) and hence the fixup applies purely to AM65x. Without this fix, ICSSG TX lock-ups due to delays in MSMC transfers in case of SR1 devices, on SR2 devices, lockups were not observed so far but high retry rates of ICSSG Ethernet (icssg-eth) and, thus, lower throughput. Signed-off-by: Roger Quadros Acked-by: Andrew F. Davis Acked-by: Tomi Valkeinen Acked-by: Benoit Parrot [Jan: rebased, dropped used define, extended commit log] Signed-off-by: Jan Kiszka [Nishanth: Provide relevant context in the commit message] Signed-off-by: Nishanth Menon

clk: ti: k3: Update driver to account for divider flags

2021-09-17T18:47:03+00:00

The K3 SoCs have some PLL output clocks (POSTDIV clocks) which in turn serve as inputs to other HSDIV output clocks. These clocks use the actual value to compute the divider clock rate, and need to be registered with the CLK_DIVIDER_ONE_BASED flags. The current k3-clk driver and data lacks the infrastructure to pass in divider flags. Update the driver and data to account for these divider flags. Signed-off-by: Suman Anna Signed-off-by: Dave Gerlach