Hi Vic, > while trying to compile u-boot v2026.07 (or v2026.04) for RK3399-based > NanoPi R4S, I run into issues with current mainline TF-A (using 2.14, more > precisely the lts-v2.14.4 tag). I'm cross-compiling both TF-A and u-boot > using GCC version 14.2.0 (Debian 14.2.0-19) from Debian Trixie. > > First, I encountered TF-A build failure with the > > region `PMUSRAM' overflowed by 3928 bytes > > error message, which seems to be a long-term issue know since 2018: > > https://github.com/ARM-software/tf-issues/issues/650 > > and recently also mentioned in this mailing list: > > https://lists.denx.de/pipermail/u-boot/2026-April/613754.html > > Although some discussions suggest that this issue may be compiler or > toolchain dependent, I've eventually found a solution in Armbian > sources, which fix this issue by changing PMUSRAM_RSIZE from 8K to 16K:
While changing that setting may allow it to build the PMU's SRAM size in hardware is fixed, so it will cause real world problems. The thing to note with the PMU FW is it's built for a Cortex-M0 core which means you need to build it with a 32 bit compiler. You likely need to add a M0_CROSS_COMPILE=arm-linux-gnu- variable (substitute with the string for your armv7 compiler string) to the beginning of your make command. EG: M0_CROSS_COMPILE=arm-linux-gnu- make HOSTCC="gcc" CROSS_COMPILE="" PLAT=rk3399 bl31 It works across numerous rk3399 devices for me with the 2.14.1 build in Fedora and that firmware is about 5.7K in size. > > https://github.com/armbian/build/blob/main/patch/atf/atf-rockchip64/v2.14/1002-2.14-rk3399-PMUSRAM_RSIZE-8k-16k.patch > > I'm also using two other Armbian RK3399-related patches to TF-A as these > looked useful to me: > > > https://github.com/armbian/build/blob/main/patch/atf/atf-rockchip64/v2.14/1001-2.14-rk3399-m0-LDFLAGS-no-pie.patch > > https://github.com/armbian/build/blob/main/patch/atf/atf-rockchip64/v2.14/1003-rk3399-fix-pl330-dmac-sgrf-init.patch > > With all these patches applied to TF-A lts-v2.14.4, I can successfully > build TF-A and get bl31.elf with .pmusram segment of 0x2f58 (12120) > bytes (i.e. 8192 bytes of the original limit plus 3928 bytes which used > to overflow without the patch): > > $ readelf -l ../trusted-firmware-a/build/rk3399/release/bl31/bl31.elf > > Elf file type is EXEC (Executable file) > Entry point 0x40000 > There are 6 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000010000 0x0000000000040000 0x0000000000040000 > 0x0000000000023000 0x0000000000023000 R E 0x10000 > LOAD 0x0000000000033000 0x0000000000063000 0x0000000000063000 > 0x0000000000000051 0x0000000000081000 RW 0x1000 > LOAD 0x0000000000034000 0x00000000ff3b0000 0x00000000ff3b0000 > 0x0000000000002f58 0x0000000000002f58 RWE 0x1000 > LOAD 0x0000000000037000 0x00000000ff8c0000 0x00000000ff8c0000 > 0x0000000000002000 0x0000000000002000 R E 0x1000 > LOAD 0x0000000000000000 0x00000000ff8c2000 0x00000000ff8c2000 > 0x0000000000000000 0x0000000000001000 RW 0x1000 > GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 RW 0x10 > > Section to Segment mapping: > Segment Sections... > 00 .ro > 01 .data .stacks .bss .per_cpu .xlat_table .coherent_ram > 02 .pmusram > 03 .incbin_sram .text_sram > 04 .stack_sram > 05 > > I can also successfully build u-boot with nanopi-r4s-rk3399_defconfig > and this bl31.elf, where a 12120 bytes blob goes to atf-3 according to > mkimage: > > Image 3 (atf-3) > Description: ARM Trusted Firmware > Created: Sat Jul 18 17:02:03 2026 > Type: Firmware > Compression: uncompressed > Data Size: 12120 Bytes = 11.84 KiB = 0.01 MiB > Architecture: AArch64 > OS: ARM Trusted Firmware > Load Address: 0xff3b0000 > Hash algo: sha256 > Hash value: > bb3956f441de43bdc2b0946e2429f1166b4e54fe67cbca6c9fbfa9371b5ecfc9 > > Sadly, when I try to boot it from SD card, it fails because of hash > verification failure for atf-3: > > U-Boot SPL 2026.07 (Jul 17 2026 - 15:40:20 +0200) > Trying to boot from MMC2 > ## Checking hash(es) for config config-1 ... OK > ## Checking hash(es) for Image atf-1 ... sha256+ OK > ## Checking hash(es) for Image u-boot ... sha256+ OK > ## Checking hash(es) for Image fdt-1 ... sha256+ OK > ## Checking hash(es) for Image atf-2 ... sha256+ OK > ## Checking hash(es) for Image atf-3 ... sha256 error! > Bad hash value for 'hash' hash node in 'atf-3' image node > spl_load_simple_fit: can't load image loadables index 2 (ret = -1) > mmc_load_image_raw_sector: mmc block read error > > An easy workaround is to disable FIT verification (SPL_FIT_SIGNATURE > and CONFIG_SPL_FIT_FULL_CHECK) in the SPL, without these I get a working > u-boot and smooth running linux-6.18.38 without any signs of trouble: > > U-Boot TPL 2026.07 (Jul 15 2026 - 17:34:15) > Trying to boot from BOOTROM > Returning to boot ROM... > > U-Boot SPL 2026.07 (Jul 15 2026 - 17:34:15 +0200) > Trying to boot from MMC2 > load_simple_fit: Skip load 'atf-5': image size is 0! > NOTICE: BL31: v2.14.4(release):lts-v2.14.4-3-g4660bf8b7 > NOTICE: BL31: Built : 22:54:17, Jul 14 2026 > > > U-Boot 2026.07 (Jul 15 2026 - 17:34:15 +0200) > > SoC: Rockchip rk3399 > Reset cause: POR > Model: FriendlyElec NanoPi R4S > DRAM: 4 GiB (total 3.9 GiB) > PMIC: RK808 > Core: 281 devices, 25 uclasses, devicetree: separate > MMC: mmc@fe320000: 1 > Loading Environment from <NULL>... OK > In: serial > Out: serial > Err: serial > Model: FriendlyElec NanoPi R4S > Hit any key to stop autoboot: 0 > ** Booting bootflow '[email protected]_1' with script > 7211491 bytes read in 310 ms (22.2 MiB/s) > 62459 bytes read in 5 ms (11.9 MiB/s) > Uncompressing Kernel Image to 0 > ## Flattened Device Tree blob at 12000000 > Booting using the fdt blob at 0x12000000 > Working FDT set to 12000000 > Loading Device Tree to 00000000f4f63000, end 00000000f4f753fa ... OK > Working FDT set to f4f63000 > > Starting kernel ... > > However, the need to disable SPL FIT verifications because of the > mysterious hash verification failure for atf-3 (which seems to contain > the PMUSRAM blob whose size I had to change from 8K to 16K to fix the > TF-A build failure) makes the resulting system considerably less > trustworthy to me. > > I suspect that the PMUSRAM_RSIZE setting in TF-A may have a > corresponding counterpart in u-boot, which may need to be changed too > when the TF-A value is raised from 8K to 16K. But I didn't manage to > find any such setting in u-boot. > > Also, I'm also quite confused that despite mainline TF-A failing to > build for RK3399, there seem to be several people submitting recent > patches for RK3399 boards to u-boot. As TF-A is required by u-boot for > RK3399, this makes me wonder what version of TF-A those people use > and/or how they fix the PMUSRAM region overflow issue. > > Any hints or thoughts on what is wrong here will be appreciated. > > Vic
