[OpenWrt-Devel] Issues backporting 4-byte opcode support for w25q256 fix to 4.14 kernel and Lima board

Aleksander Morgado aleksander at aleksander.es
Fri May 1 13:38:33 EDT 2020


Hey!

> > I'm working on porting your 4-byte opcode support fix for the w25q256
> > (in openwrt git master, 4745969ad7c0cb65f55c8de1f05eba786ca27f71) to
> > the 4.14 kernel used in 19.07 for the Lima board.
> >
> > The port is relatively easy just adding the post-bfpt parsing hook,
> > but I'm stuck much earlier than that. In the Lima board I'm testing
> > with (with a w25q256jv), the BFPT parsing is not even done. I've added
> > several logs along the spi-nor codebase to see why that happened, and
> > surprisingly the SFDP header version check done in
> > spi_nor_parse_sfdp() is failing; the header version read is 0xff000010
> > (??)
> >
> > [    0.862552] m25p80 spi0.0: found w25q256, expected m25p80
> > [    0.868205] m25p80 spi0.0: running spi_nor_init_params...
> > [    0.873799] m25p80 spi0.0: info->flags SPI_NOR_DUAL_READ |
> > SPI_NOR_QUAD_READ: yes
> > [    0.881522] m25p80 spi0.0: info->flags !SPI_NOR_SKIP_SFDP: yes
> > [    0.887553] m25p80 spi0.0: will parse SFDP
> > [    0.891780] m25p80 spi0.0: parsing SFDP...
> > [    0.896047] m25p80 spi0.0: SFDP header version check failed...
> > signature 0xff000010 (!= 0x50444653), major 0 (!= 1)
> > [    0.916268] m25p80 spi0.0: running spi_nor_setup...
> > [    0.921319] m25p80 spi0.0: enabling 4 byte addressing mode...
> > [    0.927294] m25p80 spi0.0: w25q256 (32768 Kbytes)
> >
> > The outcome is that the 4-byte opcode is not enabled and the spi-nor
> > ends up running in 4-byte addressing mode instead. Any idea or hint
> > why this could be happening? Does the 0xff000010 header version value
> > ring any bell?
>
> That's the first word of flash content, not sfdp header. You are hit
> by a flash reading patch for ath79-spi driver.[0]
> spi_flash_read interface is used by both flash data reading and
> SFDP reading. However this patch only handles the former case
> and returns flash data when reading SFDP table.
> To fix this problem, you need to check opcode in
> ath79_spi_read_flash_data and return -ENOTSUPP on SFDP
> reading request.
>
> [0] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch;h=7c24fc5e14e593e8945789c2ac3e37bd14ad92be;hb=33732f4a9c17921b782167a0dcaba9703d4e6753

That worked! I updated the read_flash_data() with the same logic found
in git master for kernel 5.4, looking like this:

diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
index 131e15b6b577..cf0b13a06443 100644
--- a/drivers/spi/spi-ath79.c
+++ b/drivers/spi/spi-ath79.c
@@ -214,7 +214,7 @@ static int ath79_spi_read_flash_data(struct spi_device *spi,
 {
        struct ath79_spi *sp = ath79_spidev_to_sp(spi);

-       if (msg->addr_width > 3)
+       if (msg->addr_width > 3 || msg->dummy_bytes != 1 ||
msg->read_opcode != 0x0b)
                return -EOPNOTSUPP;

        /* disable GPIO mode */

And that seems to have solved the problem with reading the SFDP.
Hopefully these changes aren't breaking anything else.

-- 
Aleksander
https://aleksander.es

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list