I’m trying to flash the easy installer (or to get my iMX8 again to work after the modul seem to be bricked due to trying to install an easy installer from previous BSPs (3b3 …))
During the recovery, the script stops at this point:
I even tried different possible arguments with uuu/uuu.exe with uuu.auto in different versions of easy installer
but i get the same result always, it loads only the imx-boot, but the board cannot boot at all.
For the iMX8 series, we strongly recommend using the latest Toradex Easy Installer (2.0b6 - nightly), due to the fact that they solve a detected issue with environment variables with U-Boot.
So, only consider using the 2.0b6 (or newer) for the iMX8.
About the usage of the console through a USB-RS232, that is normally not a problem through a USB Hub.
But we observed a lot of customers replying issues when using the USB-Device mode activated by the module in its Recovery Mode.
Me, for example, I have hubs with me here that works fine, others do not.
But it always works fine when connecting directly to the PC.
Well, some few things that worth mentioning:
Do you have other Toradex Apalis module over there that you could try?
Could you try again the Recovery Mode with the latest 2.0b6 nightly, with the USB-Device connected directly in your PC?
I tried with my Apalis iMX8QM “V1.0B” and it’s fine.
Well I tried on an iMX8QM 1.0B module and the recovery works fine. The problem is in the new hardware Module 1.1B.
We have 2 bricked modules so far, because of flashing an U-Boot from BSP3. We are trying to get it to work again with easy installer 2.0b6 but it stops during the recovery as mentioned in the main question.
The Apalis iMX8 V1.1x hardware really does need LATER software be it Toradex Easy Installer 2.0b6-nightly or Embedded Linux BSP 5.1-nightly. There is absolutely no way around this, sorry!
Thank you, but unfortunately this doesn’t answer the original question. It’s bad enough, that we are forced to switch from 3b3 to 5.0.0 during the development process even if we don’t want to.
But it’s even worse, that we can’t recover the bricked modules that have been flashed with an BSP 3b3 image. So, how can we recover the bricked modules?
I expect a satisfying answer to this within this week. Otherwise, we’ll be forced to switch to another SoM supplier that provides a stable development environment.
Thank you, but unfortunately this doesn’t answer the original question.
I am unsure as to what exactly you are referring to. Just doing recovery mode with any latest Toradex Easy Installer nightly build works fine, not?
It’s bad enough, that we are forced to switch from 3b3 to 5.0.0 during the development process even if we don’t want to.
You might want to read up on that. After all, so far, those modules were/are still just early access resp. sample modules.
But it’s even worse, that we can’t recover the bricked modules that have been flashed with an BSP 3b3 image. So, how can we recover the bricked modules?
Just run the latest nightly Toradex Easy Installer in recovery mode. Very straight forward really.
I expect a satisfying answer to this within this week. Otherwise, we’ll be forced to switch to another SoM supplier that provides a stable development environment.
I am really sorry if you are not happy with this. Let me escalate this through our sales. OK?
Well to make it clear the IMX8 is not a production module yet. It always takes very long til a Chip from NXP goes from sampling and beta into mass production.
We try to give our customers as early as possible access to the first modules like the IMX8QM. Usually, it takes some time to develop a product and if we just give the customer no early access and wait till the final production SOCs for NXP and sell then the module you would be 1 or 2 years too late with your product. So the first BSP that will be support the IMX8V1.1B when it is launched is the BSP 5. If you rahter have a mature product then better take products from us that are already in production status. But in general in embdeed Linux there is only one way. Always looking forward. so it is typical to alsways improve and move to a newer BSP. But you can also wait till the release of the LTS version of BSP5 to build your system on a longterm supported BSP.
Again the IMX8 is a new platform from NXP and they have not solved yet all there issues. Our effort is to always give you the newest BSP with all the NXP fixes.
How to recover a bricked module is well documented on our developer page and this is a very common process to reset the module to its delivery state during the development process. Use the recovery mode. best with USB cable from your host system. iMX Recovery Mode | Toradex Developer Center. We have also a huge amount of training videos to make yourself familiar with the embedded Linux environment.
So if it is too much effort wait till the final production release.
I am unsure as to what exactly you are referring to. Just doing recovery mode with any latest Toradex Easy Installer nightly build works fine, not?
No, unfortunately it doesn’t. That’s what I’ve been trying to say with “this doesn’t answer the original question”. We’ve tried different host PCs, different OS’es, with/without USB2.0 hub, even different developers following your guide → we just can’t get the EasyInstaller running on the V1.1B SoMs after they’ve been flashed with an 3b3 image before. This is what I would call “bricked”.
Product Change Notification/End-of-Life Policy - Toradex
I’m following your newsletter, I read the bug list, but still I wasn’t aware that the V1.1B SoMs won’t work with the 3b3 BSP. Could you please point out where exactly this was mentioned?
Just run the latest nightly Toradex Easy Installer in recovery mode. Very straight forward really.
We did, several times, but it just doesn’t work. It stops like @majd.m described above, we never get to the EasyInstaller where we could install a BSP5.0.0 image. Maybe we could arrange a TeamViewer session so you could see for yourself?
We’re willing to take the risks that come with a sample product. But as stated above, we’ve tried all of your guides to recover the bricked modules, they just don’t work.
Can we at least assume that BSP5.0.0 images will work on V1.0B modules without bricking them?
We’re willing to take the risks that come with a sample product. But as stated above, we’ve tried all of your guides to recover the bricked modules, they just don’t work.
You mean even using the latest nightly version of the Toradex Easy Installer it does not work for you? That seems rather strange but if true this mandates further investigation.
Can we at least assume that BSP5.0.0 images will work on V1.0B modules without bricking them?
We will definitely not do anything to actively prevent that. However, please understand that those modules might have chips in versions assembled which long since got obsoleted by their manufacturers e.g. NXP. And as such should not really be used in any kind of production environment as completely unvalidated.
Did you use the nightly build of the Toradex Easy Installer?
If yes did the Recovery process from the host PC was successful?
If yes and the module did not boot or hangs then you need to reset the env. by stoping
uboot and enter the following
env default -a
saveenv
Thank you very much for the suggestion, but I don’t even get that far. Download of Toradex Easy Installer stops at .
There is no output from U-Boot or on the HDMI screen during the whole process.
As far as I understand it, an incompatible SC firmware was flashed to the module, preventing U-Boot to start. But also loading Toradex Easy Installer directly into RAM does not work as described. Maybe we could set up a short Teams call so you can see for yourself?
This was tested with various versions of Tezi, including “Apalis-iMX8_ToradexEasyInstaller_2.0b6-nightly-20201102”
I see that you are using windows as a host. I have seen some cases with certain Windows 10 settings e.g. using a hub in between the SOM and computer. There Window would not recognize the NXP SOC as USB device when plugged in. Please check if after you put the SOM into recovery mode it also shows up under the USB devices in the device manager in windows.
This was also tested on another PC running Win10, inside a VM running Ubuntu on a Win10 PC and finally on a system running Debian 10 natively. It’s always the same behaviour, it gets stuck right there.
How can I check on a linux system if the SoM is detected correctly? What should lsusb return?
We assume that the binary uuu tool from NXP not working properly on our host systems (windows and linux) for some reason, therefore I pulled the uuu source from the repository GitHub - NXPmicro/mfgtools: Freescale/NXP I.MX Chip image deploy tools. , and built it again on a raspberry pi system, then replaced the current uuu.
The recovery worked through the raspberry without problems after that.
Glad to hear that. I just installed BSP 3.0b3 on my module which bricked it but doing regular recovery worked flawlessly. Not sure what exactly about uuu went wrong in your case. We have not heard of anybody having faced any similar issue so far.
BTW: We released the Toradex Easy Installer 2.0b6 earlier this week which should now officially support both V1.0B as well as V1.1B modules.
Actually the method worked on one of our bricked modules. We thought it will do on the other one, but after sometime we tested it on the second module and we determined unfortunately the same issue the second iMX8 1.1B (even with the officiall Tezi 2.0b6) so we appreciate any suggestion to get it to work again…
