Flashing u-boot manually on verdin am62

Technical Support
,
1

I need to update u-boot on my verdin am62 module to improve boot time. I have patched u-boot and completed a Yocto build that produces new u-boot binaries. I have a few questions about how to proceed.

In your documentation, you use these commands to update from within u-boot

> tftpboot ${loadaddr} tiboot3-am62x-gp-verdin.bin
> run update_tiboot3

> tftpboot ${loadaddr} tispl.bin
> run update_tispl

> tftpboot ${loadaddr} u-boot.img
> run update_uboot

However, in an image.json file I downloaded from a Tezi image for the AM62, I also see the tiboot3-am62x-hs-fs-verdin.bin file installed. What’s the difference between those files? Is the gp version the correct one to use here?

After I complete a manual update, I would like to automate this process somewhat. To flash my linux images, I already use a dd command like this

dd if=my-image.rootfs.wic of=/dev/mmcblk0 bs=1M

Is it possible to use dd to flash u-boot as well? I see in the image.json Tezi file that dd_options are specified for each raw file, but I’m not sure how to translate those to a dd command that writes all the files. Should they just be concatenated before writing? This is the section that I’m referencing:

"name": "mmcblk0boot0",
            "erase": true,
            "content": {
                "filesystem_type": "raw",
                "rawfiles": [
                    {
                        "filename": "tiboot3-am62x-gp-verdin.bin",
                        "dd_options": "seek=0",
                        "product_ids": "0069"
                    },
                    {
                        "filename": "tiboot3-am62x-gp-verdin.bin",
                        "dd_options": "seek=0",
                        "product_ids": "0071"
                    },
                    {
                        "filename": "tiboot3-am62x-gp-verdin.bin",
                        "dd_options": "seek=0",
                        "product_ids": "0072"
                    },
                    {
                        "filename": "tiboot3-am62x-hs-fs-verdin.bin",
                        "dd_options": "seek=0",
                        "product_ids": "0073"
                    },
                    {
                        "filename": "tiboot3-am62x-hs-fs-verdin.bin",
                        "dd_options": "seek=0",
                        "product_ids": "0074"
                    },
                    {
                        "filename": "tiboot3-am62x-hs-fs-verdin.bin",
                        "dd_options": "seek=0",
                        "product_ids": "0075"
                    },
                    {
                        "filename": "tiboot3-am62x-hs-fs-verdin.bin",
                        "dd_options": "seek=0",
                        "product_ids": "0076"
                    },
                    {
                        "filename": "tispl.bin",
                        "dd_options": "seek=1024"
                    },
                    {
                        "filename": "u-boot.img",
                        "dd_options": "seek=5120"
                    }
                ]
            }
        }

I’m a little nervous about just trying things here since I don’t want to brick my board. If I do incorrectly install something, is there any way to recover?

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

  1. Difference between gp and hs-fs versions:

    The tiboot3-am62x-gp-verdin.bin and tiboot3-am62x-hs-fs-verdin.bin files represent different configurations of the bootloader for the Verdin AM62 module. The gp version typically stands for “General Purpose,” which is used for standard, non-secure boot processes. The hs-fs version stands for “High Security - Field Secure,” which is used for secure boot processes. If your application does not require secure boot features, the gp version is the correct one to use.

  2. Using dd to flash U-Boot:

    Yes, you can use the dd command to flash U-Boot, but you need to be careful with the offsets specified in the dd_options. Each file needs to be written to a specific location on the storage device. The dd_options in the image.json file specify the seek parameter, which determines the offset in blocks where the file should be written.

    For example, to write the tiboot3-am62x-gp-verdin.bin file, you would use:

    dd if=tiboot3-am62x-gp-verdin.bin of=/dev/mmcblk0boot0 bs=1M seek=0

    Similarly, for tispl.bin and u-boot.img, you would use:

    dd if=tispl.bin of=/dev/mmcblk0boot0 bs=1M seek=1024
dd if=u-boot.img of=/dev/mmcblk0boot0 bs=1M seek=5120

    Ensure that you replace /dev/mmcblk0boot0 with the correct device path for your module.

  3. Recovery:

    If you incorrectly install something and the board does not boot, you can use the Toradex Easy Installer in recovery mode to restore the module. This involves booting the module into recovery mode and using a host PC to re-flash the module with a known good image. Always ensure you have a backup of your working images and configurations before attempting manual updates.

Please, also check if these links can help you solve your problem:

https://docs.u-boot.org/en/v2024.04/board/ti/j721s2_evm.html

Cannot update uboot.

3

I followed the steps at (2) above, but it doesn’t seem to have worked.

