i.MX8 booting from QSPIFlash

[efio]

Hi we've a imx8mn based board with different DDR chip and different NOR flash connected to QSPI interface. (different from imx8mn-evk board)
As well we have two boot options: eMMC and QSPI.
The board boots and works while booting from eMMC, the QSPI flash is available in u-boot and Linux.
But, when we're trying to switch to QSPI boot option - boot fails - no output on the console.
On the other hand, we can see the clocks on SPI bus and - it means the CPU indeed tries to boot from QSPI.
We're building our QSPI flash image with a help of imx-mkimage utility, there is a guide of how to create it:
https://community.nxp.com/t5/i-MX-Processors/IMX8Mnano-EVK-How-to-make-QSPI-booting-image/td-p/17047...
In addition, here is the out of: make SOC=iMX8MN DEV=flexspi flash_evk

BL32=tee.bin DEK_BLOB_LOAD_ADDR=0x40400000 TEE_LOAD_ADDR=0x56000000 ATF_LOAD_ADDR=0x00960000 ../iMX8M/mkimage_fit_atf.sh evk.dtb  > u-boot.its

bl31.bin size: 

41456

u-boot-nodtb.bin size: 

736416

evk.dtb size: 

28304

./mkimage_uboot -E -p 0x5000 -f u-boot.its u-boot.itb

FIT description: Configuration to load ATF before U-Boot

Created:         Tue Oct  8 17:44:52 2024

 Image 0 (uboot-1)

  Description:  U-Boot (64-bit)

  Created:      Tue Oct  8 17:44:52 2024

  Type:         Standalone Program

  Compression:  uncompressed

  Data Size:    736416 Bytes = 719.16 KiB = 0.70 MiB

  Architecture: AArch64

  Load Address: 0x40200000

  Entry Point:  unavailable

 Image 1 (fdt-1)

  Description:  evk

  Created:      Tue Oct  8 17:44:52 2024

  Type:         Flat Device Tree

  Compression:  uncompressed

  Data Size:    28304 Bytes = 27.64 KiB = 0.03 MiB

  Architecture: Unknown Architecture

 Image 2 (atf-1)

  Description:  ARM Trusted Firmware

  Created:      Tue Oct  8 17:44:52 2024

  Type:         Firmware

  Compression:  uncompressed

  Data Size:    41456 Bytes = 40.48 KiB = 0.04 MiB

  Architecture: AArch64

  OS:           Unknown OS

  Load Address: 0x00960000

 Default Configuration: 'config-1'

 Configuration 0 (config-1)

  Description:  evk

  Kernel:       unavailable

  Firmware:     uboot-1

  FDT:          fdt-1

  Loadables:    atf-1

41420+1 records in

41421+0 records out

165684 bytes (166 kB, 162 KiB) copied, 0.0578868 s, 2.9 MB/s

./mkimage_imx8 -version v2 -fit -loader u-boot-spl-ddr.bin 0x912000 -second_loader u-boot.itb 0x40200000 0x60000 -out flash.bin

Platform: i.MX8M (mScale)

ROM VERSION: v2

Using FIT image

LOADER IMAGE: u-boot-spl-ddr.bin start addr: 0x00912000

SECOND LOADER IMAGE: u-boot.itb start addr: 0x40200000 offset: 0x00060000

Output: flash.bin

fit_size: 886

1+0 records in

1+0 records out

886 bytes copied, 5.7108e-05 s, 15.5 MB/s

FIT hash: 9dc0d453c9a49e3d880292c4c330e685ea495c6856ab82ab61354b134f9b

========= IVT HEADER [HDMI FW] =========

header.tag: 0x0

header.length: 0x0

header.version: 0x0

entry: 0x0

reserved1: 0x0

dcd_ptr: 0x0

boot_data_ptr: 0x0

self: 0x0

csf: 0x0

reserved2: 0x0

boot_data.start: 0x0

boot_data.size: 0x0

boot_data.plugin: 0x0

========= IVT HEADER [PLUGIN] =========

header.tag: 0x0

header.length: 0x0

header.version: 0x0

entry: 0x0

reserved1: 0x0

dcd_ptr: 0x0

boot_data_ptr: 0x0

self: 0x0

csf: 0x0

reserved2: 0x0

boot_data.start: 0x0

boot_data.size: 0x0

boot_data.plugin: 0x0

========= IVT HEADER [LOADER IMAGE] =========

header.tag: 0xd1

header.length: 0x2000

header.version: 0x41

entry: 0x912000

reserved1: 0x0

dcd_ptr: 0x0

boot_data_ptr: 0x911fe0

self: 0x911fc0

csf: 0x9527c0

reserved2: 0x0

boot_data.start: 0x911fc0

boot_data.size: 0x42860

boot_data.plugin: 0x0

========= OFFSET dump =========

Loader IMAGE:

 header_image_off 0x0

 dcd_off 0x0

 image_off 0x40

 csf_off 0x40800

 spl hab block: 0x911fc0 0x0 0x40800

Second Loader IMAGE:

 sld_header_off 0x58000

 sld_csf_off 0x59020

 sld hab block: 0x401fadc0 0x58000 0x1020

 fit-fdt csf_off 0x5b020

 fit-fdt hab block: 0x401fadc0 0x58000 0x3020

