- TF-M - lists.trustedfirmware.org

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

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

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

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

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

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

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

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

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

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

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M