root@localhost:/opt# echo 0 > /sys/class/block/mmcblk0boot0/force_ro
root@localhost:/opt# dd if=tiboot3-am62x-gp-verdin.bin of=/dev/mmcblk0boot0 bs=1M seek=0
0+1 records in
0+1 records out
264881 bytes (265 kB, 259 KiB) copied, 0.25179 s, 1.1 MB/s
root@localhost:/opt# dd if=tispl.bin of=/dev/mmcblk0boot0 bs=1M seek=1024
dd: /dev/mmcblk0boot0: cannot seek: Invalid argument
0+0 records in
0+0 records out
0 bytes copied, 0.000351065 s, 0.0 kB/s
root@localhost:/opt# dd if=tispl.bin of=/dev/mmcblk0boot0 seek=1024
2016+1 records in
2016+1 records out
1032555 bytes (1.0 MB, 1008 KiB) copied, 0.579845 s, 1.8 MB/s
root@localhost:/opt# dd if=u-boot.img of=/dev/mmcblk0boot0 seek=5120
1919+1 records in
1919+1 records out
983003 bytes (983 kB, 960 KiB) copied, 0.574152 s, 1.7 MB/s

I power cycled the board and now it won’t boot. Maybe because I used a block size of 1M in the first command but not the others? Or maybe because I didn’t erase mmcblk0boot0 before starting? I’ll put my board into recovery mode and see if I can get it back to a usable state.

I guess it’s possible it could also be that my patch is no good? Here’s what it is

From d7fe741a8bb675f30c30217f94b8d389e7b00afa Mon Sep 17 00:00:00 2001
From: sarah
Date: Mon, 14 Oct 2024 07:23:40 -0700
Subject: [PATCH] boot optimizations

---
 configs/verdin-am62_a53_defconfig | 8 +++++---
 include/configs/verdin-am62.h     | 4 ++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/configs/verdin-am62_a53_defconfig b/configs/verdin-am62_a53_defconfig
index 77d61595d33..45641d84930 100644
--- a/configs/verdin-am62_a53_defconfig
+++ b/configs/verdin-am62_a53_defconfig
@@ -39,7 +39,9 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x81000000
 CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTDELAY=1
+CONFIG_BOOTDELAY=0
+CONFIG_ZERO_BOOTDELAY=y
+CONFIG_UBI_SILENCE_MSG=y
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="test -n ${fdtfile} || setenv fdtfile k3-am625-verdin-${variant}-${fdt_board}.dtb"
 CONFIG_LOG=y
@@ -146,8 +148,8 @@ CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
-CONFIG_I2C_EEPROM=y
-CONFIG_SPL_I2C_EEPROM=y
+# CONFIG_I2C_EEPROM is not set
+# CONFIG_SPL_I2C_EEPROM is not set
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_SPL_MMC_IO_VOLTAGE=y
diff --git a/include/configs/verdin-am62.h b/include/configs/verdin-am62.h
index a2cbcce33d1..1982af40d0f 100644
--- a/include/configs/verdin-am62.h
+++ b/include/configs/verdin-am62.h
@@ -53,8 +53,8 @@
 	"boot_script_dhcp=boot.scr\0" \
 	"console=ttyS2\0" \
 	"fdt_board=dev\0" \
-	"setup=setenv setupargs console=tty1 console=${console},${baudrate} " \
-		"consoleblank=0 earlycon=ns16550a,mmio32,0x02800000\0" \
+	"setup=setenv setupargs console=${console},${baudrate} " \
+		"consoleblank=0 earlycon=ns16550a,mmio32,0x02800000 quiet\0" \
 	"update_tiboot3=askenv confirm Did you load tiboot3.bin (y/N)?; " \
 		"if test \"$confirm\" = \"y\"; then " \
 		"setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt " \
-- 
2.25.1

Update: I put my module into recovery mode and used the easy installer to flash a toradex-provided minimal image. Then I copied my desired boot files to an SD card and tried to install them at u-boot. The commands are from here

Verdin AM62 # ls mmc 1
            System Volume Information/
   983003   u-boot.img
   264881   tiboot3.bin
   264881   tiboot3-am62x-gp-verdin.bin
  1032555   tispl.bin

4 file(s), 1 dir(s)

Verdin AM62 # mmc dev 0 1
switch to partitions #1, OK
mmc0(part 1) is current device
Verdin AM62 # fatload mmc 1 ${loadaddr} tiboot3-am62x-gp-verdin.bin
264881 bytes read in 14 ms (18 MiB/s)
Verdin AM62 # mmc write ${loadaddr} 0x0 0x400

