diff mbox series

[v3,2/2] mtd: spi-nor: micron-st: Add support for mt25qu01g

Message ID 20231026112312.3217502-2-festevam@gmail.com
State Superseded
Delegated to: Ambarus Tudor
Headers show
Series [v3,1/2] mtd: spi-nor: Set the erase flag for multi-die | expand

Commit Message

Fabio Estevam Oct. 26, 2023, 11:23 a.m. UTC 
From: Fabio Estevam <festevam@denx.de>

Add support for the MT25QU01G 128MB Micron Serial NOR Flash Memory
model.

Datasheet:
https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf

Tested on a i.MX8MP based board:

~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/jedec_id
20bb21104400

~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/manufacturer
st

~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/partname
mt25qu01g

~# xxd -p  /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
53464450060101ff00060110300000ff84000102800000ffffffffffffff
ffffffffffffffffffffffffffffffffffffe520fbffffffff3f29eb276b
273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e
03e1ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff
ffffffffffffffffffe7ffff21dcffff

~# md5sum  /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
9d28d1b11de8b15ba9152644219d9a78 /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp

~# dd if=/dev/urandom of=spi_test bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 4.77424 s, 28.1 MB/s

~# mtd_debug write /dev/mtd0 0 134217728 spi_test
Copied 134217728 bytes from spi_test to address 0x00000000 in flash

~# mtd_debug read /dev/mtd0 0 134217728 spi_read
Copied 134217728 bytes from address 0x00000000 in flash to spi_read

~# sha1sum spi_test spi_read
6778615a7b7db2d3c3fa122721d940082eb67039  spi_test
6778615a7b7db2d3c3fa122721d940082eb67039  spi_read

~# flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 100 % complete 

~# hexdump -C /dev/mtd0
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
08000000

Signed-off-by: Fabio Estevam <festevam@denx.de>
---
Changes since v2:
- Added fixups to report the correct n_dice information.
- Removed .flags = NO_CHIP_ERASE (Michael)
- Removed .mfr_flags = USE_FSR (Michael)

 drivers/mtd/spi-nor/micron-st.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

Comments

Tudor Ambarus Oct. 27, 2023, 6:59 a.m. UTC | #1 
Hi, Fabio,

The entire patch looks very suspicious to me. I'd like some more tests
please, see my reasoning below.

On 26.10.2023 14:23, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> Add support for the MT25QU01G 128MB Micron Serial NOR Flash Memory
> model.
> 
> Datasheet:
> https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
> 
> Tested on a i.MX8MP based board:
> 
> ~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/jedec_id
> 20bb21104400
> 
> ~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/manufacturer
> st
> 
> ~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/partname
> mt25qu01g
> 
> ~# xxd -p  /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
> 53464450060101ff00060110300000ff84000102800000ffffffffffffff
> ffffffffffffffffffffffffffffffffffffe520fbffffffff3f29eb276b
> 273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e
> 03e1ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff
> ffffffffffffffffffe7ffff21dcffff
> 
> ~# md5sum  /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
> 9d28d1b11de8b15ba9152644219d9a78 /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
> 
> ~# dd if=/dev/urandom of=spi_test bs=1M count=128
> 128+0 records in
> 128+0 records out
> 134217728 bytes (134 MB, 128 MiB) copied, 4.77424 s, 28.1 MB/s
> 
> ~# mtd_debug write /dev/mtd0 0 134217728 spi_test
> Copied 134217728 bytes from spi_test to address 0x00000000 in flash
> 
> ~# mtd_debug read /dev/mtd0 0 134217728 spi_read
> Copied 134217728 bytes from address 0x00000000 in flash to spi_read
> 
> ~# sha1sum spi_test spi_read
> 6778615a7b7db2d3c3fa122721d940082eb67039  spi_test
> 6778615a7b7db2d3c3fa122721d940082eb67039  spi_read
> 
> ~# flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 100 % complete 
> 
> ~# hexdump -C /dev/mtd0
> 00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
> *
> 08000000

This doesn't prove the flash works because if the entire flash is
already erased and all the ops are noops, the test passes.

Would you please do the following tests instead?

