Error building reference image (device-tree) with yocto-openembedded

Dear @flatz,

Sorry for the delay in reaching back to you. I’ve sent the wrong file path. You should find it in meta-toradex-nxp. I’ve updated the commentary.

Could you please check it there and tell us if you could make it work?

Best regards,

hi @gclaudino.tx

this is the content of the file layers/meta-toradex-nxp/conf/machine/colibri-imx7.conf :

~/Toradex/iMX7/oe-core/layers/meta-toradex-nxp/conf/machine$ cat colibri-imx7.conf
# cope with renamed machine file in meta-freescale-3rdparty
require conf/machine/colibri-imx7-nand.conf

The variable called KERNEL_DEVICETREE isn’t present .

Hi @flatz,

Ok, it seems again that it was not the right path. If your device tree doesn’t show up in boot, you could use something like:

KERNEL_DEVICETREE_forcevariable = "imx7d-colibri-eval-v3.dtb imx7d-colibri-my-eval-v3.dtb"

However, I found one interesting thing on your layer.conf. It has no priority. Can you please set a number for it and try again? You could use for instance:

bitbake-layers show-layers

With this, you can see every layer that is being built and the priority to check if your layer is really being used.

Hi @gclaudino.tx

I have set the KERNEL_DEVICETREE_forcevariable into my 'meta-customer/conf/layer.conf` and set the priority to 25 :

/Toradex/iMX7/oe-core/layers/meta-customer/conf$ cat layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"
# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "meta-customer"
BBFILE_PATTERN_meta-customer = "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-customer = "25"
LAYERDEPENDS_meta-esauto = "core"
LAYERSERIES_COMPAT_meta-customer = "dunfell"
KERNEL_DEVICETREE_append = " imx7d-colibri-my-eval-v3.dtb"
KERNEL_DEVICETREE_forcevariable = "imx7d-colibri-eval-v3.dtb imx7d-colibri-my-eval-v3.dtb"

But the image.json rebuilded not not have my dtb :

 [ ... cut ...]
{
                    "name": "dtb",
                    "content": {
                        "rawfiles": [
                            {
                                "filename": "imx7s-colibri-eval-v3.dtb",
                                "product_ids": "0032"
                            },
                            {
                                "filename": "imx7d-colibri-eval-v3.dtb",
                                "product_ids": "0033"
                            },
                            {
                                "filename": "imx7d-colibri-eval-v3.dtb",
                                "product_ids": "0041"
                            }
                        ]
                    },
                    "size_kib": 128,
                    "type": "static"
                },
[ ... cut ...]

and last but not least, in the Tezi .tar file I found my dtb file duplicated:

Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/toradexlinux.png
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/marketing.tar
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/prepare.sh
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/wrapup.sh
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/LA_OPT_NXP_SW.html
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/image.json
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/Reference-Multimedia-Image-rt-colibri-imx7.tar.xz
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/zImage
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7d-colibri-eval-v3.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7d-colibri-my-eval-v3.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7d-colibri-my-eval-v3.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7d-colibri-iris.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7d-colibri-iris-v2.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7s-colibri-iris.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7s-colibri-iris-v2.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7d-colibri-aster.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/imx7s-colibri-aster.dtb
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/u-boot-initial-env
Colibri-iMX7_Reference-Multimedia-Image-rt-Tezi_5.7.0-devel-20220623145416+build.0/u-boot-nand.imx

If you want, I can send to you my layer and local.conf file to reproduce the issues …
Thank you!

Dear @flatz,

If you do forcevariable you’d not need the append. This may explain why you ended up with two files for your device tree.

If you install this image, can you find your device tree under /boot/dts? What’s the output of a printenv fdt_file on U-boot? Have you tried changing the default to your device tree name on there to check if it’s working?

Please share with us the configuration files and also the final recipe you currently have. You could use share.toradex.com to do so.

Ok, this issue is solved. I’ve removed the _append.

No, the /boot directory in empty:

root@colibri-imx7-03090138:/boot# ls -al
total 0
drwxr-xr-x  2 root root  160 Mar  9  2018 .
drwxr-xr-x 17 root root 1120 Mar  9  2018 ..

