Best practice for building firmware using Yocto

Question

I have a working Yocto build system based on the rocko branch that is generating images for an ARM-based target board. One of the chips on this board is a small ARM-based micro-controller that is separate to the main CPU. It needs to be loaded with a firmware image that I have to build.

It would be easy to make a recipe to build this microcontroller firmware. It requires an ARM cross compiler and then some special compiler options to control the code generation (for cortex-m4 + thumb etc). The trouble is, if I setup a normal recipe, it will assume that I'm building something for the target ARM architecture, which is a different type of ARM needing different code generation options. I can of course have the firmware Makefile override the cross-compile environment that is provided for the target system and have the Makefile just produce the binary firmware image.

But this will result in a package that is nominally for the target ARM architecture, but which contains a binary blob intended to be flashed onto a chip on the target board.

So my question is, how should I make a recipe for firmware that will execute on a totally different architecture to the MACHINE that the yocto build is ultimately for?

It seems like I need to create a recipe that builds specially for the micro-controller and is therefore different in some way to normal target recipes.

Bathy

Answer 1

Multiconfig may help you. One of the use case is that you want to build image for board which consists of FPGA and ARM core, this is somehow similar to your use case.

Quoting release notes of morty (2.2), it was introduced there:

Basic support for multi-configuration builds. For example, this enables building for more than one MACHINE at a time, which may be useful if you have a board with two separate SoCs on it, each with their own OS, but you want to target both in the same build.

I didn't try it yet, but the documentation for rocko is here: https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#platdev-building-targets-with-multiple-configurations

You basically define two machine configuration files, define them in BBMULTICONFIG variable and run bitbake with multiconfig:<configuration>: prefix for target when needed.

Saccharin

Answer 2

You need to create a bbclass, that will change the necessary variables for you, and inherit it in your recipe. Let's take as an example nativesdk.bbclass. Your newarch.bbclass file will look something like:

CLASSOVERRIDE = "class-newarch"
PACKAGE_ARCH = "newarch"
PACKAGE_ARCHS += "newarch"
TARGET_ARCH = "newarch"
TARGET_CC_ARCH = "newarch"
TARGET_LD_ARCH = "newarch"
TARGET_AS_ARCH = "newarch"
TARGET_CPPFLAGS = "..."
TARGET_CFLAGS = "..."
TARGET_CXXFLAGS = "..."
TARGET_LDFLAGS = "..."
CPPFLAGS = "..."
CFLAGS = "..."
CXXFLAGS = "..."
LDFLAGS = "..."

Neuroblast