Re: Reading QSPI on zynq7 broken since commit 9bb02f7f4533

[Mike Looijmans <mike.looijmans@topic.nl>]

On 12-03-2025 05:05, Abbarapu, Venkatesh wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Mike,
> Can you try disabling the config SPI_STACKED_PARALLEL.
> Is read getting failed?
>
> Thanks
> Venkatesh
>
>> -----Original Message-----
>> From: Mike Looijmans <mike.looijmans@topic.nl>
>> Sent: Tuesday, March 11, 2025 3:08 PM
>> To: u-boot@lists.denx.de
>> Cc: Abbarapu, Venkatesh <venkatesh.abbarapu@amd.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Subject: Reading QSPI on zynq7 broken since commit 9bb02f7f4533
>>
>> After a bisect session, turned out this causes my topic-miami board to fail to boot
>> from QSPI:
>>
>> Commit 9bb02f7f4533: "mtd: spi-nor: Fix the spi_nor_read() when config
>> SPI_STACKED_PARALLEL is enabled"
>>
>> I haven't determined yet what the bug is exactly. The board has a single QSPI chip
>> attached to a 7-series Zynq. SPL fails to read from it since this commit.
>>
I spent some time digging into this driver, but only got into a 10-year 
headache plan... The attempts at getting this specific Frankenstein 
hardware working has been a cycle of broken driver code and repairs and 
breaking again ever since its inception in the early zynq 7-series, in 
both Linux and U-boot. Makes me wonder what possesses the hardware 
designers to keep using it instead of simply slapping a octa-spi 
controller on the newer chips. And why the cadence folks thought that 
2x4=16.

For the time being I'll just revert the commit before building. If 
AMD/Xilinx ever come up with a decent fix I'll be happy to test it 
(though there should be plenty zynq7 boards that only have a single QSPI).


-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl