Adding custom overlays to Yocto image

spasoye · December 7, 2023, 11:56am

Hello,
I started researching Yocto recently. I followed Toradex documentation and successfully added new packages to reference image, created and added new layers, but Im having problems adding new overlays to an image. This is how my layer currently looks like:
meta-customer_layer

device-tree-overlays_*.bbappend:

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

SRC_URI += "\
    file://aunit_tcm_overlay.dts \
    file://can-overlay.dts \
"

TEZI_EXTERNAL_KERNEL_DEVICETREE += "\
    aunit_tcm_overlay.dtbo \
    can-overlay.dtbo \
" 

TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT = "\
    aunit_tcm_overlay.dtbo \
    can-overlay.dtbo \
"

do_collect_overlays:prepend() {
    cp ${WORKDIR}/aunit_tcm_overlay.dts ${S}
    cp ${WORKDIR}/can-overlay.dts ${S}
}

After running bitbake device-tree-overlays it returns warning but no custom .dtbo are located in deploy folder:

This document didn’t help me much.

John1 · December 7, 2023, 12:14pm

Hi @spasoye,

I recommend using this name: device-tree-overlays_git.bbappend. A bbappend file has to have the name identical with the original recipe name, the only difference can be the version number (can be replaced with %).
You can use command bitbake-layers show-appends | grep <recipe-name> to verify your changes will be applied.

John1 · December 8, 2023, 12:36pm

I had to add two custom DST files to support my displays, so I did this in device-tree-overlays_git.bbappend:

FILESEXTRAPATHS:prepend := "${THISDIR}/linux-toradex-5.15-2.2.x/dts:"

TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:colibri-imx8x = "colibri-imx8x-custom-rgb_overlay.dtbo"

SRC_URI += " \
    file://colibri-imx8x-custom-rgb_overlay.dts;subdir=git/overlays \
    file://colibri-imx8x-custom-rgb-lvds_overlay.dts;subdir=git/overlays \
    file://display-97G084S3N2F2_overlay.dtsi;subdir=git/overlays \
    file://display-fg050720dsswdgt1_overlay.dtsi;subdir=git/overlays \
    file://Makefile;subdir=git/overlays \
"

Not sure if this is 100% correct way, but in the end, all requested dtbo files are created and deployed. The original Makefile was updated with those two *.dts files. Not sure if this step is necessary.

spasoye · December 8, 2023, 12:37pm

Thank @John1 this solved my problem.

lucas_a.tx · December 11, 2023, 8:00pm

Hi @spasoye ,

Glad your problem was solved. Thank you for your help @John1 !

Your initial overlay looks mostly correct @spasoye . Apart from using % instead of * for the bbappend version you should put an override in TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT as @John1 did e.g.

TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:colibri-imx8x

For reference, here’s how you can add overlays with mainline images (iMX6 and iMX7 SoMs):

device-tree-overlays-mainline_git.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/device-tree-overlays-mainline:"

CUSTOM_OVERLAYS_SOURCE = " \
    <custom_overlay1>.dts \
    <custom_overlay2>.dts \
"

CUSTOM_OVERLAYS_BINARY = " \
    <custom_overlay1>.dtbo \
    <custom_overlay2>.dtbo \
"

SRC_URI += " \
    file://<custom_overlay1>.dts \
    file://<custom_overlay2>.dts \
"

TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:use-mainline-bsp += " \
    ${CUSTOM_OVERLAYS_BINARY} \
"

do_collect_overlays:prepend() {

    for DTS in ${CUSTOM_OVERLAYS_SOURCE}; do
        cp ${WORKDIR}/${DTS} ${S}
    done

}

Best regards,
Lucas Akira

spasoye · December 20, 2023, 3:21pm

Where is the original device-tree-overlays recipe name defined ?

lucas_a.tx · December 20, 2023, 4:05pm

Hi @spasoye ,

You can find the device-tree-overlays recipe defined in meta-toradex-nxp:

linux « recipes-kernel - meta-toradex-nxp.git - Toradex BSP layer, recipes for NXP based modules

The overlays above are for the downstream kernel from NXP currently used in BSP 6 for our iMX8 SoMs.

