Automated NAND flashing for iMX6Ull

Technical Support
, , ,
1

Hello,
I have a task to automate the initial flashing and testing for a large number of iMX6Ull devices. I prefer not to use the graphical UI interface of TEZI for that task, because it requires manual operations from operator. My goal is to automate the initial setup process as much as possible.

I followed this article :

I took ToradexEasyInstaller 6.6, modified to include my custom script that downloads from tftp the uboot, zImage and the rootfs and writes them to flash. But later on the device does not boot to uboot-1.

  1. flash_eraseall /dev/mtd0
  2. nandwrite /dev/mtd1 config_block (previously I have read the valid Device Config data with nanddump)
  3. nandwrite -p /dev/mtd2 u-boot-nand.imx (u-boot1)
  4. nandwrite -p /dev/mtd3 u-boot-nand.imx (u-boot2)
  5. nandwrite -p /dev/mtd4 u-boot-env.bin
  6. Later setup the ubi part.

The u-boot-nand.imx is taken unmodified from TEZI.

After power-on, the device does not try to load u-boot1, some condition is not met. It stays in Serial BootROM protocol, from where I can download next TEZI attempt. Can you please point me what should be done to boot to /dev/mtd2(u-boot1).

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello,

Automating the flashing process for a large number of iMX6ULL devices, especially when aiming to avoid manual operations, requires careful consideration of the NAND flash programming sequence and ensuring that all necessary components are correctly written to the flash.

Given the steps you’ve followed, it seems there might be a discrepancy in the flashing process or the U-Boot configuration that prevents the device from booting correctly. Here are a few suggestions and checks to ensure the automation process works as intended:

  1. Verify U-Boot Binary Compatibility: Ensure that the u-boot-nand.imx binary is compatible with the iMX6ULL devices you’re working with. Even though it’s taken unmodified from TEZI, it’s crucial to confirm it matches the hardware revision and configuration of your specific modules.

  2. Correct MTD Partitioning: Double-check that the MTD partitioning scheme used matches the expected layout for U-Boot and other components. The NAND flash must be partitioned correctly for U-Boot to find its environment and for the system to boot properly.

  3. U-Boot Environment: The U-Boot environment (u-boot-env.bin) must be correctly configured for your specific setup. This includes setting the correct boot commands and ensuring that the environment is written to the correct MTD partition. It might be beneficial to compare the environment settings used in a manually flashed device (that boots correctly) with the one you’re automating.

  4. Flash Erase and Write Operations: Ensure that the flash_eraseall and nandwrite commands are used correctly:

    • The flash_eraseall /dev/mtd0 command will erase the entire NAND flash, including the U-Boot area. Make sure this is intended, as erasing the U-Boot partition without correctly rewriting it will prevent booting.
    • Verify that the nandwrite operations for U-Boot and the environment are targeting the correct MTD partitions. The partition numbers (/dev/mtd1, /dev/mtd2, etc.) should match the intended layout for your device.

  5. Check for Error Messages: Monitor the serial console output during boot. The BootROM and U-Boot stages often provide error messages or hints about what might be going wrong. This can offer clues about missing steps or misconfigurations.

  6. Review U-Boot Environment Settings: After flashing, but before rebooting the device, it might be useful to access the U-Boot environment (if possible) and

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

Updating NAND-based modules from userspace | Toradex Developer Center.

3

The u-boot-nand.imx and the environment file are for the exact device. Using the graphical interface of TEZI over VNC I flash successfully the device with the same files

4

Hello @plamen,

Welcome to the Toradex Community!

When using the Toradex Easy Installer, you can make the installation unattended.
To do this, you need two changes in your image:

  1. Add a "autoinstall": true to your image’s image.json file.
  2. Add a reboot -f command to your image’s wrapup.json file.

Here is an example when this is done for the Reference Minimal Image 6.6.0 for the Verdin iMX8MP:

image.json:

