Re: [TF-M] TF-M NS regression tests - linker issue

Hi Devaraj,

Good to know you have a solution for this. I was thinking about the name ‘tfm_log_printf’ – because we shared this function between NS and SPE so there is a ‘tfm’ prefix. After this linker issue is reported, it reminds me that we need to define this interface into a more rational name for portability.

We need to think about how the ns test can be integrated with a RTOS. Let’s see if some other RTOS users could provide more feedback.

/Ken

From: Devaraj Ranganna Devaraj.Ranganna@arm.com Sent: Thursday, February 6, 2020 9:39 PM To: Ken Liu Ken.Liu@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] TF-M NS regression tests - linker issue

Hi Ken,

I’d prefer that TF-M keep exporting the pre-compiled archive for regression tests. The rational behind that is less files to be added/maintained by NS RTOS. Considering this, I think quick and easy way to solve this is for NS RTOS to implement ` tfm_log_printf ` using the print method available. This way no changes are needed in TF-M.

I thought about platform-specific shim layer, like adding a new print function “ns_log_printf” to the OS wrapper (app/os_wrapper_cmsis_rtos_v2.c) and use that for NS regression tests. I believe it’s not worth the effort and also it will add another layer of indirection.

To summarise, we’ll implement `tfm_log_printf ` in Mbed OS which should resolve the linker issue.

Thanks, Dev

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com> Date: Wednesday, 5 February 2020 at 04:50 To: "tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org" <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue

Hi Devaraj,

Thanks for the clarification. Looks like this issue is caused by the way the building system integrates the test package with NS RTOS - if source-level integration is applied then the modification is not a problem and this should be the better way - even if we recover the 'printf' implementation, for those RTOS who has no printf, it would be another issue.

I think the possible solutions can be:

* If we keep using the pre-compiled archive, then some platform-specific shim layer needs to be available to provide platform-specific functions.

* If we changed to source-level integration then things would be easier.

* A quick way is as you requested, recover back to 'printf'. For the 3rd point, there are some pre-actions to be done:

* Make sure the compiler optimization function is limited for easier the implementation of these stdio functions. There is a leading patch for this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3217 * Define the HAL functions for output so that the printf implementation is not CMSIS specific. May I ask how you fix this issue?

/Ken

________________________________ From: Devaraj Ranganna <Devaraj.Ranganna@arm.commailto:Devaraj.Ranganna@arm.com> Sent: Tuesday, February 4, 2020 11:16 PM To: Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue

Hi Ken,

Currently, TF-M build process creates an pre-compiled archive of NS tests and exports it. But the implementation of `tfm_log_printf` is not exported. This causes a linker issue when NS tests archive is linked with NS RTOS, which is the reason why subject of this mail contains `linker issue`.

Having said that, exporting `tfm_log_printf` won’t solve the problem because `tfm_log_printf` assumes availability of CMSIS driver framework.

Also the latest suggestion on the ticket https://developer.trustedfirmware.org/T664 `And I think if you forward the TEST_LOG to your OS printf implementation then everything would be fine?` won’t help because of pre-compiled archive.

It looks like only possible solution for NS RTOS is to implement ` tfm_log_printf `. Please do recommend if you have any other ideas.

Thanks,

Dev

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com> Date: Saturday, 1 February 2020 at 04:46 To: "tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org" <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue

Hi,

Why the title is ‘linker issue’ since it is discussing about the printf things?

/Ken

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday, January 31, 2020 9:57 PM To: TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org Subject: [TF-M] TF-M NS regression tests - linker issue

Hi,

The TF-M NS regression tests were portable enough to run in a rich OS environment. After replacing printf with tfm_log_printf, the TF-M regression tests are now no longer portable enough to run in an OS environment. Many OSes already have a way to print, usually via a printf function, and the TF-M regression tests probably should use this.

It's important that TF-M regression tests remain portable and capable of running in an OS environment so that system integrators can be confident that TF-M is working as intended post-integration.

I’ve already created a ticket for this https://developer.trustedfirmware.org/T664

Response from Ken in the ticket:

Hi Jamie,

The background for this changing is, the ARMCLANG printf involves __stdout' into the image and this conflicts with some CMSIS functionalities. (CMSIS team reported that __stdout would affect the mutex init in ARMCLANG). That is the reason why I skipped the default printf.

I think for an RTOS, the toolchain provided printf sometimes come with unknown symbols and causes unexpected behaviour, as the discussion in list/channel, most people are trying to avoid toolchain printf and use some lightweight output.

And for the test, it should use wrapped TEST_LOG(), instead of calling printf itself, since some RTOS do not provide a std 'printf' function.

Is there any discussion thread about this issue?

Thanks

Thanks,

Dev

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.