The output is:

Colibri iMX7 # print fdt_board 
fdt_board=eval-v3
Colibri iMX7 # print fdtfile 
fdtfile=imx7d-colibri-eval-v3.dtb

Yes. Overwriting the image.json file with my dtb files:

{
                                "filename": "imx7d-colibri-my-eval-v3.dtb",
                                "product_ids": "0033"
                            },
                            {
                                "filename": "imx7d-colibri-my-eval-v3.dtb",
                                "product_ids": "0041"
                            }

the result is the same as above.

Writing fdt_board=my-eval-v3 and fdtfile=imx7d-colibri-my-eval-v3.dtb, (and saving
the u-boot environment, off course …), my DT configuration is correctly loaded.

Ok. my meta-customer.tar.gz, oe-core/build/conf/local.conf and bblayers.conf:
meta-customer.tar.gz, oe-core/build/conf/local.conf bblayers.conf

(The Open Embedded environment was built wit those commands:

repo init -u https://git.toradex.com/toradex-manifest.git -b dunfell-5.x.y -m tdxref/default.xml
bitbake -k tdx-reference-multimedia-image

)
Thank you
F.

Dear @flatz,

From the local.conf file you sent us, it seems that you didn’t set the machine. Is this right? You should uncomment the desired machine if you’re using bitbake like this: bitbake -k tdx-reference-multimedia-image. Could you please uncomment the line for your desired machine and check?

# Machine Selection
#
# You need to select a specific machine to target the build with. These are the
# machines which target the Toradex Apalis, Colibri and Verdin computer on
# module families:
#
#MACHINE ?= "apalis-imx6"
#MACHINE ?= "apalis-imx8"
#MACHINE ?= "apalis-tk1"
#
#MACHINE ?= "colibri-imx6"
#MACHINE ?= "colibri-imx6ull"
#MACHINE ?= "colibri-imx6ull-emmc"
#MACHINE ?= "colibri-imx7"
#MACHINE ?= "colibri-imx7-emmc"
#MACHINE ?= "colibri-imx8x"
#
#MACHINE ?= "verdin-imx8mm"
#MACHINE ?= "verdin-imx8mp"
#
# There are also a selection of emulated machines available which can boot and run
# in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"

Also, your u-boot bbappend file seems to be different from the sample we provided on the developer page. Why did you remove the ${S}/include/configs/colibri_imx7.h command? Have you tried, to run with it?


These are the two points that caught my attention the most at the moment.

Hi @gclaudino.tx

The machine is set at line 285 of the file:

PREFERRED_PROVIDER_virtual/kernel = "linux-toradex-rt"
TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc"

DL_DIR ?= "${TOPDIR}/../../downloads"
MACHINE ?= "colibri-imx7"   # <===

ACCEPT_FSL_EULA = "1"
IMAGE_INSTALL_append = " \

Ops! probably it was my mistake. But I have added the command, rebuilded the image
but in the image.json file have the original .dtb file, not the modified ..my-eval..

Otherwise, I’m rebuilding from scratch the image, the bitbaking will be terminate this night, or tomorrow morning …

Dear @flatz,

Thanks for the update. Please give us the feedback of your new test.

In the meantime, I’d suggest you have a look at this post on our community where it is explained how to find and how to change the default image.json: Make changes to image.json file before yocto build.

Best regards,

Hi @gclaudino.tx
About the rebuild from scratch, notning is changed.
I watched at the the link, but isn’t clear how to proceed…

I added this to the meta-customer recipe:

$ oe-core/layers/meta-customer$ tree -L 3 conf
conf
├── layer.conf
+└── machine   <== added
+   ├── colibri-imx7.conf
+   └── include
+       └── colibri-imx7.inc

where :

$ oe-core/layers/meta-customer$ cat conf/machine/colibri-imx7.conf 
require conf/machine/include/colibri-imx7.inc

and

