[meta-zephyr] Issues and possible solutions

[meta-zephyr] Issues and possible solutions

[Eilís Ní Fhlannagáin]

Following on from Bartosz's recent patch, Naveen suggested I take this
to the list. We've been recently discussing some of the drawbacks of
meta-zephyr between myself, Diego Sueiro and Jon Mason at ARM and
Bartosz Golaszewski and we've come up with a few ideas we want to
propose. (Diego, Jon, Bartosz, please add anything I may have missed
from my notes)

The main issues we've seen with the layer are:

1. No separation of BSP layer and functionality.
2. Limited machine support.
3. Kernel SRC_URI is incomplete.
4. Needing to maintain two sets of build information/configuration.

I'd like to propose a few solutions to this and get your thoughts and
feedback before we go further.

First, I would like to refactor the layer into a slightly different setup:

meta-zephyr
  |-meta-zephyr-bsp
  |-meta-zephyr-core
  |-meta-zephyr-west

Where:
meta-zephyr-bsp: contains MACHINE configs and base kernel recipes and
nothing more.
meta-zephyr-core: contains images (zephyr-hello-world.bb, etc),
classes, and nativesdk bits.
meta-zephyr-west: contains a west build implementation and additions
to the sdk needed for this.

There are a few reasons why I'm proposing this.

meta-zephyr-bsp:
For YP compatibility we really should be splitting bsp layers out from
core functionality.

Secondly, I've been working on a meta-zephyr-bsp layer that contains
285 machine configurations autogenerated from zephyr. You can view the
layer here https://booting.oniroproject.org/distro/meta-zephyr-bsp and
the patch to zephyr I use to generate these here
https://booting.oniroproject.org/distro/meta-zephyr-bsp/-/blob/dunfell/recipes-core/meta/files/0001-zephyr-Export-an-OpenEmbedded-machine-config.patch.
It's missing some bits, specifically around do_flash_usb, but it gets
us many more machines than what we currently have. (keep in mind, this
is dunfell and zephyr v2.6.0 atm)

I also want to split out the base kernel bits (zephyr-kernel*) into
the bsp layer and move all the "image" recipes like zephyr-blinky, etc
into meta-zephyr-core/meta-zephyr-core/recipes-core/images.

meta-zephyr-west:
We need to do a lot of MACHINE_OVERRIDES with ZEPHYR_MODULES. Short of
tracking all of this (which is a maintenance nightmare), or generating
them from KConfigs, the only way Diego and I have figured out how to
do this is to offload that onto zephyr itself.

One way we've looked at this is that we can do it via a west.bbclass
where bitbake need not know anything about the oecmake flags, it just
essentially shells out and runs west. Modifying the Kconfigs is done
via menuconfig as usual. Doing this avoids the need to do all those
overrides and track every single module in zephyr (or not in zephyr
even). As well, those MACHINE_OVERRIDES have no knowledge of what is
in the Kconfig, so this would allow us to detangle some of that.

Both Diego and I have come up with a solution for this (mine bbclass
based, Diego doing do_compile overrides directly in the recipe). My
thought would be extending the meta-zephyr layer with a
meta-zephyr-west layer inside that would allow people to use both the
CMAKE way of building zephyr or the west way, depending on their needs
but we're open for some suggestions/ideas.

-b