On 07/01/2020 01:23, Ken Liu via TF-M wrote:
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
Hi Ken, The TF-A uses -fno-builtin compiler flag. Hence it doesn't face this problem. If the goal is to not to pull in compiler builtin libraries, setting this flag would be the right approach. The TF-M source tree would need to provide libc.
Best Regards Soby Mathew
Good, I think this flag is necessary for TF-M. Let me send out another mail to discuss this.
/Ken
-----Original Message----- From: Soby Mathew Soby.Mathew@arm.com Sent: Tuesday, January 7, 2020 7:02 PM To: Ken Liu Ken.Liu@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] The logging mechanism change in TF-M
On 07/01/2020 01:23, Ken Liu via TF-M wrote:
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
Hi Ken, The TF-A uses -fno-builtin compiler flag. Hence it doesn't face this problem. If the goal is to not to pull in compiler builtin libraries, setting this flag would be the right approach. The TF-M source tree would need to provide libc.
Best Regards Soby Mathew
tf-m@lists.trustedfirmware.org
-
Ken Liu -
Soby Mathew