Cypress PSoC64 TF-M Integration #13243

CharleyChu · 2020-07-06T23:20:07Z

Summary of changes

Impact of changes

WIP

Import TF-M release package
Couple of change in release files required to work with MBedOS

Migration actions required

Documentation

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

ciarmcom · 2020-07-07T01:00:31Z

@CharleyChu, thank you for your changes.
@maclobdell @ARMmbed/mbed-os-maintainers please review.

maclobdell · 2020-07-07T19:31:27Z

I tried to build this and got the failure below.

mbed compile -m CY8CKIT_064B0S2_4343W -t gcc_arm -v

[Fatal Error] tfm_multi_core_api.c@8,10: os_wrapper/semaphore.h: No such file or directory
[DEBUG] Return: 1
[DEBUG] Output: .\features\FEATURE_EXPERIMENTAL_API\FEATURE_PSA\TARGET_TFM\TARGET_TFM_DUALCPU\src\tfm_multi_core_api.c:8:10: fatal error: os_wrapper/semaphore.h: No such file or directory
[DEBUG] Output:     8 | #include "os_wrapper/semaphore.h"
[DEBUG] Output:       |          ^~~~~~~~~~~~~~~~~~~~~~~~
[DEBUG] Output: compilation terminated.

Is this a scoping problem with the include?

Please note that you can run greentea tests with the following steps.