1/ dd if=/dev/urandom of=spi_test bs=1M count=128
2/ mtd_debug write /dev/mtd0 0 134217728 spi_test
3/ just make sure that we wrote something and the flash does not
contains just 0xff data. Read 246 bytes from both dies and dump them.
mtd_debug read /dev/mtd0 0 256 first-die
cat first-die
mtd_debug read /dev/mtd0 67108864 256 second-die
cat second-die
4/ now that we are sure we have some data in it and not just 0xff, erase
the entire flash and make sure we get just 0xff when reading
flash_erase /dev/mtd0 0 0
hexdump -C /dev/mtd0
6/ now do the write-readback-verify test
mtd_debug write /dev/mtd0 0 134217728 spi_test
mtd_debug read /dev/mtd0 0 134217728 spi_read
sha1sum spi_test spi_read

> 
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> Changes since v2:
> - Added fixups to report the correct n_dice information.
> - Removed .flags = NO_CHIP_ERASE (Michael)
> - Removed .mfr_flags = USE_FSR (Michael)

Not a good idea to remove USE_FSR. FSR is used to determine page program
and erase errors, please keep it.
> 
>  drivers/mtd/spi-nor/micron-st.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
> index 8920547c12bf..31839d6bc3ac 100644
> --- a/drivers/mtd/spi-nor/micron-st.c
> +++ b/drivers/mtd/spi-nor/micron-st.c
> @@ -192,6 +192,20 @@ static struct spi_nor_fixups mt25qu512a_fixups = {
>  	.post_bfpt = mt25qu512a_post_bfpt_fixup,
>  };
>  
> +static int mt25qu01g_post_sfdp_fixup(struct spi_nor *nor)
> +{
> +	struct spi_nor_flash_parameter *params = nor->params;
> +
> +	/* MT25QU01G does not define the SCCR entry, so pass n_dice manually. */
> +	params->n_dice = 2;
> +

I wonder why this is needed if it's not used anywhere. Do you set this
just so that based on it to set the no-chip-erase flag? If yes, set the
no chip erase flag directly and drop the entire fixup hook. Would be
good to introduce the die erase capability if you care about erase speed.

Skimming over the datasheet you pointed out didn't help me remove my
concerns.
See "Table 24: 4-BYTE READ MEMORY Operations", it says "a die can be
read with a single command", but we don't consider this anywhere in the
code.

If the flash works with the current code, why does it work?
Please enable dev_dbg, we have one in spi_nor_read(), we shall see
what's going on.

Cheers,
ta
Fabio Estevam Oct. 27, 2023, 12:28 p.m. UTC | #2 
Hi Tudor,

On Fri, Oct 27, 2023 at 3:59 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:

> Would you please do the following tests instead?

Ok, I am back to using v2:

+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -429,6 +429,11 @@ static const struct flash_info st_nor_parts[] = {
                         SPI_NOR_BP3_SR_BIT6,
                .no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
                .mfr_flags = USE_FSR,
+       }, {
+               .id = SNOR_ID(0x20, 0xbb, 0x21, 0x10, 0x44, 0x00),
+               .name = "mt25qu01g",
+               .flags = NO_CHIP_ERASE,
+               .mfr_flags = USE_FSR,
        }, {

Here are the results:

1)
~# dd if=/dev/urandom of=spi_test bs=1M count=128
128+0 records in
128+0 records out

2)
~# time mtd_debug write /dev/mtd0 0 134217728 spi_test
Copied 134217728 bytes from spi_test to address 0x00000000 in flash

real 2m21.889s
user 0m0.001s
sys 1m14.607s

3)
~# mtd_debug read /dev/mtd0 0 256 first-die
Copied 256 bytes from address 0x00000000 in flash to first-die

~# hexdump first-die
0000000 8090 0008 4d0d d780 0a18 422d 002c c182
0000010 2d54 0248 0119 0680 11cc 8080 301e 0401
.....[snip]
00000f0 0010 4480 2800 4208 a830 6451 0882 4088
0000100
~# mtd_debug read /dev/mtd0 67108864 256 second-die
Copied 256 bytes from address 0x04000000 in flash to second-die
~# hexdump second-die
0000000 1080 ca40 0890 2000 880d 00c0 0142 8440
0000010 1081 6908 0804 0120 82b8 40a4 9440 0290
....[snip]
00000f0 c116 1630 221c 4222 0080 0271 4141 a00c
0000100