For the upstream kernel we provide a different DT overlay recipe found in meta-toradex-bsp-common:

linux-toradex-mainline_git.bb « linux « recipes-kernel - meta-toradex-bsp-common.git - Toradex BSP layer, recipes common to all modules

And for the Verdin AM62 the overlays recipe is in meta-toradex-ti:

device-tree-overlays-ti_git.bb « linux « recipes-kernel - meta-toradex-ti.git - Toradex BSP layer, recipes for TI based modules

Hope this helps.

Best regards,
Lucas Akira

spasoye · December 20, 2023, 4:15pm

Thanks @lucas_a.tx

facundo.n.r · December 22, 2023, 4:13pm

Hi, I have one a question. How did you build binary file (.dtbo) ?

lucas_a.tx · December 22, 2023, 10:06pm

Hi @facundo.n.r ,

There are a couple of ways to build a device tree overlay:

You can use a build system like Yocto to build it for you as detailed in this thread;
If you’re using Torizon OS you can use TorizonCore Builder to build it for you;
You can manually build it with the kernel sources using Makefile or directly invoking dtc, the Device Tree Compiler.

The last two ways are explained in more detail in our developer site:

First Steps with Device Tree Overlays | Toradex Developer Center

Best regards,
Lucas Akira

spasoye · January 5, 2024, 12:57pm

Hello,
after vacation was over, I continued on this issue of customizing torizoncore image.
After flashing Verdin SoM with built Yocto image (i decided to build torizon-upstream-rt docker image) and connecting it to custom board no additional CAN interface (defined in my overlay) was visible in Linux. Same overlay .dtbo works fine when running on Torizoncore images pulled from Toradex artifactory built with torizoncore builder.
Serial console outputs:

mcp251xfd spi0.0 (unnamed net_device) (uninitialized): Failed to read Oscillator Configuration Register (osc=0xffffffff).

I decided to list files in /proc/device-tree/soc@0/bus@30800000/, this are the files listed on image built using torizoncore builder:

#address-cells   dma-controller@30bd0000  i2c@30a40000  mmc@30b60000  ranges           serial@30a60000  spi@30bb0000
#size-cells      ethernet@30be0000        i2c@30a50000  mu@30aa0000   serial@30860000  spi@30820000
compatible       i2c@30a20000             mmc@30b40000  name          serial@30880000  spi@30830000
crypto@30900000  i2c@30a30000             mmc@30b50000  phandle       serial@30890000  spi@30840000

And this are files listed on my Yocto built image:

'#address-cells'   dma-controller@30bd0000   i2c@30a40000       mmc@30b50000   ranges              spi@30bb0000
'#size-cells'      ethernet@30be0000         i2c@30a50000       mmc@30b60000   reg
 compatible        i2c@30a20000              mailbox@30aa0000   name           serial@30a60000
 crypto@30900000   i2c@30a30000              mmc@30b40000       phandle        spba-bus@30800000

Lots of node that are defined in .dts are missing in Yocto build among which is also spi@30820000 node used in additional CAN. What am I missing ?

lucas_a.tx · January 5, 2024, 5:05pm

Hi @spasoye ,

You are using a custom version of Torizon OS on a Verdin iMX8M Mini, is this correct?

I see that you’re building Torizon OS with the torizon-upstream-rt distro. Is there a specific reason you’re using the upstream version?

Currently for all our iMX8 SoMs by default we use the downstream kernel (torizon distro), and using the upstream distros for the iMX8M SoMs is considered experimental.

Can you check if the .dtbo file is actually present in your custom Torizon OS build? If the bbappend file is including your overlay in the downstream kernel, this could explain why you’re not seeing the overlay changes, since your custom image uses the upstream one.

Can you try building with a downstream distro e.g. torizon/torizon-rt and see if that works?

Best regards,
Lucas Akira

spasoye · January 10, 2024, 12:16pm

Sorry for the late reply, but I had some issues when trying to built new distro, I finally managed to build booth torizon_rt and torizon and I faced the same issue, /proc/device-tree is incomplete.

