[PATCH v4] mtd: spi-nor: Add support for sst26vf032b flash

[Miquel Raynal]

Hi Michael,

michael at walle.cc wrote on Tue, 08 Aug 2023 10:11:51 +0200:

> Am 2023-08-08 09:50, schrieb Miquel Raynal:
> > Describe this new part. The datasheet is public.
> > 
> > Link: > https://ww1.microchip.com/downloads/aemDocuments/documents/MPD/ProductDocuments/DataSheets/SST26VF032B-SST26VF032BA-2.5V-3.0V-32-Mbit-Serial-Quad-IO-%28SQI%29-Flash-Memory-20005218K.pdf
> > 
> > Here are the sfdp tables plus base testing to show it works.
> > 
> > $ cat /sys/bus/spi/devices/spi0.0/spi-nor/partname
> > sst26vf032b
> > $ cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id
> > bf2642
> > $ cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer
> > sst
> > $ xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
> > 53464450060102ff00060110300000ff81000106000100ffbf0001180002
> > 0001fffffffffffffffffffffffffffffffffd20f1ffffffff0144eb086b
> > 083b80bbfeffffffffff00ffffff440b0c200dd80fd810d820914824806f
> > 1d81ed0f773830b030b0f7ffffff29c25cfff030c080ffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffff0004fff37f0000f57f0000f9ff
> > 3d00f57f0000f37f0000ffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> > ffffbf2642ffb95ffdff30f260f332ff0a122346ff0f19320f1919ffffff
> > ffffffff00669938ff05013506040232b03072428de89888a585c09faf5a
> > ffff06ec060c0003080bffffffffff07ffff0202ff060300fdfd040600fc
> > 0300fefe0202070e
> > $ md5sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
> > e7efddddb3d5ee89ca37bf6b6e789645  > /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
> > 
> > $ dd if=/dev/urandom of=./qspi_test bs=1M count=1
> > 1+0 records in
> > 1+0 records out
> > $ mtd_debug write /dev/mtd0 0 1048576 qspi_test
> > Copied 1048576 bytes from qspi_test to address 0x00000000 in flash
> > $ mtd_debug erase /dev/mtd0 0 1048576
> > Erased 1048576 bytes from address 0x00000000 in flash
> > $ mtd_debug read /dev/mtd0 0 1048576 qspi_read
> > Copied 1048576 bytes from address 0x00000000 in flash to qspi_read
> > $ hexdump qspi_read
> > 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
> > *
> > 0100000
> > $ mtd_debug write /dev/mtd0 0 1048576 qspi_test
> > Copied 1048576 bytes from qspi_test to address 0x00000000 in flash
> > $ mtd_debug read /dev/mtd0 0 1048576 qspi_read
> > Copied 1048576 bytes from address 0x00000000 in flash to qspi_read
> > $ sha1sum qspi_test qspi_read
> > 2f2f191c7a937eca5db21a1c39e79e7327587cc1  qspi_test
> > 2f2f191c7a937eca5db21a1c39e79e7327587cc1  qspi_read
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
> > ---
> > 
> > Changes in v4:
> > * Just providing the PARSE_SFDP flag seem to work but actually does
> >   not. As opposed to the NAND world which loudly fails when WP is
> >   enabled, here the destructive operations are silently ignored by the
> >   chip, so actually the reads work but without the additional
> >   LOCK/SWP_IS_VOLATILE flags, the chip does not process writes and
> >   erasures. Reinstate these two lines as in my backported patch (a
> >   linux4microchip kernel on which I actually run this hardware), so I > am
> >   sure it also works in mainline.  
> 
> Mhh, this flash has vendor tables. The sst26vf global unlock should
> be discoverable. There is a table with all supported opcodes, which
> could be used to see whether this flash needs the global unlock.

Is this logic already existing in the core? Do you have a pointer?

> I'd like to push as much as possible into auto-discovering
> features.. after working on that flash db cleanup.

I understand, but as I said, testing latest versions of the kernel on
my hardware is not straightforward.

> > Changes in v3:
> > * Dropped the second patch (untested changes as advised by Tudor).
> > * Avoided playing with locking as I cannot test it either: simplified
> >   the diff by just using the PARSE_SFDP flag.
> > * Rebased on top of -rc1 and adapted the patch to the current state.
> > 
> >  drivers/mtd/spi-nor/sst.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
> > index 688eb20c763e..414ee4692fd1 100644
> > --- a/drivers/mtd/spi-nor/sst.c
> > +++ b/drivers/mtd/spi-nor/sst.c
> > @@ -111,6 +111,10 @@ static const struct flash_info sst_nor_parts[] = {
> >  			      SPI_NOR_QUAD_READ) },
> >  	{ "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32)
> >  		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ) },
> > +	{ "sst26vf032b", INFO(0xbf2642, 0, 0, 0)
> > +		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
> > +		PARSE_SFDP
> > +		.fixups = &sst26vf_nor_fixups },
> >  	{ "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128)
> >  		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
> >  		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)  
> 
> Honestly, this is such a mess. There are three identical chips:
> sst26v016b, 032b and 064b and all have different flags :(

I only have the 32b variant, but I believe they are all identical. The
FLAGS and fixups fields are missing from the 16b variant in mainline
but they are all identical in the linux4microchip repository, I believe
the missing patches have never been upstreamed, that's all.

And I am now using the PARSE_SFDP flag as advised because it works, but
initially I wanted to keep the hardcoded flags.

Thanks,
Miquèl