4)
~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 100 % complete

real 4m5.447s
user 0m0.001s
sys 3m42.945s
~# hexdump -C /dev/mtd0
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
08000000

5)
~# time mtd_debug write /dev/mtd0 0 134217728 spi_test
Copied 134217728 bytes from spi_test to address 0x00000000 in flash

real 2m7.288s
user 0m0.005s
sys 1m52.549s
~# time mtd_debug read /dev/mtd0 0 134217728 spi_read
Copied 134217728 bytes from address 0x00000000 in flash to spi_read

real 0m5.372s
user 0m0.000s
sys 0m3.524s
~# sha1sum spi_test spi_read
3dd58f6d935db05a37d597d25562cfa107c3cf7f  spi_test
3dd58f6d935db05a37d597d25562cfa107c3cf7f  spi_read

Please note the very long time it takes to complete the full write and
erase commands in steps 4) and 5).

> Not a good idea to remove USE_FSR. FSR is used to determine page program
> and erase errors, please keep it.

Ok, I will keep it.

> I wonder why this is needed if it's not used anywhere. Do you set this
> just so that based on it to set the no-chip-erase flag? If yes, set the

Yes, correct. I did it as per Michael's suggestion. I will keep the
no-chip-erase flag.

> no chip erase flag directly and drop the entire fixup hook. Would be
> good to introduce the die erase capability if you care about erase speed.

Yes, the erase speed is bad.

Any suggestions as to how to introduce the die-erase capability?

> Skimming over the datasheet you pointed out didn't help me remove my
> concerns.
> See "Table 24: 4-BYTE READ MEMORY Operations", it says "a die can be
> read with a single command", but we don't consider this anywhere in the
> code.
>
> If the flash works with the current code, why does it work?
> Please enable dev_dbg, we have one in spi_nor_read(), we shall see
> what's going on.

Here is the 'mtd_debug read' result with dev_dbg() enabled:

~# time mtd_debug read /dev/mtd0 0 134217728 spi_read
[  174.405423] spi-nor spi0.0: from 0x00000000, len 4194304
[  174.499346] spi-nor spi0.0: from 0x00400000, len 4194304
[  174.592396] spi-nor spi0.0: from 0x00800000, len 4194304
[  174.685531] spi-nor spi0.0: from 0x00c00000, len 4194304
[  174.778882] spi-nor spi0.0: from 0x01000000, len 4194304
[  174.871549] spi-nor spi0.0: from 0x01400000, len 4194304
[  174.964846] spi-nor spi0.0: from 0x01800000, len 4194304
[  175.057758] spi-nor spi0.0: from 0x01c00000, len 4194304
[  175.151109] spi-nor spi0.0: from 0x02000000, len 4194304
[  175.244185] spi-nor spi0.0: from 0x02400000, len 4194304
[  175.337410] spi-nor spi0.0: from 0x02800000, len 4194304
[  175.430272] spi-nor spi0.0: from 0x02c00000, len 4194304
[  175.523659] spi-nor spi0.0: from 0x03000000, len 4194304
[  175.616721] spi-nor spi0.0: from 0x03400000, len 4194304
[  175.710109] spi-nor spi0.0: from 0x03800000, len 4194304
[  175.803029] spi-nor spi0.0: from 0x03c00000, len 4194304
[  175.896167] spi-nor spi0.0: from 0x04000000, len 4194304
[  175.989247] spi-nor spi0.0: from 0x04400000, len 4194304
[  176.082623] spi-nor spi0.0: from 0x04800000, len 4194304
[  176.175383] spi-nor spi0.0: from 0x04c00000, len 4194304
[  176.268842] spi-nor spi0.0: from 0x05000000, len 4194304
[  176.361777] spi-nor spi0.0: from 0x05400000, len 4194304
[  176.455055] spi-nor spi0.0: from 0x05800000, len 4194304
[  176.548084] spi-nor spi0.0: from 0x05c00000, len 4194304
[  176.641573] spi-nor spi0.0: from 0x06000000, len 4194304
[  176.734721] spi-nor spi0.0: from 0x06400000, len 4194304
[  176.827902] spi-nor spi0.0: from 0x06800000, len 4194304
[  176.920998] spi-nor spi0.0: from 0x06c00000, len 4194304
[  177.014415] spi-nor spi0.0: from 0x07000000, len 4194304
[  177.107817] spi-nor spi0.0: from 0x07400000, len 4194304
[  177.201154] spi-nor spi0.0: from 0x07800000, len 4194304
[  177.294104] spi-nor spi0.0: from 0x07c00000, len 4194304
Copied 134217728 bytes from address 0x00000000 in flash to spi_read

