I'd really prefer to see the patch reverted first, and then we can figure out exactly what's going on and push a revised patch that achieves the objectives without breaking anything. It does seem to have some side-effects on the PSoC64 armclang build, too.

It's pretty standard open source process to revert a patch that breaks something like this...

Chris

From: Jamie Fox Jamie.Fox@arm.com Sent: Thursday, February 6, 2020 3:15 PM To: tf-m@lists.trustedfirmware.org; Christopher Brand chris.brand@cypress.com Cc: Gabor Abonyi Gabor.Abonyi@arm.com; nd nd@arm.com Subject: Re: PsoC64 build broken

Hi Chris,

Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START.

I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563.

Best wishes, Jamie

________________________________ From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 06 February 2020 20:11 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: Gabor Abonyi <Gabor.Abonyi@arm.commailto:Gabor.Abonyi@arm.com> Subject: [TF-M] PsoC64 build broken

Hi,

Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333

Building with gcc, I get:

/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000)

collect2: error: ld returned 1 exit status

secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed

I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it.

I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM.

Can we please revert this patch for now?

Chris

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.