$ oe-core/layers/meta-customer$ cat conf/machine/include/colibri-imx7.inc 
IMAGE_CLASSES_append = " image_type_tezi"
IMAGE_FSTYPES_append = " teziimg"
TORADEX_PRODUCT_IDS = "0032 0033 0041"
TORADEX_PRODUCT_IDS[0032] = "imx7s-colibri-eval-v3.dtb"
TORADEX_PRODUCT_IDS[0033] = "imx7d-colibri-my-eval-v3.dtb" <== changed from original
TORADEX_PRODUCT_IDS[0041] = "imx7d-colibri-my-eval-v3.dtb"  <== changed from original
TORADEX_FLASH_TYPE = "rawnand"

MACHINE_NAME = "Colibri-iMX7"

MACHINEOVERRIDES_append_upstream = ":use-mainline-bsp"

MACHINE_FIRMWARE_remove = "firmware-imx-epdc"
MACHINE_FIRMWARE_remove_use-mainline-bsp = "firmware-imx-vpu-imx6q firmware-imx-vpu-imx6d"

KERNEL_DEVICETREE_append_use-nxp-bsp += " \
    imx7d-colibri-iris.dtb \
    imx7d-colibri-iris-v2.dtb \
    imx7s-colibri-iris.dtb \
    imx7s-colibri-iris-v2.dtb \
"
KERNEL_DEVICETREE_append_use-mainline-bsp = " \
    imx7d-colibri-aster.dtb \
    imx7s-colibri-aster.dtb \
"

PREFERRED_PROVIDER_virtual/kernel = "linux-toradex"
PREFERRED_PROVIDER_virtual/kernel_preempt-rt = "linux-toradex"
PREFERRED_PROVIDER_virtual/kernel_use-mainline-bsp = "linux-toradex-mainline"
PREFERRED_PROVIDER_virtual/kernel_use-mainline-bsp_preempt-rt = "linux-toradex-mainline"
PREFERRED_PROVIDER_virtual/dtb_use-mainline-bsp = "device-tree-overlays-mainline"

PREFERRED_PROVIDER_u-boot-default-script = "u-boot-distro-boot"

UBOOT_MAKE_TARGET_colibri-imx7 = "u-boot.imx"
UBOOT_ENTRYPOINT_colibri-imx7 = "0x81000000"
UBOOT_DTB_LOADADDRESS_colibri-imx7 = "0x82000000"
UBOOT_DTBO_LOADADDRESS_colibri-imx7 = "0x87000000"

After the commands

$ bitbake tdx-reference-multimedia-image -c cleansstate
$ oe-core/build$ bitbake -f -k  tdx-reference-multimedia-image

Nothing is changed in the image.json file,

Obviously I don’t want to modify directly the meta-toradex-nxp/conf/machine/include/colibri-imx7.inc file

Best Regards

Dear @flatz,

I have tried to make it work on my side by copying your files to my Yocto build. I’ve did this correction like you said you’ve done here:

However, just as a test, I’ve edited the original colibri-imx7.inc file for my image-json to have the proper device trees listed on it. You can see the diff below and the resulting image.json.
diff:

diff --git a/conf/machine/include/colibri-imx7.inc b/conf/machine/include/colibri-imx7.inc
index 4cc2d59..8778284 100644
--- a/conf/machine/include/colibri-imx7.inc
+++ b/conf/machine/include/colibri-imx7.inc
@@ -1,9 +1,10 @@
 IMAGE_CLASSES_append = " image_type_tezi"
 IMAGE_FSTYPES_append = " teziimg"
-TORADEX_PRODUCT_IDS = "0032 0033 0041"
+TORADEX_PRODUCT_IDS = "0032 0033 0041 0042"
 TORADEX_PRODUCT_IDS[0032] = "imx7s-colibri-eval-v3.dtb"
 TORADEX_PRODUCT_IDS[0033] = "imx7d-colibri-eval-v3.dtb"
 TORADEX_PRODUCT_IDS[0041] = "imx7d-colibri-eval-v3.dtb"
+TORADEX_PRODUCT_IDS[0042] = "imx7d-colibri-my-eval-v3.dtb"
 TORADEX_FLASH_TYPE = "rawnand"
 
 MACHINE_NAME = "Colibri-iMX7"

image.json:

