Open-CMSIS-Pack Technical Meeting 2022-01-18

Date

Jan 18, 2022

Participants

Jonatan Antoni

Kyle Dando

Maxime Dortel

Eric Finco

Bill Fletcher

Samuel Hultgren

Reinhard Keil

Joachim Krech

Laurent Meunier

Charles Oliveira

Cartu38 Opendev

Frederic Ruelle

Daniel Brondani

David Jurajda

Pascale MONDOLONI

Slides

Notes

DJ: There was a working group devoted to a common device API - is this still a parallel development?

RK: Discussing in Arm to restart this and a colleague should reach out about this. Our view that common device interfaces and CMSIS go hand in hand.

Digital Signing

FR: just to mention that all this would be optional : the tool could be configured to be permissive. Could log a revocation date and say what is signed before this date (via signing date) is valid. How often would we change the public keys - validity is 3 years. Don’t know if it’s necessary to remove it.

Release would be configurable - how permissive.

CO: Have some levels of warnings.

FR: we could have cpackget --ignore-validity-date

cpackget --ignore-ownership

...etc...

RK: Where could root CA be stored? Could certificate be provided with pack index.

FR: Public but can’t allow someone to change it easily. Could store it with all root certificates stored on your machine e.g. Windows OR binary for cpackget OR or easy (or not) for the user to add. Root CA can be signed by a real CA to show it really comes e.g. from Arm. Know that e.g. Microsoft is using this very extensively.

CMSIS Project Manager

EF: Is it redundant to have a target type and board layer?

RK: Target type allows to select which board. Then need to think about integration into IDE. People want to create projects against an eval board or product hardware. Type name is up to the user (label). Device needs to be a valid board (ID).

LM: Asked for having Arm specific extensions for .pdsc file . Do you see possible need for Visual Studio or others?

RK: Think this is the next step.

LM: Would there be the same extensions/opportunities in the yaml files?

DB: In yaml we have schemas and versions which might not be backward compatible but prefer to keep compatibility when adding to the schema. Already a PR open for a proposal.

JK: Can have sections which are being ignored - only specific tools would understand them?

RK: Section that perhaps starts with vendor: and then completely up to e.g. ST to define. Need to look into it.

LM: Preferable to adding data in other sections.

DB: Can add all the vendors in the schema but if it’s really custom should be maintained by the vendor. One way would be for the vendor could take generic schema and add the fields - use that to validate the file.

Wrap Up

Actions all:
- Provide review feedback
- Suggest topics for next week’s agenda