imx8mn: Cannot boot from USDHC2/SD after programming fuses to allow boot from USDHC1/eMMC

[Martin_W]

I have a custom board using the i.MX8M Nano UltraLite processor, with an eMMC device connected to USDHC1 and an SD card connected to USDHC2, and DIP switches to control the state of the BOOT_MODE0 and BOOT_MODE1 pins. Before programming any fuses, selecting either boot mode 0 or boot mode 1 causes the processor to wait for serial download, and selecting either boot mode 2 or boot mode 3 causes the processor to boot from the SD card. Although this is unexpected behaviour for boot mode 2, this is not a problem.

Because the default interface for booting from the eMMC is USDHC3, I need to program some fuses to make the processor use USDHC1. Based on the HRM, I set 0x470[15:8] = 0x2a and 0x470[28] = 1. Based on my reading of the HRM, I expected this to only affect boot mode 0, but I find it also affects boot modes 2 and 3. So there is now no way to boot from the SD card.

Is there any way to allow this processor to selectively boot from either USDHC1 or USDHC2?

[Martin_W]

Hello JorgeCas,

I used the following uboot command:

fuse prog 1 3 0x10002a00

[JorgeCas]

Hello,

Once 0x470[28] = 1, the boot mode configuration is taken from fuses and the normal boot flow is followed, where the ROM attempts to boot from the selected boot device. It is selected with:

BOOT_MODE[3:0] = 0000b

Or

FORCE_BT_FROM_FUSE = 1

If you don't force boot from fuses you should be able to change boot mode from pins

What is the behavior when you select boot from fuses and other boot modes?

Best regards.

[Martin_W]

Hello,

As mentioned, once I programmed the fuses, setting the pins to any of mode 0, mode 2, or mode 3 all result in it booting from USDHC1, even though there is a bootable SD card connected to USDHC2.

The BOOT_CFG fuses are currently programmed as shown:

u-boot=> md.l 30350470 14
30350470: 18002a00 18002a00 18002a00 18002a00 .*...*...*...*..
30350480: 00000000 00000000 00000000 00000000 ................
30350490: 00000000 00000000 00000000 00000000 ................
303504a0: 00000000 00000000 00000000 00000000 ................
303504b0: 00000000 00000000 00000000 00000000 ................

FORCE_BT_FROM_FUSE is 0x480[20], so is definitely not set.

[JorgeCas]

Hello,

Got it, thank you for the information. With that configuration on eFuses you should be able to boot from other sources than fuse configuration.

So, let's move to the first unexpected behavior on your board before you burned your eFuses.

I suggest you take a look on your boot mode pins and boot sources since you were not able to boot according to your GPIO boot pin configuration.

Best regards.

[Martin_W]

Hello,

I have checked that the boot mode pins are being driven and latched correctly, by reading back the value stored in the SRC_SBMR2 register.

Remember that before burning the fuses, I could boot from the SD card attached to USDHC2 when I selected boot mode 3. The only unexpected behaviour was that it also booted from the SD card when I selected boot mode 2. I have just reproduced this behaviour using the 8MNANOD4-EVK evaluation board, by erasing the contents of the eMMC on that board (before erasing the contents, it booted from the eMMC when I selected boot mode 2). So I don't believe this is an issue with my custom board.

[JorgeCas]

Go to serial download mode on a boot source without a valid image is expected.

Please take a new board and verify that you are able to boot from all the boot sources with switches without burn fuses. Then you can verify that boot mode pins are being read and you have a valid image on your memories to move to the eFuses.

Best regards.

[Martin_W]

It is not going to serial download mode when the eMMC is blank, it is loading from the SD card. That is not expected.

I cannot verify I can boot from the eMMC on my custom board without burning fuses, because it is connected to USDHC1, not USDHC3. And once I burn the fuses, I lose the option to boot from the SD card, as described in my original post.

As previously mentioned, I have already verified that the boot mode pins are being read correctly.

I only have two prototype boards, so I am not going to risk burning the fuses on the second one until I have a solution to this. Do you have access to the source code of the boot ROM program? Reading that would seem to be the only way to answer this question.

[Martin_W]

@JorgeCas,this remains unsolved. Can it be forwarded to the engineering team responsible for the boot code to get their input?

[JorgeCas]

Hello,

I consulted with internal team and referred me to this thread that is similar to your case.

BT_FUSE_SEL 0x470[28] shouldn't be 1 on your case.

Best regards.

[Martin_W]

Hello Jorge,

The thread you refer to agrees with the hardware reference manual that setting BT_FUSE_SEL=1 should only affect the behaviour when BOOT_MODE_PINS=0 or FORCE_BT_FROM_FUSE=1.

However, I tested on my second board just setting OVERRIDE_USDHC_BT_SEL=1 and OVERRIDE_USDHC_BT_VAL=01. Now the behaviour is that for boot mode 0 or 1 the processor waits for serial download and for boot mode 2 or 3 the processor boots from the eMMC attached to USDHC1. So it would appear that overriding the USDHC interface selection overrides both the eMMC and SD boot modes. This is undesirable behaviour, but as it is hard-coded into the boot ROM, I guess nothing can be done about it.

The strange thing is that if I blank the eMMC, the processor then boots from the SD card, so there is clearly some undocumented fallback behaviour. I hope this doesn't also include attempting to boot from the USDHC3 interface, as I am using those pins for a different purpose.

[JorgeCas]

Hello,

Could you please share me the commands you used to burn eFUses?

Best regards.