Device Tree Overlays

I am attempting to build a Yocto Project image for verdin-imx8mp. When building device-tree-overlays-toradex I am getting the following error:

ERROR: device-tree-overlays-toradex_5.15-2.0.x-imx+gitAUTOINC+d5a5823508-r0 do_deploy: verdin-imx8mp_hdmi_overlay.dtbo is not installed in your boot filesystem, please make sure it's in TEZI_EXTERNAL_KERNEL_DEVICETREE or being provided by virtual/dtb.

However, TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT is being set in machine configuration file. It’s all Toradex stock stuff:

Build Configuration:
BB_VERSION           = "2.0.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-tswp-linux"
MACHINE              = "verdin-imx8mp"
DISTRO               = "tsweighpoint"
DISTRO_VERSION       = "1.0"
TUNE_FEATURES        = "aarch64 armv8a crypto"
TARGET_FPU           = ""
meta                 
meta-poky            = "kirkstone:24a3f7b3648185e33133f5d96b184a6cb6524f3d"
meta-oe              
meta-multimedia      
meta-networking      
meta-python          = "kirkstone:744a4b6eda88b9a9ca1cf0df6e18be384d9054e3"
meta-qt6             = "dev:e950cff143165c5dacbf7bb400c03c53a1fc0c44"
meta-freescale       = "kirkstone:c15bd05a1e94b2329b051cb7672a46c8eef69ef6"
meta-freescale-3rd-party = "kirkstone:6d8213fc5ec192c33f963b8095d1f01af1574eea"
meta-toradex-bsp-common = "kirkstone-6.x.y:ca5ce278e2baa20b50ab5ce7b6a0f5a2d8898e4d"
meta-toradex-nxp     = "kirkstone-6.x.y:9e006dccef9e22a430ab56b765420b13f532c56a"

Looking at the bitbake environment shows that the variable TEZI_EXTERNAL_KERNEL_DEVICETREE is not set:

$ MACHINE="verdin-imx8mp"  bitbake -e device-tree-overlays  |grep EXTERNAL_KERNEL_DEVICETREE

# $TEZI_EXTERNAL_KERNEL_DEVICETREE
TEZI_EXTERNAL_KERNEL_DEVICETREE=""
# $TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT [3 operations]
TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT="verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo"
# $TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:use-mainline-bsp
TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:use-mainline-bsp="verdin-imx8mp_spidev_overlay.dtbo"

What is broken?

Hi @RudolfStreif

I cannot reproduce this using either our default.xml or integration.xml manifests. (docs are here but not yet updated for BSP 6).

Can you elaborate on how you created your layer collection?

Also, does your custom DISTRO include the Toradex distro settings?

Drew

Hi @drew.tx,

Thank you. Using the distro settings from meta-toradex-distro solved the problem.

However, graphics does not work. There is no graphics output on the HDMI ports, neither the native one nor the one with the Toradex DSI-to-HDMI adapter board on the Verdin dev board. dmesg shows no video driver output at all. I suppose there is a DT overlay missing. However, overlays.txt contains:

fdt_overlays=verdin-imx8mp_native-hdmi_overlay.dtbo verdin-imx8mp_lt8912_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo

Hi @RudolfStreif

Glad to hear you got past the build problem.

As for the HDMI issue, the first question is do the standard Toradex reference image builds and/or Easy Installer show anything on HDMI? This is outside of my expertise but my colleague @henrique.tx may have more insight.

Drew

Thank you, Drew.

What actually is the Toradex standard image? There are no image recipes in meta-toradex-distro (where I would expect them). There are also none in meta-toradex-bsp-common and meta-toradex-nxp.

in meta-toradex-bsp there is a class called image_type_tezi.bbclass. I am not sure what that is (have not looked at the code) and if it is required to build a working image.

Thank you.

I was referring to the prebuilt binary images that are installed via our Toradex Easy Installer. Basically, you put the device in recovery mode and then load a bootable image into the RAM of the SOM from your PC. This then boots into a GUI allowing installation of images in the TEZI format.

