DJ points out the script is in evaluation stage but already gives good results.
DJ walks through the reports generated by the script, see example output in GitHub next to the script.
JK asks how DJ expects people to use this script. There is no component focus, yet.
DJ prepared the script with a general purpose usage in the first place. But mapping data to components should be possible.
RK suggests to look into the lwIP pack that is already available. Taking this pack as an example might help to evaluate how this script can help creating such kind of packs.
EF asks if we shall combine tools at some point or keep them separate.
RK don’t want to judge on this. It might be challenging to integrate C++- and Python-based tools, easily. But it might be useful to add some hook-mechanism to PackChk to add external scripts into the PackChk process.
JK adds that the main focus should be accessability of such tools, i.e. the tools needs to be ease to use.
DJ points out the usage of YAML format for the reports. To his view this makes it fairly readable to humans while having it fully processable by scripts.
JK moves on into the CMSIS-Zone Methodology.
DN comments that the presented methodology maps well to a single trutz zone device. He concerns that the same might become very complex when it comes to multi-core devices with potentially multiple trust zone contexts. I.e. when parts of such a complex system are maintained by different people/teams distributed over the organization. How can one manage consistency across such a team setup.
RK explains the CMSIS-Zone approach of distributing system resources (i.e. rzone) into multiple project resources (i.e. azone’s).
DN is keen from a user point of view how to simplyfy this process.
RK agrees the complexity should be handled by the tool.
PH advertises that NXP already provides a tool to configure trust zone in terms of memory layout and security features.
RK points out the aim of Open-CMSIS-Pack project is to allow reuse of software components, for example a boot loader. The constraints and requirements of such a component needs to be integrated with all the different partner tools and devices.
JK takes focus to standardization vs. differentiation.
EF suggest to split the boxes .
JK concludes that we might need a “Common Project Framework”.