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:
For the 3rd point, there are some pre-actions to be done:
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.