- TF-M - lists.trustedfirmware.org

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

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

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

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

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

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

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

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

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, 1 month

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, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M