[PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability

[Michael Walle]

Am 2023-11-06 15:23, schrieb Tudor Ambarus:
> On 11/6/23 09:34, Michael Walle wrote:
>> Am 2023-11-03 14:48, schrieb Tudor Ambarus:
>>> On 03.11.2023 15:37, Fabio Estevam wrote:
>>>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>>> 
>>>>> Which version of mtd-utils are you using? I guess the flash-erase
>>>> 
>>>> mtd-utils 2.1.5
>>>> 
>>>>> utility is written in a bad way. Please use the following while I 
>>>>> check
>>>>> what flash_erase is doing:
>>>>> 
>>>>> time mtd_debug erase /dev/mtd0 0 134217728
>>>> 
>>>> "mtd_debug erase" gives the same time as well:
>>>> 
>>>> root at mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>>>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>> [ 4322.120861] spi-nor spi0.0: *****
>>>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>> [ 4322.140154] spi-nor spi0.0: *****
>>>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>>> [ 4322.159761] spi-nor spi0.0: *****
>>>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>> [ 4322.174118] spi-nor spi0.0: *****
>>>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>> [ 4439.971920] spi-nor spi0.0: *****
>>>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>> [ 4439.991174] spi-nor spi0.0: *****
>>>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>>> [ 4440.011272] spi-nor spi0.0: *****
>>>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>> [ 4440.025606] spi-nor spi0.0: *****
>>>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>> Erased 134217728 bytes from address 0x00000000 in flash
>>>> 
>>>> real    3m57.384s
>>>> user    0m0.005s
>>>> sys    3m35.211s
>>>> 
>>> 
>>> 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.
>> 
>> Had the flash some contents or was it all-ff? Maybe the Micron flash 
>> will
>> check if all bytes are one and will skip the erase.
> 
> it had some contents, but not different than 0xff
>> 
>> Die/Chip erases will take much longer most of the time and are 
>> comparable
>> to individual sector erases (as Fabio also found out). You'll probably
>> just save the overhead of the indivudal commands.
> 
> There is a speed benefit in using die erase instead of individual 
> sector
> erases.
>> 
>> I've looked at the N25Q00AA datasheet and the erase time there is 153s
>> (typ) for *one* die.
>> 
> 
> you mean mt25q. Table 49 in
> 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
> 
> 
> Each die has 64MB. A die is composed of either 16384 4KB sectors or 
> 2048
> sectors of 32KB.
> 
> 4KB typical erase time is 0.05s, thus a die will be erased in 819.2s.
> 32KB typical erase time is 0.1s, thus a die will be erased in 204.8s.
> die erase typical erase time is 153s.
> 
> 4K max erase time is 0.4s, thus a die will be erased in 6553.6s
> 32KB max erase time is 1, thus a die will be erased in 2048s.
> die erase max time is 460s.
> 
> so you might say that 32KB typical erase time might be comparable to a
> die erase command when erasing an entire die with 32KB erases, but even
> so, it should be preferable to use die erase cmd. Instead of sending a
> write enable followed by a sector erase command for each sector, you
> could instead use a single write enable followed by a single die erase
> command.

I was just implying that your 5s chip erase time sounded unlikely.

I'm also still undecided on the use of a chip/die erase command. How
often is a flash erased entirely? I don't think very often, maybe during
board manufacturing. And is that worth the (maintenance) efforts?

Anyway, I won't stand in the way if you insist.

Nobody commented on that so far: The jedec spec doesn't say anything
about the chip/die erase command, right? There is a flag which
indicates wether the chip has one (in 8d8d8d mode) and there is a field
for its erase time, but not *what* the actual command is. Such a pity,
esp. because the die erase now differs among vendors.. whereas the chip
erase command seems to be common among vendors.

Btw. if we want to speed the erase up we should make use of the erase
regions. AFAIK, at the moment we do (slow) 4k erases most of the time
because distros have this kernel option enabled.

-michael