Open-CMSIS-Pack Technical Meeting 2021-07-27

Owned by Joachim Krech
Last updated: Jul 28, 2021 by Bill Fletcher
3 min read

Date

Jul 27, 2021

Attendees

Jonatan Antoni

Daniel Brondani

Eric Finco

Bill Fletcher

Ian Fyall

Mark Goodchild

Graham Hammond

Martin Kojtal

Joachim Krech

David Jurajda

David Noverraz

Petr Hradsky

 

Slides

 

 

Notes

JK: Any feedback on actions/outputs from last week? Looking for a dialogue in order to help this project to become successful.

EF: Now in the middle of the summer break so some people who could experiment are off. It’s going to take some time to get feedback.

DJ: “Include paths” generator could generate too many paths e.g. related to system libraries which are not necessary. Some paths are valid but not used in the pack. Missing differentiation how to describe association between particular include file and C or C++ compiler or assembler.

JK: Think we need to add this into the gap analysis. Please could you create a comment in Gap Analysis issue 10.

DB: Consider propagation of include path - something like private and public. Should it be just for one file or for all files in the project?

JK: Current scheme is that all includes are collected and applied to all modules. I guess main concern is conflicts.

DJ: Would start with global visibility. It’s good enough.

JK: But would completely separate between C, C++ and assembler.

DJ: Yes

Also would like to observe that header files are not usually owned by component but by whole pack. Would like to assign header files to a component. Some headers are present but not connected to a component (ie unused). Should we remove unused files from the pack?

JK: Any comments? Guess you would need to validate that they are actually unused. Personal view is it should be role for the pack validator to give a list of unused/unreferenced files.

DN: Hard to comment as don’t use this kind of technology currently.

JK: Should probably create an issue for the package validation (JK will take the action)

Presentation on CMSIS Zone

DN: Needs to be central repository to allow teams to see what resources have been allocated to them, but also need to allow a non-secure developer to take an unallocated resource but not de-allocate a resource.

JA: Has not been considered. Would need a mechanism to authenticate access.

DN: Need a way to allocate eg. a timer without reconfiguring the project.

JA: If 2 teams concurrently grab the same timer that wouldn’t work. Still need a central allocator.

PH: Is set of secure project determined only by the trust zone?

JA: Settings need to be programmed on the start of the first core. Security settings need to be known. Sub projects are only used to further partition using e.g. MPUs

DH: What’s the workflow with the files? Is there an interaction with the IDE?

JA: So far we didn’t integrate it with the build manager. It’s up to the user. Not so far integrated in CMSIS build

DN: Is CMSIS Zone a command line utility?

JA: Can run the generator from the command line. In the background it still drives the Java/Eclipse. It’s a draft implementation at that point to show how it could work. Need to discuss how to integrate into all the different tool set ups.

PH: Any connection to Trusted Firmware?

JA: Basically it sits on top. TF-M has a couple of configuration files that can be generated out of CMSIS Zone.

JK: Not fully aligned. TF-M has other ways to generate these files. All agree big challenge is in the user flows.

Should we have something indicating unused resources?

Common Hardware Descriptions

PH: What would consume this data?

JK: We’re exploring this for e.g. consuming resources or ensuring alignment. Also if the debugger would understand what are secure/non-secure areas it would me much simpler to understand what resources it can access and not fall over with errors.

May not be limited to trustzone. Can have different levels of debug permissions unrelated to trustzone.

EF: Think we should first focus on data format and how to manipulate it. Not necessary to have an exhaustive list of data. Can we have e.g. interoperability? What level of description can we afford? Can we end up only with SVD type of file.

JK: Need generate steps and hooks in the flow based on common data formats. Action JK to create a issue on GitHub.

Recording