- TF-M - lists.trustedfirmware.org

Re: [TF-M] Changes to CI for python dependencies

by Antonio De Angelis

Minos, could you have a look at this? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 02 August 2019 12:44 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Changes to CI for python dependencies In an effort to migrate to the more modern 'cryptography' module in imgtool.py (which mcuboot has already switched to upstream), I created a change request here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 The change fails in CI, however, due to the missing cryptography module in the CI build environment: https://ci.trustedfirmware.org/job/tf-m-build-test-review/1740/artifact/bui… This brings up the following issues: - How can/should changes be made to the CI build environment? - Can the overall TF-M installation process be improved automating Python module installation via a requirements.txt file? Adding a requirements.txt file means that file could be run when the CI environment starts a new test build, taking into account any dependency changes that are part of the change request (version updates, etc.). This would also have the positive side effect of users no longer having to scan through tfm_sw_requirement.rst to see what they don't have installed, or parse build failures for missing module names. I'm happy to make a new change request adding a requirements.txt file, and update the documentation accordingly, but t's not clear to me how to propose the required changes to the CI setup? Best regards, Kevin Townsend -- 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.

7 years, 1 month

1
0
0 0

Changes to CI for python dependencies

by Kevin Townsend

In an effort to migrate to the more modern 'cryptography' module in imgtool.py (which mcuboot has already switched to upstream), I created a change request here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 The change fails in CI, however, due to the missing cryptography module in the CI build environment: https://ci.trustedfirmware.org/job/tf-m-build-test-review/1740/artifact/bui… This brings up the following issues: - How can/should changes be made to the CI build environment? - Can the overall TF-M installation process be improved automating Python module installation via a requirements.txt file? Adding a requirements.txt file means that file could be run when the CI environment starts a new test build, taking into account any dependency changes that are part of the change request (version updates, etc.). This would also have the positive side effect of users no longer having to scan through tfm_sw_requirement.rst to see what they don't have installed, or parse build failures for missing module names. I'm happy to make a new change request adding a requirements.txt file, and update the documentation accordingly, but t's not clear to me how to propose the required changes to the CI setup? Best regards, Kevin Townsend

7 years, 1 month

1
0
0 0

tfm_ns_interface functions refactoring

by Kevin Peng (Arm Technology China)

Hi, I made some changes to the tfm_ns_interface_ functions. They have common implementations that call os_wrapper_ functions. With these changes, RTOSes only need to implement the OS dependent functions defined in os_wrappers rather than the tfm_ns_interface_ functions. There are several changes with a same topic: https://review.trustedfirmware.org/q/topic:%22refine_ns_interface_functions… Please help on reviewing. Thanks. - Kevin

7 years, 1 month

1
0
0 0

Non-secure SVC handling

by Miklos Balint

[from thread: RE: Adding a platform specific tfm_svc_number_t] Hi Andrej, Please note that non-secure SVC handling is independent of secure SVC handling - the two are implemented separately in the code base and hardware resources are banked for their execution. The original discussion is about secure SVC handling type and functions, which are unrelated to NS RTOS dependency on (NS) SVC. I'm starting a separate discussion thread for NS SVC occupancy to avoid blurring the lines between the two. Please note that any example code in the TF-M repository on NS SVC handling is for demonstration purposes and not, strictly speaking, part of TF-M core implementation. It shows how a non-secure privileged entity needs to register a client ID to the SPM on task creation, if multiple client IDs are managed by the RTOS. Whether a specific implementation uses SVC or another method for running the corresponding privileged code is out of scope of the design, only one possible option is shown, but this is an RTOS-specific problem. Meaning that in an RTOS where the adaptation layer mustn't use SVC and is relying on some other method, there's no design limitation in TF-M that is in conflict with that - the implementation can be adjusted in line with the RTOS's method of choice, but where the NS RTOS has no such restriction, the adaptation layer can rely on SVC for this feature. Thanks Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 26 July 2019 08:29 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>; DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Just another use-case, FreeRTOS is using the non-secure SVC. It does not expect that it may be used by somebody else (not RTOS). Ideally, if TFM will not occupy SVC. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, July 26, 2019 3:49 AM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Hi Alan, Can you share us your usage details? This could help us on defining the svc number things you mentioned. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Friday, July 26, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Adding a platform specific tfm_svc_number_t > > I need to define platform specific SPM APIs that will be invoked by our SPs. > > Is there a convention for 'cleanly' adding platform specific SVC > enumerations to the tfm_svc_number_t typedef in tfm_svc.h as well as > platform specific 'case's to SVCHandler_main() and/or SVC_Handler_IPC()? > > Alan > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C42c1df29f3b84ac62f5708d7116b749e%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636997025530401902&sdata=vO0tq34jt > zFFn9D3cnrDP3a4fnrkq4h5jvzZmob2HnU%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 1 month

