| Message ID | 20230808075001.223150-1-miquel.raynal@bootlin.com |
|---|---|
| State | Accepted |
| Delegated to: | Ambarus Tudor |
| Headers | show |
| Series | [v4] mtd: spi-nor: Add support for sst26vf032b flash | expand |
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. I'd like to push as much as possible into auto-discovering features.. after working on that flash db cleanup. > 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 :( -michael
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
Hi, >> 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? No unfortunately not. > Do you have a pointer? It seems that we'd need to have some kind of parser support for vendor specific SFPD tables. Then look for the sst25vf family and the availability of the global unlock command, if both is satisfied, set the locking ops. >> 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. Ah sorry, I was just stating a fact, not criticizing your patch. There are also other places in the flash_info db with such a mess. But with the current rule "not to touch anything untested" I guess that is what we get. Funny enough, vendor trees seem to fix 'em. -michael
Hi Michael, michael@walle.cc wrote on Tue, 08 Aug 2023 10:35:08 +0200: > Hi, > > >> 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? > > No unfortunately not. > > > Do you have a pointer? > > It seems that we'd need to have some kind of parser support for > vendor specific SFPD tables. Then look for the sst25vf family > and the availability of the global unlock command, if both is > satisfied, set the locking ops. Do you mind if we actually take that one which, on this regard should be absolutely identical to the existing 64b entry? If one ever brings the logic you described I'll be pleased to test it as long as I have the board. > >> 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. > > Ah sorry, I was just stating a fact, not criticizing your patch. There > are also other places in the flash_info db with such a mess. But with > the current rule "not to touch anything untested" I guess that is > what we get. Funny enough, vendor trees seem to fix 'em. ;-) Thanks, Miquèl
On 08.08.2023 18:30, Miquel Raynal wrote: > Hi Michael, > > michael@walle.cc wrote on Tue, 08 Aug 2023 10:35:08 +0200: > >> Hi, >> >>>> 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? >> >> No unfortunately not. >> >>> Do you have a pointer? >> >> It seems that we'd need to have some kind of parser support for >> vendor specific SFPD tables. Then look for the sst25vf family >> and the availability of the global unlock command, if both is >> satisfied, set the locking ops. > > Do you mind if we actually take that one which, on this regard should > be absolutely identical to the existing 64b entry? > > If one ever brings the logic you described I'll be pleased to test it > as long as I have the board. > I'm fine with it. For the moment these entries are not supper annoying to maintain, but would be great if we use as much of the vendor tables in the future if possible.
On Tue, 08 Aug 2023 09:50:01 +0200, Miquel Raynal wrote: > 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 > > [...] Applied to git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git, spi-nor/next branch. Thanks! [1/1] mtd: spi-nor: Add support for sst26vf032b flash https://git.kernel.org/mtd/c/9d0164c6500e Cheers,
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)
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. 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(+)