All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Michael Walle <michael@walle.cc>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <tudor.ambarus@linaro.org>,
	Pratyush Yadav <pratyush@kernel.org>,
	linux-mtd@lists.infradead.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v4] mtd: spi-nor: Add support for sst26vf032b flash
Date: Tue, 8 Aug 2023 10:24:01 +0200	[thread overview]
Message-ID: <20230808102401.26631155@xps-13> (raw)
In-Reply-To: <e618ba6c48d67469b9a2c19ee8bb5a1c@walle.cc>

Hi Michael,

michael@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@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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2023-08-08  8:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08  7:50 [PATCH v4] mtd: spi-nor: Add support for sst26vf032b flash Miquel Raynal
2023-08-08  8:11 ` Michael Walle
2023-08-08  8:24   ` Miquel Raynal [this message]
2023-08-08  8:35     ` Michael Walle
2023-08-08 15:30       ` Miquel Raynal
2023-08-18 10:06         ` Tudor Ambarus
2023-08-18 10:07 ` Tudor Ambarus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230808102401.26631155@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.