{
    "config_format": "2",
    "autoinstall": false,
    "name": "Toradex Embedded Linux Reference Minimal Image",
    "description": "Minimal image without graphical interface that just boots",
    "version": "5.7.0-devel-20220630195555+build.0",
    "release_date": "2022-06-30",
    "u_boot_env": "u-boot-initial-env",
    "prepare_script": "prepare.sh",
    "wrapup_script": "wrapup.sh",
    "marketing": "marketing.tar",
    "icon": "toradexlinux.png",
    "license": "LA_OPT_NXP_SW.html",
    "supported_product_ids": [
        "0032",
        "0033",
        "0041",
        "0042"
    ],
    "mtddevs": [
        {
            "name": "u-boot1",
            "content": {
                "rawfile": {
                    "filename": "u-boot-nand.imx",
                    "size": 1
                }
            }
        },
        {
            "name": "u-boot2",
            "content": {
                "rawfile": {
                    "filename": "u-boot-nand.imx",
                    "size": 1
                }
            }
        },
        {
            "name": "u-boot-env",
            "erase": true,
            "content": {}
        },
        {
            "name": "ubi",
            "ubivolumes": [
                {
                    "name": "kernel",
                    "size_kib": 12288,
                    "type": "static",
                    "content": {
                        "rawfile": {
                            "filename": "zImage",
                            "size": 5
                        }
                    }
                },
                {
                    "name": "dtb",
                    "content": {
                        "rawfiles": [
                            {
                                "filename": "imx7s-colibri-eval-v3.dtb",
                                "product_ids": "0032"
                            },
                            {
                                "filename": "imx7d-colibri-eval-v3.dtb",
                                "product_ids": "0033"
                            },
                            {
                                "filename": "imx7d-colibri-eval-v3.dtb",
                                "product_ids": "0041"
                            },
                            {
                                "filename": "imx7d-colibri-my-eval-v3.dtb",
                                "product_ids": "0042"
                            }
                        ]
                    },
                    "size_kib": 128,
                    "type": "static"
                },
                {
                    "name": "m4firmware",
                    "size_kib": 896,
                    "type": "static"
                },
                {
                    "name": "rootfs",
                    "content": {
                        "filesystem_type": "ubifs",
                        "filename": "Reference-Minimal-Image-colibri-imx7.tar.xz",
                        "uncompressed_size": 105.59765625
                    }
                }
            ]
        }
    ]
}

I’ll check tomorrow how to properly add these files to your custom layer but as a workaround, you could do this small patch to the original include file in the meantime.

Hi @gclaudino.tx

I did your modification in my custom layer, but after a image rebuild, the product id 0042 does not appear in the file image.json .

Dear @flatz,

The modification I made on this quick test was not on the inc file on my custom-layer. It was on the generic one.

I did some tests on my side to get things working for you. What I’ve done was to change a few things to ensure that there were no duplicates and no file conflicts. My folder structure looks like this:

meta-test-dts tree
.
├── conf
│   ├── layer.conf
│   └── machine
│       ├── colibri-imx7-nand.conf
│       ├── include
│       │   └── my-colibri-imx7.inc
│       └── my-colibri-imx7.conf
├── recipes-bsp
│   └── u-boot
│       └── u-boot-toradex_%.bbappend
└── recipes-kernel
    └── linux
        ├── linux-toradex
        │   ├── defconfig
        │   ├── imx7-colibri-my-eval-v3.dtsi
        │   ├── imx7d-colibri-my-eval-v3.dts
        │   ├── imx7d-my-colibri.dtsi
        │   └── imx7-my-colibri.dtsi
        └── linux-toradex%.bbappend

8 directories, 11 files

It has basically all your files but I’ve created a conf file called my-colibri-imx7.conf. Therefore, I’d compile it with: MACHINE ?= my-colibri-imx7 on the local.conf file.

I’ve then copied the colibri-imx7-nand.conf from meta-freescale-3rdparty and changed this line:

MACHINEOVERRIDES =. "my-colibri-imx7:"

Then, on the my-colibri-imx7-conf I had only:

# cope with renamed machine file in meta-freescale-3rdparty
require conf/machine/colibri-imx7-nand.conf