MMC write: dev # 0, block # 0, count 1024 ... 1024 blocks written: OK
Verdin AM62 # fatload mmc 1 ${loadaddr} tispl.bin
1032555 bytes read in 22 ms (44.8 MiB/s)
Verdin AM62 # mmc write ${loadaddr} 0x400 0x1000

MMC write: dev # 0, block # 1024, count 4096 ... 4096 blocks written: OK
Verdin AM62 # fatload mmc 1 ${loadaddr} u-boot.img
983003 bytes read in 21 ms (44.6 MiB/s)
Verdin AM62 # mmc write ${loadaddr} 0x1400 0x2000

MMC write: dev # 0, block # 5120, count 8192 ... 8192 blocks written: OK

There were a bunch of issues during boot, and when I power cycled the board, it wouldn’t boot.

Verdin AM62 # boot
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
No EFI system partition
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
bad MBR sector signature 0x76e8
bad MBR sector signature 0x76e8
Loading Boot0000 'mmc 0' failed
WARN endpoint is halted
WARN endpoint is halted
Resetting EP 3...
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
Resetting EP 3...
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
Resetting EP 3...
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
WARN endpoint is halted
Loading Boot0001 'usb 0' failed
Loading Boot0002 'mmc 1' failed
EFI boot manager: Cannot load any image
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
5935 bytes read in 11 ms (526.4 KiB/s)
## Executing script at 90280000
Loading DeviceTree: k3-am625-verdin-nonwifi-dev.dtb
71247 bytes read in 12 ms (5.7 MiB/s)
82 bytes read in 10 ms (7.8 KiB/s)
Working FDT set to 90200000
Applying Overlay: verdin-am62_dsi-to-hdmi_overlay.dtbo
3050 bytes read in 11 ms (270.5 KiB/s)
Applying Overlay: verdin-am62_spidev_overlay.dtbo
560 bytes read in 11 ms (48.8 KiB/s)
7838556 bytes read in 66 ms (113.3 MiB/s)
Bootargs: root=PARTUUID=78f63d8f-02 ro rootwait console=tty1 console=ttyS2,115200
   Uncompressing Kernel Image to 0
## Flattened Device Tree blob at 90200000
   Booting using the fdt blob at 0x90200000
Working FDT set to 90200000
   Loading Device Tree to 0000000098e60000, end 0000000098e94fff ... OK
Working FDT set to 98e60000

Starting kernel ...
4

Hey @sarah,

When you say you have patched your u-boot. Are you referring to our documentation on patching u-boot for upstream? From our documents on Building U-boot (same link, paragraph above) the AM-62 should use the downstream sources. Can you verify which one you are using?

For deploying the u-boot binary to an image, you can integrate it into a Toradex easy installer image. Via the guide here.

I think it would be very hard to brick the board to where it won’t go into recovery mode. When you go into recovery mode, you can load the Toradex Easy Installer, it runs completely in memory and can flash a default image back to the module.

-Eric

5

Hi Eric, thanks for your reply!

I patched u-boot using Yocto. I created a bbappend file, u-boot-toradex-ti_%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI:append = " \
                   file://0001-boot-optimizations.patch \
                   "

The contents of 0001-boot-optimizations.patch is what I pasted in my previous reply. To generate this patch, I cloned the u-boot-toradex repo and checked out to the commit referenced in the u-boot-toradex-ti_2023.04.bb recipe.

SRC_URI = "git://git.toradex.com/u-boot-toradex.git;protocol=https;branch=${SRCBRANCH}"
SRCREV = "ca551722e0b5341282a2dd346ddd1897db47cb5b"
SRCREV:use-head-next = "${AUTOREV}"
SRCBRANCH = "toradex_ti-u-boot-2023.04"

I then made my changes and used git format-patch to generate the patch. The u-boot binaries I used in my attempted updates are those generated by the Yocto build at build/deploy/images/verdin-am62/.

I can give the easy installer a try. Would you expect the binaries generated by my Yocto build to work with the easy installer?

My board is definitely not bricked! It worked to use recovery mode to get back to a usable state.

6

Hey @sarah,

The u-boot branch looks like the correct one. The yocto build will mesh well with the Tezi image. If you do a full bitbake on the image, the same u-boot binaries will included in the bitbake tezi generated image.

-Eric

7

hey @sarah,

Were you able to get your customized u-boot flashed onto the module/image?

-Eric

8

Hi Eric, thanks for following up. Other boot optimizations have proven to be sufficient for this stage of my project so I haven’t had a chance to work any more on customizing u-boot. Hopefully I’ll come back to it later this year.