Booth *.dtbo’s * are present in /boot/ostree/torizon-e###/dtb/overlays.

spasoye · January 10, 2024, 2:52pm

Good news is that CAN overlay that was built by Yocto in my custom image, works when copied to official Toradex image.

henrique.tx · January 10, 2024, 3:49pm

Hi @spasoye !

What do you mean by /proc/device-tree is incomplete? Could you please specify?

That’s good. Have you checked the contents of overlays.txt?

So your overlay (.dtbo) works on a Reference Image from Toradex BSP but doesn’t work on the image you built yourself? That’s strange.

This fact makes me believe that you are performing some modification on your image (when compared to the Reference Image) that is making the overlay not work.

Could you please share the output of tdx-info -dt (reference: Getting Device Information with Tdx-Info | Toradex Developer Center) from your image and from the Reference Image with your overlay?

Best regards,

spasoye · January 11, 2024, 8:37am

This is something that I mentioned in previous post when I built torizon-upstream-rt distro, in short lots of device tree nodes that are defined in /proc/device-tree when I run official image (for example spi@30820000 used for MCP25xxFD IC interface, in my case) are missing when running my Yocto custom image.

Booth of the overlays are defined in overlays.txt and gets loaded in U-Boot.

Sure, here it is:

torizon@verdin-imx8mm-07213973:~$ sudo tdx-info -dt
Password: 

Device tree
------------------------------------------------------------
Device tree enabled:      imx8mm-verdin-nonwifi-dev.dtb
Compatible string:        toradex,verdin-imx8mm-nonwifi-devtoradex,verdin-imx8mm-nonwifitoradex,verdin-imx8mmfsl,imx8mm
Device trees available:
                          imx8mm-verdin-nonwifi-dahlia.dtb
                          imx8mm-verdin-nonwifi-dev.dtb
                          imx8mm-verdin-nonwifi-mallow.dtb
                          imx8mm-verdin-nonwifi-yavia.dtb
                          imx8mm-verdin-wifi-dahlia.dtb
                          imx8mm-verdin-wifi-dev.dtb
                          imx8mm-verdin-wifi-mallow.dtb
                          imx8mm-verdin-wifi-yavia.dtb
------------------------------------------------------------

Device tree overlays
------------------------------------------------------------
Overlays enabled:         fdt_overlays=aunit_tcm_overlay.dtbo can-overlay.dtbo
Overlays available:
                          aunit_tcm_overlay.dtbo
                          can-overlay.dtbo
------------------------------------------------------------

henrique.tx · January 18, 2024, 11:59am

Hi @spasoye!

Did you continue to investigate your issue? Do you have any news?

One thing that I could recommend you is to build your Torizon OS with only one specific change, which is your SPI/CAN overlay.

It really seems like some other change you might have done is causing the issue. The fact that the very same overlay works on a default Torizon OS from Toradex, but doesn’t work on your Yocto built Torizon OS is strange.

Also, a question from my side: for Torizon OS, we have Torizon Core Builder that allows you to deal with device tree [overlay] customization. Why would you need to use Yocto? Does your use case really require Yocto? I am asking this because, as you already saw, you have your device working with Torizon OS, so you wouldn’t need to spend time on Yocto

Best regards,

spasoye · January 18, 2024, 12:23pm

Hey @henrique.tx , I haven’t done any research since I posted this.
I’ve already implemented use of Torizon Core Builder in our development and releases, but we would like to implement some other tools in Torizon Core image we use in our robots, so other teams could do quick setup and testing of our hardware without the need of fiddling with containers.
We realized that we miss some basic tools like git, wget, can-utils, netcat, netstat and other tools that people on the field expect are installed without running the Docker.

Thanks

henrique.tx · January 18, 2024, 4:08pm

Hi @spasoye !

Thanks for sharing your use case.

I would like to share one idea that might release you from dealing with Yocto.

You could set up a user that when it performs the login via SSH, it drops inside a container that has all the setup done to access the necessary hardware and has all the software tools needed. This way it is even easier to maintain the OS and you would not need to deal with Yocto.

Wouldn’t such a method be suitable (and easier) for your use case?

Best regards,