On Sun, 26 Jul 2026 at 12:46, Vic B <[email protected]> wrote: > > On Fri, Jul 24, 2026 at 02:55:20PM +0200, Quentin Schulz wrote: > > Hi Vic, > > Hi Quentin, > > > Since this is not really a U-Boot issue but rather TF-A as I understood it, > > maybe add (or switch to) the TF-A mailing list in Cc/To? c.f. > > https://lists.trustedfirmware.org/mailman3/lists/tf-a.lists.trustedfirmware.org/ > > > > The few times I wrote there I got first support in under a few days. > > Yes, switching to TF-A mailing at this point is obviously the best way > to go now. > > Although GCC 14.2 from Debian's stable which hits this issue is no longer > supported by TF-A (according to TF-A docs, minimal supported version GCC > version is 14.3), the same failure also happens on Debian testing with GCC > 15.2, which is another reason to continue with TF-A folks rather than > let this go.
The thing to note is it builds and works fine using the Fedora gcc toolchain so it might not be considered a TF-A problem by the upstream project. Now many that comes down the debian build options, or settings in TF-A code, or some random combination of pieces is what needs to be worked out. > > > The Armbian's attempt to fix the issue by increasing PMUSRAM_RSIZE > > > in plat/rockchip/rk3399/include/shared/addressmap_shared.h from 8K > > > to 16K seems like more promising course to me - although the resulting > > > build with oversized pmusram isn't really usable, it produces much more > > > > I don't think generating a broken binary over erroring out is a good thing > > (it seems however to be quite useful for your debugging session :) ). What I > > mean is that I don't think this is something we should get merged into TF-A. > > I'm sure this one shouldn't get merged, although it is useful for > debugging, when the broken binary gets loaded by u-boot (which is > possible after disabling hash verification), it most probably results > in the M0 PMU running garbage after having the first half of its code > overwritten by the overflowing part. > > But despite the M0 PMU running garbage and most probably not working at > all, the system appears stable even with this obviously broken binary. > > And this is IMHO yet another reason to ask for help from TF-A folks, as I > have no idea how to determine whether the resulting PMUSRAM image works > as expected. > > Cheers, > > Vic > > > I have neither the time nor knowledge to look at the rest unfortunately, but > > I really appreciate you giving lots of information and debugging output, I'm > > sure this will help someone help you eventually :) > > > > Cheers, > > Quentin
