Does Verdin iMX8MM support SD boot in Recovery?

Technical Support
, , , ,
1

Our carrier board design requires to be able to boot (u-boot included) from SD as a recovery precaution and I guess the proper way is to use the recovery pin available on the module.

In my understanding, the recovery pin is expected to trigger the Serial Downloader boot in the iMX8M ,so, I expect to be able to use the “SDMMC manufacture mode”. I also checked the DISABLE_SDMMC_MFG which seems still in default 0 value:

Verdin iMX8MM # md.l 0x30350490 1
30350490: 00000000                               ....

When I power on the module (SD inserted, Recovery pressed, USB OTD disconnected) seems that nothis is loaded from the SD.
I’m using an SD Image geneated by Yocto wich seems to have a proper IVT and a proper u-boot. As a last resort before posting I also copied the eMMC first 4MB into the SD, but still nothing on the u-boot console.
When I boot from the eMMC everything is ok.

2

I believe you do have some serious misconceptions here.

Our carrier board design requires to be able to boot (u-boot included) from SD as a recovery precaution and I guess the proper way is to use the recovery pin available on the module.

I’m seriously wondering where you got such strange idea from but the recovery mode has definitely absolutely nothing to do with such SD boot.

In my understanding, the recovery pin is expected to trigger the Serial Downloader boot in the iMX8M

i.MX 8M Mini that is.

,so, I expect to be able to use the “SDMMC manufacture mode”.

No, the SDMMC manufacture mode is only to be used during manufacturing on un-fused completely pristine SoCs.

I also checked the DISABLE_SDMMC_MFG which seems still in default 0 value:

Verdin iMX8MM # md.l 0x30350490 1
30350490: 00000000 …

I don’t think any such masters. Anyway, I do know for sure that this SDMMC manufacture mode does actually work on completely pristine un-fused modules but even then it only works on a special carrier board resp. the Verdin Development board if the SD card power signal is bypassed.

When I power on the module (SD inserted, Recovery pressed, USB OTD disconnected) seems that nothis is loaded from the SD.

Yes.

I’m using an SD Image geneated by Yocto wich seems to have a proper IVT and a proper u-boot.

Even here I do have my doubts as our regular images are eMMC fastboot images while an SD card image would likely need to be different.

As a last resort before posting I also copied the eMMC first 4MB into the SD, but still nothing on the u-boot console. When I boot from the eMMC everything is ok.

That’s exactly what I’m talking about. This is not how our modules boot. They boot from the primary eMMC hardware area boot partition in a mode which is called eMMC fastboot.

3

I saw that, in normal condition, the Verdin is fused to boot in fast mode from the eMMC and that’s why I put the recovery mode on the table.

As described in the IMX8MMRM:
“6.1.9 Recovery devices
The chip supports recovery devices. If the primary boot device fails, the boot ROM tries to boot from the recovery device using the USDHC2 port.”

Which is exactly what we would like to obtain if the Verdin supports it.
At the HW level we can do anything required to do so on our carrier.
Let’s forget about the SD image difference. It’s something that we can address with a proper image, but I first need to understand if a complete boot from SD is possible or not, by any means.

4

I saw that, in normal condition, the Verdin is fused to boot in fast mode from the eMMC

Yes, eMMC fast boot mode that is.

and that’s why I put the recovery mode on the table.

I still don’t quite see what a regular boot from eMMC and the recovery mode should have in common, sorry.

As described in the IMX8MMRM: “6.1.9 Recovery devices The chip supports recovery devices. > If the primary boot device fails, the boot ROM tries to boot from the recovery device using the USDHC2 port.”

Wow, NXP should receive some decoration for that sentence and its accompanying information. I have to admit, we know absolutely nothing about any such feature. I guess one would need to ask NXP about any further details…