- TF-M - lists.trustedfirmware.org

Re: [TF-M] feature-twincpu, unable to configure & build

by Christopher Brand

Hi Thomas, Are you building from the master branch or feature-twincpu? I'm assuming the latter because psoc6 support hasn't yet made it back to the master branch. Which config(s) did you try to build? The feature-twincpu branch is being built pretty regularly for psoc6 (with both clang and gcc), so it should work. There's a document at platform/ext/target/psoc6//cypress_psoc_6_spec.rst detailing exactly how to build. If you can send the details of exactly what commands you're executing and what results you're getting, somebody should be able to help. Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Thomas Törnblom via TF-M > Sent: Thursday, September 5, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] feature-twincpu, unable to configure & build > > I have been tasked with making the twincpu feature work with the IAR > toolchain, and I started out trying to build it with clang and gcc but it seems > there's some issues with it. > > I tried using the psoc6 target, but it appears that none of the v6/v7 targets > are supported in configs/ConfigDefault.cmake. If I add that the build then > fails with a complaint about "Armv6-M/Armv7-M can only support multi-core > TF-M now." from tfm_arch_v6m_v7m.h, due to > TFM_MULTI_CORE_TOPOLOGY not being set, but that appears to be set in > one of the cmake files so I guess something is currently broken. > > Is this a known issue and is there are known fix? > > /Thomas > > -- > > *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> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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

feature-twincpu, unable to configure & build

by Thomas Törnblom

I have been tasked with making the twincpu feature work with the IAR toolchain, and I started out trying to build it with clang and gcc but it seems there's some issues with it. I tried using the psoc6 target, but it appears that none of the v6/v7 targets are supported in configs/ConfigDefault.cmake. If I add that the build then fails with a complaint about "Armv6-M/Armv7-M can only support multi-core TF-M now." from tfm_arch_v6m_v7m.h, due to TFM_MULTI_CORE_TOPOLOGY not being set, but that appears to be set in one of the cmake files so I guess something is currently broken. Is this a known issue and is there are known fix? /Thomas -- *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>

6 years, 3 months

1
0
0 0

T398/T413: Source cleanup and tool integration

by Thomas Törnblom

I have just pushed the latest commit for the source cleanup and IAR integration. -- *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>

6 years, 3 months

1
0
0 0

Re: [TF-M] Updated support for IAR toolchain, T398/T413

by Ken Liu (Arm Technology China)

Hi Thomas, If the topic is quite same, you can re-use the existing item. In other case please create a new one. If the existing item is resolved, you can re-open it with some comments (The history will show the status change of this task, keep same topic in one task makes an easy tracking). Thanks. /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas > Törnblom via TF-M > Sent: Friday, August 23, 2019 6:41 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Updated support for IAR toolchain, T398/T413 > > I have done some more cleanup on a later version of TF-M, which I started in > T398 and T413. > > Should I submit a new task or should I refer to these tasks in my commit? > > /Thomas > > -- > > *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> > -- > 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] Rust implementation of the Armv8-M Security Extension

by Hugues De Valon

Hi Nicolas, Thanks for your mail. From the four LLVM patches needed described in [1], the first one (L1) has landed upstream [2]. Regarding the other ones and your other questions, we are waiting for more information and we will keep you updated as soon as possible. Kind regards, Hugues [2] https://reviews.llvm.org/D59888 -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Nicolas Stalder via TF-M Sent: 30 August 2019 12:25 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Rust implementation of the Armv8-M Security Extension Hi My company SoloKeys produces open source FIDO2 security tokens (USB + NFC), and we're in the process of a) moving to a Cortex-M33 microcontroller, and b) an implementation in Rust. This is mostly to say that we're very interested in the security extensions [1] landing in LLVM, so embedded Rust can eventually use them, I understand Hugues de Valon from Arm has done some exploratory work on this. What is the status of this upstreaming process, are there any road blocks, and is there any ETA on public availability? Regards, Nicolas Stalder SoloKeys [1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/131358.html -- 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

adding an option to run code from RAM

by Andrei Narkevitch

Hello, I'm proposing to add an option to support code execution from device RAM. Basically, it comes to defining a new TFM_RAM_CODE SRAM region in gcc and clang linker scripts for code with .*_ramfunc attribute. This region is intended for privileged secure code running from SRAM. With this, whenever you define an attribute e.g. my_ramfunc, this function will be placed into SRAM instead of Flash. An example: _attribute__((section("my_ramfunc"))) void my_function(void) {}; Implementation: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1815 thanks, Andrei 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

[RFC] SPRTL (Secure Partition Runtime Library) design document update

by Ken Liu (Arm Technology China)

Hi All, There is a tiny update of SPRTL design document: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1886 Fixed a typo, added another security requirements for comparison APIs. Please help to review, thanks. /Ken

6 years, 3 months

1
0
0 0

Re: [TF-M] mcuboot and blob addresses

by Tamas Ban

Hi Thomas, You can find the memory map in: - platform/ext/target/<TARGET>/partition/flash_layout.h Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 02 September 2019 17:07 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] mcuboot and blob addresses I've been trying to find out where the tf-m payload is supposed to be stored at. In tfm_secure_boot.rst I see a memory map for the AN521, but where do find this for the Musca A, which I'm using? /Thomas -- 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

mcuboot and blob addresses

by Thomas Törnblom

I've been trying to find out where the tf-m payload is supposed to be stored at. In tfm_secure_boot.rst I see a memory map for the AN521, but where do find this for the Musca A, which I'm using? /Thomas

6 years, 3 months

1
0
0 0

Rust implementation of the Armv8-M Security Extension

by Nicolas Stalder

Hi My company SoloKeys produces open source FIDO2 security tokens (USB + NFC), and we're in the process of a) moving to a Cortex-M33 microcontroller, and b) an implementation in Rust. This is mostly to say that we're very interested in the security extensions [1] landing in LLVM, so embedded Rust can eventually use them, I understand Hugues de Valon from Arm has done some exploratory work on this. What is the status of this upstreaming process, are there any road blocks, and is there any ETA on public availability? Regards, Nicolas Stalder SoloKeys [1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/131358.html

6 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Code restructure of core/spm

by Ken Liu (Arm Technology China)

Two more patches added under this topic: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1836 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1837 BR /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Thursday, August 15, 2019 3:15 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Code restructure of core/spm > > Hi, > The first patch for moving header files is ready at: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1561 > Comments are welcome. I had thought to push patches together but looks like it > would block other patches for a while to show a neat merged list, so I would > push them one by one. > > Will keep you update when incoming patches are ready. > > BR > > /Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Thursday, August 1, 2019 11:12 AM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [TF-M] [RFC] Code restructure of core/spm > > > > 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 > > > > > > -- > > 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

Removing legacy veneer support from TF-M library model

by Mate Toth-Pal

Hi All, I'm planning to remove the custom veneer support for Library model from TF-M. Please see the proposed patch here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1597/ Ticket for the change is: https://developer.trustedfirmware.org/T439 After this change all secure services must use the automatically generated veneer functions in 'interface/include/tfm_veneers.h', as it is described in the design: https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… This change doesn't affect the NSPM secure functions ('TZ_.*()' and 'tfm_register_client_id()' ). This change also doesn't affect IPC model at all (i.e. psa api functions). Regards, Mate

6 years, 3 months

1
0
0 0

Updated support for IAR toolchain, T398/T413

by Thomas Törnblom

I have done some more cleanup on a later version of TF-M, which I started in T398 and T413. Should I submit a new task or should I refer to these tasks in my commit? /Thomas -- *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>

6 years, 4 months

1
0
0 0

[RFC] RE: Build system changes for dual core platforms

by Ken Liu (Arm Technology China)

Hi, These patches are based on an old patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1686 and the task: https://developer.trustedfirmware.org/T199 The existing idea is, app needs v8m veneer to go on the building, so make 'secure_fw' as sub-project of 'app'. While Dual-core is involved, this hierarchy does not make sense. 'secure_fw' should be a standalone sub-project of 'tfm' instead of 'app'. This would benefit the coming build configuration changes. This patch has been put in master branch for quite a while and now call for review again, since in feature branch it has been merged and verified for quite a long time. Thanks. /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrei > Narkevitch via TF-M > Sent: Thursday, August 15, 2019 2:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Build system changes for dual core platforms > > Hi, > > Please review the proposed build system changes. Intention of those is to lay > groundwork for building TFM for dual core platforms (aka twincpu). > The main problem of the existing build system is that it assumes that both tfm_s > and tfm_ns run on the same core. In dual core systems secure and non-secure > code runs on two independent cores. Each CPU core can be different in terms of > architecture, configuration etc, and this adds the requirement of separating out > secure and non-secure builds.. > The patches basically do the following: > > * Introduce TFM_MULTI_CORE_TOPOLOGY, that distinguish single core and > multicore builds. > * Split secure and non-secure builds and build both in single building execution. > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1747 > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1748 > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1749 > > Thanks, > Andrei > > 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, 4 months

1
0
0 0

Re: [TF-M] Debugger setup for MPS2+ AN521

by Jamie Fox

Hi Kevin, I don't know much about JLink so cannot help with setup, but there is a quick workaround if reset does not work: insert a "B ." instruction on the first line of the reset handler in the startup file. Then the target will sit in an infinite loop while you connect with the debugger, and afterwards you can use the debugger to increment the PC by two to step over the instruction. The typical debug setup in the TF-M team is to use either a Keil ULINKpro or Arm DSTREAM debugger with Arm Development Studio or Keil uVision. Most issues can be debugged on the FVP too, which runs a debug server when the "-S" option is passed. Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 19 August 2019 13:45 To: Kevin Townsend <kevin.townsend(a)linaro.org> Cc: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Debugger setup for MPS2+ AN521 Hi, Any feedback at all on debugging TF-M on AN521 with a HW debugger, or confirmation someone has a working setup? I'm curious how people are digging into particularly complex problems, or things that happen very early on (pre-printf) if a standard HW debugger over SWD/JTAG isn't an option? Many thanks, Kevin On Tue, 6 Aug 2019 at 13:50, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > tl;dr: unable to connect to MPS2+ AN521 with JLink and perform a soft > reset to halt at NSPE init, and debug an init issue. Connect via SWD > fails, connect via JTAG seems OK, but soft reset requests consistently > fail, preventing meaningful debug/trace of the code. Looking for > advice on known-good debug setup with GDB and Linux. > > Full explanation follows: > > I'm currently working on an application with the following setup: > > - TF-M (latest) running in the secure processing environment > - Zephyr running in the NSPE > - PSA FF APIs to communicate between PEs > > I've run into a HW problem with the UART peripheral that I need to > debug, but using a J-Link has been problematic, and I was curious if > anyone else has had any success with GDB or JLinkExe and the MPS2+. > > To debug, I currently do the following: > > - Copy a valid TF-M + Zephyr and BL2 image to the MPS2+ > - Physically reset the MPS2+ (AN521) > - Wait for the image to start up (based on serial output) > - Connect the debugger > - Attempt to reset > > I get the following output at connect (entering the 'connect' command > at the J-Link prompt): > > NOTE: I've been unable to get SWD to work, and had to fall back to > JTAG for the interface. > > ---------------------------------------- > $ JLinkExe -device Cortex-M33 -if jtag -speed auto SEGGER J-Link > Commander V6.44i (Compiled May 17 2019 17:38:03) DLL version V6.44i, > compiled May 17 2019 17:37:52 > > Connecting to J-Link via USB...O.K. > Firmware: J-Link V9 compiled May 17 2019 09:50:41 Hardware version: > V9.10 > S/N: 609100327 > License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.011V Device > position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect > JTAGConf>connect > ERROR while parsing value for IRPre. Using default: -1. > ERROR while parsing value for DRPre. Using default: -1. > Device "CORTEX-M33" selected. > > > Connecting to target via JTAG > TotalIRLen = 4, IRPrint = 0x01 > JTAG chain detection found 1 devices: > #0 Id: 0x6BA00477, IRLen: 04, CoreSight JTAG-DP Scanning AP map to > find all available APs > AP[3]: Stopped AP scan as end of AP map has been reached > AP[0]: APB-AP (IDR: 0x54770002) > AP[1]: AHB-AP (IDR: 0x84770001) > AP[2]: AHB-AP (IDR: 0x84770001) > Iterating through AP map to find AHB-AP to use > AP[0]: Skipped. Not an AHB-AP > AP[1]: Core found > AP[1]: AHB-AP ROM base: 0xF0008000 > CPUID register: 0x410FD211. Implementer code: 0x41 (ARM) Found > Cortex-M33 r0p1, Little endian. > FPUnit: 8 code (BP) slots and 0 literal slots Security extension: > implemented Secure debug: enabled CoreSight components: > ROMTbl[0] @ F0008000 > ROMTbl[0][0]: F0009000, CID: B105900D, PID: 000BB9A4 GPR > ROMTbl[0][1]: E00FF000, CID: B105100D, PID: 000BB4C9 ROM Table > ROMTbl[1] @ E00FF000 > ROMTbl[1][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33 > ROMTbl[1][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT > ROMTbl[1][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB > ROMTbl[1][3]: E0000000, CID: B105900D, PID: 000BBD21 ITM > ROMTbl[1][5]: E0041000, CID: B105900D, PID: 001BBD21 ETM > ROMTbl[1][6]: E0042000, CID: B105900D, PID: 000BBD21 CTI > Cortex-M33 identified. > ---------------------------------------- > > But any attempt to perform a soft reset fails, which makes debugging > the init code problematic: > > ---------------------------------------- > J-Link>r 0 > Reset delay: 0 ms > Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via AIRCR.SYSRESETREQ. > Reset: CPU may have not been reset (DHCSR.S_RESET_ST never gets set). > Reset: Using fallback: Reset pin. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via reset pin > Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). > Reset: Reconnecting and manually halting CPU. > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 > > ************************** > WARNING: CPU could not be halted > ************************** > > Reset: Core did not halt after reset, trying to disable WDT. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via reset pin > Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). > Reset: Reconnecting and manually halting CPU. > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 > > ************************** > WARNING: CPU could not be halted > ************************** > > > ****** Error: Could not find core in Coresight setup > ---------------------------------------- > > If anyone is using a J-Link or J-Trace and ideally GDB to do any > meaningful debugging or tracing on the MPS2+ any suggestions on proper > setup would be valuable, and I'm happy to document an eventual working > config for inclusion in the project doc files. > > Barring that, an alternative GDB-based setup would be useful if > someone has a known-good solution? > > Best regards, > Kevin Townsend > -- > 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, 4 months

1
0
0 0

Re: [TF-M] Debugger setup for MPS2+ AN521

by Kevin Townsend

Hi, Any feedback at all on debugging TF-M on AN521 with a HW debugger, or confirmation someone has a working setup? I'm curious how people are digging into particularly complex problems, or things that happen very early on (pre-printf) if a standard HW debugger over SWD/JTAG isn't an option? Many thanks, Kevin On Tue, 6 Aug 2019 at 13:50, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > tl;dr: unable to connect to MPS2+ AN521 with JLink and perform a soft > reset to halt at NSPE init, and debug an init issue. Connect via SWD > fails, connect via JTAG seems OK, but soft reset requests consistently > fail, preventing meaningful debug/trace of the code. Looking for > advice on known-good debug setup with GDB and Linux. > > Full explanation follows: > > I'm currently working on an application with the following setup: > > - TF-M (latest) running in the secure processing environment > - Zephyr running in the NSPE > - PSA FF APIs to communicate between PEs > > I've run into a HW problem with the UART peripheral that I need to > debug, but using a J-Link has been problematic, and I was curious if > anyone else has had any success with GDB or JLinkExe and the MPS2+. > > To debug, I currently do the following: > > - Copy a valid TF-M + Zephyr and BL2 image to the MPS2+ > - Physically reset the MPS2+ (AN521) > - Wait for the image to start up (based on serial output) > - Connect the debugger > - Attempt to reset > > I get the following output at connect (entering the 'connect' command > at the J-Link prompt): > > NOTE: I've been unable to get SWD to work, and had to fall back to > JTAG for the interface. > > ---------------------------------------- > $ JLinkExe -device Cortex-M33 -if jtag -speed auto > SEGGER J-Link Commander V6.44i (Compiled May 17 2019 17:38:03) > DLL version V6.44i, compiled May 17 2019 17:37:52 > > Connecting to J-Link via USB...O.K. > Firmware: J-Link V9 compiled May 17 2019 09:50:41 > Hardware version: V9.10 > S/N: 609100327 > License(s): RDI, FlashBP, FlashDL, JFlash, GDB > VTref=3.011V > Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect > JTAGConf>connect > ERROR while parsing value for IRPre. Using default: -1. > ERROR while parsing value for DRPre. Using default: -1. > Device "CORTEX-M33" selected. > > > Connecting to target via JTAG > TotalIRLen = 4, IRPrint = 0x01 > JTAG chain detection found 1 devices: > #0 Id: 0x6BA00477, IRLen: 04, CoreSight JTAG-DP > Scanning AP map to find all available APs > AP[3]: Stopped AP scan as end of AP map has been reached > AP[0]: APB-AP (IDR: 0x54770002) > AP[1]: AHB-AP (IDR: 0x84770001) > AP[2]: AHB-AP (IDR: 0x84770001) > Iterating through AP map to find AHB-AP to use > AP[0]: Skipped. Not an AHB-AP > AP[1]: Core found > AP[1]: AHB-AP ROM base: 0xF0008000 > CPUID register: 0x410FD211. Implementer code: 0x41 (ARM) > Found Cortex-M33 r0p1, Little endian. > FPUnit: 8 code (BP) slots and 0 literal slots > Security extension: implemented > Secure debug: enabled > CoreSight components: > ROMTbl[0] @ F0008000 > ROMTbl[0][0]: F0009000, CID: B105900D, PID: 000BB9A4 GPR > ROMTbl[0][1]: E00FF000, CID: B105100D, PID: 000BB4C9 ROM Table > ROMTbl[1] @ E00FF000 > ROMTbl[1][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33 > ROMTbl[1][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT > ROMTbl[1][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB > ROMTbl[1][3]: E0000000, CID: B105900D, PID: 000BBD21 ITM > ROMTbl[1][5]: E0041000, CID: B105900D, PID: 001BBD21 ETM > ROMTbl[1][6]: E0042000, CID: B105900D, PID: 000BBD21 CTI > Cortex-M33 identified. > ---------------------------------------- > > But any attempt to perform a soft reset fails, which makes debugging > the init code problematic: > > ---------------------------------------- > J-Link>r 0 > Reset delay: 0 ms > Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via AIRCR.SYSRESETREQ. > Reset: CPU may have not been reset (DHCSR.S_RESET_ST never gets set). > Reset: Using fallback: Reset pin. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via reset pin > Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). > Reset: Reconnecting and manually halting CPU. > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 > > ************************** > WARNING: CPU could not be halted > ************************** > > Reset: Core did not halt after reset, trying to disable WDT. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via reset pin > Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). > Reset: Reconnecting and manually halting CPU. > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 > > ************************** > WARNING: CPU could not be halted > ************************** > > > ****** Error: Could not find core in Coresight setup > ---------------------------------------- > > If anyone is using a J-Link or J-Trace and ideally GDB to do any > meaningful debugging or tracing on the MPS2+ any suggestions on proper > setup would be valuable, and I'm happy to document an eventual working > config for inclusion in the project doc files. > > Barring that, an alternative GDB-based setup would be useful if > someone has a known-good solution? > > Best regards, > Kevin Townsend > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Please enable -pedantic-errors for gcc builds

by Ken Liu (Arm Technology China)

Hi Thomas, This is a very helpful suggestion. Since I am doing some cleanup these days, let me try this option and see how much we need to improve. I have created an task for tracking this: https://developer.trustedfirmware.org/T475 And, do you have an error report could be share? You can attch the log in the task if you do have some. Thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, August 16, 2019 4:24 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Please enable -pedantic-errors for gcc builds I'm now looking at compilation issues with our standards compliant compiler, and I run into one issue after another that are due to the use of non-standard C allowed by gcc and armclang. Things like zero sized arrays, which are fairly easy to fix by making sure that they have at least one element, but there are other issues that may not be as easy to solve. The latest issue is illegal pointer arithmetic on void * in the IPC code. --- ... [ 20%] Building C object app/secure_fw/CMakeFiles/tfm_s_obj_lib.dir/core/ipc/tfm_svcalls.o msg->invec[invec_idx].base += bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",595 Error[Pe852]: expression must be a pointer to a complete object type msg->invec[invec_idx].base += num_bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",666 Error[Pe852]: expression must be a pointer to a complete object type tfm_memcpy(msg->outvec[outvec_idx].base + msg->outvec[outvec_idx].len, ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",750 Error[Pe852]: expression must be a pointer to a complete object type ... --- I suggest enabling "-pedantic-errors" for gcc, and also for clang, if it has a similar setting, to avoid having illegal C code creeping into tf-m. Comments? /Thomas -- *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> <http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Please enable -pedantic-errors for gcc builds

by Thomas Törnblom

I'm now looking at compilation issues with our standards compliant compiler, and I run into one issue after another that are due to the use of non-standard C allowed by gcc and armclang. Things like zero sized arrays, which are fairly easy to fix by making sure that they have at least one element, but there are other issues that may not be as easy to solve. The latest issue is illegal pointer arithmetic on void * in the IPC code. --- ... [ 20%] Building C object app/secure_fw/CMakeFiles/tfm_s_obj_lib.dir/core/ipc/tfm_svcalls.o msg->invec[invec_idx].base += bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",595 Error[Pe852]: expression must be a pointer to a complete object type msg->invec[invec_idx].base += num_bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",666 Error[Pe852]: expression must be a pointer to a complete object type tfm_memcpy(msg->outvec[outvec_idx].base + msg->outvec[outvec_idx].len, ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",750 Error[Pe852]: expression must be a pointer to a complete object type ... --- I suggest enabling "-pedantic-errors" for gcc, and also for clang, if it has a similar setting, to avoid having illegal C code creeping into tf-m. Comments? /Thomas -- *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>

6 years, 4 months

1
0
0 0

Re: [TF-M] [RFC] Code restructure of core/spm

by Ken Liu (Arm Technology China)

Hi, The first patch for moving header files is ready at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1561 Comments are welcome. I had thought to push patches together but looks like it would block other patches for a while to show a neat merged list, so I would push them one by one. Will keep you update when incoming patches are ready. BR /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Thursday, August 1, 2019 11:12 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] [RFC] Code restructure of core/spm > > 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 > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Linker file changes for multi-core

by Christopher Brand

Please take a look at the patches I've put together to the linker files for multi-core. The fundamental issue that necessitates this change is that the ARMv6/v7 MPU is quite constrained in terms of configuration - the size has to be an exact power of 2, and the base address has to be aligned to the size. This means that we need to group data together in memory so that we can minimize the gaps that we have to introduce to meet the MPU* requirements. To that end, I've grouped all the privileged data together and grouped all the unprivileged data together, and introduced a new #define, S_DATA_UNPRIV_START, that (optionally, in multi-core only) allows the start address of the unprivileged secure data to be specified. This then enables configuring a single MPU region to cover all the unprivileged secure data. Note that only data sections are affected - code is left alone (mostly because the PSoC6 platform has so little Flash that we can't afford any padding at all). https://review.trustedfirmware.org/c/trusted-firmware-m/+/1731 groups the privileged data separate from the unprivileged https://review.trustedfirmware.org/c/trusted-firmware-m/+/1732 adds support for S_DATA_UNPRIV_START Thanks, Chris * In this email I've said "MPU". Technically it's the "SMPU (System Memory Protection Unit) on PSoC6, but that has the same limitations as the ARMv6 MPU. 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, 4 months

1
0
0 0

Build system changes for dual core platforms

by Andrei Narkevitch

Hi, Please review the proposed build system changes. Intention of those is to lay groundwork for building TFM for dual core platforms (aka twincpu). The main problem of the existing build system is that it assumes that both tfm_s and tfm_ns run on the same core. In dual core systems secure and non-secure code runs on two independent cores. Each CPU core can be different in terms of architecture, configuration etc, and this adds the requirement of separating out secure and non-secure builds.. The patches basically do the following: * Introduce TFM_MULTI_CORE_TOPOLOGY, that distinguish single core and multicore builds. * Split secure and non-secure builds and build both in single building execution. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1747 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1748 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1749 Thanks, Andrei 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, 4 months

1
0
0 0

Re: [TF-M] tfm_core_irq_signals array

by Miklos Balint

Hi Thomas, The first variable in a tfm_core_irq_signal_data_t structure is a partition_id. ID 0 is reserved and cannot be a valid entry in this array so it could, in theory, be checked for terminating the loop. I would argue, however, that having a compile time constant loop count variable is better from a performance and optimization point of view. If loop count is const 0 an optimizing compiler can eliminate the loop altogether while if the iteration count depends on the value of an entry in the array, it would be more unlikely to eliminate the unused loop. The key metrics that TF-M is currently measured against are memory footprint and to a lesser degree latency, and having the extra element in the array and the extra iteration in the loop are both sub-optimal in this respect. I do understand the need, however, to keep the constructs standard C and eliminate deviations. Those can lead to build errors or worse: unexpected runtime behaviour with a simple change in a compiler version or similar, so having a clean, standard, predictable code is essential. So thank you for your effort and yes, until and unless we find a more optimal way to get around this problem, please do introduce the proposed change, taking into possible consideration my first comment on helping the compiler detect the unused code. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 14 August 2019 08:53 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tfm_core_irq_signals array Just back from vacation and I notice that a lot seems to have happened while I was away :) As you may know, I'm adding support for the IAR toolchain to tf-m, and this mostly involve cleaning up and eliminating non-standard C constructs that gcc and armclang seems to accept, but which our toolchain does not and is non-standard. One thing we don't accept is zero sized arrays, and I cleaned up a few instances before going on vacation and now I see that a new one has crept in, tfm_core_irq_signals. For the other instances I added a zero initialized element at the end of the array and instead of generating a "count" variable at compile time I used that trailing zero element as a limit while looping over the array. In those cases it was fairly easy and safe as there was at least one pointer element that was non-null for all elements except the last. In this case all members of the struct are scalars and I'm not sure if there is a value I can assign to any of the members that are guaranteed to never be legal and that I can test for. Or should I just use the changes below, where I add a dummy trailing element and adjust the tfm_core_irq_signals_count variable for this? --- /* Definitions of the signals of the IRQs */ const struct tfm_core_irq_signal_data_t tfm_core_irq_signals[] = { #ifdef TFM_PARTITION_TEST_CORE { TFM_IRQ_TEST_1_ID, SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ, TFM_TIMER0_IRQ, 64 }, #endif /* TFM_PARTITION_TEST_CORE */ {0, 0, 0, 0} }; const size_t tfm_core_irq_signals_count = (sizeof(tfm_core_irq_signals) / sizeof(*tfm_core_irq_signals)) - 1; --- /Thomas -- *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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

tfm_core_irq_signals array

by Thomas Törnblom

Just back from vacation and I notice that a lot seems to have happened while I was away :) As you may know, I'm adding support for the IAR toolchain to tf-m, and this mostly involve cleaning up and eliminating non-standard C constructs that gcc and armclang seems to accept, but which our toolchain does not and is non-standard. One thing we don't accept is zero sized arrays, and I cleaned up a few instances before going on vacation and now I see that a new one has crept in, tfm_core_irq_signals. For the other instances I added a zero initialized element at the end of the array and instead of generating a "count" variable at compile time I used that trailing zero element as a limit while looping over the array. In those cases it was fairly easy and safe as there was at least one pointer element that was non-null for all elements except the last. In this case all members of the struct are scalars and I'm not sure if there is a value I can assign to any of the members that are guaranteed to never be legal and that I can test for. Or should I just use the changes below, where I add a dummy trailing element and adjust the tfm_core_irq_signals_count variable for this? --- /* Definitions of the signals of the IRQs */ const struct tfm_core_irq_signal_data_t tfm_core_irq_signals[] = { #ifdef TFM_PARTITION_TEST_CORE { TFM_IRQ_TEST_1_ID, SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ, TFM_TIMER0_IRQ, 64 }, #endif /* TFM_PARTITION_TEST_CORE */ {0, 0, 0, 0} }; const size_t tfm_core_irq_signals_count = (sizeof(tfm_core_irq_signals) / sizeof(*tfm_core_irq_signals)) - 1; --- /Thomas -- *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>

6 years, 4 months

1
0
0 0

Re: [TF-M] gcc linker script help

by Miklos Balint

Hi Chris, Please note that the master branch does support level 2 isolation, so the grouping of sections according to trust domains is already present both for gcc and armclang there. I suggest to refer to that implementation and work from that instead of re-doing it from scratch to avoid unnecessary bifurcation of linker scripts and scatter files for the two platform types. Isolation level 2 readiness was a non-trivial piece of work executed in Q2 so I'd hope that effort can be reused in the twincpu branch. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 07 August 2019 22:04 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] gcc linker script help Hi, I'm working on supporting TFM_LVL 2 on the PSoC6 platform in the feature-twincpu branch. To that end, I want to group all the secure data that needs to be accessed by secure unprivileged code separate from the secure data that is privileged-only. I have a patch at https://review.trustedfirmware.org/c/trusted-firmware-m/+/1731 that moves sections around to make this practical and then a patch at https://review.trustedfirmware.org/c/trusted-firmware-m/+/1732 that fixes the start of the unprivileged secure data for the armclang linker. I've been trying to get the same result with the gcc linker, but so far it either hasn't done what I want or it's failed to link. If anyone more familiar with the gcc linker is able to help, I'd really appreciate it! And of course review comments are always welcome, too - I don't want this to break anything. 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, 4 months

2
1
0 0

gcc linker script help

by Christopher Brand

Hi, I'm working on supporting TFM_LVL 2 on the PSoC6 platform in the feature-twincpu branch. To that end, I want to group all the secure data that needs to be accessed by secure unprivileged code separate from the secure data that is privileged-only. I have a patch at https://review.trustedfirmware.org/c/trusted-firmware-m/+/1731 that moves sections around to make this practical and then a patch at https://review.trustedfirmware.org/c/trusted-firmware-m/+/1732 that fixes the start of the unprivileged secure data for the armclang linker. I've been trying to get the same result with the gcc linker, but so far it either hasn't done what I want or it's failed to link. If anyone more familiar with the gcc linker is able to help, I'd really appreciate it! And of course review comments are always welcome, too - I don't want this to break anything. 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, 4 months

1
0
0 0

Debugger setup for MPS2+ AN521

by Kevin Townsend

tl;dr: unable to connect to MPS2+ AN521 with JLink and perform a soft reset to halt at NSPE init, and debug an init issue. Connect via SWD fails, connect via JTAG seems OK, but soft reset requests consistently fail, preventing meaningful debug/trace of the code. Looking for advice on known-good debug setup with GDB and Linux. Full explanation follows: I'm currently working on an application with the following setup: - TF-M (latest) running in the secure processing environment - Zephyr running in the NSPE - PSA FF APIs to communicate between PEs I've run into a HW problem with the UART peripheral that I need to debug, but using a J-Link has been problematic, and I was curious if anyone else has had any success with GDB or JLinkExe and the MPS2+. To debug, I currently do the following: - Copy a valid TF-M + Zephyr and BL2 image to the MPS2+ - Physically reset the MPS2+ (AN521) - Wait for the image to start up (based on serial output) - Connect the debugger - Attempt to reset I get the following output at connect (entering the 'connect' command at the J-Link prompt): NOTE: I've been unable to get SWD to work, and had to fall back to JTAG for the interface. ---------------------------------------- $ JLinkExe -device Cortex-M33 -if jtag -speed auto SEGGER J-Link Commander V6.44i (Compiled May 17 2019 17:38:03) DLL version V6.44i, compiled May 17 2019 17:37:52 Connecting to J-Link via USB...O.K. Firmware: J-Link V9 compiled May 17 2019 09:50:41 Hardware version: V9.10 S/N: 609100327 License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.011V Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect JTAGConf>connect ERROR while parsing value for IRPre. Using default: -1. ERROR while parsing value for DRPre. Using default: -1. Device "CORTEX-M33" selected. Connecting to target via JTAG TotalIRLen = 4, IRPrint = 0x01 JTAG chain detection found 1 devices: #0 Id: 0x6BA00477, IRLen: 04, CoreSight JTAG-DP Scanning AP map to find all available APs AP[3]: Stopped AP scan as end of AP map has been reached AP[0]: APB-AP (IDR: 0x54770002) AP[1]: AHB-AP (IDR: 0x84770001) AP[2]: AHB-AP (IDR: 0x84770001) Iterating through AP map to find AHB-AP to use AP[0]: Skipped. Not an AHB-AP AP[1]: Core found AP[1]: AHB-AP ROM base: 0xF0008000 CPUID register: 0x410FD211. Implementer code: 0x41 (ARM) Found Cortex-M33 r0p1, Little endian. FPUnit: 8 code (BP) slots and 0 literal slots Security extension: implemented Secure debug: enabled CoreSight components: ROMTbl[0] @ F0008000 ROMTbl[0][0]: F0009000, CID: B105900D, PID: 000BB9A4 GPR ROMTbl[0][1]: E00FF000, CID: B105100D, PID: 000BB4C9 ROM Table ROMTbl[1] @ E00FF000 ROMTbl[1][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33 ROMTbl[1][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT ROMTbl[1][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB ROMTbl[1][3]: E0000000, CID: B105900D, PID: 000BBD21 ITM ROMTbl[1][5]: E0041000, CID: B105900D, PID: 001BBD21 ETM ROMTbl[1][6]: E0042000, CID: B105900D, PID: 000BBD21 CTI Cortex-M33 identified. ---------------------------------------- But any attempt to perform a soft reset fails, which makes debugging the init code problematic: ---------------------------------------- J-Link>r 0 Reset delay: 0 ms Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit. Reset: Halt core after reset via DEMCR.VC_CORERESET. Reset: Reset device via AIRCR.SYSRESETREQ. Reset: CPU may have not been reset (DHCSR.S_RESET_ST never gets set). Reset: Using fallback: Reset pin. Reset: Halt core after reset via DEMCR.VC_CORERESET. Reset: Reset device via reset pin Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). Reset: Reconnecting and manually halting CPU. AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 ************************** WARNING: CPU could not be halted ************************** Reset: Core did not halt after reset, trying to disable WDT. Reset: Halt core after reset via DEMCR.VC_CORERESET. Reset: Reset device via reset pin Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). Reset: Reconnecting and manually halting CPU. AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 AP map detection skipped. Manually configured AP map found. AP[0]: CUSTOM-AP (IDR: Not set) AP[1]: AHB-AP (IDR: Not set) AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00 ************************** WARNING: CPU could not be halted ************************** ****** Error: Could not find core in Coresight setup ---------------------------------------- If anyone is using a J-Link or J-Trace and ideally GDB to do any meaningful debugging or tracing on the MPS2+ any suggestions on proper setup would be valuable, and I'm happy to document an eventual working config for inclusion in the project doc files. Barring that, an alternative GDB-based setup would be useful if someone has a known-good solution? Best regards, Kevin Townsend

