Hi,

Today’s meeting minutes:

https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/

Notes/Minutes

Status updates

• Status update from Wayne regarding PR#22668
• No news.
• Status update from Thomas regarding IAR: Nothing new. regarding PR#22668
• Has been working on two routes: 
• CMake

• work has come fairly far.
• not able to build entire chain, but fairly close,

expect to hit same include files issue, as with using IAR IDE.

• IAR IDE

• Struggle with include file issue, as there are much gcc specific include (gcc assembly)

This will be hard to solve.

• IAR Linking

• IAR has --whole-archive support, so should not be an issue.
• Thomas has looked into linker script generation in other projects
• TF-M generates toolchain specific linker script.
  Those are based on toolchain specific templates.
• Mbed specific linker script for each toolchain.
• cmsis uses memory layer on target

There are attributes set per target regarding memory:

read-only

read-write

Settings are specified in an xml file

AP:

•  Nothing new

Short term goals:

• Toolchain test cases
• Test cases should not be ordinary Zephyr tests

Could be completely different test system with focus on:

• Optimization
• Linker
• archive
• Should test features that is known to be used inside Zephyr
• Determine what is most important to test / ensure support for.
• Needs to work with any toolchain, also out-of-tree toolchains.

Toolchain abstraction:

• Several choices in current Zephyr originates from the early KBuild solution, as example, the cross-compiler interface.
• Consider to drop compatibility to old legacy, in order to ease the process of going forward.
• Things was carried over from KBuild, without cleaning up
• Consider drop support for not-used features
• Support for toolchain files

• Current situation is that in order to add additional toolchain support, then there is a need to implement a lot of macros, even macros that is of no interest, and thus just empty.
• To improve:
  The toolchain abstraction interface must be improved. (Agreed by everyone)

• Note: It is still important to ensure the possibility of out-of-tree toolchains.
  Also, keep in mind there are users that are using the current toolchain abstraction interface.

Linker

• What Zephyr faces, is a common issue
• What have other done
• What Zephyr solves might be useful for others (generic solution)
• Step 1) Get it working for Zephyr, but have the generic support in mind.

Best regards

Torsten T. Rasmussen