Cannot boot u-boot from QSPI on IMX7S

cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot boot u-boot from QSPI on IMX7S

Jump to solution
630 Views
Contributor II

Hello,

We are struggling to get u-boot to load from QSPI on our custom IMX7S board (based on MCIMX7S5EVK08SC). We have been desperately trying to work on this for several days. Would it be possible to have some advice on what we could be doing wrong?

This is what we have so far: We have booted u-boot via USB SDP and programmed the NOR flash with the QuadSPI configuration parameters at 0x400 0x0 (see update), and the u-boot image at 0x1000 0x400 (see update). We followed this post: How do we get the mx6ull evk to boot from QSPI NOR flash? and also used the same qspi-header.bin configuration parameters because they looked like they should at least be compatible (but perhaps not optimal).

The QuadSPI configuration parameters have been loaded and we can verify them as follows: (note 0x60000000 is the memory mapped address for the QSPI NOR flash - using sf read ... shows the same).

=> sf probe
SF: Detected s25fl064l with page size 256 Bytes, erase size 64 KiB, total 8 MiB

=> md 0x60000400 0x80
60000400: 00000000 00000000 00000000 00000000    ................
60000410: 00000000 00000000 00000000 02000000    ................
60000420: 00000003 00000003 08000000 00000000    ................
60000430: 08000000 00000000 00000000 00000000    ................
60000440: 00000002 00000000 00000001 00000000    ................
60000450: 00000000 00000000 00000000 00000000    ................
60000460: 00000000 00000000 2818043d 39040d06    ........=..(...9
60000470: 00002400 00000000 00000000 00000000    .$..............
60000480: 00000000 00000000 00000000 00000000    ................
60000490: 00000000 00000000 00000000 00000000    ................
600004a0: 00000000 00000000 00000000 00000000    ................
600004b0: 00000000 00000000 00000000 00000000    ................
600004c0: 00000000 00000000 00000000 00000000    ................
600004d0: 00000000 00000000 00000000 00000000    ................
600004e0: 00000000 00000000 00000000 00000000    ................
600004f0: 00000000 00000000 00000000 00000000    ................
60000500: 00000000 00000000 00000000 00000000    ................
60000510: 00000000 00000000 00000000 00000000    ................
60000520: 00000000 00000000 00000000 00000000    ................
60000530: 00000000 00000000 00000000 00000000    ................
60000540: 00000000 00000000 00000000 00000000    ................
60000550: 00000000 00000000 00000000 00000000    ................
60000560: 00000000 00000000 01000001 00000000    ................
60000570: 00000000 00000000 00000000 00000000    ................
60000580: 00000000 00000000 00000000 00000000    ................
60000590: 00000000 00000000 00000000 00000000    ................
600005a0: 00000000 00000000 00000000 00000000    ................
600005b0: 00000000 00000000 00000000 00000000    ................
600005c0: 00000000 00000000 00000000 00000000    ................
600005d0: 00000000 00000000 00000000 00000000    ................
600005e0: 00000000 00000000 00000000 00000000    ................
600005f0: 00000000 00000000 00000000 c0ffee01    ................

U-boot and IVT header is also programmed:

=> md 0x60001000 0x40
60001000: 402000d1 87800000 00000000 877ff914    .. @............
60001010: 877ff908 877ff8e8 00000000 00000000    ................
60001020: 877ff8d9 0006e000 00000000 40bc01d2    ...............@
60001030: 047c01cc 04003430 0500404f 00103930    ..|.04..O@..09..
60001040: 02000000 00007a30 01100401 64007a30    ....0z......0z.d
60001050: 1e002000 90047a30 01000000 d4007a30    . ..0z......0z..
60001060: 00006900 d0007a30 83000200 dc007a30    .i..0z......0z..
60001070: 04003005 e0007a30 00000804 e4007a30    .0..0z......0z..
60001080: 04001000 f4007a30 3f030000 00017a30    ....0z.....?0z..
60001090: 0a080e09 04017a30 0e020700 08017a30    ....0z......0z..
600010a0: 07040403 0c017a30 06200000 10017a30    ....0z.... .0z..
600010b0: 04020204 14017a30 02020303 20017a30    ....0z......0z.  
600010c0: 03080000 80017a30 20008000 90017a30    ....0z..... 0z..
600010d0: 04820902 94017a30 03030300 a0017a30    ....0z......0z..
600010e0: 03004080 a4017a30 20001000 a8017a30    .@..0z..... 0z..
600010f0: 04001080 00027a30 1f000000 04027a30    ....0z......0z..

The fuses have been blown for the BOOT_CFG and BT_FUSE_SEL = 1:

=> fuse read 1 3
Reading bank 1:

Word 0x00000003: 10004000

Our BOOT_MODE[1:0] == 00 (both boot GPIO pins are tied to ground).

Schematic for the IMX7S

pastedImage_141.png

And QSPI flash:

pastedImage_143.png

100K pull ups on QSPI_A_DATA2/3

Quick update:

I found in this post MX7D QSPI Configuration for MX66L1G45G (453394), that the offset for the QuadSPI configuration parameters I am using (the value of 0x400 that I got from the datasheet) is actually incorrect and very disappointingly this has still not been updated in the datasheets even though the post was over a year ago

So changing the offset to 0x0 and putting u-boot at 0x400 seems to get as far as loading the the QSPI config and then falls back to SDP. We are trying to work out how to recover the flash interface, does anyone perhaps know what could be wrong with our u-boot image. It appears the IVT is not detected and the DCD image is not loaded either because when we connected over JTAG we are not able to read/write to the DDR memory region yet.

Thanks for any help! 

Labels (2)
0 Kudos
1 Solution
26 Views
Contributor II

Hi all,

The problem was an error in the IVT as spotted by our fantastic FAE from Silica.

It turns out there was a problem with u-boot in the imximage.cfg and imximage.c parser. 

For the IMX7 you need to set the BOOT_OFFSET to 0x400. 

You would think that using "BOOT_OFFSET FLASH_OFFSET_STANDARD" in the .cfg file should be possible as in the documentation, but there is an include problem I could not quite figure out and imximage.c simply ignores that it cannot parse it and unhelpfully sets the offset to 0xF without warnings or errors.

Manually setting:

BOOT_OFFSET 0x400

solved it.

View solution in original post

4 Replies
27 Views
Contributor II

Hi all,

The problem was an error in the IVT as spotted by our fantastic FAE from Silica.

It turns out there was a problem with u-boot in the imximage.cfg and imximage.c parser. 

For the IMX7 you need to set the BOOT_OFFSET to 0x400. 

You would think that using "BOOT_OFFSET FLASH_OFFSET_STANDARD" in the .cfg file should be possible as in the documentation, but there is an include problem I could not quite figure out and imximage.c simply ignores that it cannot parse it and unhelpfully sets the offset to 0xF without warnings or errors.

Manually setting:

BOOT_OFFSET 0x400

solved it.

View solution in original post

26 Views
NXP TechSupport
NXP TechSupport

Hi Mark

after falling back to SDP one can attach to board any JTAG debugger, such as RV-ICE or
Lauterbach check if boot settings in SRC_SBMR1,2 are correct. Then one can

dump 0x910400 (ROM uses 0x910000 as starting address, shown on Figure 6-21. 

Internal ROM and RAM memory map i.MX7D Reference Manual), you should see your

ivt header here if the qspi access is ok. If qspi is configured as xip, please check Figure 6-40. Image

Vector Table, then processor jumps to run from qspi (without initializing ddr).

Also may be useful to look on

iMX7D boot from QSPI NOR flash 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
26 Views
Contributor II

Hi Igor,

Thank you for your help - that post was very useful.

I have now tried with the same qspi header binary, but still no luck. I attached with JLink and read the memory as follows:

   

J-Link>mem32 0x60000000 80

60000000 = 00000000 00000000 00000000 00000000  

60000010 = 00000000 00000000 03000002 02000000  
60000020 = 00000003 00000003 00800000 00000000  
60000030 = 00000000 00000000 00000000 00000000  
60000040 = 00000001 00000000 00000000 00000000  
60000050 = 00000000 00000000 00000000 00000000  
60000060 = 00000000 00000000 08180403 24001C04  
60000070 = 00000000 00000000 1C020405 00002400  
60000080 = 00000000 00000000 24000406 00000000  
60000090 = 00000000 00000000 20010401 00002400  
600000A0 = 00000000 00000000 1C010435 00002400  
600000B0 = 00000000 00000000 00000000 00000000  
600000C0 = 00000000 00000000 00000000 00000000  
600000D0 = 00000000 00000000 00000000 00000000  
600000E0 = 00000000 00000000 00000000 00000000  
600000F0 = 00000000 00000000 00000000 00000000  
60000100 = 00000000 00000000 00000000 00000000  
60000110 = 00000000 00000000 00000000 00000000  
60000120 = 00000000 00000000 00000000 00000000  
60000130 = 00000000 00000000 00000000 00000000  
60000140 = 00000000 00000000 00000000 00000000  
60000150 = 00000000 00000000 00000000 00000000  
60000160 = 00000000 00000000 01000001 00000000  
60000170 = 00000000 00000000 00000000 00000000  
60000180 = 00000000 00000000 00000000 00000000  
60000190 = 00000000 00000000 00000000 00000000  
600001A0 = 00000000 00000000 00000000 00000000  
600001B0 = 00000000 00000000 00000000 00000000  
600001C0 = 00000000 00000000 00000000 00000000  
600001D0 = 00000000 00000000 00000000 00000000  
600001E0 = 00000000 00000000 00000000 00000000  
600001F0 = 00000000 00000000 00000000 C0FFEE01

It looks like the header is loaded correctly, but the IVT does not appear to be loaded?

J-Link>mem32 0x910400 80
00910400 = 048A889C DF69AB86 1518B076 97A95EA8  
00910410 = B7024A2C CE4AC553 90C31380 F666C5FD  
00910420 = 1EA93237 89A15ACD A30DB954 8F420046  
00910430 = 94E9FE0F F3111162 FFB856FB 2C840621  
00910440 = 82B96431 D0A519B4 8ACB0009 EEBABE66  
00910450 = 8DB80013 7EA527B8 C4801214 E768CDB6  
00910460 = 7BA7C7DB 615081E3 E9C9D1BF 4CC12401  
00910470 = 8E3E17AC A188C559 543EFC6D 2C03C396  
00910480 = 38820204 D37CFB2F 0BE00301 2E55D38F  
00910490 = 14240200 E597BDA4 050C4019 BFD37DCD  
009104A0 = 143EE6DF EB0D66B2 CC0F91C9 B020B22C  
009104B0 = C49E6ABF 64C1EC11 4DEB8D1A 4387134F  
009104C0 = 00E56B20 5DDBEDE7 451C4443 75900F8E  
009104D0 = 52561285 CDBAEBF6 C24C521D 63D7D168  
009104E0 = 7C344312 6242D90B FF52BCF5 8125180C  
009104F0 = 35D3B09F 05FC4F5C 5FEFF59D 7C63FB06  
00910500 = C1801A5E 87ADB336 1AFE419E FEEB9D75  
00910510 = D1037D5B 7E5CFABE 20E0021C 577D5B3F  
00910520 = 8D3FF27F 841D390D A849FFDE CEA44401  
00910530 = 27FFA1FF 95D710E1 7F635FF4 24D6032C  
00910540 = 7A602489 73D94377 43122F0B FAFEDBC6  
00910550 = 0E459004 FEDFFD7D 554C2C2A 54EF9ADF  
00910560 = 6FB5029F C20F4201 ED53DD9C CA4008DA  
00910570 = 721BBC2F 809B6444 7FF5B24C 7734450C  
00910580 = 551DA490 1FBFA7EF 12A16DCC 5C4C5F2E  
00910590 = 58D3BA3A 3F65EF79 44709331 BF7BDD7D  
009105A0 = 21F76E9E C5EA2451 DEECDCBE 3DE415C5  
009105B0 = FD6E80B9 0F10AEA6 177DE419 47B2E558  
009105C0 = 08C03628 F9E4EDF4 E5F25421 7FFD6493  
009105D0 = 443AE326 CD97B3EF 81E10210 DF51B9E3  
009105E0 = 3CBE21D9 AED8770D EFD47B74 30BF50F9  
009105F0 = 759FDF56 E46DB409 BB7965F9 43200E48

# SRC_SBMR1

J-Link>mem32 0x30390058 1
30390058 = 00004000  

# SRC_SBMR2
J-Link>mem32 0x30390070 1
30390070 = 28000011

Does this look right to you? I set the fuses in u-boot using:

=> fuse prog -y 1 3 0x10004000

Programming bank 1 word 0x00000003 to 0x10004000...

0 Kudos
26 Views
NXP TechSupport
NXP TechSupport

Hi Mark

SRC_SBMR1,2 registers should be compared with boot settings

described in sect.6.6.6.1 QuadSPI eFUSE configuration i.MX7D Reference Manual.

Had you checked qspi signals with oscilloscope, is there data transfer.

Best regards
igor

0 Kudos