I have been working on a project which uses the Toradex Colibri IMX6ULL. I have flashed a custom Linux distro to the SOM which was built using Yocto.
Also I have configured the setup so that it can be loaded using NFS and TFTP.
Now I am trying to find a way to write the kernel, RootFS directly to the flash from u-boot.
So for that I have setup the tftp server, copied the kernel image(zImage), device tree file(dtb) and the root filesystem(image.tar.xz) into the memory via TFTP from the
build machine. Then I am loading it to the NAND flash by doing the following steps from u-boot :
ubi part ubi;
nand erase.part ubi
setenv filesize 7F2728; ubi write ${kernel_addr_r} kernel ${filesize}
setenv filesize 1F24954; ubi write ${rootfs_addr_r} rootfs ${filesize}
setenv filesize B6FC ; ubi write ${fdt_addr_r} dtb ${filesize}
Then on ‘boot’, the Kernel is loading up, but then after 2-3 seconds, ‘Kernel Panic’ happens and in the boot logs, the following error is displayed:
[ 2.166253] ubi0: scanning is finished
[ 2.170427] ubi0 error: ubi_read_volume_table: the layout volume was not found
[ 2.179401] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd4, error -22
[ 2.186650] UBI error: cannot attach mtd4
[ 2.192931] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 2.203612] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -19
[ 2.211838] Please append a correct "root=" boot option; here are the available partitions:
Kindly look into the above issue and advise a proper method for flashing the RFS.
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?
Hand-shake,
The issue you’re encountering typically arises from a misconfiguration in the UBI (Unsorted Block Images) filesystem setup or an incorrect root filesystem path in the boot arguments. Here are some steps to troubleshoot and resolve the kernel panic due to the root filesystem not being found:
Verify UBI Filesystem Creation: Ensure that the root filesystem (rootfs) you’re writing to the NAND flash is correctly prepared for UBI. The rootfs should be an UBI image, not a raw filesystem image like ext4 or a compressed archive (e.g., image.tar.xz). You can create an UBI image from your rootfs using the mkfs.ubi tool, specifying the appropriate volume size, name, and other parameters as needed.
Correct U-Boot Environment Variables: The boot arguments (bootargs) passed to the kernel must correctly specify the root device. For a NAND flash using UBI, this typically looks like root=ubi0:rootfs rootfstype=ubifs. Ensure your bootargs include these parameters correctly. You might need to adjust the root= parameter if your UBI volume name or UBI device number differs.
Check UBI Volume Creation: After writing the kernel and device tree, ensure that the UBI volumes for the rootfs (and any other filesystems) are correctly created and recognized by UBI. You can use U-Boot commands like ubi part ubi and ubi info to list UBI volumes and verify that the rootfs volume exists and is correctly sized.
Kernel Configuration: Ensure your kernel is configured with support for UBI and UBIFS, as well as the necessary MTD subsystem options. The kernel must be able to recognize and mount UBIFS volumes at boot.
U-Boot Version: Verify that you’re using a U-Boot version compatible with your operations. Some versions might have bugs or limitations affecting UBI operations. You mentioned using commands like ubi write, which should be supported, but ensuring compatibility is crucial.
Debugging Boot Arguments: Temporarily modify your boot arguments to enable early printk or console output to see more detailed kernel messages during boot. This can help identify the point at which the boot process fails.
Revisit the Flashing Process: If the issue persists, revisit the flashing process step by step, ensuring each command is executed correctly and that the sizes (filesize) specified for kernel
Please, also check if these links can help you solve your problem:
Thanks for the quick reply!
But I have some queries in them :
1. For using the mkfs.ubi tool, what should be the volume size, name, and other parameters as needed for Colibri imxu6ll device.
2. Also when copying the RFS image using TFTP boot to ${rootfs_addr_r}, what should be the value of the RFS address for th Colibri imx6ull 512MB device.
3. Even after specifying the bootargs, root=ubi0:rootfs rootfstype=ubifs. Still the issue remain, this error comes :
[ 2.203612] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -19
[ 2.211838] Please append a correct "root=" boot option; here are the available partitions:
Thanks for the reply.
Normally we are using the ‘Toradex Easy Installer’ for the flashing process.
But due to project purposes, the method we are looking is for production programming, so we did not find ‘Toradex Easy Installer’ suitable for that.
So we are looking for an option available, where we can flash from u-boot using TFTP, which is why we are looking into the above said method.
Or is there any alternative option available?
What exactly is requirement for production programming purpose?
Is it that you do not want image to be kept in SD card /Pendrive and want to flash your customized image via ethernet?
Hi @Divakaran ,
Colibri iMX6ULL comes with Toradex easy installer installed by default.
You can setup a local webserver and keep yor customized images there with AutoInstall enabled.
Once the module boots, it will automatically install the image
Hi @sahil.tx ,
In our case, we cannot use Tezi because, we may have to update and flash the image multiple times. After the first time flash, the SOM would not be having Tezi, because of which we cannot use the method which you have suggested.
We are thinking about a solution, where we can flash the image from the u-boot, provided we have a running u-boot.
In case of customizing the image, we are using Yocto tool.
Are you saying that you need to update the image multiple times in production programming?
You can copy Toradex Easy Installer in SD card and boot Toradex Easy installer from there automatically. Once it gets loaded it will automatically detect and install your customized image but since SD card is slot is also not avaiable on your board, you can check boot tezi from ethernet (not supported officially, but you can test it)
Images built using yocto are Tezi compatible already.
Incase you have to just update rootfs, you can simple replace it in your image folder.
Hi @Divakaran ,
We are recommending you this method because it seems to solve your issue and we have not tested other methods.
You may take help from external documents
eg. i.MX_Linux_Users_Guide.pdf
Thanks for the reply.
Just one more thing. If we try as per the instructions in the community link provided, the flashing would still be done using tezi. But as per the understanding, tezi does not output anything to the console. So there is no proper indication to confirm if the flashing process has been done, which is also a requirement on flashing in a production environment.
So, is there any additional configurations in Tezi with which can be enabled for console logs; if not can you please suggest a different solution, which avoids the usage of Tezi?
You should never erase UBI partition! Erasing you are losing erase counters, which is harmful. If you need to remove and then recreate UBI volumes, perhaps because of new UBI volume size requirements, then just ubi remove and ubi create UBI volumes.
Having existing UBI partition and created UBI volumes, just skip nand erase.part step.
ubi part ubi - this attaches MTD volume to UBI. nand erase.part ubi - with all UBI driver structs initialized, you erase UBI partition. UBI driver is unaware you erased UBI partition! So no wonder Linux UBI driver was unable to attach MTD. The wonder how kernel did boot. Ah, perhaps you didn’t reboot U-Boot and U-Boot driver took information from pre-erase ubi part ubi call.
