Boot-script; environment variables are not set

Good day,

I am currently working on implementing RAUC in my build.
For RAUC to work properly some adjustments to the boot.scr are needed.

My problem is that creating environment variables (inside the boot.scr), doesn’t seem to stick.
I tried the following adjustments for testing purposes:

env set test_value "test value set"
setenv testenv "test environ variable"

Both variables are not displayed when running printenv. (Neither in uboot, nor in linux)
Output below:

boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_targets=mmc1 mmc2 usb0 dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=setenv devtype dhcp; run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mfg=fastboot 0
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_mmc2=devnum=2; run mmc_boot
bootcmd_usb0=devnum=0; run usb_boot
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
preboot=setenv fdtfile imx8mp-verdin-${variant}-${fdt_board}.dtb
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}…; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing…; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing…; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing…; fi; done
setup=setenv setupargs console=${console},${baudrate} console=tty1 consoleblank=0 earlycon
update_uboot=askenv confirm Did you load imx-boot (y/N)?; if test “$confirm” = “y”; then setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200; mmc dev 2 1; mmc write ${loadaddr} 0x0 ${blkcnt}; fi
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

I know that my changes took effect on the boot-script since it can be read under /boot/boot.scr and echo commands are displayed during boot.

Is there something I am missing?
Are the variables set in the script only temporary? If i understood this link correctly, they shouldn’t.

Best regards

Hi @aigF,

My guess is that the environment is not being saved. In U-Boot you have to do an explicit saveenv command to have it flushed out to backing storage, otherwise it will be as you described. Can you add that into your boot.scr and see if it helps?



yes that was the case.
I have the complete RAUC process up and running by now.

Thanks for the help regardless.
best regrads


I have one further question:
Currently, I am creating partitions and evironment variables via the Toradex Easy Installer.
I am doing this by changing the image.json and the u-boot-initial-env-sd by hand.

How would I go about manipulating these files during the YOCTO build process?
I think, I have found the class that handles the image creation in meta-toradex-bsp-common/classes/image_type_tezi.bbclass.
But I am not quite sure where the u-boot-environment and the image.json are pulled from.

Are they automatically generated, or downloaded from somewhere?
How would I go about changing these files before the image is assembled?

Best regards

I think the best approach here is to create a custom class. You can see how it is done for Mender here: meta-mender-community/image_type_mender_tezi.bbclass at dunfell · mendersoftware/meta-mender-community · GitHub

Have you done any research on our Torizon OTA product? Is there a reason you are using RAUC?


I am currently testing with RAUC, since I have some basic experience with it from tests with another board by a different producer.
As for Torizon OTA, I am currently running a lot of tests and trying various things on our development board. Since I am rather inexperienced with Linux development, there are quite some things were the implementation is not fully defined yet.

For example if we wish to use the Torizon distribution, or if we wish to build our own image in Yocto.
If we use Torizon, if we can work with a standard image or if we need to run changes in Yocto anyways.
Since we wish to have an OTA update server in-house, this server would need to implement Uptane in some way or form, if I understood this correctly.

So in other words I am currently scrambling though tests to see what we wish to implement how in the coming project.

Good day,

after some further tests I have some questions about Torizon OTA.
Is it possible to change the Update server to our own server? If yes, how?
In house solutions are currently preferred to out of house ones.

Are there any problems we might need to watch out for, on our update server?

Best regards

Hello @aigF,

We don’t have an on-premise version of our update server so if you go that route you definitely will be in uncharted territory. The update client we use is a fork of an upstream project and we are submitting our changes back to them so it is feasible to use a different Uptane compatible server but it’s not something we have tested or can provide any guidance on.


Hello Drew,

sorry for the late reply, but how does the update server work on your side?
Do you just use a server from advancedtelemetric? Or are there third party servers that implement Uptane already?

best regards

Hi @aigF !

The server setup is based on Uptane · GitHub and, as Drew commented, Toradex’s changes are submitted to upstream.

The details of hosting, authentication, and charts are not open-source so we can’t disclose them.

Best regards,