Enabling OSPI NOR Flash (MT35XU02GCBA2G12) in custom i.MX8M Nano

[kippowens]

Hi,

We're hoping to boot (uboot/linux) off of Micron OctalSPI flash (MT35XU02GCBA2G12) in our custom i.MX8M Nano and I'm new at using the flex SPI interface.

I've noticed for the nano that there does not seem to be a pin configuration that allows for all 8 data channels.  Instead there is an A and a B channel.

Is it possible to support OSPI with this somehow?  If so, what changes are required?  If OSPI is not possible, can we still utilize the flash somehow with the A and B data lines?

Appreciate any help - thank you!

Kipp

[kippowens]

@han_xu - just booted into uboot from NOR!  I had to modify your fspi header to do an octal read on 8 pads (0xFD07208B) instead of a single pad (0xFD04208B).

Thank you so much for your help and patience through all of this.

[han_xu]

Right, I forgot the part is by default in OSPI mode. Congratulations.

[kippowens]

Hi @han_xu,

I'm curious about what I'm seeing when I try to boot using the header you provided and the header I originally created.

When using my header, I see this in the boot rom logs:

0090BFF0 = E0000000 22000000 31000000 41000000
0090BFF0 = E0000000 22000000 31000000 41000000
0090C000 = 67000000 82000000 00000B8E 83000000
0090C010 = 80000000 00000B95 81000000 0000D927
0090C020 = 50000000 A1E00001 51000000 A1E00001
0090C030 = 73000000 82000000 0000D93B 83000000
0090C040 = 80000000 0000D941 8F000000 0000D94F
0090C050 = D0000000 82000000 0000D966 83000000
0090C060 = 80000000 0000D969 D0000000 81000000
0090C070 = 00074C58 50000000 90000000 00000000

...but when I use your header, I'm unable to boot and I cannot access the boot rom log memory (or any memory) from JTAG.  Is it perhaps hanging in the boot rom code?  Is that a good sign or a bad sign?

[han_xu]

Could you please dump few words with debugger from address 0x0090bff0 when boot failed.

[kippowens]

Hi @han_xu,

As requested here's the data dump we're seeing from 0x0090bff0:

E0000000 22000000
31000000 40000000
D0000000 82000000
00000B95 83000000
80000000 00000B99
D0000000 81000000
00067993 50000000
90000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000

My amateur read on that is that we're never trying to boot into SPI?  Looking forward to your analysis.  Thank you again for the assistance.  It is truly very appreciated.

[han_xu]

This is the log for boot from fuse or from boot pin? Could you please share another boot log? ROM expert told me if boot from fuse, BT_FUSE_SEL should be burn. Could you please check if you have done it?

[kippowens]

Hi @han_xu,

You're correct,  We had not blown the correct fuses on the newly wired up board.  Here's the new data... Looks like a bad IVT header, but I'm not sure what the error is directing us to...

0090BFF0 = E0000000 22000000 31000000 41000000
0090C000 = 67000000 82000000 00000B8F 83000000
0090C010 = 80000000 00000B95 81000000 0000D927
0090C020 = 50000000 A1E00001 51000000 A1E00001
0090C030 = 73000000 82000000 0000D93B 83000000
0090C040 = 80000000 0000D941 8F000000 0000D94F
0090C050 = D0000000 82000000 0000D965 83000000
0090C060 = 80000000 0000D969 D0000000 81000000
0090C070 = 00075978 50000000 90000000 00000000

[han_xu]

Is that possible you can also dump the data when booting with boot pin? Thanks.

[kippowens]

@han_xu- here's the boot rom log for booting from boot pins - set to FlexSPI 3B (0110b).  We have the FlexSPI boot override pin set with the value set to Micron Octal (10b):

0090BFF0 = E0000000 22000000 31000000 40000000
0090C000 = D0000000 82000000 00000B9F 83000000
0090C010 = 80000000 00000BA3 D0000000 81000000
0090C020 = 000716CD 50000000 90000000 00000000

Looks like that's not working...

[kippowens]

We do not have an unfused board with JTAG wired out, so it will take me some time to provide that.  Unfortunately after trying the fspi header you provided (for the other micron part) with our fused board, it appears to be unresponsive...perhaps because it worked, but the uboot is bad?  I don't see any output and cannot access over JTAG anymore.

[han_xu]

Can you try decrease the clock frequency in fspi_header?

[kippowens]

For sure - what do you suggest?  Also, should I make the same changes to the various speed settings in u-boot?

Thank you again for the help!

[han_xu]

Please change the fspi_header I sent to you, line 18

01080700 --> 01080300

We don't need to touch the u-boot clock rate right now.

[kippowens]

Hi @han_xu - finally got to try the lower speed per your suggestion.  Unfortunately we're still not seeing any life and after programming the chip became unresponsive -- did not boot and did not re-enter serial download mode.  I cannot access it over JTAG.

We're putting in a switch to allow us to iterate more quickly between serial download mode and boot from fuses mode.

[kippowens]

Hi @han_xu - we're working on getting another board setup to try the slower speed (apologies for the delay).  In the meantime, I was looking at my imx-boot binary and noticed that my IVT header tag is: "d1002041," but the reference manual says it must be "d1200041."  Could this be an issue or is it simply an intentional byte swap?  Seemed suspicious, so I wanted to double-check.

[han_xu]

... The RM is wrong. It should be "d100204x". Why cannot burn the same board with lower clock rate fspi header?

hexdump imx-boot-imx8mnddr4evk-fspi.bin-flash_ddr4_evk_flexspi -C -n 5000
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 46 43 46 42 00 00 01 56 00 00 00 00 00 03 03 00 |FCFB...V........|
00000410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000440 00 00 00 00 01 01 02 00 00 00 00 00 00 00 00 00 |................|
00000450 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000480 0b 04 18 08 08 30 04 24 00 00 00 00 00 00 00 00 |.....0.$........|
00000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000005c0 00 01 00 00 00 00 01 00 00 00 00 00 00 00 00 00 |................|
000005d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000 d1 00 20 41 00 20 91 00 00 00 00 00 00 00 00 00 |.. A. ..........|

[kippowens]

Ah - ok, thanks for checking that.  It seemed like it was representing the length correctly, but I wasn't sure.

As for the slower speed - the board I was using was fused to force boot from fuses and after the last flash we are unable to get it back into serial download mode.  As such, I'm unable to reprogram it.  We're hoping to have another up and running very shortly.

Apologies for the delay.

[kippowens]

Hi - thank you for the response and apologies for the delay.  We need to run some lines out to get JTAG and have a part on order.  I'll get that data to you ASAP.

In the meantime - could you confirm what our boot mode should be?  Do we (or should we) fuse the part (say to FlexSPI - Micron Octal)?

Thanks so much for the help!

[han_xu]

The fuse setting for DDRx8 looks correct.

[han_xu]

Hi Kipp,

i.MX8MN use the same flexspi controller as other i.MX8 platforms so it can support Octal SPI Nor chips. Using both QSPIA0~3 and QSPIB0~3 as the 8 data lines is the normal way to design. Do you have any progress right now? Only failed to boot or you can not even probe the chip in either u-boot nor kernel? Please first check if this Micron chip info is in the id_table or not, the driver might already read the correct ID back but not found in known id table, even only 4 data lines connected to the chip, since read ID only needs D0 and D1 two lines.