Hi,
If no objections, I would like to ask for code review on
the patch. The patch has been verified by CI.
Thanks,
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Bøe, Sebastian via TF-M
Sent: Friday, December 10, 2021 9:20 PM
To: tf-m@lists.trustedfirmware.org; Tamas Ban <Tamas.Ban@arm.com>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Eliminate unnecessary space in tfm_s.bin
Great, then no objections from our side on this change.
From: TF-M <tf-m-bounces@lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, December 10, 2021 2:18 PM
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Eliminate unnecessary space in tfm_s.bin
Hi Sebastian,
The veneers location is a built time contract between the Secure and the Non-secure image. When NS image calls a Secure function it jumps to build time hardcoded (by the compiler) address.
This mandates that for supporting independent updates (either S or NS) the veneer location must be on a fixed address. Otherwise, the contract will be broken and the secure function call not working anymore.
So, if we would move the veneer region from the end of the image to the beginning (behind the vector table) then this requires updating the device once with both images together to keep them synced. When this is done then again the images
can be updated independently because the new veneer location will be fixed again.
> Is it DFU from 1.5 to 1.6 that would not be possible?
It works but S and NS must be updated together.
Tamas
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Bøe, Sebastian via TF-M
Sent: 2021. december 10., péntek 13:28
To: tf-m@lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2@arm.com>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Eliminate unnecessary space in tfm_s.bin
Hi,
we are concerned about the time it will take to do Over-the-Air Device Firmware Update
when we can't update the images independently.
This timing is of critical importance for products that don't want downtime during updates.
Also, we don't understand why the veneers are not considered to be fixed in both situations.
And consequently, why moving them prevents update of the images independently.
Please clarify.
Is it DFU from 1.5 to 1.6 that would not be possible?
That we are OK with.
From: TF-M <tf-m-bounces@lists.trustedfirmware.org> on behalf of Sherry Zhang via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, December 9, 2021 11:18 AM
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: [TF-M] Eliminate unnecessary space in tfm_s.bin
Hi,
Currently, in the compiler link script, the CMSE VENEER section is placed at a fixed address which is at the end of tfm code. See code for
armclang and
gnu arm.
Placing the veneers at the fixed address has the benefit that the when the secure image updates, the veneer symbols remain unchanged. So, the nonsecure image does not have to be updated together.
The problem is that the size of tfm_s.bin is always the same in different TF-M build configurations(debug mode, release mode, profile small, profile large and so on). So, there can be large empty space between the end of tfm code and
the veneer section.
As we discussed on today's tech forum meeting, I propose to move the LR_VENEER from the end of tfm code to right after the secure vector table. In this way, the space between the tfm code and the veneers section is eliminated. Also,
the supported number of interrupts for each platform is fixed. So, the size of the vector table is fixed for each platform. So, the start address of veneer section is still fixed for each platform. The size of tfm_s.bin is reduced significantly after this
change. Take the AN521 platform for example, the size of tfm_s.bin has a 70 percent reduction.
The link script change for
armclang and
gnu arm in
this patch can help me demonstrating my proposal. I am not hurry asking for review and merge this patch. As it impacts all the platforms, I want to get confirmed that all platforms which are using the common link script are happy with this proposal.
Any comments or especially concerns on this proposal?
Thanks,
Regards,
Sherry Zhang