unable to boot imx6sx from qspi

[aaroncornelius]

We are having trouble getting a custom i.MX6sx board to boot from QSPI:

It has a single Micron N25Q256A flash device connected to the QSPI2A port of the processor.

We have built our custom uboot and linux kernel images image to be used with the mfgtool, and to boot the target from QSPI.

We updated the mfgtool script (ucl2.xml) to program our the BOOT_CFG fuses like so:

BOOT_CFG1 = 0x18

BOOT_CFG4 = 0x10

We have selected the qspi-nor-micron-n25q256a-config file to be programmed by the mfgtool.

But we are unable to get the system to boot.  It appears to be trying to boot from QSPI2, I have verified that the QSPI2_LUTx registers are being populated with the LUT sequences from the qspi header that is programmed by the mfgtool.  But it always seems to fail, and then return to the "serial downloader" USB mod (when the processor has returned to the "serial downloader" mode I have to restart the processor with the BOOT_MODE pins set to "serial downloader" otherwise the Linux kernel is unable to communicate with the QSPI flash device).

I have tried a variety of settings in the QSPI configuration header between single/quad mode and SDR/DDR as well as customizing the command sequences in the LUT.

What sort of qspi configuration header values should I be using?  And should I go about debugging this boot problem?

[igorpadykov]

for QSPIA2 one can use Sabre configuration, as part of i.MX_Linux_User's_Guide.pdf

shows:

[aaroncornelius]

After some investigation I have some additional information that might help.  Note that none of these U-Boot images were successfully loaded and started from QSPI by the processor.

When generating the final imximage for the mfgtool, this is the command that is run:

  ./tools/mkimage -n board/freescale/mx6sxsabresd/imximage.cfg.cfgtmp -T imximage -e 0x87800000 -d u-boot.bin u-boot.imx

Image Type:  Freescale IMX Boot Image

Image Ver:    2 (i.MX53/6 compatible)

Mode:        DCD

Data Size:    385024 Bytes = 376.00 kB = 0.37 MB

Load Address: 877ff420

Entry Point:  87800000

And this is the initial part of the resulting u-boot.imx image where the IVT/DCD/etc. structures are:

00000000: d100 2040 0000 8087 0000 0000 2cf4 7f87  .. @........,...

00000010: 20f4 7f87 00f4 7f87 0000 0000 0000 0000  ...............

00000020: 00f0 7f87 00e0 0500 0000 0000 d202 0840  ...............@

00000030: cc02 0404 020c 4068 ffff ffff 020c 406c  ......@h......@l

00000040: ffff ffff 020c 4070 ffff ffff 020c 4074  ......@p......@t

00000050: ffff ffff 020c 4078 ffff ffff 020c 407c  ......@x......@|

00000060: ffff ffff 020c 4080 ffff ffff 020c 4084  ......@.......@.

00000070: ffff ffff 020e 0618 000c 0000 020e 05fc  ................

When generating the U-Boot imximage intended to boot from qspi (CONFIG_SYS_BOOT_QSPI is defined), this is the command that is run:

  ./tools/mkimage -n board/freescale/mx6sxsabresd/imximage.cfg.cfgtmp -T imximage -e 0x87800000 -d u-boot.bin u-boot.imx

Image Type:  Freescale IMX Boot Image

Image Ver:    2 (i.MX53/6 compatible)

Mode:        DCD

Data Size:    389120 Bytes = 380.00 kB = 0.37 MB

Load Address: 877ff7f0

Entry Point:  87800000

And this is the initial part of the resulting u-boot.imx image, note that the only major change is the "size" in the boot data section (I think?):

00000000: d100 2040 0000 8087 0000 0000 fcf7 7f87  .. @............

00000010: f0f7 7f87 d0f7 7f87 0000 0000 0000 0000  ................

00000020: d0e7 7f87 00f0 0500 0000 0000 d202 0840  ...............@

00000030: cc02 0404 020c 4068 ffff ffff 020c 406c  ......@h......@l

00000040: ffff ffff 020c 4070 ffff ffff 020c 4074  ......@p......@t

00000050: ffff ffff 020c 4078 ffff ffff 020c 407c  ......@x......@|

00000060: ffff ffff 020c 4080 ffff ffff 020c 4084  ......@.......@.

