Feb 28 2023
Feb 27 2023
A fix has been made available through the patch https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18679. It is now merged. Thanks to Sylwester Garncarek.
Feb 21 2023
Please see https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19401 which should fix this for all targets.
Jan 8 2023
The patch stack is still a work in progress so BL1 is the only fixed image so far, but BL2 and BL31 need the same treatment. Your best bet until I get around to applying these fixes to the remaining images is the current workaround (TF_LDFLAGS="--no-warn-rwx-segment").
Thanks, good to know. So, 2.9 will likely carry a fix? Is there a better patch I can use already (the one referenced does not directly appear to solve the issue)?
Hi Jan, sorry for the delay. This is currently in progress under the mixed-rwx topic: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18661/5
What's the status of this? Currently trying to build TF-A against the bookworm toolchain, and there the warning is even fatal. For now I'm working around it with this patch:
Jan 3 2023
I want to find a way to clean a memory region in TF-A firmware.
Dec 19 2022
I want to find a way to clean a memory region in TF-A firmware.
Can you elaborate what you mean by "clean" ?
From the description it seems to be a simple memset, in which case data may remain in caches.
Does the requested operation need to complete to memory e.g. involving cache clean?
Dec 13 2022
Dec 7 2022
Found a fix in atf master which seems to touch on exactly this issue: https://github.com/ARM-software/arm-trusted-firmware/commit/fa7fdfabf07d91439b0869ffd8e805f0166294bf
Nov 17 2022
Nov 16 2022
There may be something wrong with my network that I can't visit https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a. I will follow up this issue after my network is fixed.
Nov 15 2022
fix submitted
Nov 14 2022
Patch from Bug submitter also raised https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17768
Nov 10 2022
I agree with the idea and its a good capability to have. I don't thing there will be many TF-A build flags which has chance of name collision with environment variables. we can add TF-A prefix to them.
Sep 27 2022
Hi Andre-ARM, to fix the problem, here's the pull request: https://github.com/ARM-software/arm-trusted-firmware/pull/1988
Sep 26 2022
Hi,
thanks for the info, I will have a look at this, though probably only later this week.
As for rebuilding: I assume you are using the firmware drops from the pftf github?
This is deeply hidden in the EDK2 build system, but it will effectively use a precompiled version of bl31.bin checked into the edk2-non-osi.git repository. This will be placed into the first 128KB of RPI_EFI.fd file, filled up with 0xff.
So to replace just bl31.bin, you simply overwrite the first part of that file, with your compiled version.
To get bl31.bin from source, you just need an aarch64 (cross-)compiler, then:
$ CROSS_COMPILE=aarch64-linux-gnu- make PLAT=rpi4 DEBUG=0
This should be described in docs/plat/rpi4.rst. If you find something missing, let me know, or even better: send a patch ;-)
So that's a lot of details (thanks for that!), but what is the actual problem? That secondaries cannot be taken offline? Or that they don't came back online? And did that work before the commit you mentioned?
Sep 25 2022
I can confirm this occurs with binutils 2.39. We (coreboot) are trying to update binutils from our toolchain and we are about to adjust our build system. --no-warn-rwx-segment fixes the issue. https://review.coreboot.org/c/coreboot/+/66920
Sep 24 2022
Pinging @Andre-ARM RPi4 platform code owner for comment.
Sep 22 2022
Hello Olivier,
Thanks for your reply. Looks like there is a fix under works:
Adding that the linking warns about both rwx-sections and execstack for bl2 too.
So both are needed or the linking needs to be fixed.
I think the no-warn flags are only available to newer tools, so defaulting to them will probably break things.
Sep 17 2022
Hello Olivier,
Sep 13 2022
Hi,
From the logs I understand BL31 is started by U-Boot SPL rather than TF-A's BL1/BL2, correct?
Would it be possible to gather more verbose logs (build with DEBUG=1 LOG_LEVEL=50) ?
Can you share the TF-A command line used to build this platform?
In particular what's the state of EL3_EXCEPTION_HANDLING, SPD, SPMD_SPM_AT_SEL2 toggles?
Thanks, Olivier.
Sep 11 2022
Sep 10 2022
Sep 8 2022
Hey Chris, I may have raised the bug wrong we are tracking internally as its binutils-2.39, sorry!
Hi Heitbaum, could you tell me which toolchain you're using to build TF-A? The latest Arm GNU AArch64 toolchain is 11.3.Rel1, which packages binutils-2.38 and therefore compiles successfully, so I'm currently unable to reproduce this error.
Aug 19 2022
I see. Thanks for the replies. Feel free to close this task then.
Regarding this web page reporting system its mainly now being used for Bug reporting. There is now a TF-A mailing list https://lists.trustedfirmware.org/mailman3/lists/tf-a.lists.trustedfirmware.org/ where many more people can help with questions.
Yes, this is a known issue. The DTs for the base FVP model were once imported from the Linux tree, but haven't been updated since. Meanwhile both DTC and the DT schema compliance tooling in the kernel tree got stricter, so the old files trigger warnings now.
One could go ahead and just fix each of those warnings, but I am actually working on rearranging the FVP DT files, so we can sync them from the kernel tree. That should fix those messages automatically.
Aug 17 2022
I tried to follow the guidelines on https://github.com/ARM-software/tf-issues but I can't find where to add the "question" label. Sorry about this.