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

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
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 
Colibri iMX7 # print fdt_board 
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:~# 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:~# modprobe spidev
root@my-colibri-imx7-03090138:~# ls -l /dev/spi*
crw------- 1 root root 153, 0 Jul  5 08:01 /dev/spidev2.0

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. device-trees/imx7-colibri.dtsi at toradex_5.4-2.3.x-imx · toradex/device-trees · GitHub. 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.