real 0m5.525s
user 0m0.001s
sys 0m3.687s

Thanks
Tudor Ambarus Oct. 27, 2023, 12:59 p.m. UTC | #3 
On 10/27/23 13:28, Fabio Estevam wrote:
> Hi Tudor,

Hi!

> 
> On Fri, Oct 27, 2023 at 3:59 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> 
>> Would you please do the following tests instead?
> 
> Ok, I am back to using v2:
> 
> +++ b/drivers/mtd/spi-nor/micron-st.c
> @@ -429,6 +429,11 @@ static const struct flash_info st_nor_parts[] = {
>                          SPI_NOR_BP3_SR_BIT6,
>                 .no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
>                 .mfr_flags = USE_FSR,
> +       }, {
> +               .id = SNOR_ID(0x20, 0xbb, 0x21, 0x10, 0x44, 0x00),
> +               .name = "mt25qu01g",
> +               .flags = NO_CHIP_ERASE,
> +               .mfr_flags = USE_FSR,
>         }, {
> 
> Here are the results:
> 
> 1)
> ~# dd if=/dev/urandom of=spi_test bs=1M count=128
> 128+0 records in
> 128+0 records out
> 
> 2)
> ~# time mtd_debug write /dev/mtd0 0 134217728 spi_test
> Copied 134217728 bytes from spi_test to address 0x00000000 in flash
> 
> real 2m21.889s
> user 0m0.001s
> sys 1m14.607s
> 
> 3)
> ~# mtd_debug read /dev/mtd0 0 256 first-die
> Copied 256 bytes from address 0x00000000 in flash to first-die
> 
> ~# hexdump first-die
> 0000000 8090 0008 4d0d d780 0a18 422d 002c c182
> 0000010 2d54 0248 0119 0680 11cc 8080 301e 0401
> .....[snip]
> 00000f0 0010 4480 2800 4208 a830 6451 0882 4088
> 0000100
> ~# mtd_debug read /dev/mtd0 67108864 256 second-die
> Copied 256 bytes from address 0x04000000 in flash to second-die
> ~# hexdump second-die
> 0000000 1080 ca40 0890 2000 880d 00c0 0142 8440
> 0000010 1081 6908 0804 0120 82b8 40a4 9440 0290
> ....[snip]
> 00000f0 c116 1630 221c 4222 0080 0271 4141 a00c
> 0000100
> 
> 4)
> ~# time flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 100 % complete
> 
> real 4m5.447s
> user 0m0.001s
> sys 3m42.945s
> ~# hexdump -C /dev/mtd0
> 00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
> *
> 08000000
> 
> 5)
> ~# time mtd_debug write /dev/mtd0 0 134217728 spi_test
> Copied 134217728 bytes from spi_test to address 0x00000000 in flash
> 
> real 2m7.288s
> user 0m0.005s
> sys 1m52.549s
> ~# time mtd_debug read /dev/mtd0 0 134217728 spi_read
> Copied 134217728 bytes from address 0x00000000 in flash to spi_read
> 
> real 0m5.372s
> user 0m0.000s
> sys 0m3.524s
> ~# sha1sum spi_test spi_read
> 3dd58f6d935db05a37d597d25562cfa107c3cf7f  spi_test
> 3dd58f6d935db05a37d597d25562cfa107c3cf7f  spi_read
> 
> Please note the very long time it takes to complete the full write and
> erase commands in steps 4) and 5).
> 
>> Not a good idea to remove USE_FSR. FSR is used to determine page program
>> and erase errors, please keep it.
> 
> Ok, I will keep it.
> 
>> I wonder why this is needed if it's not used anywhere. Do you set this
>> just so that based on it to set the no-chip-erase flag? If yes, set the
> 
> Yes, correct. I did it as per Michael's suggestion. I will keep the
> no-chip-erase flag.
> 
>> no chip erase flag directly and drop the entire fixup hook. Would be
>> good to introduce the die erase capability if you care about erase speed.
> 
> Yes, the erase speed is bad.
> 
> Any suggestions as to how to introduce the die-erase capability?

