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
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