Normally our boards come with the Easy Installer image installed by default so you don’t need to deal with recovery mode or any of that complexity but it sounds like your board already had something installed and you jumped right into the custom Yocto build. I’d encourage you to first try the Easy Installer method before dealing with a custom build.

That said, if you want to do a custom build of our standard images you can follow the instructions here to build the tdx-reference-minimal-image recipe.

Drew

Ah, OK. Well yes, the prebuilt binaries work just fine. I had tested with those two weeks ago. But now I need to make the images work that I build myself.

When I am running a prebuilt binary the device tree looks like this:

root@verdin-imx8mp-07321142:/sys/firmware/devicetree/base# ls -l
total 0
-r--r--r--  1 root root  4 Nov  1 00:01 '#address-cells'
-r--r--r--  1 root root  4 Nov  1 00:01 '#size-cells'
drwxr-xr-x  2 root root  0 Nov  1 00:01  __symbols__
drwxr-xr-x  2 root root  0 Nov  1 00:01  aliases
drwxr-xr-x  2 root root  0 Nov  1 00:01  backlight
drwxr-xr-x  2 root root  0 Nov  1 00:01  backlight-mezzanine
drwxr-xr-x  2 root root  0 Nov  1 00:01  busfreq
drwxr-xr-x  2 root root  0 Nov  1 00:01  chosen
drwxr-xr-x  2 root root  0 Nov  1 00:01  clock-ext1
drwxr-xr-x  2 root root  0 Nov  1 00:01  clock-ext2
drwxr-xr-x  2 root root  0 Nov  1 00:01  clock-ext3
drwxr-xr-x  2 root root  0 Nov  1 00:01  clock-ext4
drwxr-xr-x  2 root root  0 Nov  1 00:01  clock-osc-24m
drwxr-xr-x  2 root root  0 Nov  1 00:01  clock-osc-32k
-r--r--r--  1 root root 97 Oct 31 23:52  compatible
drwxr-xr-x  8 root root  0 Nov  1 00:01  cpus
drwxr-xr-x  2 root root  0 Nov  1 00:01  display-subsystem
drwxr-xr-x  4 root root  0 Nov  1 00:01  etf@28c04000
drwxr-xr-x  3 root root  0 Nov  1 00:01  etm@28440000
drwxr-xr-x  3 root root  0 Nov  1 00:01  etm@28540000
drwxr-xr-x  3 root root  0 Nov  1 00:01  etm@28640000
drwxr-xr-x  3 root root  0 Nov  1 00:01  etm@28740000
drwxr-xr-x  3 root root  0 Nov  1 00:01  etr@28c06000
drwxr-xr-x  4 root root  0 Nov  1 00:01  funnel
drwxr-xr-x  4 root root  0 Nov  1 00:01  funnel@28c03000
drwxr-xr-x  3 root root  0 Nov  1 00:01  gpio-keys
drwxr-xr-x  2 root root  0 Nov  1 00:01  gpu2d@38008000
drwxr-xr-x  2 root root  0 Nov  1 00:01  gpu3d@38000000
drwxr-xr-x  3 root root  0 Nov  1 00:01  hdmi-connector
drwxr-xr-x  2 root root  0 Nov  1 00:01  i2c-rpbus-3
-r--r--r--  1 root root  4 Nov  1 00:01  interrupt-parent
drwxr-xr-x  2 root root  0 Nov  1 00:01  memory@40000000
drwxr-xr-x  2 root root  0 Nov  1 00:01  mix_gpu_ml
-r--r--r--  1 root root 54 Nov  1 00:01  model
-r--r--r--  1 root root  1 Nov  1 00:01  name
drwxr-xr-x  5 root root  0 Nov  1 00:01  opp-table
drwxr-xr-x  2 root root  0 Nov  1 00:01  panel-lvds
drwxr-xr-x  3 root root  0 Nov  1 00:01  panel-lvds-mez
drwxr-xr-x  2 root root  0 Nov  1 00:01  pmu
drwxr-xr-x 21 root root  0 Nov  1 00:01  power-domains
drwxr-xr-x  2 root root  0 Nov  1 00:01  psci
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-1p8v
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-3p3v
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-5p0v
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-eth2phy
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-module-eth1phy
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-usb1-vbus
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-usb2-vbus
drwxr-xr-x  2 root root  0 Nov  1 00:01  regulator-usdhc2
drwxr-xr-x  3 root root  0 Nov  1 00:01  reserved-memory
drwxr-xr-x  2 root root  0 Nov  1 00:01  sai-mclk1
drwxr-xr-x  2 root root  0 Nov  1 00:01  sai-mclk2
drwxr-xr-x  2 root root  0 Nov  1 00:01  sai-mclk3
drwxr-xr-x  2 root root  0 Nov  1 00:01  sai-mclk5
drwxr-xr-x  2 root root  0 Nov  1 00:01  sai-mclk6
drwxr-xr-x  2 root root  0 Nov  1 00:01  sai-mclk7
-r--r--r--  1 root root  9 Oct 31 23:52  serial-number
drwxr-xr-x 19 root root  0 Oct 31 23:52  soc@0
drwxr-xr-x  4 root root  0 Nov  1 00:01  sound-card
drwxr-xr-x  2 root root  0 Nov  1 00:01  sound-hdmi
drwxr-xr-x  4 root root  0 Nov  1 00:01  thermal-zones
drwxr-xr-x  2 root root  0 Nov  1 00:01  timer
-r--r--r--  1 root root  6 Nov  1 00:01  toradex,board-rev
-r--r--r--  1 root root  5 Oct 31 23:52  toradex,product-id
drwxr-xr-x  2 root root  0 Nov  1 00:01  vipsi@38500000
drwxr-xr-x  2 root root  0 Nov  1 00:01  vpu_g1@38300000
drwxr-xr-x  2 root root  0 Nov  1 00:01  vpu_g2@38310000
drwxr-xr-x  2 root root  0 Nov  1 00:01  vpu_v4l2
drwxr-xr-x  2 root root  0 Nov  1 00:01  vpu_vc8000e@38320000

