I will close this ticket, as there was no activity since 2022 and I am assuming Chris' answer covered it.

@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?

@soby-mathew: That was the intended meaning. Reworded, thanks.

@raghuncstate Thanks!

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.

Sorry if it wasn't clear in my original answer, the SAVE_KEYS=1 option (and friends) must be passed on the command line when you build the firmware, not the cert_create tool itself. The tool has no built-in knowledge of which keys it should use, instead it is told so when it is invoked.

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 ?

By default, the cert_create tool creates temporary keys that it keeps in RAM just to sign the certificates. These keys are not stored in files on the disk and are thus discarded after the tool exits.
If you want to save them, please have a look at the SAVE_KEYS build option. In your case, adding SAVE_KEYS=1 NON_TRUSTED_WORLD_KEY=ntw.key BL31_KEY=bl31.key to your command line should do what you want. You'll get the private keys in PEM format I believe, from which you can generate the associated public keys using the openssl tool (or equivalent) if needed.

@danh-arm Good point, done.

I am not aware of any specific reason for LOG_LEVEL values being multiple of 10's. I guess at the time we thought we should leave room in between values, just in case we'd like to add more intermediate values in the future. In the end, I think it proved unnecessary but it stayed like that. I don't foresee the need for more log levels today so IMHO it would be OK to change their values to 1,2,3 and so on, as you suggested.

I've subscribed both of you to this ticket because git blame shows you as contributors for this platform port. Sorry if you're not the right people to notify about this and feel free to bounce that back to whoever would be appropriate!

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2302 has been merged so I am closing this task.

Fixed by the following patch: https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/2834
Credit to @MarekBykowski .

Hi Simon,

Could you please elaborate on your issue? How are you trying to configure your email address in Gerrit? Are you doing it from the user settings page? Do you have no email address registered on Gerrit at all or are you trying to add a secondary one? When is the error 422 showing?

So, just to be clear: Imagine a scenario with two devices - one I made (I know the keys and code on BL1) and another one that some malicious user cloned (he signed with his own keys). My device will have a Root of Trust in BL1 based on my hardware and the keys I own. The second device also has a BL1 but that image was signed by someone I don't trust. In the end, both devices will boot up successfully because they are based on each individual Chain of Trust but there's no way a third party (i.e. remote attestation server) can know the difference between the malicious device and my device solely relying on Verified Boot, right?

Sorry, I completely missed your point at first!

Hi Viviane,

This might be related to https://developer.trustedfirmware.org/T127

On the other hand, this might just hide issues. This ticket needs more thoughts.

The MPIDR_CPU/CLUSTER_ID macros have been removed by this patch.