00000070: ffff ffff 020e 0618 000c 0000 020e 05fc  ................

I did find a note in the README.imximage file (uboot-imx.git - Freescale i.MX u-boot Tree ) that "BOOT_FROM" command in the imximage.cfg file (uboot-imx.git - Freescale i.MX u-boot Tree​ ) is depreciated and the BOOT_OFFSET tag is recommended to be used instead.  So I tried modifying the imximage.cfg file to specify

BOOT_OFFSET   FLASH_OFFSET_QSPI

rather than:

BOOT_FROM qspi

Here is the mkimage output for that attempt:

  ./tools/mkimage -n board/freescale/mx6sxsabresd/imximage.cfg.cfgtmp -T imximage -e 0x87800000 -d u-boot.bin u-boot.imx

Image Type:  Freescale IMX Boot Image

Image Ver:    2 (i.MX53/6 compatible)

Mode:        DCD

Data Size:    385024 Bytes = 376.00 kB = 0.37 MB

Load Address: 877ff7f0

Entry Point:  87800000

Note that the data size is the now the same as the mfgtool U-Boot that I built, but the DCD and "boot data" pointers match the previous qspi U-Boot version that I built:

00000000: d100 2040 0000 8087 0000 0000 fcf7 7f87  .. @............

00000010: f0f7 7f87 d0f7 7f87 0000 0000 0000 0000  ................

00000020: c1f7 7f87 00e0 0500 0000 0000 d202 0840  ...............@

00000030: cc02 0404 020c 4068 ffff ffff 020c 406c  ......@h......@l

00000040: ffff ffff 020c 4070 ffff ffff 020c 4074  ......@p......@t

00000050: ffff ffff 020c 4078 ffff ffff 020c 407c  ......@x......@|

00000060: ffff ffff 020c 4080 ffff ffff 020c 4084  ......@.......@.

00000070: ffff ffff 020e 0618 000c 0000 020e 05fc  ................

[igorpadykov]

Hi Aaron

what uboot are you using ? Please try nxp

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/board/freescale/mx6qsabreauto/mx6qp.c...

or from mfg tools folder.

Is board able to boot from any other mefia, like sd ?

Best regards

igor

[aaroncornelius]

That is the U-Boot repo and branch I am using.

My u-boot configuration is based on the “mx6sxsabresd” board in the freescale u-boot repo: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/log/?h=imx_v2015.04_3.14.52_1.1.0_ga

But with the necessary changes for the custom board such as the pinmuxing and peripheral device configuration.  It is very similar to the sabre board in many ways.

I assumed that if I specify CONFIG_SYS_BOOT_QSPI that the board initialization file would be able to configure the correct offsets in the final image.  This appears to be one of only 2 differences between booting the “mx6sabresd” board between the default (SD card) and QSPI2 configurations:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/configs/mx6sxsabresd_defconfig?h=imx_v2...

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/configs/mx6sxsabresd_qspi2_defconfig?h=...

On a different board I configured the boot fuses for booting from an SDcard and I verified that works using the default U-Boot configuration.  The only difference between that target and the one that fails is the same difference between the above linked "defconfig" files, and the fact that one of the images is on an SD card on the ESDHC2 port, and the other image is on the QSPI2A bus.

[igorpadykov]

I think you can debug it more:

-try to use default qspi image provided in mfg tools folder

- run uboot from tftp and read/write from qspi, comparing validity of written data

[aaroncornelius]

I'm not entirely sure what part you would like me to debug.

The custom board is similar to the sabre board, but not similar enough that I would expect the default images to work.  I do build mfgtool uboot and linux kernel images (using yocto) for the custom board and those images work successfully.  I am able to use those to erase the /dev/mtd0 device and to program the qspi version of my customized uboot.  I also added lines to the ucl2.xml file so I can program the imx6sx fuses as needed for new boards.  All of the mfgtool script actions appear to work successfully.

I have modified the "qspi-nor-micron-n25q256a-config" file in a variety of ways that I am sure at least 1 of them should have been successful.  And I have verified that my modified qspi header values are being used on boot to populate the QSPI2 LUT, which makes me think that the issue is with the uboot image in qspi, rather than my qspi configuration header.

