Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎12-20-2017

What is going on with my QSPI? Is it broken?

I'm having trouble booting from my qspi.  I've done it recently, and it only started giving me problems today.  Did I do something wrong?

My overall approach has been to build SD-bootable BOOT.BIN and image.ub using petalinux, and debug things on an SD card.  Once I have all the bugs worked out of my software, I rebuild petalinux (specifying to use "primary flash" instead of SD card in the petalinux-config menu).  I then use "flashcp -v" from the linux command line to flash the new BOOT.BIN and image.ub into /dev/mtd0 and /dev/mtd2.  I adjust the switches that determine boot method, and power cycle.

It had been a while since I booted QSPI.  Just now, I tried it the boot failed, giving a UBoot error about the FIT image being bad.

To debug this at the uboot command line, I'm trying to load an image from SD card into DDR and then boot it from memory.  Then I'd like to flash this same image to QSPI, then load it back into memory (from QSPI) and boot it.  Sounds easy, right?

1) I have an image.ub that I create with petalinux, with the intention of flashing it to QSPI.  However, first I put it on an SD card, and I can load it and boot it thusly:

fatload mmc 0 0x20000000 image.ub_flash
iminfo 0x20000000 <-- works, but output omitted for brevity
bootm 0x20000000
## Loading kernel from FIT Image at 20000000 ...
Using 'conf@1' configuration
Trying 'kernel@0' kernel subimage


2) If I then try to flash this into the kernel partition of my QSPI memory, then load it back into ram, it fails to boot.  iminfo claims it is not a valid FIT image, and indeed, it appears to be different, always at the same offset (0x21c0000)

Here, I write it to the QSPI "kernel" partition whose offset starts at 0x1e40000:

sf probe 0
sf write 0x20000000 0x1e40000 0x3dc0000


Then, I read it back into memory at a different address, for comparison:

sf read 0x30000000 0x1e40000 0x3dc0000"

The data appears to have been changed from its original:

ZynqMP> iminfo 0x30000000

## Checking Image at 30000000 ...
FIT image found
Bad FIT image format!

I compare it to the original image, and see the place where the data differs:

ZynqMP> cmp.b 0x20000000 0x30000000 0x3dc0000
byte at 0x00000000221c0000 (0x3a) != byte at 0x00000000321c0000 (0x0)
Total of 35389440 byte(s) were the same

Old data, which was pulled directly from the SD card, starting one quadword back from the difference

