The IAR toolchain does not produce any special "builtin" calls and thus
does not have any flag similar to "-fno-builtin".
/Thomas
Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M:
>
> Hi,
>
> As TF-M needs runtime APIs so we are creating the Secure Partition
> runtime library, code is ready but we have not forwarded all necessary
> runtime APIs to the version TF-M implemented, this was caused by the
> toolchain optimization for built-in APIs, such as:
>
> - Forward printf(%s) to puts if there is only one string parameter.
>
> - ARMCLANG would forward memxxx API into an optimized variant.
>
> With the '-fno-builtin' flags set in the toolchain, this optimization
> would be disabled so that user just implement the same name built-in
> to replace the toolchain version.
>
> Please help to check these point before applying '-fno-builtin' and
> provide your feedback:
>
> - Could toolchains out of ARMCLANG and GNUARM have a similar flag?
>
> - Would it affect your project setting and how does it affect?
>
> Please help to feedback. I will keep this thread open for ~1 week and
> let's get a conclusion after this.
>
> Thanks!
>
> /Ken
>
>
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi All,
Thanks, Ken and Edison for offering the topics for tomorrow's Tech forum.
The agenda (always open) starts from:
1. Secure Partition Runtime Library
2. PSA FF 1.0.0 alignment
Best regards,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M
Sent: 07 January 2020 08:19
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M Technical Forum call - January 9
Hi Anton,
I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes.
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Tuesday, January 7, 2020 3:33 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] TF-M Technical Forum call - January 9
Hi Anton,
I can share the status of Secure Partition Runtime Library in the tech forum.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, January 7, 2020 1:56 AM
To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M Technical Forum call - January 9
Hello,
Hope that the new year is truly happy for everybody.
The next session of the Technical Forum is planned on the coming Thursday, January 9th.
Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC.
This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences.
Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it.
Best regards,
Anton Komlev
Hi,
As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as:
- Forward printf(%s) to puts if there is only one string parameter.
- ARMCLANG would forward memxxx API into an optimized variant.
With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version.
Please help to check these point before applying '-fno-builtin' and provide your feedback:
- Could toolchains out of ARMCLANG and GNUARM have a similar flag?
- Would it affect your project setting and how does it affect?
Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this.
Thanks!
/Ken
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
Hi Anton,
I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes.
Thanks,
Edison
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Tuesday, January 7, 2020 3:33 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M Technical Forum call - January 9
Hi Anton,
I can share the status of Secure Partition Runtime Library in the tech forum.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, January 7, 2020 1:56 AM
To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M Technical Forum call - January 9
Hello,
Hope that the new year is truly happy for everybody.
The next session of the Technical Forum is planned on the coming Thursday, January 9th.
Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC.
This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences.
Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it.
Best regards,
Anton Komlev
Hi Anton,
I can share the status of Secure Partition Runtime Library in the tech forum.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, January 7, 2020 1:56 AM
To: TF-M(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - January 9
Hello,
Hope that the new year is truly happy for everybody.
The next session of the Technical Forum is planned on the coming Thursday, January 9th.
Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC.
This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences.
Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it.
Best regards,
Anton Komlev
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(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M
Sent: Monday, January 6, 2020 9:35 PM
To: Anton Komlev <Anton.Komlev(a)arm.com>; TF-M(a)lists.trustedfirmware.org
Cc: nd <nd(a)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(a)lists.trustedfirmware.org> *On Behalf Of
> *Ken Liu via TF-M
> *Sent:* 27 December 2019 03:38
> *To:* tf-m(a)lists.trustedfirmware.org
> *Cc:* nd <nd(a)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/p…
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(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
This event has been changed.
Title: TF-M Tech Forum
This is an open forum for anyone to participate and it is not restricted to
Trusted Firmware project members. It will operate under the guidance of the
TF TSC.Due to expected attendees from Asia, Europe and the Americas, the
timeslot is challenging. We hope it's not too difficult for anyone - we can
review after the first couple of meetings.Initially we propose a bi-weekly
call and then we'll change cadence depending on interest Feel free to
forward it to colleagues.──────────Bill Fletcher is inviting you to a
scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting
ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New
York)+16699009128,,5810428000# US (San Jose)Dial by your location +1
646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877
853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042
8000Find your local number: https://zoom.us/u/aerUYXPhSL──────────
When: Thu 9 Jan 2020 07:00 – 08:00 United Kingdom Time
Where: https://zoom.us/j/5810428000
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
(Guest list has been hidden at organiser's request)
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
You have been invited to the following event.
Title: TF-M Tech Forum
This is an open forum for anyone to participate and it is not restricted to
Trusted Firmware project members. It will operate under the guidance of the
TF TSC.Due to expected attendees from Asia, Europe and the Americas, the
timeslot is challenging. We hope it's not too difficult for anyone - we can
review after the first couple of meetings.Initially we propose a bi-weekly
call and then we'll change cadence depending on interest Feel free to
forward it to colleagues.──────────Bill Fletcher is inviting you to a
scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting
ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New
York)+16699009128,,5810428000# US (San Jose)Dial by your location +1
646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877
853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042
8000Find your local number: https://zoom.us/u/aerUYXPhSL──────────
When: Thu 9 Jan 2020 07:00 – 08:00 United Kingdom Time
Where: https://zoom.us/j/5810428000
Joining info: Join Hangouts Meet
https://meet.google.com/xdb-txmc-xje
Or dial:
+44 20 3956 3237 (PIN:: 515715720)
More phone numbers: https://tel.meet/xdb-txmc-xje?pin=7033981256503&hs=0
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
(Guest list has been hidden at organiser's request)
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding