In the project I’m working on I have both the Colibri iMX7 512MB (NAND) and the Colibri iMX7 1GB (eMMC). However, the image installation process that I’ve been using for the NAND version has been purely done through issuing commands via UART to the bootloader (U-Boot) to load an image stored in a remote TFTP server. And from what I’ve read in Toradex wiki, this process is not valid for the eMMC version, leaving TEZI as the sole possibility.
Are there any way to figure out what’s the SoM version that I have attached to my host system through the USB-OTG interface, so I can have a script to automate the TEZI image upload vs UART bootload commands? The USB vendor ID and product ID seems to be the same for both, so it’s not an option.
If Tezi upload is fine for your eMMC units, then why don’t you use the same for NAND? Both variants are supported by Tezi, so what’s the problem?
Regarding old way used in “legacy image formats”, if you look here reference images, you may see that legacy image formats were used only with NAND variants.
I think it’s possible to update old iMX7 NAND image for iMX7 eMMC. U-boot should be able to write some raw disk image to eMMC partition, and this should be properly recognized by Linux as valid FS when Linux boots. If U-boot is able to to so, then it should be no rocked science to update update.sh script (in iMX7 legacy image distribution) to create image for eMMC instead of image for NAND. It shouldn’t be hard as well to adapt *.scp scripts in colibri-imx7_bin folder to work with eMMC. I could help you with this, but we aren’t using eMMC variants.
If Tezi upload is fine for your eMMC units, then why don’t you use the same for NAND? Both variants are supported by Tezi, so what’s the problem?
That’s not a technical problem per se, but a time-wise one :). We already have the process working on production with the NAND variant and it would require some time to both people and process to adapt to the TEZI way of installing images. So the idea was to, basically, create a transition period where we could have a tool identify the SoM variant and take the proper actions beforehand. But yes, moving both variants to the same way is indeed better than creating two different processes and tools.
Another thing that we did with the move to eMMC was to completely update our “old” NAND images based on Toradex 2.8 LTS reference (Yocto rocko, 2.4) to 5.x.y (Yocto dunfell) so we could shift completely from the NAND image. So we updated all the recipes and are now updating our internal distro tools to match toolchain and kernel version. In short, we aren’t really sure we want to keep the NAND for too long, thus “finding a way to distinguish them” seemed a good first approach.
One way that I think might be possible is to, before uploading the TEZI image to Colibri’s RAM (in recovery mode) would be to boot the SoM and check the persistent memory size and take the actions accordingly: (1) in case it’s a 512MB, download the old distro image and flash using the raw u-boot commands, or (2) in case it’s a 1GB, reboot, enter recovery mode (somewhat manual process yet), upload TEZI image, enable avahi+nginx with the index + image files (possibly with “autoinstall=true”) and that’s it. Thus, QA folks can run the automated tests from there, keeping the installation process transparent.
Do you see something too off in this approach/idea? Or something that could be done in a better way, like identifying the SoM variant without the need to interact with u-boot via serial?
I’m not sure what’s better for you.
If you are reading VID/PID, then as I understand you use USB gadget function. If so, then you can use different strings in gadget descriptor. manufacturer/product/serialnumber. Just alter some part of these to distinguish between NAND/eMMC. There should be libs or sources available to read these strings, for both Windows and Linux.
uploading the TEZI image to Colibri’s RAM (in recovery mode)
Most likely I don’t see whole process, but if you are using serial port to command NAND’s U-Boot, then you should be able to reboot Linux and wait on serial console for U-Boot command prompt, issue run usb_boot to launch Tezi from USB drive. Perhaps the same could be done over TFTP. What I’m sure about, recovery mode isn’t required to launch Tezi.
Hmmm, I didn’t think about changing some of these. Ok, we might consider something like that. Thanks for the idea.
Yes. I’m going to talk with the team here to check the availability to make the old NAND image available on the TEZI format.
Ah sure. Sorry for not being clear here: that’s for the development case where a custom image was already installed on top of TEZI’s, so uploading the TEZI via recovery mode is required.
Well… overall, thank you very much Edward for the help and ideas.
I’m going to further discuss internally with the team and see what might be the best action.
We’re still discussing the better approach. But as @Edward said, that’s more up to us as a business decision then technical :). But in general, yes, I think the overall question was indeed cleared.