6 years, 4 months

1
0
0 0

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

by Kevin Townsend

Hi Minos, Thanks for the detailed reply/explanation. This sounds similar to the CI setup for Zephyr where I test changes locally first. I'm happy to put together a change request for this, based on any feedback here (if it's deemed worth merging in, etc.): https://review.trustedfirmware.org/c/trusted-firmware-m/+/1695 Best regards, Kevin On Mon, 5 Aug 2019 at 15:34, Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > The CI comprises of three modules. The Jenkins logic, the Python Scripts and the docker build slave. > > > The environment is provided by the docker build slave and provisioned into the pipeline flow when the venv is created for each stage: > > virtualenv -p python3 ${VENV_P3_NAME} --system-site-packages > > No requirements are installed at the Jenkins Stage, but if needed as an one-off (i.e. for staging purposes), the design supports it. > > > The case for installing Python requirements on the fly using requirements.txt > > > Extending requirements dynamically on the fly, can be quite a challenge due to the way Jenkins handles the absolute resolution of workspace directory on each step. In short Python’s virtual-environment stores the configuration paths in absolute format, while Jenkins is not guaranteed to give you the same reference to a working directory in consecutive calls in the pipeline. > > So if you create a venv at stage 1, which evaluates ~/ as /server/workspace/fubar-job/venv/.. and then attempt to call it in a following parallel step, the code may be located at /server/workspace/1/fubar-job/venv > > At this point you can either create the VENV in each stage, and reinstall the requirements, effectively wasting bandwidth or hack it by piping everything in SED before activating to ensure the path is resolved correctly. > > For that purposes the ci-scripts level requirements.txt will be deprecated in the next feature update. > > > How should a user access or modify the TF-M Build environment. > > > Environment will be established at the docker build stage. > > https://review.trustedfirmware.org/admin/repos/ci/dockerfiles > > And more specifically the requirements for Python3 in this file: > > https://git.trustedfirmware.org/ci/dockerfiles.git/tree/xenial-amd64-tf-m-b… > > After it has been updated and merged you should raise a ticket and request the image to get rebuilt, or if it is not very critical, wait for some other party change to trigger the build. > > The process requires creating local docker image, meant to test your changes but also allowing you to access the TF-M build environment as deployed on the CI. You can do that following the steps below: > > > # Get the docker image > > $ git clone https://review.trustedfirmware.org/ci/dockerfiles && cd dockerfiles/xenial-amd64-tf-m-build > > # Edit the entry point to convert it not to be a jenkins-slave > > $ vi Dockerfile > > # change ENTRYPOINT ["/usr/local/bin/jenkins-slave"] to ENTRYPOINT [/bin/bash"], save exit > > # Build the image > > $ docker build ./ > > # Find the image hash id > > $ docker image ls > > # Run an interactive bash shell, mounting a local directory as /opt/openci in instance (if required to share files) > > $ docker run -it --name tf-m-build-env -v /YOUR_CUSTOM_PATH:/opt/openci 10bcb173cd39 > > # You can relaunch that instance in the future by starting it again. > > $ docker start && docker -exec -it tf-m-build-env /bin/bash > > > > Please let me know if you need more clarity or guidance on how to handle modifications on the CI. > > > Regards, > > Minos Galanakis > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 02 August 2019 14:57 > To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Changes to CI for python dependencies > > +Minos now > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M > Sent: 02 August 2019 14:47 > To: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Changes to CI for python dependencies > > 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. > -- > 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, 4 months

2
1
0 0

Re: [TF-M] independent device driver model working along side SPM

by Miklos Balint

Hi Manoj, Please elaborate on the problem you are seeing and the steps you want to take so we can consider if it's something TF-M is in the process of addressing or if it is out of scope. On first read I feel there's a contradiction: The point of having TF-M - or any secure "supervising entity" - in the system is that it has awareness of the goings-on in the system, understands the states of parallel contexts that are supported by the hardware, to control its security aspects. Having a device driver "not plugged in TF-M" would, on the face of it, defeat the purpose of TF-M as a management entity, and the device driver would need not only to handle its own threat vectors, but any potential collisions with TF-M's understanding and control of the system state, making it, in effect, part of the management entity. So rather than the driver being not plugged in, I guess what we need to work out is how TF-M can be extended to cover the type of use case you are working on, without compromising the holistic security model that TF-M implements - but there's no one-size-fits-all solution. Thanks and regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of R, Manoj via TF-M Sent: 05 July 2019 10:24 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] independent device driver model working along side SPM Hi, Is there a design guideline available for device driver which is working on secure side alongside SPM. I do not want to plug my driver in TF-M due to latency considerations. Basically my plan is to introduce non secure callable veneers for calling the interfaces of the driver which I am introducing. Any thoughts on this will be helpful. Regards Manoj -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

2
5
0 0

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

by Minos Galanakis

The CI comprises of three modules. The Jenkins logic, the Python Scripts and the docker build slave. The environment is provided by the docker build slave and provisioned into the pipeline flow when the venv is created for each stage: virtualenv -p python3 ${VENV_P3_NAME} --system-site-packages No requirements are installed at the Jenkins Stage, but if needed as an one-off (i.e. for staging purposes), the design supports it. The case for installing Python requirements on the fly using requirements.txt Extending requirements dynamically on the fly, can be quite a challenge due to the way Jenkins handles the absolute resolution of workspace directory on each step. In short Python’s virtual-environment stores the configuration paths in absolute format, while Jenkins is not guaranteed to give you the same reference to a working directory in consecutive calls in the pipeline. So if you create a venv at stage 1, which evaluates ~/ as /server/workspace/fubar-job/venv/.. and then attempt to call it in a following parallel step, the code may be located at /server/workspace/1/fubar-job/venv At this point you can either create the VENV in each stage, and reinstall the requirements, effectively wasting bandwidth or hack it by piping everything in SED before activating to ensure the path is resolved correctly. For that purposes the ci-scripts level requirements.txt will be deprecated in the next feature update. How should a user access or modify the TF-M Build environment. Environment will be established at the docker build stage. https://review.trustedfirmware.org/admin/repos/ci/dockerfiles And more specifically the requirements for Python3 in this file: https://git.trustedfirmware.org/ci/dockerfiles.git/tree/xenial-amd64-tf-m-b… After it has been updated and merged you should raise a ticket and request the image to get rebuilt, or if it is not very critical, wait for some other party change to trigger the build. The process requires creating local docker image, meant to test your changes but also allowing you to access the TF-M build environment as deployed on the CI. You can do that following the steps below: # Get the docker image $ git clone https://review.trustedfirmware.org/ci/dockerfiles && cd dockerfiles/xenial-amd64-tf-m-build # Edit the entry point to convert it not to be a jenkins-slave $ vi Dockerfile # change ENTRYPOINT ["/usr/local/bin/jenkins-slave"] to ENTRYPOINT [/bin/bash"], save exit # Build the image $ docker build ./ # Find the image hash id $ docker image ls # Run an interactive bash shell, mounting a local directory as /opt/openci in instance (if required to share files) $ docker run -it --name tf-m-build-env -v /YOUR_CUSTOM_PATH:/opt/openci 10bcb173cd39 # You can relaunch that instance in the future by starting it again. $ docker start && docker -exec -it tf-m-build-env /bin/bash Please let me know if you need more clarity or guidance on how to handle modifications on the CI. Regards, Minos Galanakis ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 02 August 2019 14:57 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to CI for python dependencies +Minos now -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 02 August 2019 14:47 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes to CI for python dependencies 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. -- 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, 4 months

1
0
0 0

Re: [TF-M] PSA Storage API

by Jamie Fox

Hi Andrej, Alignment with the PSA 1.0.0 APIs is on the TF-M roadmap for next quarter: https://developer.trustedfirmware.org/w/tf_m/planning/ The "release" branch of the psa-arch-tests repo should be used for functional API certification. TF-M is compatible with that branch. Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 05 August 2019 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Storage API Just only FYI: The latest PSA Test Suite has been switched to a newer version of PSA Storage API: https://github.com/ARM-software/psa-arch-tests/issues/105 Best regards, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

PSA Storage API

by Andrej Butok

Just only FYI: The latest PSA Test Suite has been switched to a newer version of PSA Storage API: https://github.com/ARM-software/psa-arch-tests/issues/105 Best regards, Andrej Butok

6 years, 4 months

1
0
0 0

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

by Antonio De Angelis

+Minos now -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 02 August 2019 14:47 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes to CI for python dependencies 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

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.

6 years, 4 months

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

6 years, 4 months

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

6 years, 4 months

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

6 years, 4 months

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

6 years, 4 months

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

6 years, 4 months

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.

6 years, 4 months

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

6 years, 4 months

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

6 years, 4 months

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

6 years, 4 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: PSA API prototype update

by Mate Toth-Pal

Hi Alan, Currently there are no plans to deprecate the 'tfm_irq_priority' optional attribute. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 25 July 2019 04:44 To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: PSA API prototype update Hi Alan, These attributes should be already included in 'test/test_services/tfm_irq_test_service_1' of latest master, you can check the sources. The alignment is a big task and the patch mentioned in this mail thread is the first one of prototype change. The whole FF 1.0.0 alignment (behaviors change e.g.) would come step by step later on. And the interrupt priority -- let me check with interrupt designers to know more details. Current from my point of view it is platform defined setting which is out of FF scope. Thanks. -Ken > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, July 25, 2019 9:53 AM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [EXTERNAL] RE: PSA API prototype update > > Ken, > > Will support for the new “source” attribute in “irqs” be included in > this API alignment? If not, when might it be supported? Also, is the “irqs” “priority” > attribute being deprecated? > > Alan > > > On Jul 24, 2019, at 6:12 PM, Ken Liu (Arm Technology China) > <Ken.Liu(a)arm.com> wrote: > > > > Hi Alan, > > > > Should by this weekend or early next week, depends on if there are > > new > comments. > > > > Thanks. > > > > -Ken > > > >> -----Original Message----- > >> From: DeMars, Alan <ademars(a)ti.com> > >> Sent: Wednesday, July 24, 2019 11:17 PM > >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > >> Cc: tf-m(a)lists.trustedfirmware.org > >> Subject: RE: PSA API prototype update > >> > >> When do you anticipate that this patch will be merged to master? > >> > >> -----Original Message----- > >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On > >> Behalf Of Ken Liu (Arm Technology China) via TF-M > >> Sent: Tuesday, July 23, 2019 11:17 PM > >> To: tf-m(a)lists.trustedfirmware.org > >> Cc: nd > >> Subject: [EXTERNAL] [TF-M] PSA API prototype update > >> > >> Hi, > >> > >> A patch is pushed for couple of days reveals the update on PSA API > >> prototype and its related caller change: > >> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 > >> > >> The most obvious part is a new parameter member 'type' is > >> introduced in 'psa_call'. This is the first step of our upgrading > >> to the latest PSA Firmware Framework Specification. The API > >> internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. > >> > >> The callers included in TF-M has been updated in this patch. > >> Developers who developed extra services should mention this change > >> and update PSA API related sources. > >> Any feedback please comment under the patch, or reply to this mail thread. > >> > >> Thanks. > >> > >> -Ken > >> -- > >> 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, 4 months

