i.MX 6ULL bails out of SD/MMC Manufacturing Mode back to USB Download Mode

[jay2]

From the above figure from the reference manual, what are the likely causes for the SDMMC check failing? I soldered up three copies of a new revision of a board that was previously booting without issue, and all three of them refuse to boot into U-Boot from an SD card via SD/MMC Manufacture Mode.

Probing the SD/MMC bus shows activity on CMD and then DAT1 (1-bit SD mode, as mentioned in the datasheet) for approximately 175 ms:

This is identical to the behavior on a good board. But right after this is completed, the board will jump to the USB bootloader.

I'm wondering if my RAM didn't quite reflow properly — but it seems strange to have the same problem with all three boards.

Any other things I should check? The difference between board revisions is only some low-speed GPIO signals getting moved around, which shouldn't affect any of this, so from U-Boot's perspective, they should look identical to the last revision.

[igorpadykov]

Hi jay2

for SDMMC boot failing may be recommended to run ddr test

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-6-7-DDR-Stress-Test-Tool/ta-p/11082...

then rebuild uboot with new calibration settings found from ddr test, put them in dcd header:

https://source.codeaurora.org/external/imx/uboot-imx/tree/board/freescale/mx6ullevk/imximage.cfg?h=i...

DCD is described in sect.8.7.2 Device Configuration Data (DCD)

i.MX 6ULL Applications Processor Reference Manual

Best regards
igor

[jay2]

Good call! I completely forgot about that tool. Sure enough, there's something really screwed up with my DDR3L. All three boards I'm testing all report all 1's on the data right at the first address 0x80000000.

I noticed that on good boards, DDR_RESET de-asserts (goes high) as soon as I download the script. On the bad boards, it never de-asserts. This is a problem across all three boards. I checked the pull-down resistor and it's 10k. There's no short to GND on the signal.

If I force the DDR_RESET signal high to take the DRAM out of reset and then re-run the stress-test tool, I get the same failure.

Any ideas?

[jay2 · Accepted solution]

Found the problem! Apparently, the 2V5 regulator net got renamed between versions, and the corresponding DRAM supply pin still had the old name, so they were disconnected. Soldered a wire between the two nets and we're back in business!