Table that lists package versions for different machines doesn’t have a package version for verdin-am62. Is it no longer supported ? I couldn’t find any info on that…
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
The Verdin AM62 module is indeed still supported. According to the documentation, the bootloader package version for the AM62 aligns with other i.MX-based modules when performing major OS upgrades from version 6.x.y to 7.x.y. The recommended package version to use is 2024.07-7.0.0+git.3f772959501c-r1. You can find more details in the Toradex documentation.
For your reference, the package name format should be bootloader/<MACHINE>/u-boot-ota.bin, where <MACHINE> is the specific name of your machine. To determine your exact machine name, you can run the following command on your device:
echo $MACHINE
This will help you ensure that you are using the correct package for your specific hardware configuration.
Best regards,
Toradex AI Assistant
Thanks Mr. Computer,
I haven’t found any documents that explicitly mention alignment between verdin am62 and imx bootloaders. Even if they do, there is an imx8mm and imx8mp bootloader. Do they both align with am62?
Greetings @stasgil,
The reason the verdin AM62 is not mentioned in the Bootloader Updates article, is simply because Bootloader Updates have not been implemented yet for the Verdin AM62.
The bootloader structure of the Verdin AM62 is a bit different from the previous i.MX based devices. Therefore we couldn’t just immediately support it using the same processes. We do intend to eventually add support to it for this feature.
Typically we provide bootloader updates since updating the bootloader can be needed when going between major versions of the software (i.e 6.X.Y → 7.X.Y). Is this what you want here? Or do you require Bootloader Updates for other purposes?
For what it’s worth I recall we determined that a bootloader update wasn’t strictly required for the Verdin AM62 to go from 6.X.Y to 7.X.Y. If you need it for other purposes though it would be appreciated if you could elaborate on your use-case.
Best Regards,
Jeremias
Hi Jeremias,
Thanks for the explanation. I was planning to update bootloader exactly for the purpose of updating OS 6 to OS 7. The reason i thought the update is necessary is because when i change the input of my tcbuild.yml file to torizon-docker-verdin-am62-Tezi_7.1.0+build.4.tar and then update device with this image, bootloader seems to fail to start the kernel.
U-Boot SPL 2023.04-ti-gc997b1b09fba (Jan 01 1970 - 00:00:00 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.8--v09.02.08 (Kool Koala)')
Changed A53 CPU frequency to 1250000000Hz (T grade) in DT
SPL initial stack usage: 13440 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 9 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...
NOTICE: BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE: BL31: Built : 00:00:00, Jan 1 1970
U-Boot SPL 2023.04-ti-gc997b1b09fba (Jan 01 1970 - 00:00:00 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.8--v09.02.08 (Kool Koala)')
SPL initial stack usage: 1920 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
U-Boot 2023.04-ti-gc997b1b09fba (Jan 01 1970 - 00:00:00 +0000)
SoC: AM62X SR1.0 HS-FS
DRAM: 1 GiB
Core: 143 devices, 31 uclasses, devicetree: separate
MMC: mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... OK
In: serial@2800000
Out: serial@2800000
Err: serial@2800000
Model: Toradex 0075 Verdin AM62 Dual 1GB WB IT V1.1B
Serial#: 15361822
Carrier: Toradex Yavia V1.0A, Serial# 35408046
am65_cpsw_nuss ethernet@8000000: K3 CPSW: nuss_ver: 0x6BA01103 cpsw_ver: 0x6BA81103 ale_ver: 0x00290105 Ports:2 mdio_freq:1000000
Net:
Warning: ethernet@8000000port@1 MAC addresses don't match:
Address in ROM is 1c:63:49:1f:df:05
Address in environment is 00:14:2d:ea:67:1e
eth0: ethernet@8000000port@1 [PRIME]Could not get PHY for ethernet@8000000port@1: addr 7
am65_cpsw_nuss_port ethernet@8000000port@2: phy_connect() failed
Saving Environment to MMC... Writing to MMC(0)... OK
Hit any key to stop autoboot: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
973 bytes read in 10 ms (94.7 KiB/s)
## Executing script at 90280000
7644 bytes read in 11 ms (677.7 KiB/s)
69183 bytes read in 12 ms (5.5 MiB/s)
108 bytes read in 11 ms (8.8 KiB/s)
Working FDT set to 90200000
Applying Overlay: verdin-am62_pin_names_overlay.dtbo
1154 bytes read in 12 ms (93.8 KiB/s)
Applying Overlay: invendor_verdin-am62_overlay.dtbo
4262 bytes read in 12 ms (346.7 KiB/s)
Applying Overlay: custom-kargs_overlay.dtbo
204 bytes read in 11 ms (17.6 KiB/s)
11059985 bytes read in 74 ms (142.5 MiB/s)
13160245 bytes read in 84 ms (149.4 MiB/s)
Uncompressing Kernel Image
## Flattened Device Tree blob at 90200000
Booting using the fdt blob at 0x90200000
Working FDT set to 90200000
Loading Ramdisk to 98256000, end 98ee2f35 ... OK
Loading Device Tree to 0000000098222000, end 0000000098255fff ... OK
Working FDT set to 98222000
Starting kernel ...
Message above is the result of
- Installing an image based on torizon-core-docker-verdin-am62-Tezi_6.8.0+build.22.tar to a Verdin AM62 module over a USB media.
- Booting device
- Initiating a device update in the torizon cloud to a new image that uses torizon-docker-verdin-am62-Tezi_7.1.0+build.4.tar
I get the same result if i
- replace my input image to torizon-docker-verdin-am62-Tezi_7.1.0+build.4.tar
- Build image
- Install it over a USB media
Hmm it’s possible that something might have changed since we last tested this ourselves. That said there’s something you said that I want you to explain more:
I get the same result if i
replace my input image to torizon-docker-verdin-am62-Tezi_7.1.0+build.4.tar
Build image
Install it over a USB media
So you built your custom image using TorizonCore Builder, using a 7.1.0 image as an input. You then install this custom image over USB media, which I take to understand as you using Toradex Easy Installer, correct?
If that is the case maybe the issue here is something else entirely. If you are using the 7.1.0 image as an input, then this should have the 7.1.0 bootloader as well when you install it via Toradex Easy Installer. This sounds like some customization you are doing with TorizonCore Builder is not compatible with 7.1.0. Though I would need to know more about what you are doing with TorizonCore Builder to comment further.
Best Regards,
Jeremias
Yes, I take the module into the recovery mode and install torizon easy installer on it, then plug in USB stick and the image i have automatically installs. I had an assumption that this process would install new bootloader straight away, but I wasn’t sure.
In addition to filesystem changes, I have some device tree overlays and a kernel module compiled into the image. I guess this might be the likely culprit.
Are there any known breaking changes? Looking through OS 7 / BSP 7 release notes I haven’t noticed anything obvious
It seems that the problem is in using the mallow device tree overlay
device-tree:
include-dirs:
- linux/arch/arm64/boot/dts/ti/
- linux/include/
custom: linux/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts
For our PCB design mallow board was used as a reference, hence the usage of the overlay.
I suspect this might have something to do with OS7 using kernel version 6.6. Will have to dig in.
I suspect this might have something to do with OS7 using kernel version 6.6. Will have to dig in.
Did you update the version of the Linux kernel sources where you are getting linux/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-mallow.dts from?
If you are using an older version of this, it could explain the issue you have been observing on your device.
I had an assumption that this process would install new bootloader straight away, but I wasn’t sure.
Just to confirm this is correct. When you install an image with Toradex Easy Installer it should re-flash the entire device, bootloader included. Therefore this is most definitely an issue with your device tree and not the bootloader as you’ve already determined.
Best Regards,
Jeremias
Hi Jeremias,
That is my bad, it seems i didn’t update the kernel submodule… After updating to 6.6 branch the image booted fine, thanks for your help and sorry for bothering.
That is my bad, it seems i didn’t update the kernel submodule… After updating to 6.6 branch the image booted fine, thanks for your help and sorry for bothering.
No worries this is an easy thing to miss when going between kernel versions. Glad I was able to help point you in the right direction.
Best Regards,
Jeremias