[U-Boot] [PATCH] spi: cadence_qspi_apb: Add trigger-base DT bindings from Linux

[Rush, Jason A.]

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