Strictly speaking, the files in interface/src are a possible implementation of the interface described in interface/include. Your integration can provide a different implementation of tfm_ns_lock_dispatch(...) based on your requirements, without the need to upstream your change. But if you think that your change can be useful for a wider audience, yes, please create a change where you modify tfm_ns_lock_dispatch(...) using CMSIS-RTOS2 APIs to check for pre-rtos stage and we'll get that reviewed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jun 10 2019
Jun 10 2019
After dropping 1123, create another change which adds support for pre-retos dispatch in tfm_ns_lock_dispatch by checking kernel state with osKernelGetState, right?
Jun 7 2019
Jun 7 2019
Thanks for summarising the three options.
1123 is for NS secure call at pre-rtos stage and 1124 for in interrupt-disabled condition. They are different and so separate changes. For 1123, since osKernelGetState can substitute for get_init_state. I have three choices:
- Abandon 1123 (and also get_init_state)
- Re-implement get_init_state with osKernelGetState
- Abandon 1123 (and also get_init_state) and integrate pre-rtos NS secure call into tfm_ns_lock_dispatch
Jun 6 2019
Jun 6 2019
Just to be clear, as there has been some confusion between get_init_state() and get_lock_state (particularly on my side :) ), I think that the get_init_state(...) doesn't need to be exported as probably the same result can be obtained by proper usage of CMSIS-RTOS2 API's (or equivalent API's, based on the NS side scenario). Regarding the get_lock_state(...), I will comment on the other thread. T378
I agree in principle with the idea, but I have a comment regarding the implementation.
The NS lock is initialized at a point in time when the scheduler is not yet started, therefore there is a single thread of execution on the NS side.
I agree it is safe to assume that in such a scenario, the only actor on the NS side is privileged and therefore is assumed to be in full control of execution, there are no separate protection domains within NSPE.
Secure lock is already set up so there's no risk of introducing new exploits with this change.
Change for this ticket is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1223
Update integration guide:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1155/
Jun 5 2019
Jun 5 2019
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/951/ reviewed, approved, upstreamed
Could you open a review on https://review.trustedfirmware.org and push the code there for review?
cuipingzhang added a comment to T389: Add independent updates for security and non-security in MCUBoot.
trusted-firmware-m-20190603.rar8 MBDownload
cuipingzhang updated the task description for T389: Add independent updates for security and non-security in MCUBoot.
Jun 4 2019
Jun 4 2019
Patch for this task https://review.trustedfirmware.org/c/trusted-firmware-m/+/1212
jf549 triaged T390: Ensure flash driver is initialised before use by NV counters as Normal priority.
cuipingzhang changed the edit policy for T389: Add independent updates for security and non-security in MCUBoot.
Jun 3 2019
Jun 3 2019
Due to increased interest in this feature and no objections to the implementation concept, I'm raising the priority and will rebase my proposal change and do some polishing to make it a good candidate for upstreaming.
The suggested change of naming convention was discussed offline but was deemed unnecessary as there's limited risk of the feature being misunderstood and that is planned to be mitigated by improved documentation, while the design pattern evoked by the current name is hopefully a reasonable point of reference.
wmnt raised the priority of T329: Platform: create design pattern for platform-specific services from Normal to High.
May 31 2019
May 31 2019
Fix for second issue:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1197/
May 30 2019
May 30 2019
Additional patch is required for Musca A to make sure that the quantity of RAM assigned to the SPE in the region_defs.h header is increased for IPC mode build even if the tests are not build, as RAM requirements for IPC are higher than the current default limit of 64 KB. Patch for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1184
Upstreamed
Follow-on task to remove deprecated test case: https://developer.trustedfirmware.org/T387
Patch for this task
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1181
Thanks, the change is approved.
matetothpal triaged T385: Lock secure side when entered from NS code in IPC model as Normal priority.
Toolchain: Arm Compiler 6.10
Platform: Nuvoton M2351 (M23-based)
mbed-os/tf-m
Could you provide details of the compiler configuration where you received this error?
We may need to update the configurations in CI to capture similar shortcomings.
I will execute some rudimentary tests in the meantime.
May 29 2019
May 29 2019
Patch for this task
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1174
Patch for this task
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1170
• Summer-ARM closed T240: Level 1: Partition stack size is fixed instead of from manifest as Resolved.
May 28 2019
May 28 2019
Review of patch:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1162/
davidvincze raised the priority of T372: Remove I/O format specifier macros from bootloader from Low to Normal.
May 27 2019
May 27 2019
May 25 2019
May 25 2019
May 24 2019
May 24 2019
See below review for corresponding change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1152/
May 22 2019
May 22 2019
• Summer-ARM added a comment to T240: Level 1: Partition stack size is fixed instead of from manifest.
May 21 2019
May 21 2019
Other relevant changes (fixes):
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1090/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1091/
May 20 2019
May 20 2019
May 18 2019
May 18 2019
adeaarm added a comment to T183: Build error: TF-M build fails for gcc version 6.3 for CoreTest configuration.
This needs to be merged, it has been open for months and the issue is being reported by Summer as well.
May 17 2019
May 17 2019
A fix was necessary to pass the PSA-ACK test in case of IPC model:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1115/
May 16 2019
May 16 2019
May 15 2019
May 15 2019
May 14 2019
May 14 2019
adeaarm added a comment to T352: Build: Add build configurations for PSA API compliance tests in IPC mode.
Change which fixes this issue is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1079
adeaarm triaged T352: Build: Add build configurations for PSA API compliance tests in IPC mode as Normal priority.
matetothpal closed T337: Manifest: error when printing error message for missing package as Resolved.
The change for this issue had been merged.
May 13 2019
May 13 2019
May 10 2019
May 10 2019
May 9 2019
May 9 2019
Change for this issue had been merged.
Fix for this style issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1019
It turns out that it's a configuration option which can be overriden in our custom CSS file.