I have a few Colibri iMX6’s that are in need of recovery. I am able to boot them into recovery mode,
What exactly do you mean by boot them into recovery mode?
I assume you are able to set them to recovery mode and they respond as follows when connected via USB device cable to your development workstation, correct?
[user@host ~]$ lsusb | grep -i free
Bus 002 Device 017: ID 15a2:0061 Freescale Semiconductor, Inc. i.MX 6Solo/6DualLite SystemOnChip in RecoveryMode
but when I run the update.sh scripts it fails.
...
w3 in err=-7, last_trans=0 00 00 00 00
addr=0x021b001c, val=0x04008032
w4 in err=-7, last_trans=0 00 00 00 00
!!perform_dcd returned -7
HAB security state: development mode (0x00000000)
Yes, it looks like there is an issue in actually loading/transferring the u-boot.imx binary. The working case would instead look as follows:
...
loading binary file(../colibri-imx6_bin/u-boot.imx) to 177ff400, skip=0, fsize=4cc00 type=aa
<<<314368, 314368 bytes>>>
succeeded (status 0x88888888)
jumping to 0x177ff400
Am I doing something wrong or is the iMX6 lost?
Good question. Let me first get some more information concerning your environment.
What exactly have you done to those modules that they are in need of recovering in the first place?
I assume you are trying this with our stable V2.6_20160826 BSP, correct?
Have you tried using a different USB cable?
Have you tried using a different carrier board (BTW: what carrier board are you using)?
Have you tried a different USB port on your development workstation?
Have you tried going through a USB hub vs. using a direct connection?
One thing we saw happening in the past is that for some reason the i.MX 6 boot ROM may still partially load some albeit corrupt configuration before entering the recovery mode which then later will fail. If that is the case one would need to prevent it getting access to the eMMC in the first place. Rather then shortening the recovery mode pad one would need to shorten the two round test points right next to the i.MX 6 SoC, waiting a few seconds for the boot ROM to exceed its retries and it should enter recovery mode this time with a truly clean slate.
I assume you are able to set them to recovery mode and they respond as follows when connected via USB device cable to your development workstation, correct?
Yes, that is correct.
What exactly have you done to those modules that they are in need of recovering in the first place?
We followed Qt 5.7 device creation tutorial and their pre-built image updates the u-boot. The iMX6 stopped worked right after that.
We have been in contact with Qt Support and they admitted there was something wrong in their image and documentation. They told us to following the Toradex Flashing from scratch documentation.
I assume you are trying this with our stable V2.6_20160826 BSP, correct?
Yes
Have you tried using a different USB cable?
I will try
Have you tried using a different carrier board (BTW: what carrier board are you using)?
I only have the Colibri Eval 3.2B carrier board.
Have you tried a different USB port on your development workstation?
Yes, I have. It made no difference. I have flashed other modules before, without any errors.
Have you tried going through a USB hub vs. using a direct connection?
I have tried both.
Rather then shortening the recovery mode pad one would need to shorten the two round test points right next to the i.MX 6 SoC, waiting a few seconds for the boot ROM to exceed its retries and it should enter recovery mode this time with a truly clean slate.
Do you mean those 2 lonely points right beneath the SoC? Between the Soc and the 2 blocks with the stickers on?
We followed Qt 5.7 device creation tutorial and their pre-built image updates the U-Boot. The Colibri iMX6 stopped working right after that. We have been in contact with Qt support and they admitted there was something wrong in their image and documentation. They told us to following the Toradex flashing from scratch documentation.
I won’t comment on their stuff.
One thing we saw happening in the past is that for some reason the i.MX 6 boot ROM may still partially load some albeit corrupt configuration before entering the recovery mode which then later will fail. If that is the case one would need to prevent it getting access to the eMMC in the first place. Rather then shortening the recovery mode pad one would need to shorten the two round test points right next to the i.MX 6 SoC, waiting a few seconds for the boot ROM to exceed its retries and it should enter recovery mode this time with a truly clean slate.
Do you mean those 2 lonely points right beneath the SoC? Between the Soc and the 2 blocks with the stickers on?
No, it would be the two little round ones right next to the i.MX 6 chip on the same side as the real recovery pads.