ZynqMP> md.q 0x00000000221bfff0 10
221bfff0: e48b9b587a0067a7 143329b2794518f8 .g.zX.....Ey.)3. <-- Same
221c0000: f10930c4fa0ccd3a 419f4489e8e066d6 :....0...f...D.A <-- Different
221c0010: 39630bc6287b471c 39d123c7f47084fa .G{(..c9..p..#.9
221c0020: dae21408b844db14 b98e7adb6789634c ..D.....Lc.g.z..
221c0030: a4b0dd19c37b2519 58e198b7cee79066 .%{.....f......X
221c0040: 4beb4bffcecbe938 c1fef679e0340e8e 8....K.K..4.y...
221c0050: cf419cbcefa42c71 d220f4c8afa438e1 q,....A..8.... .
221c0060: e215ff0521ff7c74 61f6f933557256eb t|.!.....VrU3..a

New data, which was read from SD card, written to QSPI, then read back into memory:

ZynqMP> md.q 0x00000000321bfff0 10
321bfff0: e48b9b587a0067a7 143329b2794518f8 .g.zX.....Ey.)3. <-- Same
321c0000: 1400000014000000 1400000014000000 ................ <-- Different
321c0010: 1400000014000000 1400000014000000 ................
321c0020: 584c4e58aa995566 fffc000000000000 fU..XNLX........
321c0030: 0001fae000002800 000193480001fae0 .(..........H...
321c0040: 0000080000019348 00000000fd170ff1 H...............
321c0050: 0000000000000000 0000000000000000 ................
321c0060: 0000000000000000 0100002000000000 ............ ...


The fact that the memory differs at EXACTLY 21C0000 (33 3/4 MB) makes me suspicious.  Is there an underlying partition definition that limits what I can read and write to the QSPI?  In the petalinux-config, I've defined the partition sizes as: boot=0x01e00000, bootenv=0x40000, kernel=0x3dc0000, application=0x2400000

Since it's begun failing, I've done this in a few different ways, but in all cases, no matter what I write to the QSPI, when I read it back, address 221c0000 starts with a few instances of "14000000" followed by the interesting and humorous ASCII translation "fU XLNX"

0 Kudos
5 Replies
Registered: ‎06-03-2015


QSPI is device used to boot the First stage boot loader which holds,  set of basic u-boot meory remap,DDR Initilization, board_init_f sequence, board_init_r sequence, where Image is copied to DDR  and starts decompressing Linux kernel from one of DDR memory address

For booting with QSPI

1. sf probe 0

2. sf erase 0x200000 +<sizeof memory to copy>

0x200000 is address of SPI flash , where you want to copy UImage,

Third arg. is size of uImage  

3. sf write 0x900000 0x200000 <size of memory copied>

0x900000 is address part of DDR memory, from where copying to SPI memory starting from 0x200000 with size of 4th arg.

4. sf read 0x98000000 0x200000 <size of memory copied>

Here , second arg. one of area copied from DDR memory  

5. bootm 0x98000000

boot the Image from  DDR address

In your case, sf erase cmd is missing , so it holds in the same area, older content, so while compare, It is showing old data, 

so erase from address part of SPI flash memory, to which you want to copy.

Please provide Kudos, if this post is Helpful to you

Thanks &  Regards

Satish G 

G Satish Kumar
Registered: ‎12-20-2017


I tried erasing, but did not include that output in my post.  It did not make a difference. 

As a side note: you will see that I am writing 3dc0000 bytes of data into the flash, then reading 3dc0000 bytes back into a different location of memory.  Why should I have to erase anything in the flash?  Does the write actually fail if it is not erased first?

Anyway, as I said, I did erase.  In one experiment, I sf-erased the full partition size (from offset 0 to 0x3dc0000), then read back the full partition size into memory (without writing them with any value).  Upon inspection, the values that were in memory from offset 0 to 0x21c0000 were all 0xFF (apparently, erased flash memory reads back as 0xff).  The values that appears at offset 0x21c0000 and after were exactly what is shown above (0x14000000, and so on).  So, its something about offset 0x21c0000....

I also tried programming the full boot image using program_flash over the JTAG port, and I got the same error:  the FIT image was not valid.

I think my flash has been fried, somehow, from location 0x21c0000 and on.  Maybe static electricity or too many flash write cycles?  However, it seems odd that the failure would produce not one bad memory address, but many.  All writes (or reads) fail at this location subsequent locations.

The other option is that somehow my partitions are not defined correctly (should mtdparts work at the uboot command line?  It doesn't work for me), and 32.75 MB (where the failure occurs), is beyond the partition's end.

0 Kudos
Registered: ‎06-03-2015


In general, with QSPI flashing

sf probe 

sf erase

sf write

sf read              


these cmd works fine with out any issue, if it is failing because no. of read & write cycles , it s different issue as it is specfic to QSPI used in your board.

and other one:

from u-boot prompt: mtdparts 

ubi info

ubi part <name of mtd>

ubi create 

ubi write


it will work by default, if MTD support is presented in u-boot code 

give kudos if post is helpfulg


satish g

G Satish Kumar
Registered: ‎12-20-2017

Ok, to reiterate, my main problem is that the flash doesn't seem to "hold" my image past the 32.75MB mark.  In other words, no matter what I write to that partition, when I read it back, everything is perfect up until the 32.75 MB offset.

So now I'm trying to figure out if this is some partition boundary.   Is mtdparts something that can help with this?

Should this happen at the uboot command line?

ZynqMP> mtdparts
mtdids not defined, no default present

ZynqMP> ubi info
Error, no UBI device/partition selected!


0 Kudos
Registered: ‎06-03-2015


From the Log,

mtdparts is not working,

you have to create nand partition first 

with <mtdparts> name mention size of NAND memory and start address,

 then mtdparts will show cause the partition.


>ubi info <mtdparts> 

  command provide the set of information.

see below example:

Lant> mtdparts add nand0 0x20000000@0x00000000 rootfs
mtdparts variable not set, see 'help mtdparts'
Lant> mtdparts

device nand0 <nand_iproc.0>, # parts = 1
#: name size offset mask_flags
0: rootfs 0x20000000 0x00000000 0

active partition: nand0,0 - (rootfs) 0x20000000 @ 0x00000000

mtdids : nand0=nand_iproc.0
mtdparts: mtdparts=nand_iproc.0:-(ubi0)

Lan> ubi info
Error, no UBI device/partition selected!

Lan> ubi part rootfs
Creating 1 MTD partitions on "nand0":
0x000000000000-0x000020000000 : "mtd=0"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI: create volume table (copy #2)
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=0"
UBI: MTD device size: 512 MiB
UBI: number of good PEBs: 4096
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 0
UBI: available PEBs: 4012
UBI: total number of reserved PEBs: 84
UBI: number of PEBs reserved for bad PEB handling: 80
UBI: max/mean erase counter: 1/0

Lan> ubi create rootfs2 0x10000000
Creating dynamic volume rootfs2 of size 268435456

Lan> ubi create www 0x1000000
Creating dynamic volume www of size 16777216


Lan> ubi write 0x90000000 rootfs2 0x3BB3000
62599168 bytes written to volume rootfs2

But this is different from SPI issue ,

ubifs support is with NAND placed on the board,

ubifs is to keep RFS on the board

and your issue is actually with QSPI command.


Thanks & Regards

Satish G

G Satish Kumar
0 Kudos