Definition for flash w25q128 is wrong

[Robert Marko]

On Mon, 1 Apr 2024 at 15:00, e9hack <e9hack at gmail.com> wrote:
>
> Am 01.04.2024 um 11:54 schrieb Robert Marko:
> > On Mon, 1 Apr 2024 at 11:25, e9hack <e9hack at gmail.com> wrote:
> >>
> >> Am 01.04.2024 um 11:06 schrieb Robert Marko:
> >>> On Mon, 1 Apr 2024 at 10:32, e9hack <e9hack at gmail.com> wrote:
> >>>>
> >>>> Am 01.04.2024 um 10:14 schrieb Robert Marko:
> >>>>> On Mon, 1 Apr 2024 at 06:29, e9hack <e9hack at gmail.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm using a TP-LINK WDR3600 with a bigger flash. Since some time the router hangs in an endless boot loop. I see the following message:
> >>>>>>
> >>>>>> ...
> >>>>>> [    0.402716] spi-nor spi0.0: BFPT parsing failed. Please consider using SPI_NOR_SKIP_SFDP when declaring the flash
> >>>>>> [    0.413217] spi-nor: probe of spi0.0 failed with error -22
> >>>>>> ...
> >>>>>> [    0.926180] /dev/root: Can't open blockdev
> >>>>>> [    0.930427] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
> >>>>>> [    0.938037] Please append a correct "root=" boot option; here are the available partitions:
> >>>>>> [    0.946520] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> >>>>>> [    0.954914] Rebooting in 1 seconds..
> >>>>>>
> >>>>>> It looks like the definition for the flash is wrong:
> >>>>>>
> >>>>>> --- a/drivers/mtd/spi-nor/winbond.c     2024-03-15 19:27:50.000000000 +0100
> >>>>>> +++ b/drivers/mtd/spi-nor/winbond.c     2024-04-01 05:59:17.166780732 +0200
> >>>>>> @@ -120,8 +120,8 @@ static const struct flash_info winbond_n
> >>>>>>                    NO_SFDP_FLAGS(SECT_4K) },
> >>>>>>            { "w25q80bl", INFO(0xef4014, 0, 64 * 1024,  16)
> >>>>>>                    NO_SFDP_FLAGS(SECT_4K) },
> >>>>>> -       { "w25q128", INFO(0xef4018, 0, 0, 0)
> >>>>>> -               PARSE_SFDP
> >>>>>> +       { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256)
> >>>>>> +               NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> >>>>>>                    FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) },
> >>>>>>            { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512)
> >>>>>>                    NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> >>>>>>
> >>>>>> With these changes, the flash will be detected properly.
> >>>>>
> >>>>> Yeah, I am not so sure this is correct as all w25q128 versions have
> >>>>> SFDP table so skipping SFDP parsing
> >>>>> isn't really correct.
> >>>>> Can you check what is the exact model you have?
> >>>>
> >>>> The chip (SOIC8) is marked with:
> >>>>
> >>>> winbond
> >>>> 25Q128FVSG
> >>>> 1327
> >>>
> >>> If it is Genuine Winbond then it has an SFDP table according to the datasheet:
> >>> https://www.winbond.com/hq/support/documentation/downloadV2022.jsp?__locale=en&xmlPath=/support/resources/.content/item/DA00-W25Q128FV.html&level=1
> >>>
> >>> AFAIK, all Winbond NOR with datecode 1124 and onwards have SFDP tables.
> >>>
> >>> Has this happened with kernel 6.1 or been going on for a while?
> >>
> >> My build from October is using kernel 5.15.133. I assume it is an issue of kernel 6.1.
> >>
> >> It looks like a driver issue. A SOIC8 housing doesn't support dual/quad SPI. The flash will be detect, if I change
> >>
> >> PARSE_SFDP to NO_SFDP_FLAGS(SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ).
> >
> > Hm, it really looks like your revision has broken SFDP but since
> > Winbond in their ultimate wisdom decided
> > that it was best to share the same JEDEC ID with other revisions SFDP
> > was enabled via:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/spi-nor/winbond.c?h=v6.1.83&id=7c6ba20a0b9aeb82a6c097c74ccbecdda8e9fc25
> >
> > So you really need to report this to the linux-mtd crowd.
> > Can you check if SFDP table can be dumped on your NOR, cause there
> > should be one but most likely one of the tables is broken?
>
> The flash does not have a SFDP. I use another TP-LINK router. This is an Archer C7 v2. It has the same flash chip with date code 1528. This flash has a SFDP.

Then it would be best to send a revert upstream.

Regards,
Robert
>
> Regards,
> Hartmut
> >
> > Regards,
> > Robert
> >>
> >> Regards,
> >> Hartmut
> >>
> >>>
> >>> Regards,
> >>> Robert
> >>>
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Robert
> >>>>>>
> >>>>>> Regards,
> >>>>>> Hartmut
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> openwrt-devel mailing list
> >>>>>> openwrt-devel at lists.openwrt.org
> >>>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >>>>
> >>
>