When I am building the system with the Toradex layers, the device tree looks like this:

root@tswp:/sys/firmware/devicetree/base# ls -l
total 0
-r--r--r--  1 root root  4 Oct 31 23:56 '#address-cells'
-r--r--r--  1 root root  4 Oct 31 23:56 '#size-cells'
drwxr-xr-x  2 root root  0 Oct 31 23:56  __symbols__
drwxr-xr-x  2 root root  0 Oct 31 23:56  aliases
drwxr-xr-x  2 root root  0 Oct 31 23:56  backlight
drwxr-xr-x  2 root root  0 Oct 31 23:56  backlight-mezzanine
drwxr-xr-x  2 root root  0 Oct 31 23:56  chosen
drwxr-xr-x  2 root root  0 Oct 31 23:56  clock-ext1
drwxr-xr-x  2 root root  0 Oct 31 23:56  clock-ext2
drwxr-xr-x  2 root root  0 Oct 31 23:56  clock-ext3
drwxr-xr-x  2 root root  0 Oct 31 23:56  clock-ext4
drwxr-xr-x  2 root root  0 Oct 31 23:56  clock-osc-24m
drwxr-xr-x  2 root root  0 Oct 31 23:56  clock-osc-32k
-r--r--r--  1 root root 97 Oct 31 23:56  compatible
drwxr-xr-x  7 root root  0 Oct 31 23:56  cpus
drwxr-xr-x  3 root root  0 Oct 31 23:56  gpio-keys
-r--r--r--  1 root root  4 Oct 31 23:56  interrupt-parent
drwxr-xr-x  2 root root  0 Oct 31 23:56  memory
-r--r--r--  1 root root 54 Oct 31 23:56  model
-r--r--r--  1 root root  1 Oct 31 23:56  name
drwxr-xr-x  5 root root  0 Oct 31 23:56  opp-table
drwxr-xr-x  2 root root  0 Oct 31 23:56  pmu
drwxr-xr-x  2 root root  0 Oct 31 23:56  psci
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-1p8v
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-3p3v
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-5p0v
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-eth2phy
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-module-eth1phy
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-usb1-vbus
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-usb2-vbus
drwxr-xr-x  2 root root  0 Oct 31 23:56  regulator-usdhc2
drwxr-xr-x  3 root root  0 Oct 31 23:56  reserved-memory
-r--r--r--  1 root root  9 Oct 31 23:56  serial-number
drwxr-xr-x 17 root root  0 Oct 31 23:56  soc@0
drwxr-xr-x  4 root root  0 Oct 31 23:56  thermal-zones
drwxr-xr-x  2 root root  0 Oct 31 23:56  timer
-r--r--r--  1 root root  6 Oct 31 23:56  toradex,board-rev
-r--r--r--  1 root root  5 Oct 31 23:56  toradex,product-id