And after all, it worked on my side, so I put all this folder structure here:
https://share.toradex.com/euh7nlzi9vpj87t

Can you please test it?

I’m also including my local.conf here:

#
# This file is your local configuration file and is where all local user settings
# are placed. The comments in this file give some guide to the options a new user
# to the system might want to change but pretty much any configuration option can
# be set in this file. More adventurous users can look at local.conf.extended
# which contains other examples of configuration which can be placed in this file
# but new users likely won't need any of them initially.
#
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
# variable as required.

#
# Machine Selection
#
# You need to select a specific machine to target the build with. These are the
# machines which target the Toradex Apalis, Colibri and Verdin computer on
# module families:
#
#MACHINE ?= "apalis-imx6"
#MACHINE ?= "apalis-imx8"
#MACHINE ?= "apalis-tk1"
#
#MACHINE ?= "colibri-imx6"
#MACHINE ?= "colibri-imx6ull"
#MACHINE ?= "colibri-imx6ull-emmc"
#MACHINE ?= "colibri-imx7"
MACHINE ?= "my-colibri-imx7"
#MACHINE ?= "colibri-imx7-emmc"
#MACHINE ?= "colibri-imx8x"
#
#MACHINE ?= "verdin-imx8mm"
#MACHINE ?= "verdin-imx8mp"
#
# There are also a selection of emulated machines available which can boot and run
# in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"

#
# Where to place downloads
#
# During a first build the system will download many different source code tarballs
# from various upstream projects. This can take a while, particularly if your network
# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build directory.
#
DL_DIR ?= "/home/yocto/yp-downloads"

#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
SSTATE_DIR ?= "/home/yocto/yp-sstatecache"

ACCEPT_FSL_EULA = "1"
#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"

#
# Where to place images and sw packages
#
# This places the build output in parallel to build and layers thus
# if you have several build directories you need to adjust deploy
# to something unique, e.g. "${TOPDIR}/../deploy_fb" "${TOPDIR}/../deploy_x11"
DEPLOY_DIR = "${TOPDIR}/deploy"

#
# Package Management configuration
#
# This variable lists which packaging formats to enable. Multiple package backends
# can be enabled at once and the first item listed in the variable will be used
# to generate the root filesystems.
# Options are:
#  - 'package_deb' for debian style deb files
#  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
#  - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# We default to ipk:
PACKAGE_CLASSES ?= "package_ipk"

#
# SDK target architecture
#
# This variable specifies the architecture to build SDK items for and means
# you can build the SDK packages for architectures other than the machine you are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686 and x86_64
#SDKMACHINE ?= "i686"

#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
#  "dbg-pkgs"       - add -dbg packages for all installed packages
#                     (adds symbol information for debugging/profiling)
#  "src-pkgs"       - add -src packages for all installed packages
#                     (adds source code for debugging)
#  "dev-pkgs"       - add -dev packages for all installed packages
#                     (useful if you want to develop against libs in the image)
#  "ptest-pkgs"     - add -ptest packages for all ptest-enabled packages
#                     (useful if you want to run the package test suites)
#  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
#  "tools-debug"    - add debugging tools (gdb, strace)
#  "eclipse-debug"  - add Eclipse remote debugging support
#  "tools-profile"  - add profiling tools (oprofile, lttng, valgrind)
#  "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
#  "debug-tweaks"   - make an image suitable for development
#                     e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
# package-management deploys the package meta data of deployed packeges
EXTRA_IMAGE_FEATURES ?= "debug-tweaks package-management"

#
# Additional image features
#
# The following is a list of additional classes to use when building images which
# enable extra features. Some available options which can be included in this variable
# are:
#   - 'buildstats' collect build statistics
#   - 'image-mklibs' to reduce shared library files size for an image
#   - 'image-prelink' in order to prelink the filesystem image
# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs image-prelink"

#
# Runtime testing of images
#
# The build system can test booting virtual machine images under qemu (an emulator)
# after any root filesystems are created and run tests against those images. It can also
# run tests against any SDK that are built. To enable this uncomment these lines.
# See classes/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO_qemuall = "1"

