User Details
- User Since
- Dec 4 2019, 12:30 AM (256 w, 6 d)
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").
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
Sep 8 2022
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.
Jan 17 2022
Hi @yuezhiran, I believe it's valid for this function to return 0. The bl1_plat_handle_post_image_load function is overridable by the platform, but we do not provide a mechanism for the platform to communicate the "acceptable" image IDs to the caller. We cannot therefore return an error if we receive an image ID that has no post-load process, because it may be called for any image (the FWU process does this here).
May 5 2021
I can only assume GCC <11 simply didn't have this warning, but it looks legitimate.
Feb 25 2021
Hi all, I suggest we move this discussion back to the mailing list so we can track the progression a bit more easily.
Feb 19 2021
Dec 4 2019
Snapcraft distributes builds for the latest stable versions of CMake: https://snapcraft.io/cmake