1
0
0 0

Re: [TF-M] Uniform Secure Service Signature

by Mate Toth-Pal

Hi Alan, Yes, this should happen as part of the FF 1.0.0 alignment effort. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 25 July 2019 23:59 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Uniform Secure Service Signature With the introduction of the 'type' argument in psa_call(), will the 'Uniform Secure Service Signature' also be updated to include 'type' as its first argument? https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

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

by Summer Qin (Arm Technology China)

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 on behalf of tf-m(a)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 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 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, 4 months

2
5
0 0

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

by DeMars, Alan

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

6 years, 4 months

1
0
0 0

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

by Adrian Shaw

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.

6 years, 4 months

1
0
0 0

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

by DeMars, Alan

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

6 years, 4 months

2
1
0 0

Last call for reviewing multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Hi all, I'm going to merge the multi-core topology improvement patches on feature-twincpu branch on Thursday. Could you please help review the following patches from https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 to https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/2? Please let me know if there is any issue or improper modification to single Armv8-M scenario. I'd like to fix conflict as much as possible before merging feature-twincpu back to master branch, which may bring a lot of inconvenience to master branch development. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, July 22, 2019 6:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: Hao Chuan Chu <charley.chu(a)cypress.com>; nd <nd(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; Alamy Liu <Alamy.Liu(a)cypress.com> Subject: [TF-M] Please review multi-core TF-M topology improvement patches Sorry. Switch into plain text and correct the bad format. Something was wrong with the Outlook. Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations a. If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. b. If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 2. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Adding a platform specific tfm_svc_number_t

by Ken Liu (Arm Technology China)

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://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

2
2
0 0

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

by DeMars, Alan

I found four additional code points in tfm_svcalls.c that needed to be enhanced to handle msg.type >= PSA_IPC_CALL. 3 of the four were like this: if (msg->msg.type != PSA_IPC_CALL) { Which I changed to: if (msg->msg.type < PSA_IPC_CALL) { The 4th occurrence was in the switch statement within 'tfm_svcall_psa_reply()'. I moved the 'case PSA_IPC_CALL:' logic into the default block and surrounded it with: if (msg->msg.type >= PSA_IPC_CALL) { ... } else { tfm_panic(); } With these changes in place, the new psa_call() 'type' argument appears to make its way peacefully and effectively through the plumbing. 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 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 https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

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

by DeMars, Alan

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 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 https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

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

by DeMars, Alan

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

6 years, 4 months

1
0
0 0

[RFC] Remove Isolation level 3

by Edison Ai (Arm Technology China)

Hi, There are a series of patches under "remove_isolation_level_3" topic: https://review.trustedfirmware.org/#/q/topic:remove_isolation_level_3+(stat… aim to remove isolation level 3 (TFM_LVL=3) from the library model. These patches will not affect curent isolation level 1 and level 2 for both library model and IPC model. Please help to review them and give comments if you find any problems or anywhere need to enhancement. Thanks, Edison

6 years, 5 months

1
0
0 0

Re: [TF-M] Adding a platform specific tfm_svc_number_t

by Andrej Butok

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…

6 years, 5 months

1
0
0 0

Adding a platform specific tfm_svc_number_t

by DeMars, Alan

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

6 years, 5 months

1
0
0 0

Uniform Secure Service Signature

by DeMars, Alan

With the introduction of the 'type' argument in psa_call(), will the 'Uniform Secure Service Signature' also be updated to include 'type' as its first argument? https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… Alan

6 years, 5 months

1
0
0 0

Re: [TF-M] PSA API prototype update

by DeMars, Alan

When do you anticipate that this patch will be merged to master? -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, July 23, 2019 11:17 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] PSA API prototype update Hi, A patch is pushed for couple of days reveals the update on PSA API prototype and its related caller change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 The most obvious part is a new parameter member 'type' is introduced in 'psa_call'. This is the first step of our upgrading to the latest PSA Firmware Framework Specification. The API internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. The callers included in TF-M has been updated in this patch. Developers who developed extra services should mention this change and update PSA API related sources. Any feedback please comment under the patch, or reply to this mail thread. Thanks. -Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

2
3
0 0

PSA API prototype update

by Ken Liu (Arm Technology China)

Hi, A patch is pushed for couple of days reveals the update on PSA API prototype and its related caller change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 The most obvious part is a new parameter member 'type' is introduced in 'psa_call'. This is the first step of our upgrading to the latest PSA Firmware Framework Specification. The API internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. The callers included in TF-M has been updated in this patch. Developers who developed extra services should mention this change and update PSA API related sources. Any feedback please comment under the patch, or reply to this mail thread. Thanks. -Ken

6 years, 5 months

1
0
0 0

TF-M Internal Trusted Storage service design proposal

by Jamie Fox

Hi all, As you may be aware, implementing the PSA Internal Trusted Storage (ITS) APIs is on the TF-M roadmap for this quarter (https://developer.trustedfirmware.org/w/tf_m/planning/). We plan to implement these APIs with a new TF-M Internal Trusted Storage service. The design proposal for the new TF-M ITS service is now available for design review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 . The design is currently in "draft" state, which means further refinements are to be expected, and feedback is welcome. For more information about the PSA ITS APIs themselves, the PSA Storage API document may be downloaded from here: https://pages.arm.com/PSA-APIs Kind regards, Jamie

6 years, 5 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Sorry. Switch into plain text and correct the bad format. Something was wrong with the Outlook. Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations a. If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. b. If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 2. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 5 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations * If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. * If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 1. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 5 months

1
0
0 0

Re: [TF-M] Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The hotfix has been merged. /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Monday, July 22, 2019 4:37 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Hotfix for auto-merge caused build error > > Hi, > The gerrit merge with auto rebase on this patch caused the function type change > and a build error is generated: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 > > A hotfix is on the way for fixing this: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 > > Sorry for the troublesome. > > /Ken > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The gerrit merge with auto rebase on this patch caused the function type change and a build error is generated: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 A hotfix is on the way for fixing this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 Sorry for the troublesome. /Ken

6 years, 5 months

1
0
0 0

Please help review memory access check design for multi-core topology

by David Hu (Arm Technology China)

Hi all, Could you please help review the design of TF-M memory access check in multi-core topology on https://review.trustedfirmware.org/c/trusted-firmware-m/+/1601 ? Since CMSE support is likely to be unavailable on multi-core platforms, that design proposes a general memory access check process for multi-core topology and corresponding HAL APIs to retrieve platform specific memory attribute configurations. Any comment would be gratefully received. If this design may not work in certain use cases, it would be very helpful if you can let me know the details. Thank you. Best regards, Hu Ziji

6 years, 5 months

1
0
0 0

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

by DeMars, Alan

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

6 years, 5 months

1
0
0 0

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

by Mate Toth-Pal

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

6 years, 5 months

1
0
0 0

including platform specific interrupt definitions

by DeMars, Alan

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

6 years, 5 months

1
0
0 0

Re: [TF-M] Missing veneer function implementations

by Kevin Townsend

Hi Mate, I was able to get this working by changing the build config to a non-IPC setup (ConfigDefault.cmake), in which case the tfm veneers functions are available and I can call the PSA API shims directly: SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_tfm_crypto_generate_random_veneer 100efc88 g F *ABS* 00000008 tfm_tfm_crypto_get_generator_capacity_veneer ... Thanks for the clarification. Calling `psa_generate_random` from the NSPE works are expected now. Best regards, Kevin On Wed, 17 Jul 2019 at 14:16, Mate Toth-Pal via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Kevin, > > Based on what you write your build is probably OK. To access the > psa_generate_random service, you need to call the function 'psa_status_t > psa_generate_random(uint8_t *output, size_t output_size)', declared in > interface/include/psa/crypto.h. > > in case the TFM/PSA APIs are in use (your case), the transition to the > secure code is done through the tfm_psa_* veneers. A service (for example > psa_generate_random) is connected with a call to 'psa_connect(...)', which > is provided with the ID of the selected service, and then 'psa_call(...)' > is called with the handle received from 'psa_connect(...)' (as it is > described in the PSA FF Specification). However this exchange is > implemented inside the TF-M's crypto API implementation in > interface\src\tfm_crypto_api.c, so you only need to call the API function. > > The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M > when the Library model is used. In this case the secure services can be > accessed with a single function call, and the tfm_psa_* veneers are not > available. However please note, that even in this case you can use TF-M's > crypto API, which will call the service the correct way. (Look for the > conditionally compiled blocks depending on the TFM_PSA_API macro in the API > implementation.) > > I hope this answers your questions. > > Regards, > Mate > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin > Townsend via TF-M > Sent: 17 July 2019 13:12 > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Missing veneer function implementations > > Greetings, > > I'm trying to get the TFM/PSA APIs working in Zephyr, based on the > upstream TF-M repository. > > The libraries are being built with the following settings, followed by > make and make install: > > cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f > ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > *ConfigRegressionIPC is used simply to include the test service for > debugging purposes for now. > > The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making > calls to the SPE via the PSA APIs, which should call the appropriate > veneers via the source files in the `install/export/tfm` folder, as well as > `veneers/s_veneers.o` > > This works fine calling the test service via `tfm_psa_call_veneer`, but > whenever I try to make use of any of the .c shims in the PSA API (for > example `psa_generate_random`), I get the following error(s): > > tfm_crypto_api.c:1571: undefined reference to > `tfm_tfm_crypto_generate_random_veneer' > > I assumed the veneers are in the `s_veneers.o` file generated as part of > the TF-M build, and this file is linked into during the Zephyr build > process, but when I look at the contents of the .o file (which was > suspiciously small at 740b) I only see the following: > > $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o > > /tfm/build/install/export/tfm/veneers/s_veneers.o: file format > elf32-littlearm > > SYMBOL TABLE: > 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer > 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S > 100efc90 g F *ABS* 00000008 TZ_LoadContext_S > > 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer > 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer > 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S > 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer > 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S > 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests > 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S > 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer > 100efcd8 g F *ABS* 00000008 tfm_register_client_id > > Clearly I'm missing something in the build process so that all of the > other veneers are present, but it's not obvious to me at this point what. > At present I can only make calls to `tfm_psa_call` to the test service, but > that isn't going to help with the goal of publishing a sample application > that meets the requirements for PSA Level 1 certification. > > Any suggestions on what knob to turn to include the missing veneers would > be very welcome. > > Best regards, > Kevin Townsend > -- > 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, 5 months

2
1
0 0

Re: [TF-M] Missing veneer function implementations

by Mate Toth-Pal

Hi Kevin, Based on what you write your build is probably OK. To access the psa_generate_random service, you need to call the function 'psa_status_t psa_generate_random(uint8_t *output, size_t output_size)', declared in interface/include/psa/crypto.h. in case the TFM/PSA APIs are in use (your case), the transition to the secure code is done through the tfm_psa_* veneers. A service (for example psa_generate_random) is connected with a call to 'psa_connect(...)', which is provided with the ID of the selected service, and then 'psa_call(...)' is called with the handle received from 'psa_connect(...)' (as it is described in the PSA FF Specification). However this exchange is implemented inside the TF-M's crypto API implementation in interface\src\tfm_crypto_api.c, so you only need to call the API function. The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M when the Library model is used. In this case the secure services can be accessed with a single function call, and the tfm_psa_* veneers are not available. However please note, that even in this case you can use TF-M's crypto API, which will call the service the correct way. (Look for the conditionally compiled blocks depending on the TFM_PSA_API macro in the API implementation.) I hope this answers your questions. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 17 July 2019 13:12 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Missing veneer function implementations Greetings, I'm trying to get the TFM/PSA APIs working in Zephyr, based on the upstream TF-M repository. The libraries are being built with the following settings, followed by make and make install: cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ *ConfigRegressionIPC is used simply to include the test service for debugging purposes for now. The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making calls to the SPE via the PSA APIs, which should call the appropriate veneers via the source files in the `install/export/tfm` folder, as well as `veneers/s_veneers.o` This works fine calling the test service via `tfm_psa_call_veneer`, but whenever I try to make use of any of the .c shims in the PSA API (for example `psa_generate_random`), I get the following error(s): tfm_crypto_api.c:1571: undefined reference to `tfm_tfm_crypto_generate_random_veneer' I assumed the veneers are in the `s_veneers.o` file generated as part of the TF-M build, and this file is linked into during the Zephyr build process, but when I look at the contents of the .o file (which was suspiciously small at 740b) I only see the following: $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o /tfm/build/install/export/tfm/veneers/s_veneers.o: file format elf32-littlearm SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S 100efc90 g F *ABS* 00000008 TZ_LoadContext_S 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer 100efcd8 g F *ABS* 00000008 tfm_register_client_id Clearly I'm missing something in the build process so that all of the other veneers are present, but it's not obvious to me at this point what. At present I can only make calls to `tfm_psa_call` to the test service, but that isn't going to help with the goal of publishing a sample application that meets the requirements for PSA Level 1 certification. Any suggestions on what knob to turn to include the missing veneers would be very welcome. Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

MCUBoot enhancments

by Tamas Ban

Hi All, I've pushed a set of patches for review which aims to add the following features to MCUBoot: * Integration with HW key(s). * Sign & authenticate S and NS image independently with different keys. Design proposal for this change: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Related changes are listed here: https://developer.trustedfirmware.org/T438 Please feel free to review any of the patches.:) Thanks, Tamas

6 years, 5 months

1
0
0 0

Missing veneer function implementations

by Kevin Townsend

Greetings, I'm trying to get the TFM/PSA APIs working in Zephyr, based on the upstream TF-M repository. The libraries are being built with the following settings, followed by make and make install: cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ *ConfigRegressionIPC is used simply to include the test service for debugging purposes for now. The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making calls to the SPE via the PSA APIs, which should call the appropriate veneers via the source files in the `install/export/tfm` folder, as well as `veneers/s_veneers.o` This works fine calling the test service via `tfm_psa_call_veneer`, but whenever I try to make use of any of the .c shims in the PSA API (for example `psa_generate_random`), I get the following error(s): tfm_crypto_api.c:1571: undefined reference to `tfm_tfm_crypto_generate_random_veneer' I assumed the veneers are in the `s_veneers.o` file generated as part of the TF-M build, and this file is linked into during the Zephyr build process, but when I look at the contents of the .o file (which was suspiciously small at 740b) I only see the following: $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o /tfm/build/install/export/tfm/veneers/s_veneers.o: file format elf32-littlearm SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S 100efc90 g F *ABS* 00000008 TZ_LoadContext_S 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer 100efcd8 g F *ABS* 00000008 tfm_register_client_id Clearly I'm missing something in the build process so that all of the other veneers are present, but it's not obvious to me at this point what. At present I can only make calls to `tfm_psa_call` to the test service, but that isn't going to help with the goal of publishing a sample application that meets the requirements for PSA Level 1 certification. Any suggestions on what knob to turn to include the missing veneers would be very welcome. Best regards, Kevin Townsend

6 years, 5 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Andrej Butok

Hi Antonio, > TF-M Crypto will align to newest release of Mbed Crypto when they will become available Just FYI: The newest official release of Mbed Crypto is v1.1.0: https://github.com/ARMmbed/mbed-crypto/releases Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 5 months

2
2
0 0

Changing IPC design document to .rst format

by Ken Liu (Arm Technology China)

Hi, This is a design document change for IPC, the intention is to change design document from wiki page to rst format. The patch is put at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1533 The plan is to put this design document under source control and the following feature changes and enhancement about IPC will be pushed as patches on it - which helps review. Since the original text is already public so I changed the doc status to 'Detailed', plan is to merge it soon with some quick comment. If you think some necessary points are missing please leave comments in this mailing thread and we will add them later with a new patch. Thanks. -Ken

6 years, 5 months

1
0
0 0

Re: [TF-M] Common scatter files and templates

by David Hu (Arm Technology China)

Hi Andrej, Does your IDE support pre-build command? Is there any chance to execute the parse and auto-generation in the pre-build step? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, July 11, 2019 7:41 PM To: Ken Liu (Arm Technology China) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Common scatter files and templates Hi Ken, > Could you help to tell the name of the file you don't want to be removed? So, any .c,.h,.inc and linker file which may be used during compilation. An IDE project (ARM Kei, MCUx, IAR etc.) assumes a fixed set of existing files. Thanks, Andrej -----Original Message----- From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Sent: Thursday, July 11, 2019 12:44 PM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: Common scatter files and templates Hi Andrej, Could you help to tell the name of the file you don't want to be removed? So that we can estimate what is important for IDE projects and how we could help on that. An introduction of how your IDE integrate with TF-M code is also welcome. Would you share this to us? Thanks. -Ken > -----Original Message----- > From: Andrej Butok <andrey.butok(a)nxp.com> > Sent: Thursday, July 11, 2019 2:25 PM > To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Antonio De > Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu (Arm Technology China) > <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: RE: Common scatter files and templates > > Pre-generated files are required for TFM IDE projects. > Please do not delete them, find other solution! > It can be solved by adding #if/#ifdef. > > Thank you, > Andrej Butok > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Hu (Arm Technology China) via TF-M > Sent: Thursday, July 11, 2019 4:08 AM > To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf- > m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) > <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Common scatter files and templates > > Hi Antonio, Ken, Miklos, > > Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to > comment the veneer sections in the templates in multi-core topology. > Each time before building, we have to run the Python script to > generate new link script/scatter file with veneer disabled, to replace the existing ones. > It becomes more inconvenient as the number of developers and users on > feature-twincpu branch grows. > > As Chris proposed on > https://review.tr > ustedfirmware.org%2Fc%2Ftrusted-firmware- > m%2F%2B%2F1527&data=02%7C01%7Candrey.butok%40nxp.com%7C068 > 37920c9bd443236e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635% > 7C0%7C0%7C636984076614785023&sdata=2SVwa0TpX4a4lP86hsIYiw25YS > Zqi8FzFErhpH3CrYI%3D&reserved=0, does it also make sense to > directly update the "generated" linker script/scatter file as well, on > feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common > flag used in multi- core topology and will help resolve our urgent problem. > If the final improvement solution is completed on master branch, we > will update the feature branch accordingly when merging it back to master branch. > > Please let me know if there is a better option for feature-twincpu branch. > Thank you. > > Best regards, > Hu Ziji > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Antonio De Angelis via TF-M > Sent: Thursday, July 11, 2019 3:53 AM > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] Common scatter files and templates > > Hi Chris, > > you are right, that file is autogenerated from the template file but > both are kept under source control. The reason for this is that the > autogenerated file is not created at build time but by manually > running the tfm_parse_manifest_list.py, which has to be run every time > something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. > > On the other hand, the build system could be modified to run the > parsers at build time so that the autogenerated files wouldn't have to > be stored in source control, and we could keep only the template. > These two alternatives are both equally valid in my view, but if there > is strong consensus for the other we can discuss. > > Thanks, > Antonio > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 10 July 2019 19:50 > To: TF-M(a)lists.trustedfirmware.org; Miklos Balint > Subject: [TF-M] Common scatter files and templates > > Can somebody please help me understand this? > $ ls platform/ext/common/armclang/ > tfm_common_s.sct tfm_common_s.sct.template $ ls > platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In > both directories, both files are under source control, but the > non-template files say that they're auto-generated: > /*********** WARNING: This is an auto-generated file. Do not edit! > ***********/ > > It's unusual to see both the source file and the artifact under source control. > > It seems that they're generated by tools/tfm_parse_manifest_list.py, > but that doesn't seem to be run as part of the build, so when is it run? > > 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.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 > 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD > bfl678%3D&reserved=0 > 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.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 > 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD > bfl678%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 > 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD > bfl678%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

2
3
0 0

Re: [TF-M] Common scatter files and templates

by Thomas Törnblom

For clarification, the IAR IDE supports both pre and post build actions. /Thomas Den 2019-07-11 kl. 15:17, skrev David Hu (Arm Technology China) via TF-M: > Hi Andrej, > > > Does your IDE support pre-build command? Is there any chance to execute the parse and auto-generation in the pre-build step? > > > Best regards, > > Hu Ziji > > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Thursday, July 11, 2019 7:41 PM > To: Ken Liu (Arm Technology China) > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Common scatter files and templates > > Hi Ken, > >> Could you help to tell the name of the file you don't want to be removed? > So, any .c,.h,.inc and linker file which may be used during compilation. > An IDE project (ARM Kei, MCUx, IAR etc.) assumes a fixed set of existing files. > > Thanks, > Andrej > > -----Original Message----- > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Sent: Thursday, July 11, 2019 12:44 PM > To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: Common scatter files and templates > > Hi Andrej, > > Could you help to tell the name of the file you don't want to be removed? > So that we can estimate what is important for IDE projects and how we could help on that. > > An introduction of how your IDE integrate with TF-M code is also welcome. > Would you share this to us? > > Thanks. > > -Ken > > >> -----Original Message----- >> From: Andrej Butok <andrey.butok(a)nxp.com> >> Sent: Thursday, July 11, 2019 2:25 PM >> To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Antonio De >> Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu (Arm Technology China) >> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> >> Cc: tf-m(a)lists.trustedfirmware.org >> Subject: RE: Common scatter files and templates >> >> Pre-generated files are required for TFM IDE projects. >> Please do not delete them, find other solution! >> It can be solved by adding #if/#ifdef. >> >> Thank you, >> Andrej Butok >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David >> Hu (Arm Technology China) via TF-M >> Sent: Thursday, July 11, 2019 4:08 AM >> To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf- >> m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) >> <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> >> Cc: nd <nd(a)arm.com> >> Subject: Re: [TF-M] Common scatter files and templates >> >> Hi Antonio, Ken, Miklos, >> >> Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to >> comment the veneer sections in the templates in multi-core topology. >> Each time before building, we have to run the Python script to >> generate new link script/scatter file with veneer disabled, to replace the existing ones. >> It becomes more inconvenient as the number of developers and users on >> feature-twincpu branch grows. >> >> As Chris proposed on >> https://review.tr >> ustedfirmware.org%2Fc%2Ftrusted-firmware- >> m%2F%2B%2F1527&data=02%7C01%7Candrey.butok%40nxp.com%7C068 >> 37920c9bd443236e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635% >> 7C0%7C0%7C636984076614785023&sdata=2SVwa0TpX4a4lP86hsIYiw25YS >> Zqi8FzFErhpH3CrYI%3D&reserved=0, does it also make sense to >> directly update the "generated" linker script/scatter file as well, on >> feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common >> flag used in multi- core topology and will help resolve our urgent problem. >> If the final improvement solution is completed on master branch, we >> will update the feature branch accordingly when merging it back to master branch. >> >> Please let me know if there is a better option for feature-twincpu branch. >> Thank you. >> >> Best regards, >> Hu Ziji >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >> Antonio De Angelis via TF-M >> Sent: Thursday, July 11, 2019 3:53 AM >> To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> >> Subject: Re: [TF-M] Common scatter files and templates >> >> Hi Chris, >> >> you are right, that file is autogenerated from the template file but >> both are kept under source control. The reason for this is that the >> autogenerated file is not created at build time but by manually >> running the tfm_parse_manifest_list.py, which has to be run every time >> something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. >> >> On the other hand, the build system could be modified to run the >> parsers at build time so that the autogenerated files wouldn't have to >> be stored in source control, and we could keep only the template. >> These two alternatives are both equally valid in my view, but if there >> is strong consensus for the other we can discuss. >> >> Thanks, >> Antonio >> >> ________________________________ >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of >> Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> >> Sent: 10 July 2019 19:50 >> To: TF-M(a)lists.trustedfirmware.org; Miklos Balint >> Subject: [TF-M] Common scatter files and templates >> >> Can somebody please help me understand this? >> $ ls platform/ext/common/armclang/ >> tfm_common_s.sct tfm_common_s.sct.template $ ls >> platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In >> both directories, both files are under source control, but the >> non-template files say that they're auto-generated: >> /*********** WARNING: This is an auto-generated file. Do not edit! >> ***********/ >> >> It's unusual to see both the source file and the artifact under source control. >> >> It seems that they're generated by tools/tfm_parse_manifest_list.py, >> but that doesn't seem to be run as part of the build, so when is it run? >> >> 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.trust >> edfirmware.org%2Fmailman%2Flistinfo%2Ftf- >> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 >> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 >> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD >> bfl678%3D&reserved=0 >> 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.trust >> edfirmware.org%2Fmailman%2Flistinfo%2Ftf- >> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 >> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 >> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD >> bfl678%3D&reserved=0 >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trust >> edfirmware.org%2Fmailman%2Flistinfo%2Ftf- >> m&data=02%7C01%7Candrey.butok%40nxp.com%7C06837920c9bd44323 >> 6e908d705a48d92%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 >> 984076614785023&sdata=CwIsfSfixxyMt0BjBQk2p0%2BrzebG2WeLVgAaD >> bfl678%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- *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>

6 years, 5 months

1
0
0 0

Re: [TF-M] Common scatter files and templates

by Andrej Butok

Pre-generated files are required for TFM IDE projects. Please do not delete them, find other solution! It can be solved by adding #if/#ifdef. Thank you, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, July 11, 2019 4:08 AM To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>; Miklos Balint <Miklos.Balint(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Common scatter files and templates Hi Antonio, Ken, Miklos, Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to comment the veneer sections in the templates in multi-core topology. Each time before building, we have to run the Python script to generate new link script/scatter file with veneer disabled, to replace the existing ones. It becomes more inconvenient as the number of developers and users on feature-twincpu branch grows. As Chris proposed on https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0, does it also make sense to directly update the "generated" linker script/scatter file as well, on feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common flag used in multi-core topology and will help resolve our urgent problem. If the final improvement solution is completed on master branch, we will update the feature branch accordingly when merging it back to master branch. Please let me know if there is a better option for feature-twincpu branch. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, July 11, 2019 3:53 AM To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Common scatter files and templates Hi Chris, you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 July 2019 19:50 To: TF-M(a)lists.trustedfirmware.org; Miklos Balint Subject: [TF-M] Common scatter files and templates Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 5 months

2
2
0 0

Re: [TF-M] Common scatter files and templates

by David Hu (Arm Technology China)

Hi Antonio, Ken, Miklos, Currently, we use a preprocessor flag `TFM_MULTI_CORE_TOPOLOGY` to comment the veneer sections in the templates in multi-core topology. Each time before building, we have to run the Python script to generate new link script/scatter file with veneer disabled, to replace the existing ones. It becomes more inconvenient as the number of developers and users on feature-twincpu branch grows. As Chris proposed on https://review.trustedfirmware.org/c/trusted-firmware-m/+/1527, does it also make sense to directly update the "generated" linker script/scatter file as well, on feature-twincpu branch? `TFM_MULTI_CORE_TOPOLOGY` will be a common flag used in multi-core topology and will help resolve our urgent problem. If the final improvement solution is completed on master branch, we will update the feature branch accordingly when merging it back to master branch. Please let me know if there is a better option for feature-twincpu branch. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, July 11, 2019 3:53 AM To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Common scatter files and templates Hi Chris, you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 July 2019 19:50 To: TF-M(a)lists.trustedfirmware.org; Miklos Balint Subject: [TF-M] Common scatter files and templates Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? 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 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, 5 months

2
2
0 0

Re: [TF-M] Common scatter files and templates

by Antonio De Angelis

Hi Chris, you are right, that file is autogenerated from the template file but both are kept under source control. The reason for this is that the autogenerated file is not created at build time but by manually running the tfm_parse_manifest_list.py, which has to be run every time something in the manifest is changed, and the resulting autogenerated file is committed under source control as well. On the other hand, the build system could be modified to run the parsers at build time so that the autogenerated files wouldn't have to be stored in source control, and we could keep only the template. These two alternatives are both equally valid in my view, but if there is strong consensus for the other we can discuss. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 July 2019 19:50 To: TF-M(a)lists.trustedfirmware.org; Miklos Balint Subject: [TF-M] Common scatter files and templates Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? 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 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.

6 years, 5 months

1
0
0 0

Common scatter files and templates

by Christopher Brand

Can somebody please help me understand this? $ ls platform/ext/common/armclang/ tfm_common_s.sct tfm_common_s.sct.template $ ls platform/ext/common/gcc tfm_common_s.ld tfm_common_s.ld.template In both directories, both files are under source control, but the non-template files say that they're auto-generated: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ It's unusual to see both the source file and the artifact under source control. It seems that they're generated by tools/tfm_parse_manifest_list.py, but that doesn't seem to be run as part of the build, so when is it run? 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, 5 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kumar Gala

How would a git repo with some submodules preclude any of the things you mentioned? I guess my initial thought is that there would be an “uber” repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. There’s also the option of using cmake ExternalProject (https://cmake.org/cmake/help/latest/module/ExternalProject.html?highlight=e…) Or west https://pypi.org/project/west/ - k > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Initial idea was to keep the external dependencies clearly visible (from code auditability point of view). With submodule we can't checkout the dependencies out of tree. Since the dependencies need to be checked out only once it was considered acceptable nuisance, until you do a pull and version of the dependencies have changed. > 'repo' was considered as well, but repo tool doesn't work on windows(last I checked). > > Thanks, > Ashu > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M > Sent: 10 July 2019 09:50 > To: Andrej Butok <andrey.butok(a)nxp.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Using git submodules for dependencies? > > There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason. > > - k > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Kevin, >> >> Only if 100% of the external project source code is used without change. >> Even if it is valid now, nobody will give you this guarantee in future. >> >> Regards, >> Andrej >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M >> Sent: Wednesday, July 10, 2019 10:41 AM >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> >> Subject: [TF-M] Using git submodules for dependencies? >> >> Hi, >> >> I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. >> >> Was the idea of git submodules for dependencies considered and rejected? >> Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. >> >> There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? >> >> Best regards, >> Kevin Townsend >> -- >> 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 > > -- > 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, 5 months

1
0
0 0

Add multi-image support to MCUBoot

by David Vincze

Hi All, I've pushed a set of patches for review which aims to add multi-image support to MCUBoot. It enables the Secure and Non-secure images to be handled and updated separately by the bootloader. You can find the links of the reviews and more information in the following ticket: https://developer.trustedfirmware.org/T421 Please feel free to review any of the patches.:) Thanks, David

6 years, 5 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Ashutosh Singh

Hi, Initial idea was to keep the external dependencies clearly visible (from code auditability point of view). With submodule we can't checkout the dependencies out of tree. Since the dependencies need to be checked out only once it was considered acceptable nuisance, until you do a pull and version of the dependencies have changed. 'repo' was considered as well, but repo tool doesn't work on windows(last I checked). Thanks, Ashu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 10 July 2019 09:50 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Using git submodules for dependencies? There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason. - k > On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Kevin, > > Only if 100% of the external project source code is used without change. > Even if it is valid now, nobody will give you this guarantee in future. > > Regards, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M > Sent: Wednesday, July 10, 2019 10:41 AM > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Using git submodules for dependencies? > > Hi, > > I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. > > Was the idea of git submodules for dependencies considered and rejected? > Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. > > There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? > > Best regards, > Kevin Townsend > -- > 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kumar Gala

There can always be a fork of the sources kept in TF-M repos to handle the case of needing local modifications for some reason. - k > On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Kevin, > > Only if 100% of the external project source code is used without change. > Even if it is valid now, nobody will give you this guarantee in future. > > Regards, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M > Sent: Wednesday, July 10, 2019 10:41 AM > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Using git submodules for dependencies? > > Hi, > > I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. > > Was the idea of git submodules for dependencies considered and rejected? > Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. > > There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? > > Best regards, > Kevin Townsend > -- > 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

6 years, 5 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Andrej Butok

Hi Kevin, Only if 100% of the external project source code is used without change. Even if it is valid now, nobody will give you this guarantee in future. Regards, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, July 10, 2019 10:41 AM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Using git submodules for dependencies? Hi, I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. Was the idea of git submodules for dependencies considered and rejected? Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 5 months

1
0
0 0

Using git submodules for dependencies?

by Kevin Townsend

Hi, I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. Was the idea of git submodules for dependencies considered and rejected? Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? Best regards, Kevin Townsend

6 years, 5 months

1
0
0 0

Re: [TF-M] [PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, The last patch for this task is pushed for review: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1487 Please help to review and the 'configs' directory would be the only place for holding configurations. Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, June 25, 2019 2:02 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] [PLEASE READ] Move configuration files into specified directory > > Hi, > Configurations has been moved into 'configs' directory. Please: > - Update your build commands to build with configurations under 'configs' > directory, check updated document: docs/user_guides/tfm_build_instruction.rst > - If you want to push new configurations, please put new configurations under > 'configs' directory. > > The dummy configurations under root directory will be removed soon so please > DO UPDATE YOUR BUILD COMMAND! > > Thanks > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, June 18, 2019 10:03 AM > > To: TF-M(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [RFC] Move configuration files into specified > > directory > > > > Hi, > > The patch has been pushed for a while and is going to be merged in one > > week, please help to review it if you planned but still not have a look: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > After this patch get merged, all new configurations created in root > > directory will be rejected. Please create new configuration files under ./configs > directory. > > The existing fake configuration files under root directory will be > > removed after CI setting changed. > > > > Thanks. > > > > -Ken > > > > > -----Original Message----- > > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > > Liu (Arm Technology China) via TF-M > > > Sent: Tuesday, June 11, 2019 1:40 PM > > > To: TF-M(a)lists.trustedfirmware.org > > > Cc: nd <nd(a)arm.com> > > > Subject: [TF-M] [RFC] Move configuration files into specified > > > directory > > > > > > Hi, > > > Since the number of configuration files is increasing, let’s move > > > the configuration files (ConfigXXXX.cmake) into specified directory. > > > This would reduces the files under root directory and makes the > > > structure more clearer. > > > > > > I have created the issue and patch for it: > > > https://developer.trustedfirmware.org/T394 > > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > > > IMPORTANT NOTES: > > > To be compatible with the existing building configurations, the > > > existing configuration files have been forwarded into the > > > corresponded configuration file under ./configs. Which means there > > > are two set of configuration files under sources tree at current – > > > but this will change soon. There is a warning while you are building > > > with root configurations files: “Please use the configs available in > > > the ./config sub- > > directory.” > > > > > > So please: > > > > > > - If you are planning to create new configuration, create it under > > > ./configs instead of root directory > > > - The reference of configuration files under root directory will be > > > removed soon, please change your build system setting to reference > > > the configuration files put under ./configs > > > > > > Any feedbacks please reply this mail or put comments under the > > > issue, thanks > > > 😉 > > > > > > -Ken > > > > > > -- > > > 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, 5 months

1
0
0 0

independent device driver model working along side SPM

by R, Manoj

Hi, Is there a design guideline available for device driver which is working on secure side alongside SPM. I do not want to plug my driver in TF-M due to latency considerations. Basically my plan is to introduce non secure callable veneers for calling the interfaces of the driver which I am introducing. Any thoughts on this will be helpful. Regards Manoj

6 years, 5 months

1
0
0 0

Changes to PSA headers in TF-M

by Jamie Fox

Hi all, I am proposing a couple of changes to the standard PSA headers in TF-M. The first change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1458/ It renames the standard PSA headers in TF-M from psa_<api>.h to psa/<api>.h. TF-M defined headers are not affected. This change also tweaks a large number of #includes across the TF-M repo to use the new names. Any code maintained outside the TF-M repo that includes PSA headers from TF-M will also need to be changed to use the new names in #includes once this is merged. The benefit of this change is that is brings the names of the headers in TF-M into agreement with the names used in the PSA Firmware Framework. It will also make running the PSA API tests easier, as the step of copying the PSA headers to the standard names is no longer required. The second change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1459/ It adds a copy of the psa/error.h header, which contains new standard error codes intended to be used by the SPM and RoT Services. The "PSA_SUCCESS" and "psa_status_t" definitions are also moved to this header, and it is included by psa/client.h and psa/service.h. This change should have minimal impact on other code -- no code is immediately changed to use the new error codes, but upstreaming the header now allows services to start using the new error codes when needed. Kind regards, Jamie

6 years, 5 months

1
0
0 0

[RFC] Secure Partition Runtime Library

by Ken Liu (Arm Technology China)

Hi, We are now involving secure partition runtime library into tf-m design. While implementing isolation level 2, some runtime APIs (printf e.g.) calling would cause fault, because it is accessing global variables (The STDIO instance) or need to manipulate hardware (UART). So we shutdown calling to these APIs - it is lucky that the secure service logic does not rely on these functions. This leads to the thinking of runtime APIs implementation - not only C runtime mentioned in PSA FF specification, but also developer APIs for service client. These APIs are definitely necessary and need to work well under all isolation levels. Since we cannot put multiple runtime copies into secure partitions (waste and not supported by single firmware linker design), shared runtime library looks like the only choice. Here we introduce the design of a runtime library for secure partition usage. We aligned the concepts with PSA FF and it does not break the mandatory requirements of isolation, and proposes designs for some dedicated APIs. I know there may be similar runtime implementations somewhere, while I just want to implement the functions quick to make out a solution before other library searching and investigating stage (which may spent quite much time). The key requirements of this runtime library are: - This library is protected as Read-Only + executable by MPU, so all other data will not be included into protected region. This point is very important. - For those session/handle based API set, necessary supporting from tooling or other parts needs to be involved. Please help to review the design document at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1425 Feel free to add you as reviewers and comment something; and you can reply to this thread, too. Any new thinking is worthy of being discussed. Thanks. -Ken

6 years, 5 months

1
0
0 0

Attestation token verifier

by Tamas Ban

Hi, You can find here a useful script which can be used to verify an initial attestation token(IAT) on server side when it is retrieved from the IoT device: https://developer.trustedfirmware.org/T411 BR, Tamas

6 years, 5 months

1
0
0 0

Re: [TF-M] tfm_mbedcrypto_include.h

by Andrej Butok

Hi Antonio, Sorry, ignore the previous e-mail. Yes, tfm_mbedcrypto_include.h was mixed up with tfm_mbedcrypto_config.h -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, June 27, 2019 12:48 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] tfm_mbedcrypto_include.h Hi Andrej, tfm_mbedcrypto_include.h is a file which is private to TF-M Crypto service and it's ok for it to be included directly by the service modules. I think what you are referring is platform/ext/common/tfm_mbedcrypto_config.h, which is indeed the configuration of the Mbed Crypto library (similar to what was done with the configuration of the Mbed TLS library), and as far as I can see is not included directly by any module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 June 2019 11:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tfm_mbedcrypto_include.h Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 5 months

1
0
0 0

Re: [TF-M] tfm_mbedcrypto_include.h

by Antonio De Angelis

Hi Andrej, tfm_mbedcrypto_include.h is a file which is private to TF-M Crypto service and it's ok for it to be included directly by the service modules. I think what you are referring is platform/ext/common/tfm_mbedcrypto_config.h, which is indeed the configuration of the Mbed Crypto library (similar to what was done with the configuration of the Mbed TLS library), and as far as I can see is not included directly by any module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 June 2019 11:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tfm_mbedcrypto_include.h Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

tfm_mbedcrypto_include.h

by Andrej Butok

Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

6 years, 5 months

1
0
0 0

Experimental IAR support

by Thomas Törnblom

Thank you for merging my cleanup in T398. I have a set of IAR build related files that I would like to push, both new and modified cmake files and startup and linker scripts for the Musca A board. There is still some work needed on the linker scripts to get everything fully functional but I can load and debug the secure and non secure images, and the non-secure image will start and execute the idle thread. I have not tested mcuboot although it appears to build properly. We have chip vendors that are eagerly awaiting our port and I would like to push this as "experimental". Would this be OK? /Thomas -- *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>

6 years, 6 months

1
0
0 0

Re: [TF-M] Feature request

by Gyorgy Szing

Hi Andrej, We shall avoid adding IDE specific workarounds to the code. I see many possible better solutions to this problem: 1. All IDEs are capable to "ignore" files present in the working copy but not part of the build. You could try this feature. 2. Irrelevant files can be deleted from the workspace by using a script. 3. Using a different generator of CMake could allow to generate a project format which your IDE can import. (See https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) 4. Using CMAKE_EXPORT_COMPILE_CMMANDS will make CMake to generate a json file listing all C files part of the build with the build command needed to compile them. It could be relative simple to write a Python script to create an IDE project or to update an existing one with build settings. (See: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.…) 5. Long term a generators could be up streamed to CMake to add Support for you IDE. Please contact the IDE vendor with this request. 6. The IDE could be updated to co-operate with "cmake server" to allow integration with cmake based build systems. Again please contact the IDE vendor with this request. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 18 June 2019 08:23 To: Miklos Balint <Miklos.Balint(a)arm.com>; Thomas Törnblom <thomas.tornblom(a)iar.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Feature request Hi Miklos, One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature request Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *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: https://eur01.safelinks.protection.outlook.com/?url=www.iar.com&data=02… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: https://eur01.safelinks.protection.outlook.com/?url=www.twitter.com%2Fiarsy… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…> -- 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://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

6 years, 6 months

2
2
0 0

[PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, Configurations has been moved into 'configs' directory. Please: - Update your build commands to build with configurations under 'configs' directory, check updated document: docs/user_guides/tfm_build_instruction.rst - If you want to push new configurations, please put new configurations under 'configs' directory. The dummy configurations under root directory will be removed soon so please DO UPDATE YOUR BUILD COMMAND! Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, June 18, 2019 10:03 AM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Move configuration files into specified directory > > Hi, > The patch has been pushed for a while and is going to be merged in one week, > please help to review it if you planned but still not have a look: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > After this patch get merged, all new configurations created in root directory will > be rejected. Please create new configuration files under ./configs directory. > The existing fake configuration files under root directory will be removed after > CI setting changed. > > Thanks. > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, June 11, 2019 1:40 PM > > To: TF-M(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [TF-M] [RFC] Move configuration files into specified > > directory > > > > Hi, > > Since the number of configuration files is increasing, let’s move the > > configuration files (ConfigXXXX.cmake) into specified directory. > > This would reduces the files under root directory and makes the > > structure more clearer. > > > > I have created the issue and patch for it: > > https://developer.trustedfirmware.org/T394 > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > IMPORTANT NOTES: > > To be compatible with the existing building configurations, the > > existing configuration files have been forwarded into the corresponded > > configuration file under ./configs. Which means there are two set of > > configuration files under sources tree at current – but this will > > change soon. There is a warning while you are building with root > > configurations files: “Please use the configs available in the ./config sub- > directory.” > > > > So please: > > > > - If you are planning to create new configuration, create it under > > ./configs instead of root directory > > - The reference of configuration files under root directory will be > > removed soon, please change your build system setting to reference the > > configuration files put under ./configs > > > > Any feedbacks please reply this mail or put comments under the issue, > > thanks > > 😉 > > > > -Ken > > > > -- > > 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, 6 months

1
0
0 0

TF-M CI Blog

by Shebu Varghese Kuriakose

Hi All, Not sure if everyone knows that there is an initial deployment of TF-M CI (Continuous Integration) system. It tests every patch that gets submitted in TF-M gerrit. Read about the CI system and find the relevant links in this blog - https://www.trustedfirmware.org/blog/trusted-firmware-open-ci-update/ Thanks, Shebu

6 years, 6 months

1
0
0 0

Please help review the patches of architecture abstraction in TF-M

by David Hu (Arm Technology China)

Hi all, Could you please review the following patches to abstract architecture specific code? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157/<https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1158 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1390/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1251/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1252/ The above patches abstract architecture specific code to decouple TF-M core to specific architecture details. It can help enable TF-M running on diverse Arm M-profile architectures. Other Arm M-profile architecture implementation will be added later. Suggestions are welcome. Thank you. Best regards, Hu Ziji

6 years, 6 months

1
0
0 0

Align manifest to PSA FF

by Edison Ai (Arm Technology China)

Hi, I had create patches related to manifest. There are two topics for it: * Align manifest to PSA FF: https://review.trustedfirmware.org/#/q/topic:Align_manifest_to_PSA_FF+(stat… * Generate SID and signal header files according to manifest: https://review.trustedfirmware.org/#/q/topic:generate_SID_signal_header_fil… I had added some reviewers to help to review them. Please feel free to give any comment even you are not in reviewer list(Sorry maybe skip someone by mistake). There are some important patches I think and please pay your attention to them: * Remove "tfm_symbol" from manifest: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1243/ * Change the value of SID: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1246/ * Rename the manifest file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1247/ * Generate manifest file name header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ * Assign signal value to SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ * Generate service ID header file: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1353/ Thanks, Edison

6 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M