cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Scholar
Scholar
4,820 Views
Registered: ‎05-28-2013

QSPI read from /dev/mtd with 14.5 (flashcp verify fails)

I'm using a ZC702 board with the 14.4 and 14.5 binaries from the wiki pages.

 

To program the QSPI, I am using the suggested command: flashcp -v boot.bin /dev/mtd0

In 14.4 release (Linux 3.6) this worked fine, exactly as described.

 

But with the 14.5 release (Linux 3.8) there's a bit of a problem. Although it erases the flash and writes the data correctly, the verification step fails. This happens for all partitions.

 

If I read from /dev/mtd0 and compare it with BOOT.BIN, there are some small differences (a few bits here and there are different). However the flash is correctly programmed; I can boot from it, and u-boot can read the uImage/uramdisk just fine. It's just reading from /dev/mtd after the kernel has booted that seems to be problematic.

 

Is anyone else seeing this issue?

0 Kudos
4 Replies
Scholar
Scholar
4,818 Views
Registered: ‎02-27-2008

r,

 

Good to ask if anyone may be seeing the same problem, but if you were using 14.4, why did you move to 14.5?  Generall, when you do decide to move to a new version, you will have to re-test everything, re-verify everything, and re-validate everything.  Updating IP blocks is especially fraught with difficulty because newer IP blocks may not be forward (or backward) compatible.  Unlike software, hardware (soft IP) may have new features, new signals, and new capabilities that will absolutely break if "upgrading" is done without thought.


You are implementing hardware (programmably).  Every step must be deliberate, thought out, complete.

 

Hope someone can comment on your issue, maybe it is something trivial (but since going to a new version is >100, 000+ changes), but I doubt it.

 

For example, if you do a diff on the bitstream before and after, you will probably find millions (tens of millions) of changed bits.

 

Which one(s) are important?  All of them.

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Scholar
Scholar
4,811 Views
Registered: ‎05-28-2013

Hi Austin,

 

We're just getting started on our project and haven't done a whole lot of PL work yet, just a few trivial experiments. We're really just exercising the PS currently. So changing to the most recent available Xilinx tools is a reasonable thing for us to do at this stage.

 

We can certainly backtrack to 14.4, but in all those 100,000 changes, there are some that are quite important - such as ethernet performance improvements, just to pick from recent memory.

 

Cheers,

-Ralph

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,800 Views
Registered: ‎03-13-2012

I suspect there is a bug in the QSPI driver or similar. I can confrim the behavior with the release kernel, but I seems to be gone on the current master-next branch (HEAD@4c8e6d724d297b66f86f8bc3fe928d283d27e96c).

0 Kudos
Highlighted
Scholar
Scholar
4,790 Views
Registered: ‎05-28-2013

Thanks for confirming. Indeed it is fixed in master-next branch.

 

I've tracked the difference down to commit 3af42ee4c222799972cf791dbff988781048fcd3 ("xilinx: arm: spi: handle zero speed in transfer message")

 

Cheers,

-Ralph

0 Kudos