SPL CSF block:

Blocks = 0x911fc0 0x0 0x40800 "flash.bin"

SLD CSF block:

Blocks = 0x401fadc0 0x58000 0x1020 "flash.bin",\

SLD FIT-FDT CSF block:

Blocks = 0x401fadc0 0x58000 0x3020 "flash.bin"

bootmode selected: FlexSPI - 3B Read '0110'

We can see on power up clock signal of the QSPI bus.
But we can't see the processor running. Nothing over the console.

1.  What is probably incorrect in our FLASH image preparation?
   
2. To which offset on QSPI FLASH the image should be burn?
3. Do we need to config something on u-boot? SPL? if so, what to config?

The flash P/N we are using is: S25FL256SAGBHVB00

Thank you so much for your help,

[pengyong_zhang]

Hi @efio 

Glad to here that. You are welcome. And for the further question, Could you please create another ticket talk about it?

B.R

[efio · Accepted solution]

Thank you for your previous assistance. I would like to provide a status update regarding the flash issue.

I've made progress by modifying the mkimage command to:

make SOC=iMX8MN DEV=flexspi flash_evk_flexspi

This resolved the initial problem as this command properly includes the QSPI header with the 0xFCFB word at address 0x400.

However, I'm now encountering a new issue when attempting to access the flash from U-Boot. Specifically, the "sf probe" command fails with the following error:

u-boot=> sf probe

Invalid bus 0 (err=-19)

Failed to initialize SPI flash at 0:0 (error -19)

Notably, when booting from eMMC and stopping at U-Boot, the "sf probe" command works correctly. This suggests that the controller might be holding the bus, preventing access to the flash.

Could you please provide guidance on how to properly configure or release the bus controller in this scenario?

Thank you for your continued support.

Best regards

[efio]

Hi,

I am pleased to inform you that the issue has been fully resolved. The root cause was identified as an incorrect mkimage file configuration.

Thank you for your valuable assistance throughout this process.

Best regards,

[pengyong_zhang]

HI @efio 

Please use the following command compile your flash.bin file.

make SOC=iMX8MN flash_evk_flexspi

B.R

[pengyong_zhang]

HI @efio 

I found the same issue with you, You can refer it follow the below link. hope it can help you.

https://community.nxp.com/t5/i-MX-Processors/i-MX8MM-QSPI-booting-and-partition/m-p/1661476

B.R

[efio]

Hi,

Unfortunately, the link doesn't help - I want to boot the imx8mn from the QSPI flash - meaning u-boot should come-up from the QSPI flash.

Any other suggestions? 

Thank you very much,

[pengyong_zhang]

hi @efio 

What is your result when you use the UUU command flash your .bin file?

B.R

[efio]

Same, doesn't work

[pengyong_zhang]

hi @efio 

I have some confuse about your schematic, you connect on flash, why your schematic have two flash chips?  My understand is you only connect S25FL256SAGBHVB00 , right?

And what is your command to flash your .bin file to your flash?

B.R

[efio]

Hi,

It's only one flash, the symbol package is divided to two for convenience.
I flashed the data using external J-Link and using dd command of linux.
both gave some results.

Hexdump gives the correct data.

I don't think the data is the issue, something is wrong what the IVT header the QSPI controller reads.

========= IVT HEADER [LOADER IMAGE] =========
header.tag:             0xd1
header.length:          0x2000
header.version:         0x41

Thank you,

[pengyong_zhang]

HI @efio 

Could you please share your board schematic file and your nor flash datasheet file?

B.R

[efio]

Hi,

Yes of course, you can see below the schematics for both QSPI Flash and imx8mn.
Please note that I can see the signals over scope and I can communicate with the flash in uboot & linux (read, write and more). The issue occurs only when trying to boot from the QSPI flash.
The mux in the schematics meant for external flash burning - which also works.

As I wrote before about observations of the QSPI controller:

1. Using an oscilloscope, I monitored the SPI wave and noticed the QSPI controller reading address 0x400 with command 0x3.
2. The read register value is 0xd1002041, which I believe should be correct.
3. The controller attempts this read twice.
4. A third read attempt is made using command 0x13 (4-byte address read), resulting in the same value: 0xd1002041.
5. After these three cycles, the operation halts.

Any suggestions?

Thank you,

QSPI Flash sideimx8mn side

[efio]

Flash data sheet:
S25FL256SAGBHVB00 

[pengyong_zhang]

hi @efio 

you are use our NXP i.MX8MN evk board or customer's board?

[efio]

Hi,

Customized board,

[efio]

Does the entry: 0x912000 correct for imx8mn?

[pengyong_zhang]

hi @efio 

I have test this on  my i.mx8mn evk board. And no issue found. Please share your uuu command result.

"uuu -b qspi <.bin file>"

B.R

[efio]

Hi,

Using uuu didn't work. I see that the flash is burned using sf read.
Is there any offset I should burn the bin file or it supposed to be in address 0x0?

Thank you

[pengyong_zhang]

HI @efio 

Did you choose the right boot selection? Please refer the following Boot selection for i.mx8MN.

B.R

[efio]

Hi,

Yes I did,