Hi,
I created a minimal image with only below packages
IMAGE_INSTALL = "\
packagegroup-core-boot \
kernel-modules \
weston \
u-boot-fw-utils \
${CONMANPKGS} \
"
When I try to load the easy installer from USB stick, I am getting the below error. I can install the same image using SD card.
Is this an issue with U-boot or am I missing some package?
Hi @jesvinonnet ,
Just to confirm, what image are you trying to load from USB? Toradex Easy Installer or your minimal image?
If youâre trying to load Easy Installer to then install your image: the contents of your custom image shouldnât affect how Easy Installer loads.
Best regards,
Lucas Akira
Hi @lucas_a.tx,
I have my custom image already installed on the colibri imx8 board. Now I want to update it with new version. So I use a USB stick for that. In my USB stick, I have the Easy installer in the root folder and my custom image inside a folder. If I execute the ârun bootcmd_usb0â from the bootloader, then the colibri board first load the Easy installer and then it loads my image automatically (autoinstall = true). I can do the same using the SD card as well(bootcmd_mmc1). SD card works as expected. But with USB, I am getting the above error. But if I install the reference image from the toradex, then everything works as expected. So is this an issue with the bootloader along with my custom image(already installed image)? Or is the right way to update an image? Is there any another good approach to update an image locally?
Hi @jesvinonnet ,
I have my custom image already installed on the colibri imx8 board. Now I want to update it with new version. So I use a USB stick for that. In my USB stick, I have the Easy installer in the root folder and my custom image inside a folder.
OK, I understood your environment. From the logs you provided I can see that youâre using a different version of U-Boot (2022.04-6.4.0-devel+git.7bd2074193e1) than the one included with our reference images (U-Boot 2022.04-6.4.0+git.dc27426aa417). This difference in versions may be the cause of the issue.
Is there any specific reason to boot Easy Installer via an external media, like USB and SD? We recommend loading Toradex Easy Installer by putting the SoM in recovery mode instead, as detailed here:
Of course, once Easy Installer is loaded you install any image through USB, like you already did.
Best regards,
Lucas Akira
Hi @lucas_a.tx ,
I have a correction. I was previously using the old version of the reference multimedia image. It is a 5.7.2 + build 21 version (U-Boot 2020.04-5.7.2+git.33bb8e968332). USB is working fine on this version. But if I install the reference image that you mentioned earlier, then I have the same issue. It is a 6.4.0 + build 8 version (U-Boot 2022.04-6.4.0+git.dc27426aa417). Then it looks like there is some issue with u-boot-toradex. I am using the latest commit from the branch âtoradex_imx_lf_v2022.04â. I just fetched the kirkstone branch of the meta-toradex-nxp repo. I think the bootloader version is integrated inside this meta layer.
I rebuild the existing image with the old version of bootloader. I created a bbappend file for the u-boot-toradex and changed the branch "SRCBRANCH = âtoradex_imx_v2020.04_5.4.70_2.3.0â. Now the new image is working fine (U-Boot 2020.04-6.4.0-devel+git.ef0fe41d1aa7). We need to do something with the branch âtoradex_imx_lf_v2022.04â.
I am trying to load easy installer from external media because we want a seamless OS update. We have the board inside a machine and they are used by different customers. So I am looking for an approach for easy OS update for the users. Do you have any other better idea in this situation?
Hi @jesvinonnet ,
I am trying to load easy installer from external media because we want a seamless OS update. We have the board inside a machine and they are used by different customers. So I am looking for an approach for easy OS update for the users. Do you have any other better idea in this situation?
Right, in this situation it makes sense to load Easy Installer via USB.
Just to be sure, youâre not currently blocked by this issue, correct? It seems you managed to get around this by using an older version of the bootloader.
From your results it really looks related to a recent update to u-boot-toradex. Iâll try doing some tests on my side to see if I can reproduce your results.
Best regards,
Lucas Akira
Hi @jesvinonnet ,
Using the following hardware:
I was able to reproduce your issue with these U-Boot versions:
dc27426aa417 is the one we currently use in our BSP 6 ref. images and the same one you tried. b754415d40d5 and de56eeed33cd are one and two commits before that, respectively.
I tested the last two commits in particular because they made changes related to Colibri iMX8X, so I wanted to see if the issue wouldnât happen if I reverted them. Unfortunately, it occurs anyway.
Like you said, this problem does not happen with the U-Boot version from BSP 5.
As an example, the logs I received are very similar to what you reported:
U-Boot 2022.04-6.4.0-devel+git.de56eeed33cd (Sep 22 2023 - 18:33:25 +0000)
CPU: NXP i.MX8QXP RevC A35 at 1200 MHz at 33C
DRAM: 2 GiB
Core: 238 devices, 19 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In: serial@5a090000
Out: serial@5a090000
Err: serial@5a090000
Model: Toradex 0038 Colibri iMX8QXP 2GB WB IT V1.0D
Serial#: 06995807
BuildInfo:
- SCFW 6638c032, SECO-FW c9de51c0, IMX-MKIMAGE 3bfcfccb, ATF 3c1583b
- U-Boot 2022.04-6.4.0-devel+git.de56eeed33cd
Net: eth0: ethernet@5b040000 [PRIME]
Normal Boot
Hit any key to stop autoboot: 0
Colibri iMX8X #
Colibri iMX8X #
Colibri iMX8X # run bootcmd
bootcmd bootcmd_dhcp bootcmd_mfg bootcmd_mmc0 bootcmd_mmc1 bootcmd_usb0
Colibri iMX8X # run bootcmd_usb0
starting USB...
Bus usb@5b0d0000: USB EHCI 1.00
Bus usbh3: XHCI-imx8 init hccr 0x000000005b130000 and hcor 0x000000005b130080 hc_length 128
Register 2000820 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@5b0d0000 for devices... 1 USB Device(s) found
scanning bus usbh3 for devices... WARN halted endpoint, queueing URB anyway.
Unexpected XHCI event TRB, skipping... (fd6cda00 00000000 13000000 01008400)
"Synchronous Abort" handler, esr 0x96000007
elr: 0000000080067e64 lr : 0000000080067e64 (reloc)
elr: 00000000ffee7e64 lr : 00000000ffee7e64
x0 : 0000000000000000 x1 : 00000000000003e8
x2 : 0000000000000040 x3 : 000000000000003f
x4 : 00000000fd6cb540 x5 : 00000000fd6b8810
x6 : 0000000000001800 x7 : 00000000fd684c20
x8 : 0000000000000000 x9 : 0000000000000008
x10: 0000000000000000 x11: 00000000ffffffe8
x12: 0000000000000010 x13: 00000000fd68427c
x14: 00000000fd686450 x15: 0000000000000021
x16: 00000000ffed6888 x17: 0000000000000000
x18: 00000000fd69dd90 x19: 00000000fd6cb540
x20: 00000000fd6f0340 x21: 0000000000000000
x22: 00000000fd6cbfb0 x23: 0000000000000000
x24: 0000000080000283 x25: 00000000fd684f00
x26: 0000000000010c04 x27: 0000000000000000
x28: 00000000fd684d80 x29: 00000000fd684c60
Code: 97ffff15 52800401 aa1303e0 97ffffa2 (b9400c00)
Resetting CPU ...
resetting ...
U-Boot 2022.04-6.4.0-devel+git.de56eeed33cd (Sep 22 2023 - 18:33:25 +0000)
[...]
Iâll report this result internally for further investigation. Iâll update here if we make any progress.
Best regards,
Lucas Akira
Hi @jesvinonnet ,
While the team is currently looking at your issue, some quick notes:
About using Toradex Easy Installer to do OS updates: keep in mind that Easy Installer wasnât developed with this use-case in mind, so we canât guarantee support for this method in the long run.
I previously said that it makes sense for your use-case (and it does), but we recommend using a more robust solution if you can.
For instance, our Torizon OS images support OS updates either via Torizon Cloud if your modules are connected to a network, or via an external device via Secure Offline Updates. Torizon OS is also based in our BSP reference images, so some things will be familiar to you if youâre already customizing our BSP. Let us know if youâre interested.
Best regards,
Lucas Akira
Hello @jesvinonnet ,
I have been informed that the issue has been solved.
Best regards,
Josep