Re: support for multi instance zephyr in same soc

Marc Herbert

Interesting, some parts of the documentation gave me the (wrong?) impression that a BOARD allowed some level of variation and configuration at build time:
- "Optional DTS format files which override BOARD.dts"
- "Extensible with DTS_ROOT"
- "This default board configuration is subordinated to features activation which is application responsibility..."
- "... the board’s default Kconfig configuration, which is used in application builds unless explicitly overridden."


On 3 Feb 2020, at 17:22, Scott Branden <sbranden@...> wrote:

Thanks Kumar - we will go with this convention for naming the target. ie board_cpu.
It will work out as long as there are not multiple cpu's on the same board that need different zephyr builds.
At that point you would need board_cpu_n

Really "boards" directory should be renamed "targets"?

On Sun, Feb 2, 2020 at 9:01 AM Kumar Gala <kumar.gala@...> wrote:
This has been a long standing issue. Since these are both ARM you can get away with doing something similar to how we handle building different images for SoCs that have 2 different M-class cores.

Look at boards/arm/lpcxpresso54114 for an example

- k

On Jan 30, 2020, at 3:17 PM, Scott Branden <sbranden@...> wrote:


We are currently running zephyr on M7 and linux on A72.

The base M7 support has been upstreamed here:

We are now looking at running Zephyr on A72 instead of linux.

But it doesn't look like Zephyr build system will work if we name the board name the same for each CPU ?

Any suggestions on how to name and add support for 2 different instances of Zephyr running on the same board?

In our case: something that might easily achieve this is if upcoming arm64 support was not put under boards/arm but under boards/arm64 and ARCH=arm64 used instead of ARCH=arm....

Scott Branden

Join to automatically receive all group messages.