Please note, this has NOT been tested with ARMCLANG, only with GNUARM. Further testing and work is required for ARMCLANG support.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3875

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3831

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3832

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.

Internal ref: https://jira.arm.com/browse/IOTPSW-2914

Internal ref : https://jira.arm.com/browse/IOTPSW-2861

Internal ref : https://jira.arm.com/browse/IOTPSW-2826

Internal ref: https://jira.arm.com/browse/IOTPSW-2801

Internal ref: https://jira.arm.com/browse/IOTPSW-2817

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
• ...

This causes random failure in PSA Arch ITS and PSA Arch PS tests.

See related Musca-A2 issue here : https://developer.trustedfirmware.org/T694

We would need to support versioning of SST FS data and also have mechanisms to detect if the flash is clean or in consistent state.

Internal ref : https://jira.arm.com/browse/IOTPSW-2808

This issue is also seen on Musca-A board.

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

This is an issue on FVP. It will case the system cannot boot up after a warm reset. So as a workaround, we have to skip BL2 when testing.

The output hangs at this point :

This is a known limitation of CC-312 and hence will not be fixed in TF-M code.

Update from Tamas

I can try end of the week. Thanks.

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.

Thanks for reminding me. Miss it. All patches had been merged, close it.

@edison-ai , both patches were merged. Is this task done?

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

Hi @sandrine-bailleux-arm, where do the PEM files go? Because I still can't find them.

Thanks a lot @sandrine-bailleux-arm for the input. I will try it now.

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.

Could we remove the "TF-A/TF-M" bit from the title and just make it clear in the "Goal of this proposal" that we're focusing on TF-A/TF-M initially? Eventually we want this to apply to all projects.

I took the patch and put it into gerrit. Due to a lack of name or email address I used mine. Happy to change that once I learn about the real identity or "armlabs".

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 page lists cmake versions available in different Linux distributions.
https://gitlab.kitware.com/cmake/community/-/wikis/CMake-Versions-on-Linux-Distros

Love to comment on Google it.