- TF-M - lists.trustedfirmware.org

by DeMars, Alan

With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Patches to share common code between TF-M ITS and SST services

by Jamie Fox

Hi all, The ITS and SST partitions in TF-M share a common implementation for the backend FS and flash layers, but currently this code is duplicated between the two partitions, increasing overall code size. To fix this, it was previously proposed to keep the common code in only the ITS partition, with SST making service requests to ITS to complete FS and flash operations. The patches to implement this are now available for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2425 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2426 The first patch refactors the FS and flash code in ITS to support multiple contexts, with multiple flash devices. The second refactors SST to make requests to ITS instead of calling the FS code directly, and modifies ITS to handle requests that originate from SST with SST's FS context and flash device. This is a fairly significant change to the architecture of the two services, so feedback would be particularly appreciated. Kind regards, Jamie

6 years, 3 months

1
0
0 0

Re: [TF-M] out of tree build

by Abhishek Pandit

Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Re: [TF-M] Weak symbols

by Grosen, Mark

Before deciding and documenting this, could we review and decide on the overall project's applicable standards? I am guessing that "more strict requirements" might hint at things like MISRAC. I would rather see a general framework for how coding standards are either inherited or defined than one-off choices. There are other questionable coding practices in the current code base that would have trouble with MISRAC. That said, if we will adopt MISRAC, we can also adopt deviations and waivers that allow for (limited) uses of general violations. A well-documented, reviewed and approved deviation is normal practice in most projects trying to adhere to formal quality standards. Mark -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 1, 2019 7:04 AM To: Abhishek Pandit; Christopher Brand; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Weak symbols Hi, In my own words, :) it is one of the steps to be compliant with some coding guidelines with more strict requirements. We are updating the doc to specify the details. Best regards, Hi Ziji ________________________________ From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Friday, November 1, 2019 6:59:32 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Weak symbols Hi David, As this thread is specifically for weak symbols, it would be helpful to provide some more reasoning behind the new guidance. Could be a good opportunity to discuss further as well. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: 01 November 2019 10:24 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Weak symbols Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

out of tree build

by DeMars, Alan

Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan

6 years, 3 months

1
0
0 0

Re: [TF-M] Weak symbols

by Abhishek Pandit

Hi David, As this thread is specifically for weak symbols, it would be helpful to provide some more reasoning behind the new guidance. Could be a good opportunity to discuss further as well. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: 01 November 2019 10:24 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Weak symbols Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

extending common linker command file template

by DeMars, Alan

We've had to add two memory regions and section placements to the "tfm_common_s.ld.template". Rather than polluting this "common" template, is there a way to extend the functionality so that platform-specific content can be included in the generated linker command file? Alan

6 years, 3 months

1
0
0 0

Re: [TF-M] Weak symbols

by David Hu (Arm Technology China)

Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] SP thread priority when servicing secure interrupts

by DeMars, Alan

After further analysis, I found this to be true: If the secure interrupt has a priority lower than the secure pendsv interrupt, then the associated SP code will run in thread mode at the exception priority level of the secure interrupt. If the priority of the secure interrupt is equal to or greater than the secure pendsv interrupt then associated the SP code will run in thread mode with NO exception priority level. Alan -----Original Message----- From: DeMars, Alan Sent: Tuesday, October 29, 2019 8:54 AM To: 'Mate Toth-Pal' Cc: 'tf-m(a)lists.trustedfirmware.org' Subject: RE: SP thread priority when servicing secure interrupts Mate, I'm using the IPC model. My secure interrupt has priority 0xe0, whereas the pendSV interrupt has priority 0x60. I'll attempt to provide a procedure for reproducing my results. In the meantime, is there a doubt-free way to determine the execution priority while the processor is in thread mode? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, October 29, 2019 5:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SP thread priority when servicing secure interrupts Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Weak symbols

by Christopher Brand

Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M