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.com Sent: Tuesday, February 4, 2020 11:16 PM To: Ken Liu Ken.Liu@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: nd 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.org on behalf of Ken Liu via TF-M tf-m@lists.trustedfirmware.org Reply to: Ken Liu Ken.Liu@arm.com Date: Saturday, 1 February 2020 at 04:46 To: "tf-m@lists.trustedfirmware.org" tf-m@lists.trustedfirmware.org Cc: nd 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.org On Behalf Of Devaraj Ranganna via TF-M Sent: Friday, January 31, 2020 9:57 PM To: 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.