topic Re: i.MX8 booting from QSPIFlash in i.MX Processors

i.MX8 booting from QSPIFlash

efio — Tue, 08 Oct 2024 15:15:54 GMT

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/1704730
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.

What is probably incorrect in our FLASH image preparation?
To which offset on QSPI FLASH the image should be burn?
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,

Re: i.MX8 booting from QSPIFlash

efio — Thu, 10 Oct 2024 07:47:32 GMT

Anyone?

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Thu, 10 Oct 2024 08:47:08 GMT

HI @efio

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

B.R

Re: i.MX8 booting from QSPIFlash

efio — Thu, 10 Oct 2024 08:49:49 GMT

Hi,

Yes I did,

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Thu, 10 Oct 2024 09:02:08 GMT

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

Re: i.MX8 booting from QSPIFlash

efio — Thu, 10 Oct 2024 10:37:04 GMT

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

Re: i.MX8 booting from QSPIFlash

efio — Thu, 10 Oct 2024 15:37:30 GMT

Does the entry: 0x912000 correct for imx8mn?

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Fri, 11 Oct 2024 02:04:28 GMT

hi @efio

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

Re: i.MX8 booting from QSPIFlash

efio — Sun, 13 Oct 2024 06:23:29 GMT

Hi,

Observations of QSPI controller:

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

Questions:

Is this behavior normal for a QSPI controller?
Could the read value (0xd1002041) be incorrect despite appearing valid?
Why might the controller stop after three read attempts?
Is there a potential issue with the controller or the connected device?

Any insights or suggestions for further troubleshooting would be greatly appreciated.
Thank you,

Re: i.MX8 booting from QSPIFlash

efio — Sun, 13 Oct 2024 06:48:17 GMT

Hi,

Customized board,

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Mon, 14 Oct 2024 05:12:57 GMT

HI @efio

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

B.R

Re: i.MX8 booting from QSPIFlash

efio — Mon, 14 Oct 2024 08:31:22 GMT

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:

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

Any suggestions?

Thank you,

QSPI Flash sideimx8mn side

Re: i.MX8 booting from QSPIFlash

efio — Mon, 14 Oct 2024 08:49:59 GMT

Flash data sheet:
S25FL256SAGBHVB00

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Tue, 15 Oct 2024 02:31:22 GMT

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

Re: i.MX8 booting from QSPIFlash

efio — Tue, 15 Oct 2024 08:57:19 GMT

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,

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Thu, 17 Oct 2024 01:51:37 GMT

hi @efio

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

B.R

Re: i.MX8 booting from QSPIFlash

efio — Thu, 17 Oct 2024 18:38:52 GMT

Same, doesn't work

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Fri, 18 Oct 2024 06:52:05 GMT

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

Re: i.MX8 booting from QSPIFlash

efio — Tue, 22 Oct 2024 06:50:11 GMT

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,

Re: i.MX8 booting from QSPIFlash

pengyong_zhang — Wed, 23 Oct 2024 01:52:27 GMT

HI @efio

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

make SOC=iMX8MN flash_evk_flexspi

B.R