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

[Tudor Ambarus]

On 09.11.2023 11:09, Michael Walle wrote:
> 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.

I don't insist, but I feel it is worth it, yes. We have some speed
improvement and we should benefit of it.

> 
> 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,

jesd216 mentions die erase, but does not provide an opcode for it. Check
BFPT dword 11, bits 30:24, "Chip Erase, Typical time", it says:

"Typical time to erase one chip (die). User must poll device busy to
determine if the operation has completed. For a device consisting of
multiple dies, that are individually accessed, the time is for each die
to which a chip erase command is applied."

So when a flash consists of a single die, this is the erase time for the
full chip (die) erase, and when it consists of multiple dies, it's the
die erase time. Chip and die are the same thing.

> esp. because the die erase now differs among vendors.. whereas the chip
> erase command seems to be common among vendors.

Indeed we saw that the die erase opcode differs among vendors, nothing
that we can do about it now. But we can handle it in software, no big deal.

> 
> 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.
> 

yes, I know, there were some attempts and the main concern was how it
will cope with what filesystems are requiring. Anyway, different topic
that needs some thought.

Cheers,
ta