2
2
0 0

[RFC] Code restructure of core/spm

by Ken Liu (Arm Technology China)

Hi, Several patches for code restructure is coming. Before I post the gerrit items, I want to collect your feedback on this. These changes contain: - Move header files into dedicated directory for easy include, and clean the included headers in sources; - Change some files' name to let them make more sense. - Move SPM related files into 'spm' folder instead of putting them in 'core'. - Move some interface files into 'ns_callable' since they are interfaces. - Remove 'ipc' folder after all files in it are well arranged. I will try to do these patches together so they can be merged together. But before that I want to request for comments about this, feel free to reply in this thread or comment on the task (add yourself if you are missing as subscribers): https://developer.trustedfirmware.org/T426 BR /Ken

7 years, 1 month

1
0
0 0

Re: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py

by Kevin Townsend

As a follow-up, mcuboot has removed the pycrypto dependency, so I will put an update together for TF-M for review: https://github.com/JuulLabs-OSS/mcuboot/tree/master/scripts/imgtool Best regards, Kevin On Wed, 31 Jul 2019 at 16:27, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > As part of an effort to enable automatic builds of TF-M in Zephyr, > I've been trying to get the TF-M + Zephyr S/NS images building and > passing on Zephyr's CI system. > > The only missing requirements for building TF-M in a clean > Zephyr SDK 0.10.1 based environment is the pycrypto module, which > is used in the imgtool.py utility, specifically: > > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… > > My concern is that this module is no longer actively maintained > (last release was 2013!), and it seems like a poor decision to rely > on something that isn't actively maintained when more recent > alternative are available. > > Is there a specific reason to keep this module in the script in favour > of something more modern? > > Best regards, > Kevin > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 1 month

1
0
0 0

Re: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py

by Antonio De Angelis

Hi Kevin, We are open to scope what would be needed to move to more supported alternatives, for example: https://pypi.org/project/cryptography/ If you have any specific idea, please submit it. As far as I can see now, there is not a specific reason to stick with the old pycrypto module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 31 July 2019 15:28 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py Hi, As part of an effort to enable automatic builds of TF-M in Zephyr, I've been trying to get the TF-M + Zephyr S/NS images building and passing on Zephyr's CI system. The only missing requirements for building TF-M in a clean Zephyr SDK 0.10.1 based environment is the pycrypto module, which is used in the imgtool.py utility, specifically: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… My concern is that this module is no longer actively maintained (last release was 2013!), and it seems like a poor decision to rely on something that isn't actively maintained when more recent alternative are available. Is there a specific reason to keep this module in the script in favour of something more modern? Best regards, Kevin -- 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.

7 years, 1 month

1
0
0 0

Outdated pycrypto dependency in BL2's imgtool.py

by Kevin Townsend

Hi, As part of an effort to enable automatic builds of TF-M in Zephyr, I've been trying to get the TF-M + Zephyr S/NS images building and passing on Zephyr's CI system. The only missing requirements for building TF-M in a clean Zephyr SDK 0.10.1 based environment is the pycrypto module, which is used in the imgtool.py utility, specifically: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… My concern is that this module is no longer actively maintained (last release was 2013!), and it seems like a poor decision to rely on something that isn't actively maintained when more recent alternative are available. Is there a specific reason to keep this module in the script in favour of something more modern? Best regards, Kevin

