i.MX6q boot from SPI failed

[wallyyeh]

Hi, all:

    before I ask this question, I do google it, and search it on community, and read the "i.MX 6Quad_6Dual Reference Manual (Rev O)" PDF file.

the two post I read from community:

Unable to boot from SPI-NOR on MX6 Duallite SABRE SDP for smart devices

Boot iMX6 from SPI using ECSPI5; possible IOMUX tool bug...

According table8-22 & table 8-25 in "i.MX 6Quad_6Dual Reference Manual (Rev O)" PDF, we should able to boot from SPI,

I soldered the SPI device to the board using the pin configuration as follows:

BOOT_CFG1[7:4] = 0011 (Boot from Serial ROM).

BOOT_CFG4[5:4] = 01  (CS#1).

BOOT_CFG4[3] = 1

BOOT_CFG4[2:0] = 000  (ECSPI-1).

and attach SPI chip pins like below:

CS     -> EIM_D19

MISO -> EIM_D17

MOSI -> EIM_D18

CLK   -> EIM_D16

but device won't boot, I measure the CLK pin at boot time, found "no clock signal" was sent.

it seems it get into serial-download mode, and I can use imx_usb_loader send u-boot from usb otg.

if I switch  boot from eMMC, we still can read/write SPI by

"sf probe 1"

"sf read 10800000 0x0 0x100000"

"sf write 10800000 0x0 0x100000"

it seems SPI works great and perfect.

could anyone give me some hint or tips about this problem?  I'll be appreciated.

[AnsonHuang]

Hi, Wally

     I just tried the SPI NOR boot on our i.MX6Q Sabreauto board, it works. And I check the boot config setting as yours, seems like they are same, so the suspected point would be the data you write into the SPI nor device is incorrect, can you please dump the SPI NOT flash data for me? Just read the first 2k data for me, from offset of 0. The data in offset 0x400 of SPI nor flash should be the IVT magic word "0x402000d1".

[wallyyeh]

Hi, Yongcai:

    thanks for tips. following is our output, I strip the size and paste the offset 0x400 on SPI:

u-boot#sf probe 1

JEDEC ID: 0xc8:0x40:0x17

8192 KiB M25P32 - 8MB at 0:1 is now current device

u-boot#mw.b 10800000 0xff 800

u-boot#sf read 10800000 0x0 0x800

u-boot#md.b 10800000 0x800

10800000: 27 05 19 56 6e d1 22 19 52 a0 4b 06 00 06 b9 74	'..Vn.".R.K....t
10800010: 00 00 00 00 00 00 00 00 b8 ba 5f 21 05 02 05 00	.........._!....
10800020: 36 39 64 63 34 2d 30 30 30 30 30 65 63 39 00 00	69dc4-00000ec9..
10800030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00	................

...

10800400: d1 00 20 40 e0 06 80 27 00 00 00 00 2c 04 80 27

.. @...'....,..'

as you can see, the IVT magic word "0x402000d1" is right there.

would you need full 2k dump? I can paste it later.

[AnsonHuang]

Well, seems like the IVT header is right. Then do you have a JTAG tool available, if yes, can you dump the ROM log buffer for me? We can see why it failed to boot in ROM. The address is 0x00902190, using JTAG to dump this address' data.

[wallyyeh]

Hi, Yongcai:

    sorry, I find out there was a resistor missing in BOOTCFG1_4,

I think this pin is internal pull high,  and I measure this pin does act high.

But after I soldered this missing resistor, every thing works fine.

I guess this ping act high "AFTER" power-up, so when I plug power, this pin act "LOW" very shortly.

After contact from FAE, he told me that i.MX6 "internal pull high"(that means if you even take out the resistor connecting between of VCC and BOOTCFG1_4 pin, the pin still act like it has a virtual resistor in there) after ROM code enter "one" BOOT MODE.

so in my case, BOOTCFG1_4 act low forst, then the ROM code decide go into serial download mode , after that i.MX6 pull BOOTCFG1_4 pin high because the "internal pull high".

sorry for bring you such a dumb mess.

Wally

[AnsonHuang · Accepted solution]

Hi, Wally

     That is OK, I am glad that you have this issue solved, just check the correct answer and close this topic if you do NOT have other questions.