Clearly, a lot of the device tree nodes are missing. The question is why? I did not modify the device tree.

Update:

When I boot the binary reference image the u-boot log shows the DT and overlays being loaded as follows:

Found U-Boot script /boot.scr
5964 bytes read in 0 ms
## Executing script at 50280000
Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
89137 bytes read in 2 ms (42.5 MiB/s)
120 bytes read in 1 ms (117.2 KiB/s)
Applying Overlay: verdin-imx8mp_native-hdmi_overlay.dtbo
2219 bytes read in 1 ms (2.1 MiB/s)
Applying Overlay: verdin-imx8mp_lt8912_overlay.dtbo
3165 bytes read in 1 ms (3 MiB/s)
Applying Overlay: verdin-imx8mp_spidev_overlay.dtbo
561 bytes read in 1 ms (547.9 KiB/s)

When I boot what I built from the Toradex layers, the DT and overlays are:

Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
57094 bytes read in 2 ms (27.2 MiB/s)
47 bytes read in 0 ms
Applying Overlay: verdin-imx8mp_spidev_overlay.dtbo
561 bytes read in 2 ms (273.4 KiB/s)

Essentially, the overlays for the graphics are not being loaded.

Update 2:

More digging revealed that the overlays.txt file is different:

  • binary reference image: dt_overlays=verdin-imx8mp_native-hdmi_overlay.dtbo verdin-imx8mp_lt8912_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo
  • built image: fdt_overlays=verdin-imx8mp_spidev_overlay.dtbo

Now, changing the overlays.txt file does not solve the problem. On boot:

Found U-Boot script /boot.scr
5964 bytes read in 1 ms (5.7 MiB/s)
## Executing script at 50280000
Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
57094 bytes read in 2 ms (27.2 MiB/s)
120 bytes read in 0 ms
Applying Overlay: verdin-imx8mp_native-hdmi_overlay.dtbo
2219 bytes read in 1 ms (2.1 MiB/s)
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
Applying Overlay: verdin-imx8mp_lt8912_overlay.dtbo
3165 bytes read in 1 ms (3 MiB/s)
failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@
Applying Overlay: verdin-imx8mp_spidev_overlay.dtbo
561 bytes read in 1 ms (547.9 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@

The base DTB (verdin-imx8mp-nonwifi-dev) is different from the reference image to the built image. The reference image has a much larger base DTB.

I would appreciate if somebody could explain how to build a working Yocto image with the Toradex layers.

Apparently, I have been building the linux-toradex-mainline kernel (IMX_DEFAULT_BSP = “mainline”) which does not support the video DT overlays. I switched to the linux-toradex kernel (IMX_DEFAULT_BSP = “nxp”). Now the device tree overlays for the video are loaded:

## Executing script at 50280000
Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
88803 bytes read in 2 ms (42.3 MiB/s)
120 bytes read in 1 ms (117.2 KiB/s)
Applying Overlay: verdin-imx8mp_native-hdmi_overlay.dtbo
2219 bytes read in 1 ms (2.1 MiB/s)
Applying Overlay: verdin-imx8mp_lt8912_overlay.dtbo
3165 bytes read in 2 ms (1.5 MiB/s)
Applying Overlay: verdin-imx8mp_spidev_overlay.dtbo
561 bytes read in 2 ms (273.4 KiB/s)
11628295 bytes read in 124 ms (89.4 MiB/s)

However, when the kernel boots it is stuck in an endless loop repeating these messages:

[    3.247503] dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
[    3.258354] dwhdmi-imx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
[    3.267217] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops)
[    3.275233] imx-drm display-subsystem: bound imx-lcdifv3-crtc.1 (ops lcdifv3_crtc_ops)
[    3.283312] imx_sec_dsim_drv 32e60000.mipi_dsi: version number is 0x1060200
[    3.290319] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    3.301999] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    3.310276] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517