#
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to do this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than one parallel
# process may require the user's attention. The default is iterate over the available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail instead):
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that 1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
# of the build. The reason for this is that running completely out of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
# It's necesary to monitor /tmp, if there is no space left the build will fail
# with very exotic errors.
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"

#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"


#
# Qemu configuration
#
# By default qemu will build with a builtin VNC server where graphical output can be
# seen. The two lines below enable the SDL backend too. By default libsdl2-native will
# be built, if you want to use your host's libSDL instead of the minimal libsdl built
# by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
#ASSUME_PROVIDED += "libsdl2-native"

#
# Hash Equivalence
#
# Enable support for automatically running a local hash equivalence server and
# instruct bitbake to use a hash equivalence aware signature generator. Hash
# equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash doesn't
# match the one that generated the artifact.
#
# A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
#
#BB_HASHSERVE = "auto"
#BB_SIGNATURE_HANDLER = "OEEquivHash"


# Toradex fitImage support (For EMMC modules)
#
# To enable fitimage, uncomment the following two lines
#
# KERNEL_CLASSES_append = " toradex-fitimage"
# KERNEL_IMAGETYPE_forcevariable = "${@'zImage' if d.getVar('TORADEX_FLASH_TYPE') == 'rawnand' else 'fitImage'}"


# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"

# Delete the the source/object/binary files once a package is built to preserve disk space
INHERIT += "rm_work"

# Add Toradex bbclasses
INHERIT += "toradex-mirrors toradex-sanity"

# Use this distro by default
DISTRO ?= "tdx-xwayland"

# Don't generate the mirror tarball for SCM repos, the snapshot is enough
# BB_GENERATE_MIRROR_TARBALLS = "0"

### NXP PROPRIETARY DRIVER
#MACHINEOVERRIDES =. "default-nxp-proprietary-driver:"
#NXP_PROPRIETARY_DRIVER_LOCATION = "file:///home/yocto/yp-downloads"


# This file does not need to exist, if it does it can be used to influence machine specific
# configurations without copying the machine file.
include conf/machine/include/${MACHINE}.inc

# DO NOT SET THE MACHINE AFTER THE ABOVE INCLUDE

Best regards,

Hi @gclaudino.tx

I did. in the image.json file now I found the --my-eval--.dtb files.

