[PATCH] mtd: spi-nor: winbond: Make sure w25q{01, 02}jv behave correctly
Michael Nazzareno Trimarchi
michael at amarulasolutions.com
Wed Sep 10 07:28:22 CEST 2025
Hi all
On Tue, Sep 9, 2025 at 7:08 PM Raghavendra, Vignesh <vigneshr at ti.com> wrote:
>
>
>
> On 9/9/2025 5:37 PM, Jagan Teki wrote:
> > On Tue, Sep 9, 2025 at 3:43 PM Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> >>
> >> Hello,
> >>
> >> On 02/07/2025 at 11:23:13 +02, Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> >>
> >>> These chips are internally made of two/four dies with linear addressing
> >>> capabilities to make it transparent to the user that two/four dies were
> >>> used. There is one drawback however, the read status operation is racy
> >>> as the status bit only gives the active die status and not the status of
> >>> the other die. For commands affecting the two dies, it means if another
> >>> command is sent too fast after the first die has returned a valid
> >>> status (deviation can be up to 200us), the chip will get corrupted/in an
> >>> unstable state.
> >>>
> >>> The solution adopted here is to iterate manually over all internal
> >>> dies (which takes about 30us per die) until all are ready. This approach
> >>> will always be faster than a blind delay which represents the maximum
> >>> deviation, while also being totally safe.
> >>>
> >>> A flash-specific hook for the status register read had to be
> >>> implemented. Testing with the flash_speed benchmark in Linux shown no
> >>> difference with the existing performances (using the regular status read
> >>> core function).
> >>>
> >>> As the presence of multiple dies is not filled in these chips SFDP
> >>> tables (the table containing the crucial information is optional), we
> >>> need to manually wire the hook.
> >>>
> >>> This change is adapted from Linux.
> >>>
> >>> Link: https://lore.kernel.org/all/20250110-winbond-6-12-rc1-nor-volatile-bit-v3-1-735363f8cc7d@bootlin.com/
> >>> Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
> >>
> >> Same question for this one, no feedback for the past 2 months, I'm not
> >> sure who's supposed to take these, Jagan and Vignesh you are marked M:
> >> in maintainers, any chances this can get it?
> >
> > Unfortunately, I was off quite some-time. Need little bit of time.
> > Vighnesh is off for years.
>
> Thats not true. I dont have access to U-Boot SPI trees. So patches have
> been flowing through individual "platfor/SoC" maintainers trees
> unfortunately. Tom picks the patches from TI contributors once
> me/Nishanth Acks where as AMD/Xlinix bits have been picked up by Michal
> Simek and so on...
>
> Happy to help out if you help to manage a merge window every now and
> then or just review things. Most of the SPI NOR/NAND follow from linux
> where its reviewed by set of maintainers and tested (example this one is
> tested on TI board).
I will go through the patches over the weekend and review them. I will
prepare a branch
spi-nor-next and try to ask to test from there
Michael
>
> > In the meantime, Michael will help in
> > review but need help on testing.
> >
> > Thanks,
> > Jagan.
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael at amarulasolutions.com
__________________________________
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info at amarulasolutions.com
www.amarulasolutions.com
More information about the U-Boot
mailing list