The Yocto Project build uses the following configuration:

Build Configuration:
BB_VERSION           = "2.2.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-tswp-linux"
MACHINE              = "verdin-imx8mp"
DISTRO               = "tsweighpoint"
DISTRO_VERSION       = "1.0"
TUNE_FEATURES        = "aarch64 armv8a crypto"
TARGET_FPU           = ""
meta                 
meta-poky            = "master:78fd269e6649000b48ef1ef3e86009bad00fa815"
meta-oe              
meta-multimedia      
meta-networking      
meta-python          = "master:3f20244401feb6975a9c35193d6cda4946c844c8"
meta-qt6             = "dev:e950cff143165c5dacbf7bb400c03c53a1fc0c44"
meta-freescale       = "master:66d738d4ab1270c2e87f5afabc085bdff205e5ac"
meta-freescale-3rd-party = "master:070f5cc7b5a29ee98899be134f24f338b59770ff"
meta-toradex-bsp-common = "master:2555ba876dc5ed366e2f705601d770febeb6cfbb"
meta-toradex-nxp     = "master:8c8aafd57b9f8418d4ca30357e8a86676345038e"
meta-toradex-distro  = "master:d24f167561ea513eba515286cb990d811ba7aa56"

This has been unexpectedly frustrating. Unfortunately, there seems to be no documentation on how to build a working system with the Yocto Project layers. If the master branch is broken there should be some info what branches/commits actually work.

I’m having the same issue.

We’re using meta-toradex-torizon as Base DEPENDS layer for our custom layer. (In this layer we have only custom recipes that has nothing to do with MACHINE type, BSP or DTBs)

Hi @RudolfStreif !

Actually, the recipes for the Reference Images of Toradex’s BSPs are placed in meta-toradex-demos/recipes-images/images. There you will find the tdx-reference-minimal-image.bb and tdx-reference-multimedia-image.bb. The reference images are a good inspiration to build your own image.

AFAIK, it is not actually mandatory but helps a lot because it packs the resulting image in a way that you can install it using Toradex Easy Installer.

I am downloading right the BSP 6 layers to give it a shot.

I will update here as soon as I have news.

Best regards,
Henrique

@henrique.tx,

Thank you for your response. I eventually was able to identify a configuration that allowed me to build images for the Verdin Mini and Verdin Plus modules with video support.

I am going a little more into the details just in case others run into the same problems.

To enable video the following device tree overlays are necessary:

  • Verdin Mini:
    • verdin-imx8mm_lt8912_overlay.dtbo (Verdin Mini has MIPI DSI output. The overlay enables the Lontium MIPI DSI-to-HDMI video bridge on the Toradex Verdin DSI to HDMI adapter.)
  • Verdin Plus:
    • verdin-imx8mp_native-hdmi_overlay.dtbo (enables the built-in HDMI on the i.MX8M Plus SoC)
    • verdin-imx8mp_lt8912_overlay.dtbo (enables the Lontium MIPI DSI-to-HDMI video bridge on the Toradex Verdin DSI to HDMI adapter.)

The overlay are applied by u-boot after it loads the base device tree e.g. imx8mm-verdin-wifi-dev.dtb. For that to work the base device tree needs to have the nodes that the overlay extends/modifies already defined, for instance, overlay defines &hdmi_lontium_lt8912 { … }; and hence the base device tree needs to contain hdmi_lontium_lt8912.

