Use the ARM64 kernel booting register settings, defined in Linux
documentation Documentation/arch/arm64/booting.rst:

 x0 = physical address of device tree blob (dtb) in system RAM.

so kernel can replace U-Boot in FIP without modification of BL31.

Use x0 for future TF-A version and keep x2 as fallback to be compatible
with previous version of TF-A BL31.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

On the RZG2L platform, the advised
TF-A (https://github.com/renesas-rz/rzg_trusted-firmware-a/tree/v2.5/rzg2l)
does not pass any DTB blob to U-Boot.

On the other hand, the RZG2L part of U-Boot expects a DTB to be passed.  It
means that if one flashes the latest TF-A as well as the mainline U-Boot,
it will crash trying to dereference the NULL DTB pointer before outputing
anything.

Check if the DTB pointer is NULL before trying to use it.

Signed-off-by: Mathieu Othacehe <othacehe@gnu.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

The LPCG number on iMX93 and iMX91 is 127 not 122. The wrong
value is used in ccm_reg structure and Coverity reports several
issues as out-of-bounds write.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

The ELE MU driver needs to be probed at init_r phase as well because
some ELE APIs will be called.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

The config "GIC_V3" seems to be typo, and currently "GICV3" remains
disabled. This should be removed until needed.

Fixes: 5cd4a355e0f0 ("board: synquacer: Add DeveloperBox 96boards EE support")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/27660

- Restore the support for the i.MX95 A0 silicon.

Enable HBMC in the R5 SPL stage

Fixes: c9df79ee64d0 ("arm: dts: k3-j721e-r5-common: Add HBMC overrides for R5 SPL")
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>

This patch is used to restore support for i.MX95 A0 silicon. To avoid
duplicating defconfig, imx95.config is added and can be shared between
imx95_a0_19x19_evk_defconfig and imx95_19x19_evk_defconfig.

container.cfg and imximage.cfg are used to created .cfgout files that
are be passed to mkimage with -n to build flash.bin. Now they have been
deleted and replaced by adding their content to properties of node which
type is nxp-imx9image under binman node.

Fixes: 9936724aa9b ("imx95_evk: Add i.MX95 B0 support")

Signed-off-by: Alice Guo <alice.guo@nxp.com>
Tested-By: Tim Harvey <tharvey@gateworks.com> # imx95-19x19-evk (rA0)

SPL recover data section is broken which causes reboot failure on
some i.MX platforms (iMX8QM/iMX95).
The global variable cold_reboot_flag is assigned to weak reset_flag
function which always return 1, so restore never been executed in
warm reboot.

Fixes: 1c37e59bfbba ("arm: armv8: Improve SPL data save and restore implementation")
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

Anshul Dalal <anshuld@ti.com> says:

On various TI's K3 platforms boot failure was observed on SPI NOR since the
commit 5609f200d062 ("arm: Kconfig: enable LTO for ARCH_K3"). This issue was
root caused to stack corruption by the 'udma_transfer' function. Where the local
variable 'paddr' of type 'dma_addr_t' was being written to as a 64-bit value
which overwrote the stack frame of the caller (dma_memcpy) as only 32-bits had
been reserved for paddr on the stack, specifically the r4 register in the frame
of dma_memcpy was being overwritten with a 0.

drivers/dma/ti/k3-udma.c:2192:

	int udma_transfer(...)
	{
		...
		dma_addr_t paddr = 0;

		...
		/* paddr was written to as 64-bit value here */
		udma_poll_completion(uc, &paddr);
	}

drivers/dma/dma-uclass.c:234:

	int dma_memcpy(...)
	{
		dma_addr_t destination;
		dma_addr_t source;
		int ret;

		...

		/* This call resolves to udma_transfer */
		ret = ops->transfer(...);

		...

		dma_unmap_single(destination, ...);
		dma_unmap_single(...);
		return ret;
	}

Enabling LTO changed how gcc mapped local variables of dma_memcpy to CPU
registers, where earlier the bug was hidden since the overwritten register
'r4' was allotted to 'ret' but was allotted to 'destination' once LTO was
enabled. And since the overwritten value was 0, the bug remained undetected
as it just meant ret was 0, but having 'destination' set to 0 caused
dma_unmap_single to fail silently leading to boot failures.

The fix entails enabling DMA_ADDR_T_64BIT which changes dma_addr_t from u32 to
u64 for the R5 SPL thus reserving enough space for 'paddr' to prevent the
overflow.

Link: https://lore.kernel.org/r/20250903115207.572304-1-anshuld@ti.com