i.MX 8M Mini NAND eFuse pad settings

[fernando_lopes]

Hi,

I'm working on a custom board that uses an i.MX 8M Mini and a NAND flash. Because of an error, the pull-up resistor on the READY/BUSY pin of the NAND was not placed on the schematic.

I successfully booted the processor using an SD card, but we need to boot from NAND.

I've noticed that there is a PAD_SETTINGS field on the eFUSE registers to configure the NAND pads, but I couldn't find any details. 

Can I use this field to enable the NAND pins' internal pull-ups?

[igorpadykov]

Hi Fernando

"PAD_SETTINGS" field corresponds to register Pad Control Register IOMUXC_SW_PAD_CTL_PAD_*

described in sect.8.2. IOMUX Controller (IOMUXC)  i.MX 8M Mini Applications Processor Reference Manual

Best regards
igor

[fernando_lopes]

Thank you Igor. Luckily, I didn't have to use this eFuse configuration. 

It seems that the ROM code enables the internal pull-up for this pin. The U-Boot SPL code is correctly loaded and starts execution, but it freezes somewhere during execution of the function void board_init_f(ulong dummy) in the spl.c file.

I changed the code to print debug/trace information but after each code change and recompilation, the address of the hang changes.

U-Boot SPL 2020.04-fw3f-5.4.70_v2020.04+g30e7e817ca (Apr 21 2021 - 11:45:38 +0000)
"Synchronous Abort" handler, esr 0x02000000
elr: 00000000007f0b5c lr : 00000000007f0b58
x 0: 0000000000000000 x 1: 0000000000000000
x 2: 00000000007e7900 x 3: 0000000000000030
x 4: 000000000091dd56 x 5: 0000000000000000
x 6: 0000000000000000 x 7: 0000000000000000
x 8: 0000000000000000 x 9: 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 0000000000000016
x14: 000000000090e558 x15: 0000000000013da4
x16: 00000000007eee94 x17: 0000000033002028
x18: 000000000091dea0 x19: 0000000000912000
x20: 00000000008015b8 x21: 00000000007f6fe1
x22: 000000000090c000 x23: 0000000030350480
x24: 0000000000801000 x25: 0000000000910000
x26: 0000000030390070 x27: 0000000072000000
x28: 0000000000000000 x29: 000000000091de10

Code: 90000040 9124a800 97ffdcdb aae3f3df (00000040)

U-Boot SPL 2020.04-fw3f-5.4.70_v2020.04+g30e7e817ca (Apr 21 2021 - 11:45:38 +0000)
"Error" handler, esr 0xbf000002
elr: 00000000007e7f80 lr : 00000000007e7eec
x 0: 0000000000000000 x 1: 0000000000000003
x 2: 000000000000000f x 3: 00000000000000f0
x 4: 000000000091dde4 x 5: 0000000000000001
x 6: 000000003b9aca00 x 7: 000000000000000a
x 8: 0000000000000000 x 9: 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 0000000000000016
x14: 000000000090e558 x15: 0000000000013da4
x16: 00000000007ee264 x17: 0000000033002028
x18: 000000000091dea0 x19: 0000000000000000
x20: 00000000007f7a40 x21: 00000000000186a0
x22: 00000000000186a0 x23: 000000000000007f
x24: 0000000000000002 x25: 0000000000910000
x26: 0000000030390070 x27: 0000000072000000
x28: 0000000000000000 x29: 000000000091de10

Code: 93407c00 3834681f 52800000 a94153f3 (f94013f5)

I'm still trying to decode this information. I couldn't understand it yet.

[igorpadykov]

Hi Fernando

had board passed ddr test, was uuu tool used for nand programming.

One can use example_kernel_nand.uuu script from Demo Image package

i.MX 8M Mini EVK​

Best regards
igor

[fernando_lopes]

Hi Igor,

I discovered what problem was happening.

The problem was that the data loaded to addresses that end with 0xb58 and 0xb5c starting from 0x7e3b58 got corrupted when booting from NAND, so the u-boot SPL triggered an exception caused by invalid instruction when executing from one of these addresses and stopped.

Using the exact same image to boot from the SD card did not show this problem and was successful.

I first thought that this problem could have happened because of corruption of the NAND, but I nandumped the SPL load addresses without ecc (nanddump -n) and there was no error at all.

The way that the data is corrupted is somewhat curious because only the 3 lower bytes from 0xb58 and the 3 higher bytes from 0xb5c are corrupted and the data is repeated in all of them. For example:

Corrupted data:
7e3b58: 52e3f3df
7e3b5c: 00000060
7e4b58: 6be3f3df
7e4b5c: 000000a1
7e5b58: 9ae3f3df
7e5b5c: 00000033
(...)
7fcb58: 00e3f3df
7fcb5c: 00000000
7fdb58: 00e3f3df
7fdb5c: 000000c1
7feb58: 04e3f3df
7feb5c: 0000006f

Correct data:
7e3b58: 52800021
7e3b5c: 52800960
7e4b58: 6b00003f
7e4b5c: 540002a1
7e5b58: 9ad70820
7e5b5c: d1004033
(...)
7fcb58: 007f6fcc
7fcb5c: 00000000
7fdb58: 00000000
7fdb5c: 000137c1
7feb58: 00000000
7feb5c: 00000000

I did a crazy workaround, allocating an address of static data that is filled in the binary after compilation with the correct data for those addresses. Then I call a function right in the beginning of board_init_f that loads these data to their addresses, overwriting the corrupted data.

I just need to be sure that this part of the code will not fall in one of the damaged regions and the code runs perfectly after that.

This looks like a ROM bug or my NAND is not compatible with it. Maybe it's related to the NAND page size (4K - similar problem described here), which is also the offset between corrupted addresses. You can escalate this information to the design team if you will. I think that this should be fixed for future revisions or at least documented in an errata. An error like this undocumented is unacceptable.

Best regards,

Fernando.