Re: support for multi instance zephyr in same soc

Carles Cufi

Hi Scott,


Yes, the whole “board” concept needs an overhaul to become instead “instances” or “targets” as you say.

In the nRF5340, which is a dual-core asymmetric Cortex-M33, we used “cpuapp” and “cpunet” to distinguish between the application core and the network core:




From: devel@... <devel@...> On Behalf Of Scott Branden via Lists.Zephyrproject.Org
Sent: 04 February 2020 02:23
To: Kumar Gala <kumar.gala@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] support for multi instance zephyr in same soc


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:
> Hello,
> 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....
> Regards,
>  Scott Branden

Join to automatically receive all group messages.