[PATCH v3 2/2] mtd: spi-nor: micron-st: Add support for mt25qu01g
Tudor Ambarus
tudor.ambarus at linaro.org
Fri Oct 27 05:59:54 PDT 2023
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 at 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
More information about the linux-mtd
mailing list