Linux image customisation

We are really new in Linux and embedded world and we are trying to find the right way, how to customize Linux image for our needs. The final product will use only Ethernet and I2C interface. No need for HMI. We need to customize:

  1. bitbake recipe adjustment - adding ICU library support to Console-trdx-image and using custom file - currently made in oe-core build, based on openembedded
  2. customize Kernel configuration - removing unused features, adding new needed features - currently made in Kernel compilation, based on Build U-Boot and Linux kernel
  3. customize Device tree, currently made in Kernel compilation
  4. customize Uboot - just to show some information we need, currently made in U-Boot compilation, based on same as point 2.

So our current workflow is:

  • generate oe-core image with customized ICU
  • extract oe-core image
  • compile custom Kernel and overwrite zImage file in extracted oe-core folder
  • compile custom Device tree and overwrite dtb file in extracted oe-core folder
  • customize rootfs structure in extracted oe-core folder (custom configs, kernel modules, applications…)
  • generate image for Colibri module using script - we are using tftp server for downloading image to Colibri module
  • compile custom U-Boot and overwrite U-Boot file generated in previous step
  • flash Linux image to Colibri module from tftp server.

So, what do you think about this scenario? Maybe we should move also Kernel customization to oe-core build?
Thank you for any comments to our setup.

IMHO you could also do the kernel and U-Boot customizations during build by applying patches upon the release kernel/U-Boot. You can create patches of your customizations and use them during build. In this way you can get a complete customized image which will save time during production programming. May be this article by @max.krummenacher would be really helpful.

thanks for tips, so maybe it will be nice to play with kernel outside oe-core and put final version of kernel to oe-core, also as mentioned in this forum

I recommend watching our webinar about building a custom image with the our OE-core build system.

It sounds like you’re on the right track. Building the kernel outside of OE-core is fine and may be easier and less error prone since you’ll have more control over the steps used to build the kernel. However, you can easily shift your development or maintenance of the kernel to OE-core. You just need to be careful using bitbake -c menuconfig virtual/kernel because the changes made to .config are not permanent - they may be overwritten by bitbake if it chooses to re-do_configure (or similar). Therefore, I’d recommend either generating a patch for the defconfig or an completely new defconfig. This can be done from within or outside of OE-core.

To generate the defconfig the standard way (outside of OE-core), you’d do:

make [name of defconfig target]
make menuconfig
make savedefconfig

To generate the defconfig within oe-core, you’d do:

bitbake -c menuconfig virtual/kernel
bitbake -c savedefconfig virtual/kernel

Then you can generate a patch by diffing the new defconfig with the old one. The patch can then be incorporated into the kernel recipe. Alternatively, you can use the new defconfig in place of the original.

Thank you Brandon for nice explanation.
I have watched your webinars yesterday and it helps a lot (good job guys!), so I’m going to try to implement all the recommendations.

I have found many defconfig files in stuff/ directory, and these two looks to be related to our Colibri-VF50 module:



Which defconfig is the right one to customize?

It depends of your preferred provdier for vitual/kernel.
To be sure that bitbake will use stuff/meta-toradex/recipes-kernel/linux/linux-toradex-4.1/defconfig, just add PREFERRED_PROVIDER_virtual/kernel = “meta-toradex” to your local.conf.

But the best way is to create your own meta with a linux-toradex-4.1.bbappend and to specify the path to your own defcong that should be in the directory files just beside you .bbapend

@VincentB I don’t think that this is right. Afaict, PREFERRED_PROVIDER_virtual/kernel expects a recipe as value, not a layer…

See also


This depends on the layer priority and in which order the recipes/bbappends get applied. In this case, the meta-toradex layer has a higher priority than meta-fsl-arm-extra (see conf/layer.conf). Therefor the defconfig in meta-toradex will take precedence over the one in meta-fsl-arm-extra.

If you add another layer for your changes, you typically would set the priority above meta-toradex, to make sure that your layer takes precedence over meta-toradex again.

Note that this only affects recipe with the same name (in this case “linux-toradex”). You can also create a new recipe (linux-mylinux) and use PREFERRED_PROVIDER_virtual/kernel = “linux-mylinux” in your local.conf to select your kernel recipe…