Soon we will have our custom carrier board for Verdin iMX8M-Plus SoM.
Now, I need to automate the process of flashing eMMC of SoM during the production.
I searched on the forum and found similar questions from other people but Toradex team usually pointed that they had Toradex Easy Installer pre-installed for all iMX8M-Plus SoM and closed the topic. But it seems Toradex Easy Installer needs human interaction (connect through VNC, selecting proper image, clicking, waiting, interpreting the operation result, etc…) which is not desired in production.
Here are my questions:
Once the Easy Installer up, is there a way to send batch of commands like erase, program the image and get the result over the ethernet gadget (IP: 192.168.11.1) without using GUI?
For the brand new SoMs which have Easy Installer preinstalled, above solution may work if the required commands can be executed remotely. But we need an automated solution also for SoMs already programmed and don’t have Easy Installer. In this case, Toradex suggested to enter to recovery mode, and then install easy installer to RAM using UUU and continue from there as if the SoM was brand new. If UUU could load the Easy Installer image in the recovery mode, that means It could also flash our own image directly, what is the benefit of using Easy Installer here then?
The best solution for the production seems something like that:
Enter into recovery mode regardless of that SoM has Easy Installer or not
Use UUU to flash production image directly
We use Toradex BSP 5.6 for our production image creation. In the deploy folder of yocto, we have *.rootfs.wic.gz, *-Tezi_3.1.13.tar, *.rootfs.tar.xz, *.rootfs.bootfs.tar.xz and some *.bin files. Can we use any of this files with UUU? Final solution should be as simple as executing one command with an image parameter.
Your suggestion to automate the process is highly appreciated.
This is indeed nice. I will study further. But brief question is that, is there a way to know if the operation is successful or fail after automated installation completed? For example can we control a GPIO depends on the operation result? Or can we query the result through USB gadget IP?
Hi @Fide , After image flashing Toradex Easy Installer executes wrapup_script (default name is wrapup.sh). You can add any available Linux commands there to indicate a completion.
I went through the link you provided above. It covers most of the cases but I feel that it is still not suitable for the production, here are remaining questions:
When operation succeed, wrapup_script will be executed. If it fails error_script will be executed. What are the available commands to be used in the script? Can we control GPIOs? Does Easy Installer image have gpiod libraries to use in the scripts for example?
At the startup, how do we know whether SoM has easy installer? Production may try to flash SoMs which has already been programmed as something else. This process should be automated as well at the startup. Any suggestion for this case?
The Toradex Easy Installer is based on Linux. It includes a BusyBox suite so you can use any of its commands, Also you can compile any other external command including your own application.
All modules shipped by Toradex has a Toradex Easy Installer pre-flashed. What is a planned source of modules “programmed as something else”? How many of them you are expecting?
To see the list of available commands, I have tried to connect through ssh to the device when Easy Installer was on the screen, but it was not possible. I think ssh service is not active. Therefore I couldn’t check the infrastructure available to access to GPIOs. As I know with Linux Kernel 5.4 and above, sysfs is deprecated to control GPIOs. Is there a way to access to rootfs of Easy Installer to see available GPIOs under /sys/class/gpio folder?
Or your second suggestion also seems suitable for us, if we can run our own application in Easy Installer’s wrapup_script or error_script, it would work for us as well. Do you have brief instructions about how to do that?
All modules shipped by Toradex has a Toradex Easy Installer pre-flashed. What is a planned source of modules “programmed as something else”? How many of them you are expecting?
In production, any mistakes can happen any times. For example last time we had a batch and about 400 Toradex modules are needed to be programmed as image1. But in production, they put wrong image and flashed image2 instead. At the end they had to reprogram all modules again with image1.
I have one more question about services available in Easy Installer. As I see that Easy Installer listens two TCP ports 5900 for VNC and 8080 for Toradex Easy Installer 5.6.0-devel HTTP API. What are the capabilities of HTTP APIs? If it is possible to follow the whole process through HTTP APIs, we may not need to control GPIOs at all.
We have Dahlia and Verdin Development boards. I forgot the serial console interface, I will check that, it is a good idea I can easily discover the capabilities of Easy Installer image with wrapup_script and error_script if I have an access to Linux subsystem of Easy Installer.
For the HTTP APIs, I will create another topic.
But the last question is still valid, what if SoMs are already programmed and we need to reprogram all again in the production which is not uncommon.
What is an expected percentage of “already programmed” modules? You can setup a dedicated workstation to flash TEZI through USB in a recovery mode and then pass them to a main production line.
Like in the example I gave, it was the whole batch programmed wrongly and needed to be reprogrammed. And these are common in production and this kind of situations must be considered when you design or offer a solution.
Your suggestion will be seen in the production like that:
First they need to try to program the SoMs in the mainline by assuming they have Easy Installer
Then they need to debug those SoMs to understand why they are not able to be programmed on the main line
Then they will realized and classified them as already programmed and don’t have Easy Installer
Then they need to transfer them to another station prepared for recovery mode with UUU to put Easy Installer back
Then they transfer them back to the main production line for the final flashing
If you look at the situation from this perspective, Easy Installer doesn’t look easy anymore.
That should be the reason why some of your customers in the forum also keep asking for possibility of using UUU with their own image.
Please let me know if it is possible and if yes, how.
I see situation in much simpler way. All SOMs received directly from Toradex (or our distributer) they should be passed to main production. If SOMs arrived from any other source they should should be flashed at TEZI flashing station first and then passed to main production.
How many SOMs per month you are planning to program? According to my estimations - Creating a universal solution for programming all modules purely through a recovery mode has a sense if you expecting thousand or more ''Non-TEZI" modules per month.
Totally agree with you. We solve the issue as follows:
Our setup in production is based on a RPI4.
We force the Verdin into Recovery mode via a relay, then load a tezi image via uuu tool.
We use the RPI USB Gadget mode to simulate a storage device and put the image we want to program there. The Verdin USB host port is connected to the RPI Gadget.
When tezi has started, it automatically detects the image on the USB storage and installs it.
Quite a lot of work, but we wanted to have predictable results, no matter what was previously installed on the module.
I can easily discover the capabilities of Easy Installer image with