The Toradex kernel tree repos contain the base device tree but the overlays are in a different repo and are built by the YP recipe linux-device-tree-overlays from a different repo. Consequently, the kernel tree repo and the overlay repo have to match.

Furthermore, the Bitbake variable TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT defines what device tree overlays are going to be applied by u-boot. The content of the variable is placed into the file overlays.txt in the boot partition as a u-boot environment variable assignment e.g. fdt_overlays=verdin-imx8mm_lt8912_overlay.dtbo verdin-imx8mm_spidev_overlay.dtbo. The Bitbake variable TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT is set in the machine file.

Hence, three things have to match otherwise it won’t work:

  • Linux kernel tree repo
  • Overlay repo
  • TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT

There are two versions of kernel tree repos being used:

  • Derived from the NXP kernel: linux-toradex
  • Derived from the kernel.org kernel: linux-toradx mainline

The variable IMX_DEFAULT_BSP chooses the kernel tree:

  • nxp → linux-toradex
  • mainline → linux-toradex-mainline

The catch is that the mainline kernel does not support the video overlays. The base device tree does not contain the necessary nodes. The Toradex distro configurations set the IMX_DEFAULT_BSP variable. The default is mainline.

Using the master branch on meta-toradex-nxp (together with the master branch of meta-toradex-bsp-common and meta-toradex-distro) with IMX_DEFAULT_BSP = "nxp" will lead to a successful build, however, there seems to be an issue with the imx_sec_dsim_drv driver as it fails to attach the bridge and ends up in an endless loop.

Using this configuration

Build Configuration:
BB_VERSION           = "2.0.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-tswp-linux"
MACHINE              = "verdin-imx8mm"
DISTRO               = "tsweighpoint"
DISTRO_VERSION       = "1.0"
TUNE_FEATURES        = "aarch64 armv8a crc cortexa53"
TARGET_FPU           = ""
meta                 
meta-poky            = "kirkstone:2e79b199114b25d81bfaa029ccfb17676946d20d"
meta-oe              
meta-multimedia      
meta-networking      
meta-python          = "kirkstone:744a4b6eda88b9a9ca1cf0df6e18be384d9054e3"
meta-qt6             = "dev:e950cff143165c5dacbf7bb400c03c53a1fc0c44"
meta-freescale       = "master:66d738d4ab1270c2e87f5afabc085bdff205e5ac"
meta-freescale-3rd-party = "master:070f5cc7b5a29ee98899be134f24f338b59770ff"
meta-toradex-bsp-common = "kirkstone-6.x.y:ca5ce278e2baa20b50ab5ce7b6a0f5a2d8898e4d"
meta-toradex-nxp     = "kirkstone-6.x.y:9e006dccef9e22a430ab56b765420b13f532c56a"
meta-toradex-distro  = "kirkstone-6.x.y:d80a3f9992c87f61228498286db89dd33f5be592"

works if the TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT is explicitly overridden:

TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:verdin-imx8mp = "verdin-imx8mp_native-hdmi_overlay.dtbo verdin-imx8mp_lt8912_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo"
TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:verdin-imx8mm = "verdin-imx8mm_lt8912_overlay.dtbo verdin-imx8mm_spidev_overlay.dtbo"

The reason is that the git version of linux-device-tree-overlays has been bumped and the newer commit changes the names of the overlay files, however the variable TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT has not been changed accordingly.

I was only able to track this down because of the git hash of linux-toradex: 5.15.40-6.1.0-devel+git.f4b7e56f237c. That version is the one used by the reference image that is loaded onto the eMMC of the recent modules. However, the master branch of meta-toradex-nxp does not contain a commit that sets the SRCREV of the kernel recipe to that version. I found it only in the kirkstone-6.x.y branch.

Toradex engineers clearly have some cleanup work to do here. This has been rather frustrating and cost me three days of work.

Hi @RudolfStreif

Thank you for the detailed writeup. I understand the frustration and am working with the team to try and identify where we may have gaps.