start looking at how spi_nor_erase() is implemented. When addr and
length are die aligned you may use the erase die command.

> 
>> Skimming over the datasheet you pointed out didn't help me remove my
>> concerns.
>> See "Table 24: 4-BYTE READ MEMORY Operations", it says "a die can be
>> read with a single command", but we don't consider this anywhere in the
>> code.
>>
>> If the flash works with the current code, why does it work?
>> Please enable dev_dbg, we have one in spi_nor_read(), we shall see
>> what's going on.
> 
> Here is the 'mtd_debug read' result with dev_dbg() enabled:
> 
> ~# time mtd_debug read /dev/mtd0 0 134217728 spi_read
> [  174.405423] spi-nor spi0.0: from 0x00000000, len 4194304
> [  174.499346] spi-nor spi0.0: from 0x00400000, len 4194304
> [  174.592396] spi-nor spi0.0: from 0x00800000, len 4194304
> [  174.685531] spi-nor spi0.0: from 0x00c00000, len 4194304
> [  174.778882] spi-nor spi0.0: from 0x01000000, len 4194304
> [  174.871549] spi-nor spi0.0: from 0x01400000, len 4194304
> [  174.964846] spi-nor spi0.0: from 0x01800000, len 4194304
> [  175.057758] spi-nor spi0.0: from 0x01c00000, len 4194304
> [  175.151109] spi-nor spi0.0: from 0x02000000, len 4194304
> [  175.244185] spi-nor spi0.0: from 0x02400000, len 4194304
> [  175.337410] spi-nor spi0.0: from 0x02800000, len 4194304
> [  175.430272] spi-nor spi0.0: from 0x02c00000, len 4194304
> [  175.523659] spi-nor spi0.0: from 0x03000000, len 4194304
> [  175.616721] spi-nor spi0.0: from 0x03400000, len 4194304
> [  175.710109] spi-nor spi0.0: from 0x03800000, len 4194304
> [  175.803029] spi-nor spi0.0: from 0x03c00000, len 4194304
> [  175.896167] spi-nor spi0.0: from 0x04000000, len 4194304
> [  175.989247] spi-nor spi0.0: from 0x04400000, len 4194304
> [  176.082623] spi-nor spi0.0: from 0x04800000, len 4194304
> [  176.175383] spi-nor spi0.0: from 0x04c00000, len 4194304
> [  176.268842] spi-nor spi0.0: from 0x05000000, len 4194304
> [  176.361777] spi-nor spi0.0: from 0x05400000, len 4194304
> [  176.455055] spi-nor spi0.0: from 0x05800000, len 4194304
> [  176.548084] spi-nor spi0.0: from 0x05c00000, len 4194304
> [  176.641573] spi-nor spi0.0: from 0x06000000, len 4194304
> [  176.734721] spi-nor spi0.0: from 0x06400000, len 4194304
> [  176.827902] spi-nor spi0.0: from 0x06800000, len 4194304
> [  176.920998] spi-nor spi0.0: from 0x06c00000, len 4194304
> [  177.014415] spi-nor spi0.0: from 0x07000000, len 4194304
> [  177.107817] spi-nor spi0.0: from 0x07400000, len 4194304
> [  177.201154] spi-nor spi0.0: from 0x07800000, len 4194304
> [  177.294104] spi-nor spi0.0: from 0x07c00000, len 4194304

It probably works because by some reason the reads are done in 4MB
steps, and we don't have any cross-die reads.
Please re-do the erase-write-readback-compare test starting at 61MB
offset with 4 MB length. This way we'll have 2 MB tested in the first
die and 2 MB in the second one.

Thanks,
ta
Fabio Estevam Oct. 27, 2023, 1:52 p.m. UTC | #4 
On Fri, Oct 27, 2023 at 9:59 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:

> start looking at how spi_nor_erase() is implemented. When addr and
> length are die aligned you may use the erase die command.

Thanks. I will look at it.