Install the tools, provision the board, set the keys
Put the debug interface into DAPLink mode (press mode button until the interface led blinks)
Run the mbedls mock command mbedls -m 1910:CY8CKIT_064B0S2_4343W (this is required because of CY8CKIT_064B0S2_4343W target name over 20 char limit, not matching mbed-os-tools #13218)
Run the test command mbed test -m CY8CKIT_064B0S2_4343W -t gcc_arm
Verify the results (takes about 30 minutes or more)
Repeat with -t arm

CharleyChu · 2020-07-07T20:15:48Z

I just update the patch to get rid of the dependency on os-wrapper. We have os-wrapper included in application level for TF-M regression test. Thanks, Charley From: Mac Lobdell <[email protected]> Sent: Tuesday, July 7, 2020 12:32 PM To: ARMmbed/mbed-os <[email protected]> Cc: Hao Chuan Chu <[email protected]>; Mention <[email protected]> Subject: Re: [ARMmbed/mbed-os] WIP: Cypress PSoC64 TF-M Integration (#13243) I tried to build this and got the failure below. mbed compile -m CY8CKIT_064B0S2_4343W -t gcc_arm -v [Fatal Error] tfm_multi_core_api.c@8,10<mailto:tfm_multi_core_api.c@8,10>: os_wrapper/semaphore.h: No such file or directory [DEBUG] Return: 1 [DEBUG] Output: .\features\FEATURE_EXPERIMENTAL_API\FEATURE_PSA\TARGET_TFM\TARGET_TFM_DUALCPU\src\tfm_multi_core_api.c:8:10: fatal error: os_wrapper/semaphore.h: No such file or directory [DEBUG] Output: 8 | #include "os_wrapper/semaphore.h" [DEBUG] Output: | ^~~~~~~~~~~~~~~~~~~~~~~~ [DEBUG] Output: compilation terminated. Is this a scoping problem with the include? Please note that you can run greentea tests with the following steps. * Install the tools, provision the board, set the keys * Put the debug interface into DAPLink mode (press mode button until the interface led blinks) * Run the mbedls mock command mbedls -m 1910:CY8CKIT_064B0S2_4343W (this is required because of #13218<#13218>) * Run the test command mbed test -m CY8CKIT_064B0S2_4343W -t gcc_arm * Verify the results (takes about 30 minutes or more) * Repeat with -t arm — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#13243 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMS3WFP3LWK4HCSFHAQRDU3R2NZ2DANCNFSM4OSBY3CA>. 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.

maclobdell · 2020-07-08T03:11:24Z

@CharleyChu Thanks! I pulled your changes. Now I am able to build successfully! I had to use a policy file that was previously shared with me over email.

I see that the default policy file (policy_multi_CM0_CM4_tfm.json) is missing. Can you add that?

CharleyChu · 2020-07-08T05:11:40Z

Hi Mac, Please let me know where do you want me to add it. Thanks, Charley From: Mac Lobdell <[email protected]> Sent: Tuesday, July 7, 2020 8:12 PM To: ARMmbed/mbed-os <[email protected]> Cc: Hao Chuan Chu <[email protected]>; Mention <[email protected]> Subject: Re: [ARMmbed/mbed-os] WIP: Cypress PSoC64 TF-M Integration (#13243) @CharleyChu<https://github.com/CharleyChu> Thanks! I pulled your changes. Now I am able to build successfully! I had to use a policy file that was previously shared with me over email. I see that the default policy file (policy_multi_CM0_CM4_tfm.json) is missing. Can you add that? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#13243 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMS3WFNL3X5GPQF4OY26Y3TR2PPWVANCNFSM4OSBY3CA>. 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.

0xc0170 · 2020-07-08T07:44:02Z

Please also fill in the pull request template (PR type, tests, etc).

0xc0170 · 2020-07-08T07:44:50Z

targets/targets.json

-            "BLE"
+            "BLE",
+            "EXPERIMENTAL_API",
+	    "PSA"


fix the alignment here

Patater

The commit "More changes" looks like a fixup commit for "psoc64: Add TF-M compatibility". Please combine these commits.

The commit title "tf-m: Add TF-M binaries for CYESKIT_064B0S2_4343W" seems wrong. Isn't it the "TARGET_CY8CKIT_064B0S2_4343W target we want to add support and binaries for? Maybe we can delete the commit if we don't need it.

Commit "Update TF-M release package for regression test" adds uses of os_wrapper, but commit "Changes required in TF-M release" later removes os_wrapper. It's easier to review and read the patchset if we don't revert changes made in earlier patches.

Commits "tf-m: Add TF-M binaries for CYESKIT_064B0S2_4343W", "Update to get 064B0S2 work with TF-M", "Update TF-M release package for regression test" all add or modify TF-M secure binaries for this target. It's a bit noisy history-wise. Are we modifying the binary in each commit to ensure that each commit builds and works on their own? If not, we should only update the binary when necessary to avoid patchset noise.

In each commit, whenever tfm_s.hex is modified, please also ensure that the tfm_s.axf is also updated to match, at least so that debugging with symbols remains remotely possible.

Patater · 2020-07-08T08:40:00Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/VERSION.txt

@@ -1 +1 @@
-1d1faca481c3
+eaaf44c87c63


Please ensure that the VERSION.txt file documenting with commit hash of TF-M the binaries were built with is correct. All TF-M binaries in Mbed OS are currently are build with the same TF-M branch, but this PR provides a binary for PSoC64 different from the others.

We may want a PSoC64-specific VERSION.txt as well as a "permissive binary license" (if source is unavailable).

I will update the version file, Please advise what algorithm is used to generate the hash

The algorithm is: the first 12 characters of the git hash of the branch of TF-M you are using to make the binary

Patater · 2020-07-08T08:54:27Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/include/psa/crypto_extra.h

- *          verified that the usage of the key with multiple algorithms
- *          is safe.
- */
-static inline void psa_set_key_enrollment_algorithm(


We need to leave this in, sorry. Enrollment algorithm support (alg2) is necessary for Pelion to function.

Patater · 2020-07-08T08:56:17Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/include/tfm_multi_core_api.h

- * \return \ref TFM_SUCCESS on success
- * \return \ref TFM_ERROR_GENERIC on error
+ * \return \ref OS_WRAPPER_SUCCESS on success
+ * \return \ref OS_WRAPPER_ERROR on error


We shouldn't be using os_wrapper nor its OS_WRAPPER error codes.

Patater · 2020-07-08T08:56:38Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/include/tfm_platform_api.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2018-2020, Arm Limited. All rights reserved.
+ * Copyright (c) 2018-2019, Arm Limited. All rights reserved.


This copyright year shouldn't go backwards

Patater · 2020-07-08T08:57:20Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/include/tfm_platform_api.h

- *          it returns TFM_PLATFORM_ERR_SYSTEM_ERROR.
- */
-enum tfm_platform_err_t
-tfm_platform_nv_counter_increment(uint32_t counter_id);


Why remove the NV counter service from TF-M targets? This code is shared with v8-M targets and isn't just used by PSoC 64.

Our code is based TF-Mv1.0, which doesn't include latest changes in TF-M master. I will revert the change.

OK, waiting for the revert

Patater · 2020-07-08T09:02:36Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/include/tfm_ns_mailbox.h

 */
-const void *tfm_ns_mailbox_get_task_handle(void);
+void * tfm_ns_mailbox_hal_create_semaphore(void);


Is this change present in any public branch of TF-M or change request to TF-M?

How will we ensure when Mbed OS upgrades TF-M next time we have the necessary changes here? We need a patch to https://github.com/ARMmbed/trusted-firmware-m/tree/dev/feature-dualcore to keep changes like these. Could you please raise a PR to https://github.com/ARMmbed/trusted-firmware-m/tree/dev/feature-dualcore with the patches we need on TF-M to support PSoC 64?

Jaeden, the plan here is to use our binary to get this out the door. We will work post-release to synchronize what we can. There remains a general problem here of supporting different versions of TFM. In this particular instance, I believe we can revert this change but will not be able to in this timeframe.

Patater · 2020-07-08T09:02:57Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/include/tfm_mailbox.h

@@ -135,7 +135,7 @@ struct mailbox_reply_t {
 struct ns_mailbox_slot_t {
    struct mailbox_msg_t   msg;
    struct mailbox_reply_t reply;
-    const void             *owner;          /* Handle of the owner task of this
+    void                   *sem;            /* Handle of the semaphore of this


Will this change be available in upstream TF-M?

I don't think we can accept changes here that will never be upstreamed to TF-M. We will update TF-M in the future and this would overwrite these changes.

Jaeden, we are going to run into problems here as there are more PSA targets supported. I doubt all PSA targets will be on the same version of TFM. E.g. the musca target is free to move along but that doesn't mean this target will move with it.

Yes, this will be a problem if Mbed OS needs to support non-upstream versions of TF-M. Mbed OS can really only support upstream versions of TF-M, one version for all targets.

This is not just non-upstream versions but different upstream versions. There is TFM v1 and v1.1 today. Although the PSA API has unlikely changed, the exports likely have. How will mbed os deal with different upstream versions? Would we really force all PSA targets to conform to current mbedos version of TFM? I think we need to have a discussion on how we handle all these cases.

Patater · 2020-07-08T09:03:12Z

features/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/include/psa_manifest/sid.h

+
+/******** TFM_PSOC_CLIENT_TEST ********/
+#define PSOC_CLIENT_TEST_LVL2_SID                                  (0x00002000U)
+#define PSOC_CLIENT_TEST_LVL2_VERSION                              (1U)


Do we want to always include these tests in the production TF-M binary we ship with Mbed OS?

Those test ID only take effective when the test service is enabled. In release build, test service is not enabled.

Is the binary added by this PR the release build or the test build?

Release Core Config. We shouldn't be using Debug or Regression builds.

When mbed-os-tf-m-regression-tests is used to add target support to Mbed OS with the release core config (ConfigCoreIPC.cmake), it will avoid adding these extra test services to the header here (because TF-M doesn't put these services into this header because the binary doesn't have these services available).

maclobdell · 2020-07-08T16:50:11Z

I'm running greentea tests with gcc compiler. Here are the initial results.

I'm using test command mbed test -m CY8CKIT_064B0S2_4343W -t gcc_arm

Issue 1

I noticed that several tests will pass in the test run until it gets to tests-mbedmicro-rtos-mbed-semaphore. Then all tests fail after that.
They fail with the message SYNC_FAILED indicating that the application failed to boot or there is a problem with the serial
Every test after the semaphore test results in the same failure.
If I power cycle the board, then the issue goes away.

Issue 2

The mbedtls tests are failing with the message TIMEOUT
You can run these tests individually with the command mbed test -n tests-mbedtls* -m CY8CKIT_064B0S2_4343W -t gcc_arm

CharleyChu · 2020-07-08T17:07:58Z

I will take a look and get back to you later. Thanks, Charley From: Mac Lobdell <[email protected]> Sent: Wednesday, July 8, 2020 9:50 AM To: ARMmbed/mbed-os <[email protected]> Cc: Hao Chuan Chu <[email protected]>; Mention <[email protected]> Subject: Re: [ARMmbed/mbed-os] WIP: Cypress PSoC64 TF-M Integration (#13243) I'm running greentea tests with gcc compiler. Here are the initial results. I'm using test command mbed test -m CY8CKIT_064B0S2_4343W -t gcc_arm Issue 1 * I noticed that several tests will pass in the test run until it gets to tests-mbedmicro-rtos-mbed-semaphore. Then all tests fail after that. * They fail with the message SYNC_FAILED indicating that the application failed to boot or there is a problem with the serial * Every test after the semaphore test results in the same failure. * If I power cycle the board, then the issue goes away. Issue 2 * The mbedtls tests are failing with the message TIMEOUT * You can run these tests individually with the command mbed test -n tests-mbedtls* -m CY8CKIT_064B0S2_4343W -t gcc_arm — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#13243 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMS3WFNZPJDBIQXIL74S7M3R2SPVFANCNFSM4OSBY3CA>. 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.

maclobdell · 2020-07-08T22:08:08Z

I have found that these tests are failing.

features-device_key-tests-device_key-functionality
tests-mbedtls-multi
tests-mbedtls-selftest
tests-mbed_hal-crc
tests-mbed_hal-trng
tests-mbed_drivers-crc
features-storage-tests-kvstore-direct_access_devicekey_test
features-storage-tests-kvstore-general_tests_phase_2

Also, as mentioned earlier, some test in the tests-mbedmicro- suite seems to cause SYNC_FAILED For tests that run after it.

I'll keep investigating on my side, but please try running these tests (both before and after your changes to confirm)

You can run tests with the '-v' option for verbose output.

Greentea should run fine with version Python 2.7.10 and later.

Pull request has been modified.

adbridge · 2020-07-09T12:55:42Z

@CharleyChu @maclobdell what is the state of this now? Are all failing tests now passing ? Have all comments been addressed? I see some additional force pushed commits but no comments as to what has changed ?

adbridge · 2020-07-09T12:57:31Z

Also is this a patch or feature update (perhaps @Patater can answer that one ?) and what testing is required? Are the internal Greentea tests sufficient or would we expect additional tests to be provided?

Patater · 2020-07-09T15:32:01Z

Testing required:

Passing log of TF-M regression tests from https://github.com/ARMmbed/mbed-os-tf-m-regression-tests/

mergify · 2020-07-17T09:55:29Z

This PR cannot be merged due to conflicts. Please rebase to resolve them.

- Remove CY8CKIT_064B0S2_4343W_NPSA target - Reserve 32KB non-secure flash for KV storage This is based on Devaraj's patch ARMmbed#13243 (comment) - Relocate policy file to policy directory Signed-off-by: Charley Chu <[email protected]>

Pull request has been modified.

CharleyChu · 2020-07-17T21:46:18Z

TFM regression test result (also run PSA hash test at the beginning)
064B0S2-tfm-regression-test.txt

The CY8CKIT_064B0S2_4343W target was added as a replacement for the prototype CY8CKIT_064S2_4343W target, but it is missing modifications added to CY8CKIT_064S2_4343W to enable it to work with TF-M. Make the CY8CKIT_064B0S2_4343W target TF-M compatible by addding flash and region definitions from TF-M and by updating the CY8CKIT_064B0S2_4343W linker script to create a flash image compatible with TF-M.

Signed-off-by: Charley Chu <[email protected]>

- Replace TF-M OS wrapper API with CMSIS API - Add busy loop in mailbox_raw_spin_lock() - Use static allocated semaphore for NS lock Signed-off-by: Charley Chu <[email protected]>

MXCRYPTO is protected by TF-M, Accessing its registers will trigger HW fault Ideally all Crypto operation should be re-direct to TF-M through PSA calls, but now only TRNG is implemented (psa_hrng.c) MBedTLS ALTs disabled CRC HAL disabled TRNG HAL disabled, use psa_hrng instead. Signed-off-by: Charley Chu <[email protected]>

Copy it to the directory where the application is built Signed-off-by: Charley Chu <[email protected]>

- Remove CY8CKIT_064B0S2_4343W_NPSA target - Reserve 32KB non-secure flash for KV storage This is based on Devaraj's patch ARMmbed#13243 (comment) - Relocate policy file to policy directory Signed-off-by: Charley Chu <[email protected]>

Signed-off-by: Charley Chu <[email protected]>

This reverts commit 3b44ac1.

Signed-off-by: Charley Chu <[email protected]>

Named TFM V1.1 as TFM_V1_1 instead of TFM_V1.1 as TFM_V1.1 is invalid as macro name Signed-off-by: Charley Chu <[email protected]>

Signed-off-by: Charley Chu <[email protected]>

CharleyChu · 2020-07-17T23:23:24Z

Rebased to resolve the conflict

romanjoe · 2020-07-20T14:23:36Z

@CharleyChu @RaymondNgun @maclobdell @0xc0170

This pull request can not be merged in current state because if will break initial implementation with CM0p image - not a TFM hex.

I suggest to leave current implementation of CY8CKIT_064B0S2_4343W as it is in targets.json and create separate target say CY8CKIT_064B0S2_4343W_TFM (just a suggestion) and define there all needed configurations, including "boot_scheme": "multi_image". Support for both boot schemes (single and multi image) already exist in PSOC6.sing_image post build function in tools/PSOC6.py.

In that case tfm.hex should be placed inside target folder, say .././../CY8CKIT_064B0S2_4343W_TFM/prebuild/tfm.hex and it name set in "hex_filename": "tfm.hex".

If you want to include policy file to a target code - i highly suggest usege of .././../CY8CKIT_064B0S2_4343W_TFM/policy directory as default, following Secure Boot User Guiade (*D) (not sure if it is already released, but @sreeharshaangara and i have worked on that)

maclobdell · 2020-07-21T12:38:21Z

@CharleyChu do you plan to make the requested changes recommended by Roman? Or alternatively, @romanjoe can this target just have TF-M enabled always? Is there a use-case for using this chip without TF-M? It seems important to unlock the nice features of PSoC64.

Patater · 2020-07-22T08:20:29Z

I suggest to leave current implementation of CY8CKIT_064B0S2_4343W as it is in targets.json and create separate target say CY8CKIT_064B0S2_4343W_TFM (just a suggestion) and define there all needed configurations, including "boot_scheme": "multi_image". Support for both boot schemes (single and multi image) already exist in PSOC6.sing_image post build function in tools/PSOC6.py.

Good suggestion to have two separate targets. Mbed OS as currently designed and documented has TF-M and PSA available on targets that support it using the bare target name. Targets that don't support TF-M or PSA have an NPSA suffix to show they don't have PSA. And indeed an earlier version of this PR indeed included a CY8CKIT_064B0S2_4343W_NPSA target, though it was removed from this PR because it needed more work. It sounds like it'd be good to bring it back.

mergify · 2020-07-23T15:00:57Z

This PR cannot be merged due to conflicts. Please rebase to resolve them.

CharleyChu · 2020-07-28T18:03:02Z

Replaced by #13358

CharleyChu changed the title ~~Cypress PSoC64 TF-M Integration~~ WIP: Cypress PSoC64 TF-M Integration Jul 6, 2020

mergify bot added the do not merge label Jul 6, 2020

ciarmcom requested review from maclobdell and a team July 7, 2020 01:00

ciarmcom added the needs: review label Jul 7, 2020

CharleyChu force-pushed the master_064b0s2 branch from f766612 to 04eca5b Compare July 7, 2020 20:08

0xc0170 requested a review from Patater July 8, 2020 07:43

0xc0170 previously requested changes Jul 8, 2020

View reviewed changes

targets/targets.json Outdated

"BLE"

"BLE",

"EXPERIMENTAL_API",

"PSA"

Copy link

Contributor

0xc0170 Jul 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix the alignment here

mergify bot added needs: work and removed needs: review labels Jul 8, 2020

Patater suggested changes Jul 8, 2020

View reviewed changes

Patater previously requested changes Jul 8, 2020

View reviewed changes

CharleyChu force-pushed the master_064b0s2 branch from 04eca5b to 5814a49 Compare July 9, 2020 01:37

CharleyChu changed the title ~~WIP: Cypress PSoC64 TF-M Integration~~ Cypress PSoC64 TF-M Integration Jul 9, 2020

0xc0170 removed the do not merge label Jul 9, 2020

0xc0170 previously approved these changes Jul 9, 2020

View reviewed changes

CharleyChu force-pushed the master_064b0s2 branch from 8ae2b90 to 651406b Compare July 17, 2020 21:41

Patater and others added 13 commits July 17, 2020 16:13

psoc64: Add TF-M release package

90f69f9

Signed-off-by: Charley Chu <[email protected]>

psoc64: Update TF-M for MBedOS

39e5716

- Replace TF-M OS wrapper API with CMSIS API - Add busy loop in mailbox_raw_spin_lock() - Use static allocated semaphore for NS lock Signed-off-by: Charley Chu <[email protected]>

psoc64: Add 064B0S2 policy file.

2a254f9

Copy it to the directory where the application is built Signed-off-by: Charley Chu <[email protected]>

psoc64: Resolve compile and runtime issues

4ae6e6f

- Remove CY8CKIT_064B0S2_4343W_NPSA target - Reserve 32KB non-secure flash for KV storage This is based on Devaraj's patch ARMmbed#13243 (comment) - Relocate policy file to policy directory Signed-off-by: Charley Chu <[email protected]>

psoc64: Add 064B0S2 default keys

7aa4f19

Signed-off-by: Charley Chu <[email protected]>

psoc64: Removed PSOC specific test IDs

3092f45

Signed-off-by: Charley Chu <[email protected]>

Revert "psoc64: Disable accessing MXCRYPTO"

5771354

This reverts commit 3b44ac1.

Use PSA TRNG if PSA is enabled and no TRNG device defined

f068337

Signed-off-by: Charley Chu <[email protected]>

psoc64: Disable TRNG and MXCRYPTO on 064B0S2

e799351

Signed-off-by: Charley Chu <[email protected]>

Move current TFM to TFM_V1_1

09dcd05

Named TFM V1.1 as TFM_V1_1 instead of TFM_V1.1 as TFM_V1.1 is invalid as macro name Signed-off-by: Charley Chu <[email protected]>

Add TFM V1.0

fdab1dd

Signed-off-by: Charley Chu <[email protected]>

CharleyChu force-pushed the master_064b0s2 branch from 651406b to fdab1dd Compare July 17, 2020 23:19

maclobdell requested a review from Patater July 18, 2020 12:10

RaymondNgun mentioned this pull request Jul 28, 2020

Add CYTFM_064B0S2 4343W Target #13358

Merged

CharleyChu closed this Jul 28, 2020

mergify bot removed needs: work release-type: patch Indentifies a PR as containing just a patch labels Jul 28, 2020

		@@ -1 +1 @@
		1d1faca481c3
		eaaf44c87c63

Cypress PSoC64 TF-M Integration #13243

Cypress PSoC64 TF-M Integration #13243

Uh oh!

Conversation

CharleyChu commented Jul 6, 2020 • edited by 0xc0170 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of changes

Impact of changes

Migration actions required

Documentation

Pull request type

Test results

Reviewers

Uh oh!

ciarmcom commented Jul 7, 2020

Uh oh!

maclobdell commented Jul 7, 2020

Uh oh!

CharleyChu commented Jul 7, 2020 via email

Uh oh!

maclobdell commented Jul 8, 2020

Uh oh!

CharleyChu commented Jul 8, 2020 via email

Uh oh!

0xc0170 commented Jul 8, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Patater left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

CharleyChu commented Jul 6, 2020 •

edited by 0xc0170

Loading

maclobdell commented Jul 8, 2020 •

edited

Loading