7 years, 1 month

1
0
0 0

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by DeMars, Alan

I cherry-picked the commit into my build area and confirmed that it behaves properly. Alan > On Jul 29, 2019, at 7:57 PM, DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Looks fine to me! > > On Jul 29, 2019, at 7:19 PM, Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> wrote: > > Hi, > > The related patch is pushed into https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1669/ > Please help to review if you have time. > > Thanks, > Summer > ________________________________ > From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> > Sent: Tuesday, July 30, 2019 6:45 AM > To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> > Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> > Subject: RE: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > It would be good to get this fix into master ASAP so master doesn’t remain broken for long. > > > > Alan > > > > From: Summer Qin (Arm Technology China) [mailto:Summer.Qin@arm.com] > Sent: Sunday, July 28, 2019 11:18 PM > To: DeMars, Alan > Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd > Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > > Hi Alan, > > > > Yeah, I see your proposed changes in the email. > > We will make the corrections under my task T435. > > > > > > Thanks, > > Summer > > > > ________________________________ > > From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> > Sent: Monday, July 29, 2019 11:30 AM > To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> > Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> > Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment > > > > Summer, > > The email I sent with the attachment was bounced back so I sent another one afterwards that detailed the changes I had to make. I’d rather someone on your team make the corrections to make sure they’re sufficient. > > Alan > >> On Jul 28, 2019, at 7:41 PM, Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> wrote: >> >> Hi Alan, >> >> Thanks for pointing out this issue. >> >> The patch related to PSA APIs alignment task is the first patch to align the PSA APIs, we will have some following patches to update. >> In your last email, I didn't see the attachment, maybe blocked by the system. If it is convenient for you, could you push your patch to https://review.trustedfirmware.org , or you can create one ticket in https://developer.trustedfirmware.org and upload your changes as attachment in the new created task. Attached the change under my task T435 is also OK. We can help to submit the changes for you. >> >> >> Thanks, >> Summer >> >> On 7/28/19, 4:39 PM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: >> >> I found several other code points in tfm_svcalls.c that need to be enhanced to handle 'type' >= PSA_IPC_CALL. >> >> Attached is my modified tfm_svcalls.c file. With these modifications, the 'type' argument makes its way through the system without causing tfm_panic() to be invoked. >> >> Alan >> >> -----Original Message----- >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M >> Sent: Friday, July 26, 2019 2:28 PM >> To: Ken Liu (Arm Technology China) >> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> >> Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment >> >> In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: >> >> msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, >> in_num, outvecs, out_num, outptr); >> >> Should be: >> >> msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, >> in_num, outvecs, out_num, outptr); >> >> Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. >> >> Alan >> >> From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] >> Sent: Thursday, July 25, 2019 7:14 PM >> To: DeMars, Alan >> Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment >> >> Summer-ARM closed this task as "Resolved". >> >> >> TASK DETAIL >> https://developer.trustedfirmware.org/T435 >> >> EMAIL PREFERENCES >> https://developer.trustedfirmware.org/settings/panel/emailpreferences/ >> >> To: Summer-ARM >> Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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

7 years, 1 month

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Mate Toth-Pal