> It probably works because by some reason the reads are done in 4MB
> steps, and we don't have any cross-die reads.
> Please re-do the erase-write-readback-compare test starting at 61MB
> offset with 4 MB length. This way we'll have 2 MB tested in the first
> die and 2 MB in the second one.

Here are the cross-die results:

~# time flash_erase /dev/mtd0 0x03e00000 0
Erasing 64 Kibyte @ 7ff0000 -- 100 % complete

real 0m5.198s
user 0m0.000s
sys 0m4.708s

~# time mtd_debug write /dev/mtd0 0x03e00000 4194304 spi_test_4M
Copied 4194304 bytes from spi_test_4M to address 0x03e00000 in flash

real 0m3.952s
user 0m0.001s
sys 0m3.646s

~# time mtd_debug read /dev/mtd0 0x03e00000 4194304 spi_read_4M
[ 5207.981747] spi-nor spi0.0: from 0x03e00000, len 4194304
Copied 4194304 bytes from address 0x03e00000 in flash to spi_read_4M

real 0m0.117s
user 0m0.002s
sys 0m0.114s

~# sha1sum spi_test_4M spi_read_4M
d3605a79e5d4edbd0a42bd356db354857bf381a6  spi_test_4M
d3605a79e5d4edbd0a42bd356db354857bf381a6  spi_read_4M
~#
Fabio Estevam Oct. 30, 2023, 3:13 p.m. UTC | #5 
Hi Tudor,

On Fri, Oct 27, 2023 at 10:52 AM Fabio Estevam <festevam@gmail.com> wrote:

> Here are the cross-die results:

Do you still have concerns about v2?

https://lore.kernel.org/linux-mtd/20231024135826.2729088-1-festevam@gmail.com/

Please note that n25q00, mt25ql02g, n25q00a, and mt25qu02g are
currently supported and are also multi-die chips.

I just don't understand why mt25qu01g cannot join the party.

Thanks
Tudor Ambarus Oct. 30, 2023, 3:29 p.m. UTC | #6 
On 10/30/23 15:13, Fabio Estevam wrote:
> Hi Tudor,
> 

Hi,

> On Fri, Oct 27, 2023 at 10:52 AM Fabio Estevam <festevam@gmail.com> wrote:
> 
>> Here are the cross-die results:
> 
> Do you still have concerns about v2?
> 

I saw your previous email, didn't get the chance to read the datasheet.

> https://lore.kernel.org/linux-mtd/20231024135826.2729088-1-festevam@gmail.com/
> 
> Please note that n25q00, mt25ql02g, n25q00a, and mt25qu02g are
> currently supported and are also multi-die chips.
> 
> I just don't understand why mt25qu01g cannot join the party.
> 
I'm not against the patch per se, but the datasheet confused me when I
skimmed over it. Will try to re-read it. FYI, the merge window hasn't
closed, I'll start queuing patches once -rc1 is out. I'll get back to you.

ta
diff mbox series

Patch

diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 8920547c12bf..31839d6bc3ac 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -192,6 +192,20 @@  static struct spi_nor_fixups mt25qu512a_fixups = {
 	.post_bfpt = mt25qu512a_post_bfpt_fixup,
 };
 
+static int mt25qu01g_post_sfdp_fixup(struct spi_nor *nor)
+{
+	struct spi_nor_flash_parameter *params = nor->params;
+
+	/* MT25QU01G does not define the SCCR entry, so pass n_dice manually. */
+	params->n_dice = 2;
+
+	return 0;
+}
+
+static struct spi_nor_fixups mt25qu01g_fixups = {
+	.post_sfdp = mt25qu01g_post_sfdp_fixup,
+};
+
 static const struct flash_info st_nor_parts[] = {
 	{
 		.name = "m25p05-nonjedec",
@@ -429,6 +443,10 @@  static const struct flash_info st_nor_parts[] = {
 			 SPI_NOR_BP3_SR_BIT6,
 		.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
 		.mfr_flags = USE_FSR,
+	}, {
+		.id = SNOR_ID(0x20, 0xbb, 0x21, 0x10, 0x44, 0x00),
+		.name = "mt25qu01g",
+		.fixups = &mt25qu01g_fixups,
 	}, {
 		.id = SNOR_ID(0x20, 0xbb, 0x21),
 		.name = "n25q00a",