Stuck in recovery mode

I have a custom yocto image I have been flashing by shorting the recovery pins on the ixora board, loading the Apalis-iMX8_ToradexEasyInstaller_2.0b6-2020110 recovery image, and then loading the tezi image from the yocto build from a USB stick.

I was making changes to u-boot-distro-boot uboot.scr file and testing those. After I updated through TEZI and removed the recovery jumper, the board continues to boot into recovery mode (NXP boot ROM). dmesg on the connected laptop shows:

[21213.266289] hid-generic 0003:1FC9:0129.0013: hiddev96,hidraw2: USB HID v1.10 Device [NXP       SemiConductor Inc  SE Blank 8QM ] on usb-0000:00:14.0-8.4/input0

I loaded TEZI in recovery mode and then installed a standard linux multimedia image over the network from the Toradex feed. It seemed to flash successfully, but on reboot it again continues to go into boot ROM download mode every time.

Is there any way to determine the reason that the chip is going into recovery mode?

Is there any way to determine the reason that the chip is going into recovery mode?

As that SoC still has not been launched by NXP, much of its documentation is still super-secret and you likely do not have an NDA with them that might get tricky. Anyway, I suggest you to just stop in U-Boot when run through recovery mode and check a few things:

Apalis iMX8 # fuse sense 0 18
Sensing bank 0:

Word 0x00000012: 00000008
Apalis iMX8 # fuse sense 0 19
Sensing bank 0:

Word 0x00000013: 00000027
Apalis iMX8 # mmc bootbus 0 2 0 2
Apalis iMX8 # mmc partconf 0 1 1 0

And the following part is really SKU and hardware version dependent (don’t mess with it unless you know exactly what you are doing!):

Apalis iMX8 # fuse read 0 276
Reading bank 0:

Word 0x00000114: 00000094
Apalis iMX8 # fuse read 0 277
Reading bank 0:

Word 0x00000115: 000044d3

BTW: What exact Apalis iMX8 SKU and hardware version are you talking about?

CPU:   NXP i.MX8QM RevB A53 at 1200 MHz
Model: Toradex Apalis iMX8 QuadMax 4GB Wi-Fi / BT IT V1.1B, Serial# 06805067

What is the mechanism of the recovery pins, is that going to bootctl GPIOs that boot into imx serial download mode? Is there a GPIO I can read from u-boot to see if that’s been shorted somehow?

What is the mechanism of the recovery pins, is that going to bootctl GPIOs that boot into imx serial download mode?

Yes.

Is there a GPIO I can read from u-boot to see if that’s been shorted somehow?

I’m not sure whether that magic system control unit firmware might interfere with that, to be honest but anyway, you are supposed to first answer all my questions before I answer any new ones from you…

I think I answered your question about the hardware, is there something else you’re looking for?

I don’t have access to the broken SOM at the moment to try the fuse commands, I can get those Monday. We have not burned any fuses, at least not intentionally, and have not run any fuse commands at all from u-boot.

OK, sure. How about the eMMC configuration (e.g. mmc bootbus/partconf)?

Hi Marcel,

I found this topic because I’m having the same issue as Aaron did. I had a working Apalis iMX8QM and used the recovery update / TEZI installer multipe times on it. The last time I used recovery/TEZI it didn’t boot anymore (not even u-boot). Then I discovered that I could still use the USB recovery boot, but now without any recovery pins shorted. So for some reason it seems stuck there.

I followed your u-boot commands above, but what does this tell?:

Apalis iMX8 TEZI # fuse sense 0 18
Sensing bank 0:

Word 0x00000012: 00000008
Apalis iMX8 TEZI # fuse sense 0 19
Sensing bank 0:

Word 0x00000013: 00000027
Apalis iMX8 TEZI # mmc bootbus 0 2 0 2
Apalis iMX8 TEZI # mmc partconf 0 1 1 0
Apalis iMX8 TEZI # fuse read 0 276
Reading bank 0:

Word 0x00000114: 000000bc
Apalis iMX8 TEZI # fuse read 0 277
Reading bank 0:

Word 0x00000115: 000044f3

EDIT: I measured both sides of the recovery mode pads on the module, and they both are at 1.8V. So it seems that one of the FETs controlled by TS_1/RECOVERY is blown :frowning: