R, Vignesh wrote: > On 2/24/2017 12:55 AM, Marek Vasut wrote: >> On 02/23/2017 08:22 PM, Rush, Jason A. wrote: >>> Marek Vasut wrote: >>>> On 02/22/2017 06:37 PM, Rush, Jason A. wrote: >>>>> Marek Vasut wrote: >>>>>> On 02/21/2017 05:50 PM, Rush, Jason A. wrote: > [...] >>> >>> While I was debugging some of my changes, I noticed that the data being >>> read from the >>> QSPI flash device appears to be random. The CPU no longer resets while >>> performing a >>> read when the indirect trigger address is setup correctly for the Altrera >>> SoC, but there >>> appears to be a larger problem with reading data in general. >>> > > How random is it? Is the problem seen only when unaligned read/write are > done or when length of transfer is not a multiple of word(4 byte)? > If the data is really random in all cases, then I suspect timing issues.
I've been doing reads starting at NOR flash address 0x0, with a size of 0x40000, reading into memory address 0x2000000. So I don't think it's an alignment issue. The NOR flash is erased, so it should be all 0xFF, but here's a memory dump of what I get running the latest from the master branch (with my patch for indirect trigger_address): => sf probe SF: Detected n25q1024 with page size 256 Bytes, erase size 64 KiB, total 128 MiB => sf read 0x2000000 0x0 0x40000 device 0 offset 0x0, size 0x40000 SF: 262144 bytes @ 0x0 Read: OK => md.b 0x2000000 0x40 02000000: fe 1f 6e dc dd fb 7b 44 ff dd 49 fe f8 5b ab 1b ..n...{D..I..[.. 02000010: 2f df 38 36 8f b6 47 eb 56 73 9c f9 05 ed 5c e7 /.86..G.Vs....\. 02000020: c2 ef ad fe da 6d a8 78 49 fd df 5e 77 f9 66 37 .....m.xI..^w.f7 02000030: cd 7f 7f eb 8d be 73 bf de c8 35 d5 10 bf a5 f6 ......s...5..... When I run from the v2016.11 tag, I get the following (expected results): => sf probe SF: Detected n25q1024 with page size 256 Bytes, erase size 64 KiB, total 128 MiB => sf read 0x2000000 0x0 0x40000 device 0 offset 0x0, size 0x40000 SF: 262144 bytes @ 0x0 Read: OK => md.b 0x2000000 0x40 02000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 02000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 02000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 02000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ > Please see if delay values are populated correctly in DT. All the delay values, as well as all other CQSPI properties, in the DT match the values at runtime. > >>> When I apply my patch to the v2016.11 release, reads appear correct. >>> However, when I >>> apply my patch to the v2017.01 release, the data read from the QSPI device >>> appear to be >>> random/corrupt. I noticed the cadence_spi_apb.c file changed significantly >>> between >>> v2016.11 and v2017.01, possibly a change in this file is causing the >>> problem on the Altera >>> SoC. >>> >>> I'm not really that familiar with the cadence device, so this issue is >>> getting a little beyond a >>> simple patch to setup the indirect trigger address correctly for the >>> Altrera SoC. Is there >>> anyone more familiar with the cadence device on the Altera SoC that could >>> take a look >>> into this? >> >> Vignesh did those changes, so I think he can assist you. In the >> meantime, you can try git bisect . Another thing you can try is >> disabling the dcache and see if that fixes things (dcache off), >> I recall seeing some caching issues with CQSPI. >> > > You could try reverting my commits: > commit 57897c13de03ac0136d64641a3eab526c6810387 spi: cadence_qspi_apb: > Use 32 bit indirect write transaction when possible > commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f spi: cadence_qspi_apb: > Use 32 bit indirect read transaction when possible > When I reverted these two commits and added my patch for the indirect trigger_address, it works correctly. Also, when I disabled the dcache (dcache off) as Marek suggested, it works correctly when running from the master branch (again with my indirect trigger_address patch). > > But there were other patches by others in v2017.01-rc1, like > spi: cadence_qspi: Fix CS timings which may have impact. > I left all other commits in except the two Vignesh suggested to revert, so it seems to be related to those two commits and caching. As another data point, I can load and boot linux with caching on from another source (MMC). So I don't think it's a problem with memory/caching in general. Any suggestions on how to proceed from here? --- Regards, Jason _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot