Hi Vikas,
On 19.06.2015 23:38, Vikas MANOCHA wrote:
- git bisect or cherry-pick to find out which patch is breaking the read functionality.
This one is the first introducing this breakage:
spi: cadence_qspi: fix base trigger address & transfer start address
Ok, can you confirm applying patches upto (& including) "spi: cadence_qspi: fix indirect read/write start address" , read/write to flash are working fine.
Please note that with this patch the code does not compile:
drivers/spi/cadence_qspi_apb.c: In function 'qpsi_write_sram_fifo_push': drivers/spi/cadence_qspi_apb.c:227:32: error: 'struct cadence_spi_platdata' has no member named 'trigger_base' unsigned int *dest_addr = plat->trigger_base;
I've manually fixed this trivial change (trigger_base -> ahbbase) and tests with these patches applied show some problems with "sf" stability (bit-flips):
=> sf update 400000 100000 100000 1048576 bytes written, 0 bytes skipped in 34.196s, speed 31395 B/s => sf read 500000 100000 100000 SF: 1048576 bytes @ 0x100000 Read: OK => cmp.b 400000 500000 100000 byte at 0x0040001e (0x9f) != byte at 0x0050001e (0x8f) Total of 30 byte(s) were the same
This is new - removing all your patches seems to solve this issue again. So there seems to be something wrong with the previous patches as well. here the output with the patches reverted:
=> sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR => sf update 400000 100000 100000 1048576 bytes written, 0 bytes skipped in 35.872s, speed 29929 B/s => sf read 500000 100000 100000 SF: 1048576 bytes @ 0x100000 Read: OK => cmp.b 400000 500000 100000 Total of 1048576 byte(s) were the same
The point is if after applying above mentioned patch (...: fix indirect read/write start address), Read/write are working fine, then trigger_base value of 0xFFA00_0000 should also work fine. Can you please modify the trigger_base value from 0x0 to 0xFFA0_0000 in Socfpga.dtsi & check. If it works, it would mean both (socfpga & stv0991) are behaving same.
No. With this change, the "sf read" command crashes / hangs on the SoCFPGA board.
Thanks, Stefan