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.

fix submitted

Patch from Bug submitter also raised https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17768

Hi Andre-ARM, to fix the problem, here's the pull request: https://github.com/ARM-software/arm-trusted-firmware/pull/1988

In T1003#11851, @Andre-ARM wrote:

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 ;-)

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 ;-)

In T1003#11849, @Andre-ARM wrote:

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?

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?

Pinging @Andre-ARM RPi4 platform code owner for comment.

Hello Olivier,

Thanks for your reply. Looks like there is a fix under works:

Hello Olivier,

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.

Ping @raghuncstate for comment https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=7c2fe62f1347bb94d82e9fdd3bc5eaebedaf0bc7

TF-A works on a 6 month release cadence and we typically update the gcc toolchain to the latest released version along with the TF-A release. gcc versions we use are downloaded from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/downloads.
Currently we don't update the toolchain to any versions newer than the one released here. We used the version 10.3-2021.07 with TF-A v2.6 release and will be updating to version 11.2-2022.02 with our upcoming v2.7 release which is planned for the end of May, 2022.

A similar issue was reported in the ticket https://developer.trustedfirmware.org/T984
Can you confirm if this issue is due to a bug in the toolchain itself?

Reported bug in gcc 12.1.0

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523

The issue is related to this GCC ticket:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Which is corrected in the official GCC 12.1 version.

fix change need to review at:
11218: fix(xlat): fix crash when enable verbose log on some platform.

The problem has been solved.

Hi,
A developer submitted a patch which closely relates to this issue. Please give your feedback here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7314

Hi,
Please use personal email and git configs/identity to push the patch to trustedfirmware.org. Few developers from the tf-a community have done this. Here is a link to contribution guidelines:

Thanks for your reply. It is difficult to submit code to community or Gerrit using company's account and system. So, I wonder whether it's permitted to upload by providing modifications or “git send-email” with patches.

Hi,
Yeah, looks like such a large system with numerous clusters will run into an issue with the current limitation of "lock_index" being "unsigned char". Please go ahead and submit a patch for review:

Yes, The power domain topology of the system can be described as 8 sockets, each socket with 10 clusters and each cluster with 8 cores. We just consider a system like this might face the constraint mentioned above, and we must modify the declaration of lock_index to solve this problem. Feature, more and more interconnected system, with numerous cpus, might face the same problem.

Hi,
The struct "non_cpu_pwr_domain_node" represents a non-leaf power domain in an SoC such as a logical cluster. As you mentioned, the lock_index declaration with "unsigned char" limits such non-cpu power domains to 64. I believe it doesn't restrict the number of CPUs in a system to be <= 64. Do you currently face an issue with PSCI implementation due to the above constraint? Can you advise what is the power domain topology of your system? I think the lock_index can be expanded using "unsigned int" if needed.

@ManishVB-Arm has posted a patch to address your issue, see https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5119
Would you mind taking a look and letting us know whether it fixes the issue for you?

Thanks for your comments and clarification. I should have updated this ticket with the information provided in the mail list, in order to keep them in sync.

I noticed this as well, and I was on the verge of submitting a patch until I looked into it further and decided that the current default is justifiable.

Hello Matteo,
Yes, you are right ID_AA64PFR0_EL1 must be used. Thanks for spotting this!

OK. Regarding naming suggestions, I like func_noabi/endfunc_noabi the most. The reason why I am discounting asmfunc/endasmfunc is because a function implemented in assembly language might still respect the ABI.
I suggest we start with func_noabi/endfunc_noabi and continue the discussion on the patch on Gerrit. Unfortunately, this ticketing system does not have the same visibility as Gerrit or the mailing list and not everyone subscribe to these.

Hi @sandrine-bailleux-arm
Ok, In order to safe iterations.
I plan to suggest a new macro which does the followin

• creates a new section - as func does
• sets the alginment - as func does
• sets the type
• together with the counterpart end??? is sets the .size

. Proposals for names

• func_noabi/endfunc_noabi - a non-abi conformant function
• asmfunc/endasmfunc - a assembly routine/function
• sym/endsym - short, but the name does not imply that it actually creates a block of code/own section
• ...

Current gerrit proposal to fix this can be found in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3749 (and related preceding commits).

I can try end of the week. Thanks.

Corrected with the following commit that has just been merged:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3518

This makes sense to me. Would you mind preparing a patch that removes the func macro on el3_exit and post it on review.trustedfirmware.org ?

Hi Andrew, yes the change looks fine.

If this generally looks okay I'm happy to follow https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ and push this for review according to the TF-A workflow.

Again, this is for now staged via Pete's tree and you can view the pull request here - https://github.com/pbatard/arm-trusted-firmware/pull/2

This has been fixed in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2789.

Fixed and merged on 8/10/2019:
https://git.trustedfirmware.org/TF-A/tf-a-tests.git/commit/?id=fb003380a01843d0de71ba3374394a798289c64f

Patch submitted for review as https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2724

I don't know what options you tried to build with, but I managed to build with the ROMLIB feature for the FVP platform. I will post everything I did here, hoping it will be of some use to you.
I used the following command to build:

MBEDTLS_DIR=<path_to_mbedtls> make ARM_ROTPK_LOCATION=devel_rsa CROSS_COMPILE=<path_to_cross_compiler(aarch64)> GENERATE_COT=1 PLAT=fvp ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem TRUSTED_BOARD_BOOT=1 USE_ROMLIB=1  DEBUG=1 fiptool all

The cross-compiler I used is GCC 8.3 for AArch64 ELF bare-metal target. You can get it from here:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads

https://review.trustedfirmware.org/#/c/TF-A/tf-a-tests/+/2179/