Hi Soby,

Thanks for providing the reference - we have investigated the version in TF-A earlier, the difference part is we are facing the problem about how to flush the formatted data into device - TF-A has full control to the device so it could just output_char() but the secure partition cannot do this due to some driver sharing consideration. We can reference the TF-A implementation after the logging device mechanism is settled down.

One question, the ARM Complier built-in would change printf to puts or some other variants in RVCT like __2printf, I searched TF-A sources found there is no '--fbulit-in' or 'no_scanlib' flags for the compiler but looks like TF-A has not met the scenarios TF-M met? Or...the runtime library mechanism for A and M are different?

/Ken

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Soby Mathew via TF-M Sent: Monday, January 6, 2020 9:35 PM To: Anton Komlev Anton.Komlev@arm.com; TF-M@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] The logging mechanism change in TF-M

On 06/01/2020 11:45, Anton Komlev via TF-M wrote:

Hi Ken, All,

I like your approach of providing a minimalistic version of printf() for the logging purpose only.

This would benefit to code size and performance while rich print formatting has no practical needs in this project.

Best regards,

Anton

*From:* TF-M tf-m-bounces@lists.trustedfirmware.org *On Behalf Of *Ken Liu via TF-M *Sent:* 27 December 2019 03:38 *To:* tf-m@lists.trustedfirmware.org *Cc:* nd nd@arm.com *Subject:* [TF-M] The logging mechanism change in TF-M

Hi,

We met some issues while implementing logging APIs like printf:

• The build-in symbol optimization references other toolchain provided symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), this would happen in both we are implementing your ‘printf’ and referencing toolchain ‘printf’. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers.
• If we don’t provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env.
• Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?)

So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as ‘printf’ directly.

Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be – there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs).

Please provide your thinking, or what kind of logging API you are using.

Thanks

/Ken

The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/pr...

Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well.

Best Regards Soby Mathew

-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m