Based on this post: IMX6 SoloX: Unable to boot from QSPI NOR FLASH The only theory I have is that there is something wrong with the offsets in the IVT header created by the "imximage" U-Boot tool.  But I am not really sure what the correct offsets should be.  As far as I can tell the values would appear to be correct since they are 0x1000 for the qspi uboot and 0x400 for the sdcard uboot.

[igorpadykov]

config file should be placed on 0x400, and ivt header at 0x1000 for the qspi boot

Also could you say what is the reason for changing "qspi-nor-micron-n25q256a-config" file ?

Seems it should be ok for custom board, if qspi part is the same.

[aaroncornelius]

here are the commands used to program flash:

<CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mtd0 bs=1k seek=4" ifdev="MX6SX">write U-Boot to NOR flash</CMD>

<CMD state="Updater" type="push" body="$ dd if=qspi-header of=/dev/mtd0 bs=1k seek=1" ifdev="MX6SX">Writing header to NOR flash</CMD>

as far as I understand those should be the correct offsets.

the qspi-nor-config file, I tried it with no modifications and things didn't work.  Then I tried it with some modifications that seemed logical, and it continued to not work.  For example this board has only 1 qspi device on port 2A rather than 2 qspi devices on ports 2A and 2B.

What I need to know now is how I go about debugging this boot process?  How do I figure out what part of the qspi boot is failing?  Is there something wrong with the configuration?  Or is there something wrong with the IVT header that the mkimage step of the uboot build performs?  Or is there a configuration value in uboot that would correct this that may not be obvious?

[igorpadykov]

as I already suggested, try to run uboot from tftp and read ivt header  from qspi (0x1000),

you should see Load Address as 9-th word,Entry Point as 2-th word

Load Address: 877ff7f0

Entry Point:  87800000

1-st word should be pattern D1 x x 40, refer to

Figure 8-23. Image Vector Table i.MX6SX Reference Manual (rev.0  2/2015)

http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6SXRM.pdf

[aaroncornelius]

I hope to get back to debugging this issue as soon as possible.  But due to customer deadlines we are proceeding with our board bring-up testing using the SDcard boot method for now.

[igorpadykov]

if you have working (booting from qspi) i.MX6SX Sabre SD, one can

copy qspi n25q256a config data to tftp, then program it on custom board.

[aaroncornelius]

I stumbled onto the solution while gathering some data to post here.

This is the "flash size" values Sabre board's qspi configuration

8000000		/*sflash_A1_size=size in byte(hex)*/
0		/*sflash_A2_size=size in byte(hex)*/
8000000		/*sflash_B1_size=size in byte(hex)*/
0		/*sflash_B2_size=size in byte(hex)*/

Because we are using a flash chip on QSPIA2 I changed the values to this:

0		/*sflash_A1_size=size in byte(hex)*/
2000000		/*sflash_A2_size=size in byte(hex)*/
0		/*sflash_B1_size=size in byte(hex)*/
0		/*sflash_B2_size=size in byte(hex)*/

However, that doesn't appear to work.  When I instead changed the flash data back to the "sFlash_A1_size" value it works:

2000000		/*sflash_A1_size=size in byte(hex)*/
0		/*sflash_A2_size=size in byte(hex)*/
0		/*sflash_B1_size=size in byte(hex)*/
0		/*sflash_B2_size=size in byte(hex)*/

Is this correct?  If so the "Table 8-27 QuadSPI Configuration Parameters" information in the reference manual is not correct (or very misleading).

Why would setting the "A1" flash size (even though we are booting from QSPIA2) work but not the "A2" flash size?

As a note of interest, using the "BOOT_OFFSET" value in the imximage.cfg in U-Boot does not work.  The default "BOOT_FROM" value does work.  Whoever is maintaining the IMX related portion of U-Boot may want to update the documentation in the README.imximage file (uboot-imx.git - Freescale i.MX u-boot Tree ).

[igorpadykov]

Hi Aaron

had you checked signal with oscilloscope ?

Also one can test with bare metal example:

MX6 SoloX bare metal startup

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[aaroncornelius]

I was going to, but since I was able to use a JTAG device to verify that the QSPI2_LUT was being populated with the configuration values from the QSPI configuration header, I was sure that the processor was trying to boot from QSPI.  But what I don't know is what goes wrong during the QSPI boot process that causes the processor to fallback to the serial downloader mode.