Re: [PATCH 1/6] Revert "spi: zynq_qspi: Add parallel memories support in QSPI driver"

[Jon Humphreys <j-humphreys@ti.com>]

Marek Vasut <marek.vasut@mailbox.org> writes:

> On 11/6/24 8:18 PM, Jon Humphreys wrote:
>> Marek Vasut <marek.vasut@mailbox.org> writes:
>> 
>>> On 10/23/24 10:17 AM, Michal Simek wrote:
>>>>
>>>>
>>>> On 10/22/24 23:06, Marek Vasut wrote:
>>>>> This reverts commit 1e36d34b52e7a1ebe5a2a5339d6905540f4253aa.
>>>>>
>>>>> This parallel/stacked support breaks basic SPI NOR support,
>>>>> e.g. this no longer works:
>>>>>
>>>>> => sf probe && sf update 0x50000000 0 0x160000
>>>>> SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB,
>>>>> total 64 MiB
>>>>> device 0 offset 0x0, size 0x160000
>>>>> SPI flash failed in read step
>>>>
>>>> Reverting everything seems to me too much. Tom has tested it on his HW
>>>> and didn't see any issue. That's why better to look at code which is
>>>> causing this.
>>>> You are reverting everything but likely there is specific patch which is
>>>> causing this. Which one is it?
>>>> Which board was used for your testing? Likely we don't have access to it.
>>>> Is there any QEMU available which can be used for debugging?
>>>
>>> The testcase including the exact SPI NOR model is above.
>>>
>>> iMX6 with w25q16dw seems to be broken too.
>>>
>>> Basically every board I have access no longer has a working "sf probe ;
>>> sf update" combination ... so yeah, this means this patchset is
>>> fundamentally broken.
>>>
>> 
>> I can also confirm that the patch series:
>> 
>> f8efc68b30e Merge patch series "spi-nor: Add parallel and stacked memories
>> support"
>> 
>> breaks SPI NOR on TI platforms, particularly SK-AM62 and SK-AM62P:
>> 
>> U-Boot 2024.10-00752-gf8efc68b30e2 (Nov 06 2024 - 12:25:13 -0600)
>> 
>> SoC:   AM62X SR1.0 HS-FS
>> Model: Texas Instruments AM625 SK
>> ...
>> Hit any key to stop autoboot:  0
>> => sf probe && sf update ${loadaddr} 0x400000 0x10
>> SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
>> device 0 offset 0x400000, size 0x10
>> SPI flash failed in read step
>> =>
> Sigh ... can you please test current u-boot/master and see if the error 
> is fixed there ?
>

Yes I had verified it also fails against master, although the behavior was
a bit different.  The .'s below are our DMA engine waiting indefinitely.

=> sf probe && sf update ${loadaddr} 0x400000 0x10
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
device 0 offset 0x400000, size 0x10
.....................................................

I have not investigated further.

Jon

> We really should've gone with a full revert I think ...