At a minimum, the fact that we are just rolling out BSP 6 (based on kernel 5.15) is no doubt causing some of the issues you are having. Have you tried any of this on our BSP 5 release? I suspect it will be simpler there.

Also, above you mentioned using the “master branch” and it seems you have a custom DISTRO so I suspect you are not building your setup using our repo config. Is that correct?

Can you help me understand how you expected this all to work?

I know the vast majority of our customers use our canned setup and thus don’t see these kinds of issues but I’d like to understand how you put together your custom setup to help us figure out what documentation is missing.

Thanks,
Drew

1 Like

Hi @drew.tx,

Thank you for your response. Much appreciated. My apologies for the delayed response.

Have you tried any of this on our BSP 5 release? I suspect it will be simpler there.

No, I have not. I am new to Toradex hardware and software. I saw the DT overlays on the distro installed with TEZI and liked the idea how it was set up for the very reason that I have to make additions to the DT as I have to get RemoteProc, RPMesg and OpenAMP working with the Cortex-M core. However, if I am not mistaken I read somewhere that BSP 5 does not support the DT overlays.

Also, above you mentioned using the “master branch” and it seems you have a custom DISTRO so I suspect you are not building your setup using our repo config. Is that correct?

Correct. BTW, I tried the repo config but with BSP 6 and it did not yield a working result either.

Can you help me understand how you expected this all to work?

Essentially the good old-fashioned YP/OE way: pull a BSP layer, integrate it with your distro layer and build. The whole idea of YP/OE BSPs are that they are orthogonal to the rest of the build environment. Basically, I can exchange a BSP for another and build the exact same system just for a different machine.

I know the vast majority of our customers use our canned setup and thus don’t see these kinds of issues but I’d like to understand how you put together your custom setup to help us figure out what documentation is missing.

Understood, and that makes for a smooth start. However, through my long journey with embedded systems, embedded Linux and vendor BSPs I often made the experience that these solutions can be hard to customize and even harder to maintain. Commonly they incorporate patched versions of the u-boot and Linux kernel source trees, pulled from a vendor repository that deviate from their mainline upstream ancestors and siblings. It works reasonably well as long as the vendor is committed to maintaining their solution. More often than I wished for, I found myself diff’ing a kernel tree to find the patches and port them forward to a newer kernel version because the vendor stopped maintenance. I such a case, I’d rather have the vendor use a pristine upstream kernel and apply the patches separately.

Unfortunately, it seems that Toradex engineers are going both ways:

SRCBRANCH = "toradex_5.15-2.0.x-imx"
MIRRORS:append:preempt-rt = "${KERNELORG_MIRROR}/linux/kernel/projects/rt/5.15/older/ ${KERNELORG_MIRROR}/linux/kernel/projects/rt/5.15/"
SRC_URI:append:preempt-rt = " \
    file://0001-Revert-Revert-ARM-9113-1-uaccess-remove-set_fs-imple.patch \
    ${KERNELORG_MIRROR}/linux/kernel/projects/rt/5.15/older/patch-5.15.40-rt43.patch.xz;name=rt-patch \
    file://0003-Revert-Revert-Revert-ARM-9113-1-uaccess-remove-set_f.patch \
    file://preempt-rt.scc \
    file://preempt-rt-less-latency.scc \
"

Although the patches are for the realtime kernel only. You are already using a vendor kernel which is derived from the NXP vendor kernel with a specific branch. Why not have a branch for the RT kernel that has the patches already applied? Or better, use a pristine upstream kernel and provide the patchsets for the standard and the RT kernel. But in all fairness, a lot of this has been created by NXP.

The YP kernel repositories have been providing an infrastructure on how to manage such things for the longest time.

Hi @RudolfStreif

Thanks for the details. That is very good info and I have passed this thread back to the dev and docs teams for review. My colleague @henrique.tx is considering at least some documentation to help clarify things.

As for the branching, yes, it is complicated by the NXP architecture but I’m not the right one to comment on it as that is out of my wheelhouse. Hopefully, @henrique.tx can help further with that as well.

Drew