u-boot.git/arch, branch v2025.01

imx: Fix usable memory ranges for imx8m SOCs

2024-12-19T18:17:52+00:00

commit e27bddff4b97 ("imx8m: Restrict usable memory to space below 4G boundary")
tried to adjust the usable memory limits on a 4GB boundary.

ram_top is described as 'top address of RAM used by U-Boot' and we want
to preserve that. This is defined as a phys_addr_t and unfortunately
its size differs across architectures. This has lead us to a weird
state where 32bit boards define it 'SZ_4GB - 1' and 64bit boards as
'SZ_4GB' unless it was otherwise defined.

With some recent LMB changes and specifically
commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
the board fails to boot properly although the commit above is correct
since it's making sure that no memory above ram_top is usable -- but
added to our memory map so EFI can hand it over to the booted OS.

The reason for that is that during the LMB init we add all usable memory
in lmb_add_memory(). In that function any memory above ram_top gets added
as 'reserved' for LMB. With the current values tha's set to 0xFFFF_FFFF
for this board. Later LMB is trying to protect the memory area U-Boot lives
in with lmb_reserve_common(). The latter fails though since it tries to
add U-Boot top (which is 0xFFFF_FFFF as well) to U-Boot 'bottom'. This call
will fail since 1 byte of that memory range is already marked as 'reserved'.

Since we are close to the release, LMB seems to assume that the address
is rounded up and is the 'next address' and so does parsing and adding
memory ranges from DT files, bump the ram_top of the board by 1byte.

In the long run we should change all of the above and have 32b and 64b
platforms define ram_top identically.

Add a Fixes tag although the commit is correct, so people can figure out
the broken scenarios in the future.

Suggested-by: Sughosh Ganu
Fixes: commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
Signed-off-by: Ilias Apalodimas
Reviewed-by: Frieder Schrempf
Reported-by: João Paulo Gonçalves
Closes: https://lore.kernel.org/all/20241216114231.qpfwug3zfqkxn3d5@joaog-nb.corp.toradex.com/
Reviewed-by: Peng Fan
Fixes: 74f88b72219e ("ARM: imx: imx8m: Fix board_get_usable_ram_top()")

ARM: dts: stm32: Reinstate missing root oscillators on DH STM32MP15xx DHCOR

2024-12-18T10:30:27+00:00

The root oscillators reference used to be in rcc node since
3d15245502c4 ("ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver")
however this is not part of upstream stm32mp151.dtsi . The
RCC driver does need this reference, reinstate it locally.

Signed-off-by: Marek Vasut 
Reviewed-by: Patrice Chotard

ARM: dts: stm32: Reinstate missing root oscillators on STM32MP15xx

2024-12-18T10:29:47+00:00

The root oscillators reference used to be in rcc node since
3d15245502c4 ("ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver")
however this is not part of upstream stm32mp151.dtsi . The
RCC driver does need this reference, reinstate it globally.

Signed-off-by: Marek Vasut 
Reviewed-by: Patrice Chotard 
Tested-by: Patrice Chotard

ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB located above ram_top

2024-12-17T15:14:01+00:00

Previously, all LMB marked with LMB_NOMAP (above and below ram_top)
are considered as invalid entry in TLB.

Since commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top
 even from same bank") all LMB located above ram_top are now marked
LMB_NOOVERWRITE and no more LMB_MAP.

This area above ram_top is reserved for OPTEE and must not be cacheable,
otherwise this leads to a Panic on some boards (Issue on STM32MP135F-DK).

Restore previous behavior by marking invalid entry all TLB above ram_top.

Fixes: 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")

Signed-off-by: Patrice Chotard 
cc: Sughosh Ganu 
Acked-by: Sughosh Ganu

board: sl28: fix USB0

2024-12-15T01:00:32+00:00

Since commit 61ff13283c3b ("board: sl28: move to OF_UPSTREAM") USB0 is
broken because the former u-boot soc dtsi was setting dr_mode to "host"
but the linux device tree isn't. That is because linux fully supports
OTG but u-boot doesn't. Therefore, u-boot only ever enabled host mode
and never OTG mode. Add it to our board "-u-boot.dtsi" to fix it.

Fixes: 61ff13283c3b ("board: sl28: move to OF_UPSTREAM")
Reported-by: Heiko Thiery 
Signed-off-by: Michael Walle 
Tested-by: Heiko Thiery 
Signed-off-by: Peng Fan

ARM: renesas: Fix R-Car spelling

2024-12-11T07:36:24+00:00

The correct spelling is R-Car, including the dash, update the usage.
Kconfig strings and comment changes only, no functional change.

Signed-off-by: Marek Vasut

ARM: dts: renesas: Fix R-Car spelling

2024-12-11T07:36:24+00:00

The correct spelling is R-Car, including the dash, update the usage.
Comment change only, no functional change.

Signed-off-by: Marek Vasut

arm64: renesas: Disable AVB1 and AVB2 on R8A779G0 V4H White Hawk board

2024-12-08T22:07:34+00:00

The U-Boot is currently not capable of handling ethernet-phy-ieee802.3-c45
PHYs correctly, and also does not handle MDIO bus wide reset-gpios property.
Until proper C45 PHY support lands in U-Boot, disable AVB1/AVB2 interfaces.
This only disables the two MACs with 88Q2110/88Q2112 100/1000BASE-T1 PHYs
on ethenet sub-board, the main board AVB0 ethernet is unaffected.

Signed-off-by: Marek Vasut

Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-samsung

2024-12-03T18:37:20+00:00

Revert "global_data: Drop spl_handoff"

2024-12-02T13:40:39+00:00

This breaks chromebook_coral which says:

   Video: No video mode configured in FSP!

This reverts commit 2e9313179a846b581c0fc3f6a49e19f3d343efa8.

Signed-off-by: Simon Glass