{
    "config_format": "4",
    "autoinstall": true,
    "name": "Toradex Embedded Linux Reference Minimal Image",
    "description": "Minimal image without graphical interface that just boots",
    "version": "6.6.0+build.12",
    "release_date": "2024-04-02",
    "u_boot_env": "u-boot-initial-env-sd",
    "prepare_script": "prepare.sh",
    "wrapup_script": "wrapup.sh",
    "marketing": "marketing.tar",
    "icon": "toradexlinux.png",
    "license": "LA_OPT_NXP_SW.html",
    "supported_product_ids": [
        "0058",
        "0061",
        "0063",
        "0064",
        "0065",
        "0066",
        "0070"
    ],
    "blockdevs": [
        {
            "name": "emmc",
            "partitions": [
                {
                    "partition_size_nominal": 48,
                    "want_maximised": false,
                    "content": {
                        "label": "BOOT",
                        "filesystem_type": "FAT",
                        "mkfs_options": "",
                        "filename": "Reference-Minimal-Image-verdin-imx8mp.bootfs.tar.xz",
                        "uncompressed_size": 11.875
                    }
                },
                {
                    "partition_size_nominal": "512",
                    "want_maximised": true,
                    "content": {
                        "label": "RFS",
                        "filesystem_type": "ext4",
                        "mkfs_options": "-E nodiscard",
                        "filename": "Reference-Minimal-Image-verdin-imx8mp.tar.xz",
                        "uncompressed_size": 170.6640625
                    }
                }
            ]
        },
        {
            "name": "emmc-boot0",
            "erase": true,
            "content": {
                "filesystem_type": "raw",
                "rawfiles": [
                    {
                        "filename": "imx-boot",
                        "dd_options": "seek=0"
                    }
                ]
            }
        }
    ]
}

wrapup.sh:

#!/bin/sh

reboot -f
exit 0

You can also read more about production programming Toradex SoMs on the following page: Production Programming for Linux | Toradex Developer Center

Best Regards,
Bruno

5

Hello,
I tried the procedure “Unattended flashing over Ethernet” from the document that you referenced.

I setup nginx server and setup an image with image.json autoinstall set to true.
image.json (2.7 KB)

The only detour from the document is that I didn’t setup dnsmasq but changed TEZI /etc/host to have this record:

192.168.11.2 tezi.toradex.com

After reboot it doesn’t start automatically the update procedure. If I start VNC I see the status:

Waiting for external media or network…

If I go to Feeds, select Toradex Image Server and click OK the update starts. It downloads the image from nginx, flashes the devices and boots into the operating system. What do I miss to start immediately the update procedure?

6

Hello @plamen,

While changing the DNS could be a solution, using zeroconf should be the most straight-forward way to do this.

The easiest way to get the server setup properly is to use the TorizonCore Builder serve command, even if you are not using a Torizon image.

You probably already have this configured, but here is an example of the file structure that can be used for this:

The images need to be listed in the image-list.json file, as can be seen in the following example:

File Structure:

$  tree -L 1 images_server
images_server
├── image_list.json
└── Verdin-iMX8MP_Reference-Minimal-Image-Tezi_6.6.0+build.12

image_list.json:

{
    "config_format": 1,
    "images": [
        "Verdin-iMX8MP_Reference-Minimal-Image-Tezi_6.6.0+build.12/image.json"
    ]
}

Best Regards,
Bruno

7

Hello,
Thank you for your help. In my case the torizon builder server didn’t fix the problem - it just added another Custom Feed Image list, but automatic update was not triggered.

In my case the problem appeared to be that I attach to the device using only the USB NCIM interface usb0 with IP 192.168.11.1 . The ethernet interface eth0 is not connected, doesn’t have IP address and tezi is waiting for it before starting an automatic update.

What I did is in /etc/rc.local after the start of /usr/bin/tezi I assign some dummy IP address to eth0. After that the update immediately starts.

8

Hello @plamen,

Thanks for sharing this information.
We have not tested this setup when using only USB NCIM (or RNDIS for older versions).

Is the workaround you used a viable alternative for you?

Best Regards,
Bruno

9

Hello,
Yes - the workaround is working, the automatic update runs smoothly.

1 Like