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.
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
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
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
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
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
+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
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.
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
