Marek Vasut <marek.va...@mailbox.org> writes:
> On 11/6/24 10:58 PM, Jon Humphreys wrote:
>> Marek Vasut <marek.va...@mailbox.org> writes:
>>
>>> On 11/6/24 8:18 PM, Jon Humphreys wrote:
>>>> Marek Vasut <marek.va...@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.
>
> Can you try and run some 'git bisect' to find out exactly which commit
> broke your use case ? There is a bunch of fixes for the worst breakage
> that landed recently, but clearly there is more.
>
> Full revert seems increasingly appealing ...
commit 5d40b3d384d
Jon
