Where are the correct instructions for building a custom torizon-core-docker?


Project is moving to the Dahlia carrier from the full-size dev board. For dev testing we were installing Torizon Core with Docker sans container then manually running:

sudo fw_setenv board 'dahlia-imx8mp'
sudo fw_setenv board_name 'dahlia-imx8mp'
sudo fw_setenv fdt_board 'dahlia'
sudo fw_setenv fdtfile 'imx8mp-verdin-wifi-dahlia.dtb'

To make the CODEC work.

Now we are getting to the point of building a custom image. So I went here:
TorizonCore Builder Tool - Customizing TorizonCore Images (toradex.com)
Where it didn’t list any U-Boot capabilities. One U-Boot tweak and phi-slamma-jamma a pair of docker containers and I would have been done. So I went here:
Build TorizonCore from Source With Yocto Project/OpenEmbedded (toradex.com)
then here
Build a Reference Image with the Yocto Project/OpenEmbedded - Toradex System/Computer on Modules

I followed along on the videos because I needed to tweak U-Boot. I dutifully made all of my changes creating files all over replaying many parts to be certain I did everything “correct” for my U-Boot mods.


Searching for “Failed to get layers information. Exception: <class ‘bb.process.ExecutionError’>” lead me to this page:
Custom meta layers, recipes and images in Yocto Project (hello-world examples) (toradex.com)
which states git is now mandatory for Torizon Core. I’m more than half way through the second video and have yet to hear Git mentioned at all. I got the error this page states and didn’t use any of the tools this page says to use because they weren’t in the video, so I’m guessing this link is a bit more current?

This link was offered up in a 2021 message as being the latest documentation for TorizonCore Builder

It appears one can change most anything other than U-Boot variables.


Should I be ignoring the video and following the instructions found here?

Then follow these instructions for pre-provisioning two docker containers?

I’ve been chasing my tail since before 6am following conflicting documentation. I just need to find the correct set.

Thank you

Greetings @seasoned_geek,

Let’s see if we can clear this up. First of all, are you making U-Boot changes just to change the U-Boot environment variables so that system boots with the Dahlia device tree by default? Or are their other changes you wish to make?

If it’s just the change for the device tree. You should be able to make this with TorizonCore Builder. See this section here: Device Tree Overlays on Torizon | Toradex Developer Center

Basically you can use the dt apply command to set any device tree (even custom made ones) as the default.

Best Regards,

No, you can’t, at least not according to the documentation. You can build and deploy custom device trees which is all well and good if you are replacing the default.

To do what you say I would have to do a massive never get it through FDA approval process hack and rename the Dahlia dtb I want to the verdin one that is default.

Some individual thought this would be cool.

verdin-imx8mp-06848980:/$ cat etc/u-boot-initial-env-verdin-imx8mp-sd-2020.04-r0
preboot=setenv fdtfile imx8mp-verdin-${variant}-${fdt_board}.dtb

The Dahlia device tree is already in the build. It’s already deployed. To use it one must change fdt_board from dev to dahlia. Only way I could find to reliably do that is

jed recipes-bsp/u-boot/u-boot-toradex_%.bbappend

because that line is generated as part of the build.

Whether it is correct or not, the above works. The CODEC functions after boot. No manual intervention required.

To get the touch screen working I need to replace overlays.txt. Saw absolutely no way to do that with TorizonCore Builder. Maybe it’s there, but I couldn’t see it.

After half a day of trying to search through the code repository via the Web interface, I finally stumbled on this.

= "verdin-imx8mp_native-hdmi_overlay.dtbo verdin-imx8mp_lt8912_overlay.dtbo"

It’s in this file:

So I need to have yet another piece of sed magic

sed -i 's/^TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT.*/TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT = "touch-atmel-mxt_overlay.dtbo verdin-imx8mp_sn65dsi84-lt170410_overlay.dtbo verdin-imx8mp_sn65dsi84_overlay.dtbo"/' ${S}/conf/machine/verdin-imx8mp.conf

I don’t know if that is the correct path to the file during the build. Haven’t tested yet. I do know that sed command works on a local copy of the file.

Even if TorizonCore Builder magically got rid of the offending line containing fdt_board I can find no documented method of replacing overlays.txt. If I have to do custom build for one thing, I might as well try to do it all in the build.

Yes TorizonCore Builder compiles and deploys the selected device tree. No there is no need to change the name of the dahlia dtb. I don’t see how this is anymore of a hurdle in terms of FDA approval than patching U-Boot and doing a re-build of the image.

Also in that same documentation I referenced, you can compile and deploy overlays which changes the contents of overlays.txt. But perhaps you didn’t see this in the documentation. We provide all our source for overlays and device trees. So you can deploy exactly the same thing that’s on the device.

But if your method works then great, I don’t see the issue then.

Best Regards,


Thank you for attempting to help.

What I have only works for the CODEC.

Have you physically tried what you are telling me to do on a Dahlia carrier then tried to use sound?

In case you didn’t read this little part.

verdin-imx8mp-06848980:/$ cat etc/u-boot-initial-env-verdin-imx8mp-sd-2020.04-r0
preboot=setenv fdtfile imx8mp-verdin-${variant}-${fdt_board}.dtb

The U-Boot startup has a hard coded line that calculates the fdtfile value. It ignores the current stored value for the variable. You can verify this rather quickly by either looking at the value of the variable in memory after boot or just trying to play sound.

I will burn yet another half day trying what you are suggesting. It did not work last time. It changes the stored value of the variable which has no effect because the u-boot script calculates the variable value based on fdt_board.

The FDA approval issue had to do with forcing the Dahlia dtb to have the Verdin name so it would match the calculated value.

Yes I did try, surprisingly it works as I documented and as I described.

The U-Boot startup has a hard coded line that calculates the fdtfile value. It ignores the current stored value for the variable . You can verify this rather quickly by either looking at the value of the variable in memory after boot or just trying to play sound.

You are correct, but the following statement from the documentation is also true:

TorizonCore overrides the default value of the U-Boot environment variable fdtfile in a file named uEnv.txt , which is evaluated during U-Boot runtime. Therefore, if you read the value of fdtfile using a tool like U-Boot fw-utils or directly from the bootloader, you will not be reading the value to which this variable evaluates, instead, you should check the contents of /boot/loader/uEnv.txt .

So what happens is that preboot sets fdtfile initially. However the bootscript then overrides fdtfile if applicable. When you apply a device tree using torizoncore-builder it creates this override in the bootscript. As seen here:

verdin-imx8mp-06849059:~$ cat /boot/loader/uEnv.txt | grep fdtfile

Therefore fdtfile gets overwritten to what you want and the filename of the dtb doesn’t need to change.

Best Regards,