From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Fabio Estevam <festevam@denx.de>
Cc: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>,
michael@walle.cc, pratyush@kernel.org,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, bacem.daassi@infineon.com,
miquel.raynal@bootlin.com, richard@nod.at
Subject: Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
Date: Fri, 3 Nov 2023 16:37:35 +0200 [thread overview]
Message-ID: <5b3b8de5-b2fc-4c8f-a2d7-662748ce9213@linaro.org> (raw)
In-Reply-To: <c533a2af60f27d21c9c703b6cb34ff77@denx.de>
On 03.11.2023 16:16, Fabio Estevam wrote:
> On 03/11/2023 10:48, Tudor Ambarus wrote:
>
>> Yep, it's strange, we'll have to check what's happening. I found my
>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>> defines how long the erase die should take, see BFPT dword 11. You can
>> start with that.
>
> Where does BFPT dword 11 reside inside SFDP?
BFPT stands for Basic Flash Parameter Table. BFPT is the first table of
SFDP. Please compare the standard with the dump. We haven't written yet
an utility to decode the SFDP data.
>
> ~# hexdump -C
> /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
> 00000000 53 46 44 50 06 01 01 ff 00 06 01 10 30 00 00 ff
> |SFDP........0...|
> 00000010 84 00 01 02 80 00 00 ff ff ff ff ff ff ff ff ff
> |................|
> 00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000030 e5 20 fb ff ff ff ff 3f 29 eb 27 6b 27 3b 27 bb |.
> .....?).'k';'.|
> 00000040 ff ff ff ff ff ff 27 bb ff ff 29 eb 0c 20 10 d8
> |......'...).. ..|
> 00000050 0f 52 00 00 24 4a 99 00 8b 8e 03 e1 ac 01 27 38
> |.R..$J........'8|
> 00000060 7a 75 7a 75 fb bd d5 5c 4a 0f 82 ff 81 bd 3d 36
> |zuzu...\J.....=6|
> 00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000080 ff e7 ff ff 21 dc ff ff |....!...|
> 00000088
>
> Do we need a fixup to tell the erase die to be faster?
no. We can retrieve the erase time from BFPT and use it to narrow the
wait time.
>
> I haven't found the 'BFPT' term in the JEDEC spec.
>
>> real 0m5.485s
>> user 0m0.000s
>> sys 0m5.461s
>
> Before erasing, did the flash contain 128MB of random data on your test?
not everywhere
>
> On my tests, when the flash contains 128MB of random data, the first erase
> takes 4 minutes. Subsequent erases take only 2 seconds.
>
I confirm I see the same behavior on n25q00 flash.
Erased 134217728 bytes from address 0x00000000 in flash
real 3m49.082s
user 0m0.000s
sys 3m48.485s
I'll continue to investigate this at a best effort rate, expect for some
delays, I'm handling SPI NOR mostly in my spare time. Happy to guide you
though. You may join #mtd irc channel for short questions, see where it
is in the MAINTAINERS file.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Fabio Estevam <festevam@denx.de>
Cc: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>,
michael@walle.cc, pratyush@kernel.org,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, bacem.daassi@infineon.com,
miquel.raynal@bootlin.com, richard@nod.at
Subject: Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
Date: Fri, 3 Nov 2023 16:37:35 +0200 [thread overview]
Message-ID: <5b3b8de5-b2fc-4c8f-a2d7-662748ce9213@linaro.org> (raw)
In-Reply-To: <c533a2af60f27d21c9c703b6cb34ff77@denx.de>
On 03.11.2023 16:16, Fabio Estevam wrote:
> On 03/11/2023 10:48, Tudor Ambarus wrote:
>
>> Yep, it's strange, we'll have to check what's happening. I found my
>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>> defines how long the erase die should take, see BFPT dword 11. You can
>> start with that.
>
> Where does BFPT dword 11 reside inside SFDP?
BFPT stands for Basic Flash Parameter Table. BFPT is the first table of
SFDP. Please compare the standard with the dump. We haven't written yet
an utility to decode the SFDP data.
>
> ~# hexdump -C
> /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
> 00000000 53 46 44 50 06 01 01 ff 00 06 01 10 30 00 00 ff
> |SFDP........0...|
> 00000010 84 00 01 02 80 00 00 ff ff ff ff ff ff ff ff ff
> |................|
> 00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000030 e5 20 fb ff ff ff ff 3f 29 eb 27 6b 27 3b 27 bb |.
> .....?).'k';'.|
> 00000040 ff ff ff ff ff ff 27 bb ff ff 29 eb 0c 20 10 d8
> |......'...).. ..|
> 00000050 0f 52 00 00 24 4a 99 00 8b 8e 03 e1 ac 01 27 38
> |.R..$J........'8|
> 00000060 7a 75 7a 75 fb bd d5 5c 4a 0f 82 ff 81 bd 3d 36
> |zuzu...\J.....=6|
> 00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000080 ff e7 ff ff 21 dc ff ff |....!...|
> 00000088
>
> Do we need a fixup to tell the erase die to be faster?
no. We can retrieve the erase time from BFPT and use it to narrow the
wait time.
>
> I haven't found the 'BFPT' term in the JEDEC spec.
>
>> real 0m5.485s
>> user 0m0.000s
>> sys 0m5.461s
>
> Before erasing, did the flash contain 128MB of random data on your test?
not everywhere
>
> On my tests, when the flash contains 128MB of random data, the first erase
> takes 4 minutes. Subsequent erases take only 2 seconds.
>
I confirm I see the same behavior on n25q00 flash.
Erased 134217728 bytes from address 0x00000000 in flash
real 3m49.082s
user 0m0.000s
sys 3m48.485s
I'll continue to investigate this at a best effort rate, expect for some
delays, I'm handling SPI NOR mostly in my spare time. Happy to guide you
though. You may join #mtd irc channel for short questions, see where it
is in the MAINTAINERS file.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-03 14:37 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-01 14:58 [PATCH v2 0/6] mtd: spi-nor: introduce die erase Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 1/6] mtd: spi-nor: use kernel sized types instead of c99 types Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 16:04 ` Tudor Ambarus
2023-11-01 16:04 ` Tudor Ambarus
2023-11-01 16:17 ` Fabio Estevam
2023-11-01 16:17 ` Fabio Estevam
2023-11-01 17:27 ` Tudor Ambarus
2023-11-01 17:27 ` Tudor Ambarus
2023-11-02 16:43 ` Fabio Estevam
2023-11-02 16:43 ` Fabio Estevam
2023-11-02 17:36 ` Tudor Ambarus
2023-11-02 17:36 ` Tudor Ambarus
2023-11-02 17:40 ` Fabio Estevam
2023-11-02 17:40 ` Fabio Estevam
2023-11-02 17:47 ` Tudor Ambarus
2023-11-02 17:47 ` Tudor Ambarus
2023-11-02 17:54 ` Tudor Ambarus
2023-11-02 17:54 ` Tudor Ambarus
2023-11-02 17:59 ` Tudor Ambarus
2023-11-02 17:59 ` Tudor Ambarus
2023-11-02 18:01 ` Fabio Estevam
2023-11-02 18:01 ` Fabio Estevam
2023-11-02 18:21 ` Tudor Ambarus
2023-11-02 18:21 ` Tudor Ambarus
2023-11-02 18:33 ` Fabio Estevam
2023-11-02 18:33 ` Fabio Estevam
2023-11-02 18:46 ` Tudor Ambarus
2023-11-02 18:46 ` Tudor Ambarus
2023-11-02 18:56 ` Tudor Ambarus
2023-11-02 18:56 ` Tudor Ambarus
2023-11-02 21:42 ` Fabio Estevam
2023-11-02 21:42 ` Fabio Estevam
2023-11-03 11:47 ` Tudor Ambarus
2023-11-03 11:47 ` Tudor Ambarus
2023-11-03 12:30 ` Fabio Estevam
2023-11-03 12:30 ` Fabio Estevam
2023-11-03 12:53 ` Fabio Estevam
2023-11-03 12:53 ` Fabio Estevam
2023-11-03 13:26 ` Tudor Ambarus
2023-11-03 13:26 ` Tudor Ambarus
2023-11-03 13:37 ` Fabio Estevam
2023-11-03 13:37 ` Fabio Estevam
2023-11-03 13:48 ` Tudor Ambarus
2023-11-03 13:48 ` Tudor Ambarus
2023-11-03 14:16 ` Fabio Estevam
2023-11-03 14:16 ` Fabio Estevam
2023-11-03 14:37 ` Tudor Ambarus [this message]
2023-11-03 14:37 ` Tudor Ambarus
2023-11-03 14:58 ` Fabio Estevam
2023-11-03 14:58 ` Fabio Estevam
2023-11-06 14:24 ` Tudor Ambarus
2023-11-06 14:24 ` Tudor Ambarus
2023-11-06 9:34 ` Michael Walle
2023-11-06 9:34 ` Michael Walle
2023-11-06 14:23 ` Tudor Ambarus
2023-11-06 14:23 ` Tudor Ambarus
2023-11-06 14:56 ` Tudor Ambarus
2023-11-06 14:56 ` Tudor Ambarus
2023-11-09 9:09 ` Michael Walle
2023-11-09 9:09 ` Michael Walle
2023-11-15 7:06 ` Tudor Ambarus
2023-11-15 7:06 ` Tudor Ambarus
2023-11-08 8:06 ` Takahiro Kuwano
2023-11-08 8:06 ` Takahiro Kuwano
2023-11-08 8:54 ` Tudor Ambarus
2023-11-08 8:54 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 3/6] mtd: spi-nor: spansion: enable die erase for multi die flashes Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 4/6] mtd: spi-nor: micron-st: " Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 5/6] mtd: spi-nor: remove NO_CHIP_ERASE flag Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 6/6] mtd: spi-nor: micron-st: Add support for mt25qu01g Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 15:54 ` [PATCH v2 0/6] mtd: spi-nor: introduce die erase Fabio Estevam
2023-11-01 15:54 ` Fabio Estevam
2023-11-15 6:10 ` Re (subset): " Tudor Ambarus
2023-11-15 6:10 ` 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=5b3b8de5-b2fc-4c8f-a2d7-662748ce9213@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=Takahiro.Kuwano@infineon.com \
--cc=bacem.daassi@infineon.com \
--cc=festevam@denx.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
/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.