On Wed, Jul 22, 2026 at 05:23:58PM +0100, Peter Robinson wrote: > Hi Vic,
Hi Peter, > 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. I've been trying to figure out whether the PMU SRAM size is fixed on RK3399, but haven't found the answer. Unlike e.g. RK3528A, where the block diagram clearly says "PMU_SRAM(8KB)", RK3399's datasheet only mentions that SRAM size is 200KB and security or non-security space is software programmable by 4 KB step. I was therefore hoping that changing PMUSRAM_RSIZE will cause something (TF-A or u-boot) to adjust the PMU SRAM region automatically, but it's probably better to assume that it's indeed fixed to 8KiB. I have also modified boot/image-fit.c to dump whole image on hash verification failure, and found out that while the original oversized byte pmusram image (atf-3) of 12120 bytes consist of 3859 mostly non-zero bytes (looking like code), followed by zero padding up to offset 8191, some data from offset 8192, followed by zeroes from offset 8508 till the end, the image that u-boot sees in memory during hash verification has its beginning overwritten by the part which can be seen at offset 8192 in the original. This kind of overflow probably also indicates that the limit is 8 KiB (and also definitely causes me to no longer trust this oversized build of trusted firmware, despite the fact that the systems seems to run fine with it). > 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 I've tried M0_CROSS_COMPILE with both arm-linux-gnuebi- and arm-none-eabi-, but neither helps. I also suspects that TF-A 2.14 selects arm-none-eabi- automatically for M0, as it fails to build without gcc-arm-none-eabi installed (at least on Debian), and it builds successfully (with increased PMUSRAM_RSIZE) when installed, without using M0_CROSS_COMPILE. Also make_helpers/toolchains/rk3399-m0.mk and the last Chris Kays's comment in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36981/comments/877be809_5abf10d8?tab=comments suggest that arm-none-eabi is the right way to go. > 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. As Quentin Schulz explained in his reply, the overflow issue is known to happen with Debian's gcc, and considered to be a Debian bug by some because it doesn't happen on Fedora. According to my fiddling with it so far, it appears that Debian's gcc decides to align a part of pmusram (more precisely, the part called rk3399m0pmu_bin, which seems to be linked using the recipe in plat/rockchip/rk3399/drivers/pmu/pmu_fw.S) to 8 KiB boundary, which causes the overflow. I also have doubts that this is a bug in Debian's gcc, adjusting the build/linking of TF-A so that it prevents gcc (or its ld) from aligning rk3399m0pmu_bin to 8 KiB seems like more promising solution than waiting for maintainers of Debian's gcc to do something that will fix this issue. I'll post more details in reply to Quentin's message. Vic
