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

Marek Vasut marek.vasut at mailbox.org
Wed Nov 6 21:50:33 CET 2024


On 11/6/24 8:18 PM, Jon Humphreys wrote:
> Marek Vasut <marek.vasut at 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 ?

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


More information about the U-Boot mailing list