I am setting up dual copy update with Yocto/SWUpdate. I have modified the “image.json” to create two rootfs partitions and I have configured Yocto to include the kernel and device tree related files in the /boot folder of each rootfs. But, I do not see how to configure the “u-boot-initial-env-sd” file to load the kernel from the rootfs partitions rather than the bootfs partition. Any help will be appreciated.
tdx-info
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello!
To configure U-Boot to load the kernel from the /boot directory within your rootfs partitions, you’ll need to modify the U-Boot environment variables. This involves adjusting the boot command sequence to point to the kernel and device tree files located in the /boot directory of your rootfs partitions.
Here’s how you can do it:
Access the U-Boot Console: During the boot process, interrupt the autoboot by pressing any key to access the U-Boot console.
Modify the Boot Command: You need to change the bootcmd environment variable to load the kernel from the desired rootfs partition. Typically, this involves setting the bootargs and load commands to point to the correct partition and file paths.
For example, if your rootfs partitions are on mmcblk0p2 and mmcblk0p3, you might set:
setenv bootargs 'root=/dev/mmcblk0p2 ro rootwait console=tty1 console=ttymxc2'
setenv loadkernel 'ext4load mmc 0:2 ${loadaddr} /boot/zImage'
setenv loadfdt 'ext4load mmc 0:2 ${fdt_addr} /boot/imx8mp-verdin.dtb'
setenv bootcmd 'run loadkernel; run loadfdt; bootz ${loadaddr} - ${fdt_addr}'
saveenv
Make sure to adjust the partition numbers and file paths according to your setup.
Save the Changes: Use the saveenv command to save your changes to the U-Boot environment.
Reboot: Restart the system to apply the changes.
By following these steps, U-Boot should load the kernel from the /boot directory within the specified rootfs partition. Ensure that the paths and partition numbers match your specific configuration. If you encounter any issues, double-check the file paths and partition identifiers used in the commands.
I hope this helps! If you have any more questions, feel free to ask.
Best regards,
Toradex AI Assistant.
Please, also check if these links can help you solve your problem:
The ToradexAI has given me some clues. I may be able to track down the answer on my own now.
I don’t know that the ToradexAI response is helpful in this situation. It appears that the bootz command it suggested is not available. Any suggestions on how to load the kernel and device tree files from the /boot folder of the rootfs would be appreciated.
Hey @Sutter99,
Was the link helpful for solving this issue?
I’d also like to mention that Torizon OS has a build in solution for OTA updates . We make use of OSTree + Aktualizr (which is an implementation of automotive Uptane). There are a host of benefits to preforming updates this way, it might be better to set up a call. Let me know if this is of intrested and I’ll get the ball rolling.
-Eric
Hi @eric.tx,
I had looked at the Toradex documentation but I was not familiar with uboot syntax. The following was helpful and I am making progress.
Thank you
Hi @eric.tx,
If I create a folder in the rootfs and copy the kernel and device tree files into it, I can get uboot to boot the kernel successfully. If the kernel and device tree files are in the /boot folder of the rootfs, uboot is unable to load the files. I am unsure of why this is the case. One difference from a standard Linux /boot folder is that the group is “disk” instead of “root”. I have been unable to modify the group though as it indicates this is not permitted. Might you have any suggestions as to why this is occurring?
Thank you
Hi @Sutter99
The approach of putting the file directly in the rootfs is correct here. It’s not clear why this would not work. Do you have any logs of the actual UBoot commands?
I did some experimenting with swupdate in the past for some benchmarking and did manage to get it working on my custom Yocto builds. I used a fork of GitHub - sbabic/meta-swupdate-boards: Examples how to use SWUpdate to add the board-specific support. I only got it far enough along to do my benchmarking so never managed to get my changes submitted upstream. You can see my work here in case it is helpful. Maybe it will tell you something.
Drew
Hi @drew.tx,
Thank you for the link to your work with SWUpdate. That will be helpful.
I am currently entering the commands at the uboot prompt to learn the syntax. The following is a failed attempt with the relevant files in the /boot folder.
Verdin iMX8MP # devtype=mmc
Verdin iMX8MP # devnum=2
Verdin iMX8MP # devpart=2
Verdin iMX8MP # boot_part=2
Verdin iMX8MP # distro_bootpart=2
Verdin iMX8MP # overlays_prefix=boot/overlays
Verdin iMX8MP # kernel_image=boot/Image.gz
Verdin iMX8MP # fdtfile=boot/imx8mp-verdin-nonwifi-dev.dtb
Verdin iMX8MP # setenv boot_a_script ‘load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} boot/boot.scr; source ${scriptaddr}’
Verdin iMX8MP # run boot_a_script
Failed to load ‘boot/boot.scr’
Wrong image format for “source” command
If I copy the relevant files to the /root directory or to a /boot2 folder I create, with the appropriate paths, it will boot correctly using these commands as shown below.
Wrong image format for “source” command
Verdin iMX8MP # overlays_prefix=overlays
Verdin iMX8MP # kernel_image=Image.gz
Verdin iMX8MP # fdtfile=imx8mp-verdin-nonwifi-dev.dtb
Verdin iMX8MP # setenv boot_a_script ‘load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} /boot.scr; source ${scriptaddr}’
Verdin iMX8MP # run boot_a_script
5942 bytes read in 1 ms (5.7 MiB/s)
Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
88144 bytes read in 1 ms (84.1 MiB/s)
157 bytes read in 1 ms (153.3 KiB/s)
Working FDT set to 50200000
Applying Overlay: verdin-imx8mp_hdmi_overlay.dtbo
2219 bytes read in 1 ms (2.1 MiB/s)
Applying Overlay: verdin-imx8mp_sutter_cam3_overlay.dtbo
972 bytes read in 1 ms (949.2 KiB/s)
Applying Overlay: verdin-imx8mp_dsi-to-hdmi_overlay.dtbo
4099 bytes read in 2 ms (2 MiB/s)
Applying Overlay: verdin-imx8mp_spidev_overlay.dtbo
561 bytes read in 1 ms (547.9 KiB/s)
8105388 bytes read in 26 ms (297.3 MiB/s)
Bootargs: root=PARTUUID=ded2f140-02 ro rootwait console=tty1 console=ttymxc2
Uncompressing Kernel Image to 0
Booting using the fdt blob at 0x50200000
Working FDT set to 50200000
Loading Device Tree to 00000000fea8e000, end 00000000feac6fff … OK
Working FDT set to fea8e000
Starting kernel …
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
The /boot folder information is below:
root@verdin-imx8mp-15335644:~# ls -al /boot
total 8806
drwxrwx— 3 root disk 2048 Jan 1 1970 .
drwxr-xr-x 20 root root 4096 Jan 14 17:59 …
-rwxrwx— 1 root disk 8105388 Jan 14 17:29 Image.gz
-rwxrwx— 1 root disk 5942 Jan 14 17:29 boot.scr
-rwxrwx— 1 root disk 88715 Jan 14 17:29 imx8mp-verdin-nonwifi-dahlia.dtb
-rwxrwx— 1 root disk 88144 Jan 14 17:29 imx8mp-verdin-nonwifi-dev.dtb
-rwxrwx— 1 root disk 92260 Jan 14 17:29 imx8mp-verdin-nonwifi-ivy.dtb
-rwxrwx— 1 root disk 87757 Jan 14 17:29 imx8mp-verdin-nonwifi-mallow.dtb
-rwxrwx— 1 root disk 87782 Jan 14 17:29 imx8mp-verdin-nonwifi-yavia.dtb
-rwxrwx— 1 root disk 89187 Jan 14 17:29 imx8mp-verdin-wifi-dahlia.dtb
-rwxrwx— 1 root disk 88612 Jan 14 17:29 imx8mp-verdin-wifi-dev.dtb
-rwxrwx— 1 root disk 92724 Jan 14 17:29 imx8mp-verdin-wifi-ivy.dtb
-rwxrwx— 1 root disk 88229 Jan 14 17:29 imx8mp-verdin-wifi-mallow.dtb
-rwxrwx— 1 root disk 88250 Jan 14 17:29 imx8mp-verdin-wifi-yavia.dtb
drwxrwx— 2 root disk 3072 Jan 14 17:29 overlays
-rwxrwx— 1 root disk 118 Jan 14 18:31 overlays.txt
Hi @drew.tx,
In the attached text file, I have listed the items uboot sees in the /boot and /boot2 directories using ext4ls. I included the “ls -al” output for the /boot folder showing it contains the same files as /boot2. I do not know why the ext4ls outputs for /boot and /boot2 differ. Could uboot be pointing to a different location?
ext4ls_output.txt (2.0 KB)
Hi,
Not sure if this will be helpful or not, but have you looked into the generated image?
It is just a compressed tar file. Inside you will see a manifest that describes how each “partition image” is deployed.
Each of those subsequent archive file contains the content of what is written to the partitions.
I would check what is contained in those to see what files are deployed.
Also, how are you specifying where to put the boot files in the yocto build?
My understanding is that all the boot files are written to a /boot folder, but when building the image these are pulled out into the boot partition (which may explain why the /boot files on the rootfs are not there).
I believe you might be able to see what is happening by searching for do_image_boot in the build logs to identify the recipe script that is doing this.
Then you can modify as required to ensure the relevant files stay in the rootfs image.
I have not delved into that area myself, however I did a similar thing with an extra encrypted partition for a sort of factory restore process.
Regards,
Izzy
Hi @izzycoding,
Thank you for suggesting I look in the generated image. You are correct and the contents of the rootfs /boot folder in the compressed image mirror what the “extls” uboot command sees (i.e. not what is shown in the rootfs /boot folder after the system is fully booted). Perhaps the boot partition is being mounted at the /boot folder location resulting in it appearing that the files are present.
The commands I used to try to place the kernel and device tree files in the rootfs /boot folder were:
CORE_IMAGE_EXTRA_INSTALL += "
kernel-image
kernel-devicetree
"
Along along with a recipe to add the device tree overlay files.
I will look into what command removes those files and places them in the boot partition as you suggest.
Thank you!
Hi @izzycoding,
The build log references only my image recipe with do_image_bootfs. Do you know if the code to remove the files from /boot and add them to the boot partition is a standard Yocto option or something Toradex specific?
Thank you
Hi @Sutter99,
As far as I’m aware, the bootfs creation is a standard yocto thing.
There is likely a python script somewhere for generating the bootfs.
Off the top of my head I would do a search in your layers directory… looking for something like ‘[bootfs]’.
If I remember correctly, it is a set of •IMAGE• variables, and in there somewhere will be the bootfs configs which will point you to the function being called.
When I’m in the office tomorrow I will check where I did my changes to see if I can find where it might be.
A good place to start though might be at the tezi image recipe, as they have a similar thing in there to add the tezi image type support.
Can’t remember which of the many layers that was in.
I believe it was either the images one or the BSP one.
Regards,
Izzy
Hi @Sutter99
The standard processing of the boot files is part of Yocto but that assumes a single partition. For swupdate you will need something like I did here with a custom image type that ensures the boot files are copied into the actual root partitions instead of the boot.
Drew
Hi @aa
Drew Moseley
Toradex
Hi @izzycoding,
Thank you again for your help. I found a boolean within the image_type_tezi.bbclass called TEZI_USE_BOOTFILES. Setting this to false removes the boot partition. The contents of the rootfs /boot folder are then the same whether examined with uboot or using “ls -al” when fully booted.
Hi @drew.tx,
Thank you for the link to your code. I believe it will be very helpful.