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:
bitbake recipe adjustment - adding ICU library support to Console-trdx-image and using custom IUCdtxx.zip file - currently made in oe-core build, based on openembedded
customize Kernel configuration - removing unused features, adding new needed features - currently made in Kernel compilation, based on Build U-Boot and Linux kernel
customize Device tree, currently made in Kernel compilation
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
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
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:
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.
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
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…