Hi Alan, The interface call from ' tfm_core_init() ' to 'tfm_spm_hal_set_secure_irq_priority()' is planned to be left there as it is now. If a certain platform implementation doesn't allow interrupt priorities to be set, it can leave the implementation of 'tfm_spm_hal_set_secure_irq_priority()' function empty. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 30 July 2019 01:10 To: Adrian Shaw <Adrian.Shaw(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] including platform specific interrupt definitions Adrian, Yes, I noticed this. I guess that means that the handler name will be derived from the 'source' string. Sadly, it appears that the CMSIS convention for naming IRQ numbers is 'PeripheralX_IRQn'. Given your handler naming convention, that means that the handler names I have to put in my platform's vector table must be 'PeripheralX_IRQn_Handler'. I prefer 'PeripheralX_Handler' myself and that is what I've telegraphed to our development team. I'm thinking we will honor the PSA FF convention that if ONLY the 'source' attribute is provided for an IRQ, your name mangling rule will be followed for generating the ISR function name. Additionally, we will modify the template such that if a custom attribute of 'handler_name' (or some such) is ALSO provided, we will use our own name mangling rules for generating the ISR function name so that we are free to populate the vector table with whatever function names we want. Similarly, it appears that support for the 'tfm_irq_priority' attribute will be a platform-specific extension. Does this mean that the logic currently in tfm_core_init() that calls tfm_spm_hal_set_secure_irq_priority() for each interrupt will be removed from the standard code base? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Adrian Shaw via TF-M Sent: Monday, July 29, 2019 7:49 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Just as a heads up for future consideration. In the final version of the PSA-FF spec we replaced the `line_num` and `line_name` attributes with a new single attribute called “source”. You can use numbers or string identifiers with it (see change log in Appendix E of PSA-FF 1.0.0). Best, Adrian > On 29 Jul 2019, at 15:37, Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > When I created the templates, I was thinking that it is a good idea to have the '_Handler' postfix on the privileged interrupt handler names in both cases (e.g. 'line_num' or 'line_name' is provided.). This would keep the names aligned to the current pattern applied in the existing platform implementations. > > If I understand your proposal correctly, that means, in case a 'line_name' is provided in the partition manifest, there would be two different entities in the code, which are referred by the same name: > - The IRQ handler function > - A macro which is substituted to the number of that IRQ line > > I'm not completely sure that it will not happen that the header file containing the macro gets included in a file that defines or declares the function which would break the privileged handler declaration or definition. Although I didn't check this situation occurs in the current implementation. > > Is my understanding correct? Is there a benefit of this proposal that I missed? > > Thanks, > Mate > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: 22 July 2019 17:23 > To: tf-m(a)lists.trustedfirmware.org; Mate Toth-Pal > <Mate.Toth-Pal(a)arm.com> > Subject: RE: including platform specific interrupt definitions > > After pulling in all the latest commits, I have the following suggestion regarding the use of the 'irqs' manifest properties: > > 1) Use the 'line_num' property unchanged within the 'tfm_core_irq_signals[]' structure array and as the third argument to tfm_irq_handler(). This is consistent with the PSA FF definition for this property: "line_num: A valid IRQ number for the platform" > > 2) When/if it is provided, use the 'line_name' property UNCHANGED as the name of the privileged IRQ handler functions. This is consistent with the PSA FF definition for this property: "line_name: A named IRQ, represented by a string identifier. The string identifier references an external definition, which is resolved in an IMPLEMENTATION DEFINED manner. This is helpful for implementations that do not wish to duplicate information already provided by an existing platform abstraction layer. The string identifiers are not defined in this specification and, as a result, are not portable" > > 3) Only if the 'line_name' property is NOT provided, derive the privileged IRQ handler function name by appending '_Handler' to the 'line_num' property. > > I achieved the above functionality by simply changing this logic in 'tfm_secure_irq_handlers_ipc.inc.template': > > {% if handler.line_num %} > void irq_{{handler.line_num}}_Handler(void) > {% elif handler.line_name %} void > {{handler.line_name}}_Handler(void) > > To this: > > {% if handler.line_name %} > void {{handler.line_name}}(void) > {% elif handler.line_num %} void > {{handler.line_num}}_Handler(void) > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of DeMars, Alan via TF-M > Sent: Friday, July 19, 2019 1:36 PM > To: Mate Toth-Pal > Cc: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt > definitions > > Mate, > > Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. > > Thanks again, > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of Mate Toth-Pal via TF-M > Sent: Friday, July 19, 2019 1:22 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd > Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt > definitions > > Hi Alan, > > I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ > This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. > > Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. > This replaces the manually created IPC model signal definitions to the generated signals: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ > > This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ > > This, and the related changes remove the manually created signal files. > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ > > So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. > > As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. > > Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. > > Regards, > Mate > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: 19 July 2019 18:35 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] including platform specific interrupt definitions > > I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. > > What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? > > 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 > -- > 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 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M