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
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?
Thank you so much for your help,
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
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,
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
HI @efio
Please use the following command compile your flash.bin file.
make SOC=iMX8MN flash_evk_flexspi
B.R
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,
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
hi @efio
What is your result when you use the UUU command flash your .bin file?
B.R
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,
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
Flash data sheet:
S25FL256SAGBHVB00
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,
HI @efio
Could you please share your board schematic file and your nor flash datasheet file?
B.R
Hi,
Customized board,
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,
hi @efio
you are use our NXP i.MX8MN evk board or customer's board?
Does the entry: 0x912000 correct for imx8mn?
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
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
Hi,
Yes I did,
HI @efio
Did you choose the right boot selection? Please refer the following Boot selection for i.mx8MN.
B.R
Anyone?