But a new problem appeared.
When I insert my sd-card into the SD slot of the Eval board, (after writing autoinstall=true;
into image.json, Toradex Easy installer (both 5.6.0 and 5.7.0) tell that “image is not compatible with this module”.
I tried to install the image with Colibri-iMX7_ToradexEasyInstaller_5.6.0+build.9 and Colibri-iMX7_ToradexEasyInstaller_5.7.0-devel-20220703+build.400 .

Thank you
F.

Hi @flatz,

That was my fault, I’m sorry. I’ve changed the product id’s to other numbers for testing purposes and forget to update it when sharing it with you. If you have a look here, your module should probably have ID 33: Colibri iMX7 | Toradex Developer Center. Therefore, you may need to edit the my-colibri-imx7.inc with the ID 33 instead of 34 and then you’ll be able to install it. Also, remember to ensure that this line has your device tree.

Please note however that if the inc file in future releases get changed, you may need to update your inc file later on.

Best regards,

hi @gclaudino.tx

Yes, now it start. In image.json I’ve the correct .dtb:

"name": "dtb",
        "content": {
        "rawfiles": [
         {
                "filename": "imx7s-colibri-eval-v3.dtb",
                "product_ids": "0032"
         },
         {
                "filename": "imx7d-colibri-my-eval-v3.dtb",
                "product_ids": "0033"
          },
          {
                 "filename": "imx7d-colibri-my-eval-v3.dtb",
                 "product_ids": "0041"
          }
       ]
   },

but in the u-boot I but I still have the default .dtb:

U-Boot 2020.07-5.7.0-devel+git.8a365642835e (Apr 04 2022 - 15:40:59 +0000)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 40C
Reset cause: POR
DRAM:  512 MiB
PMIC:  RN5T567 LSIVER=0x01 OTPVER=0x0d
NAND:  512 MiB
MMC:   FSL_SDHC: 0
Loading Environment from NAND... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Colibri iMX7 Dual 512MB V1.1D, Serial# 03090138
SEC0: RNG instantiated
Net:   eth0: ethernet@30be0000
Hit any key to stop autoboot:  0 
Colibri iMX7 # print fdtfile 
fdtfile=imx7d-colibri-eval-v3.dtb
Colibri iMX7 # print fdt_board 
fdt_board=eval-v3
Colibri iMX7 #

But, booting the system, it looks like it has been loaded my DT configuration: flexcan instead the can with mcp251x.ko, spidev enabled:

my-colibri-imx7-03090138 login: root
Last login: Tue Jul  5 08:01:40 UTC 2022
root@my-colibri-imx7-03090138:~# 
root@my-colibri-imx7-03090138:~# lsmod
Module                  Size  Used by
usb_f_rndis            24576  2
u_ether                24576  1 usb_f_rndis
imx_sdma               24576  2
virt_dma               16384  1 imx_sdma
flexcan                24576  0
can_dev                24576  1 flexcan
secvio                 16384  0
libcomposite           49152  10 usb_f_rndis
configfs               36864  3 usb_f_rndis,libcomposite
root@my-colibri-imx7-03090138:~# 
root@my-colibri-imx7-03090138:~# modprobe spidev
root@my-colibri-imx7-03090138:~# ls -l /dev/spi*
crw------- 1 root root 153, 0 Jul  5 08:01 /dev/spidev2.0
root@my-colibri-imx7-03090138:~# 

I missed something ?

Thank you

Dear @flatz,

I just rechecked it and no, you didn’t miss anything. NAND Modules such as the Colibri iMX7D 512Mb work with device trees a bit differently from other eMMC based-modules. They use ubiupdatevol to update the module instead of the fdt variables in u-boot Updating NAND-based modules from userspace | Toradex Developer Center. Therefore, if your interfaces are there like you designed it’s loading your correct device tree and you should be fine. You can also have a look at this post to learn more: How to copy multiple DTB files via U-boot - #2 by alex.tx.

To be 100% sure that your device tree is being used you could change the following line on your colibri-imx7-my-eval-v3.dts to something like model = "Toradex My Colibri iMX7D and then you could check with: dmesg | grep Machine.

Best regards,

Hi @gclaudino.tx

I did it. It works.

root@my-colibri-imx7-03090138:~# dmesg | grep Machine
[    0.000000] OF: fdt: Machine model: Toradex My-Colibri iMX7D on Colibri Ev. Board V3

At boot I have this message:

[   ...  ]
ubi0: available PEBs: 0, total reserved PEBs: 4056, PEBs reserved for bad PEB handling: 72
No size specified -> Using max size (6282672)
Read 6282672 bytes from volume kernel to 81000000
No size specified -> Using max size (66328)
Read 66328 bytes from volume dtb to 82000000
Kernel image @ 0x81000000 [ 0x000000 - 0x5fddb0 ]
## Flattened Device Tree blob at 82000000
   Booting using the fdt blob at 0x82000000
ERROR: reserving fdt memory region failed (addr=9fe00000 size=1fffff)
   Loading Device Tree to 8feec000, end 8feff317 ... OK
   Updating MTD partitions...

Starting kernel ...
[    0.000000] 000: Booting Linux on physical CPU 0x0
  [ ... and the kernel starts normally ... ]

Do you know if that could be a problem ?

Thank you!

Hi @flatz,

That’s great. So your custom layer is able to generate the device tree and load it in Tezi and Boot after installation. Can we mark the post then as solved?

This error is linked to the address in the memory of the M4 Cortex on the module. https://github.com/toradex/device-trees/blob/toradex_5.4-2.3.x-imx/dts-arm32/imx7-colibri.dtsi#L66. If you don’t plan to use the M4 Cortex it should not be a problem. You can use the module normally. There was already a ticket open on our side about it. We’re working to solve this error.

Hi @gclaudino.tx

Yes, of course !

Ok, I don’t care for now…

Thank you for the support.
F.