Re: flash_lock issue for n25q 128mb spi nor part

[<Tudor.Ambarus@xxxxxxxxxxxxx>]

On 12/3/19 12:31 PM, John Garry wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 03/12/2019 09:45, Tudor.Ambarus@xxxxxxxxxxxxx wrote:
>> Hi, John,
> 
> Hi Tudor,
> 
> Thanks for getting back to me.
> 
>>
>> On 12/2/19 7:28 PM, John Garry wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Hi guys,
>>>
>>> I am testing the following driver on top of Linus' master branch with a
>>> n25q128a11 part:
>>
>> I understand the you enabled locking support for this flash on your side,
>> because in mainline it is not yet there.
>>
>> Be aware that this flash has BP3 support, and in mainline we support for now
>> just BP0-BP2, so just a partial lock can be achieved, and it depends on what you
>> tried to lock. It will be helpful to tell how you enabled the locking and what
>> commands did you use.
> 
> So I am simply using flash_lock -l /dev/mtd0, which will try to lock the
> whole device. Now I see what you're saying about BP3 and how complete
> locking is not available.
> 
>>
>>>
>>> https://lore.kernel.org/linux-mtd/1572886297-45400-3-git-send-email-john.garry@xxxxxxxxxx/
>>>
>>> I am finding flash lock is not working. Even after a “successful” lock,
>>> flash_lock is reporting flash is unlocked. And I can still write to the
>>> flash.
>>>
>>> I find that since 39d1e3340c73 ("mtd: spi-nor: Fix clearing of QE bit on
>>> lock()/unlock()"), we're using a 16b SR for this part in the driver, but
>>> this part only has a 8b SR.
>>>
>>> This hack fixes the problem for me:
>>>
>>> @ -4691,7 +4691,7 @@ static void spi_nor_info_init_params(struct spi_nor
>>> *nor)
>>> params->set_4byte = spansion_set_4byte;
>>> params->setup = spi_nor_default_setup;
>>> /* Default to 16-bit Write Status (01h) Command */
>>> - nor->flags |= SNOR_F_HAS_16BIT_SR;
>>> +// nor->flags |= SNOR_F_HAS_16BIT_SR;
>>
>> This means that bfpt is not parsed. You can confirm this by running with the
>> patch from below.
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index f4afe123e9dc..735cd5202598 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -3545,8 +3545,11 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>>                  return err;
>>
>>          /* Fix endianness of the BFPT DWORDs. */
>> -       for (i = 0; i < BFPT_DWORD_MAX; i++)
>> +       for (i = 0; i < BFPT_DWORD_MAX; i++) {
>>                  bfpt.dwords[i] = le32_to_cpu(bfpt.dwords[i]);
>> +               dev_err(nor->dev, "bfpt.dwords[%d] = %08x\n", i,
>> +                       bfpt.dwords[i]);
>> +       }
>>
>>          /* Number of address bytes. */
>>          switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
>> @@ -3649,6 +3652,9 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>>          params->page_size >>= BFPT_DWORD11_PAGE_SIZE_SHIFT;
>>          params->page_size = 1U << params->page_size;
>>
>> +       dev_err(nor->dev, "bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK =
>> %08x\n",
>> +               bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK);
>> +
>>          /* Quad Enable Requirements. */
>>          switch (bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK) {
>>          case BFPT_DWORD15_QER_NONE:
>>
> 
> john@ubuntu:~$ dmesg | grep spi
> [   14.935740] spi-nor spi-PRP0001:00: bfpt.dwords[0] = fff920e5
> [   14.941480] spi-nor spi-PRP0001:00: bfpt.dwords[1] = 07ffffff
> [   14.947215] spi-nor spi-PRP0001:00: bfpt.dwords[2] = 6b27eb29
> [   14.952949] spi-nor spi-PRP0001:00: bfpt.dwords[3] = bb273b27
> [   14.958683] spi-nor spi-PRP0001:00: bfpt.dwords[4] = ffffffff
> [   14.964417] spi-nor spi-PRP0001:00: bfpt.dwords[5] = bb27ffff
> [   14.970150] spi-nor spi-PRP0001:00: bfpt.dwords[6] = eb29ffff
> [   14.975884] spi-nor spi-PRP0001:00: bfpt.dwords[7] = d810200c
> [   14.981618] spi-nor spi-PRP0001:00: bfpt.dwords[8] = 0000520f
> [   14.987351] spi-nor spi-PRP0001:00: bfpt.dwords[9] = 00994a24
> [   14.993085] spi-nor spi-PRP0001:00: bfpt.dwords[10] = c9038e8b
> [   14.998906] spi-nor spi-PRP0001:00: bfpt.dwords[11] = 382701ac
> [   15.004726] spi-nor spi-PRP0001:00: bfpt.dwords[12] = 757a757a
> [   15.010547] spi-nor spi-PRP0001:00: bfpt.dwords[13] = 5cd5bdfb
> [   15.016367] spi-nor spi-PRP0001:00: bfpt.dwords[14] = ff820f4a
> [   15.022187] spi-nor spi-PRP0001:00: bfpt.dwords[15] = 00003d81
> 

This falls into the BFPT_DWORD15_QER_NONE case. If there's a correspondence
between the BFPT_DWORD15_QER_NONE and no 16-bit Write SR support, we can clear
the flag there, but JESD216D does not specify this :(.

Please enable CONFIG_DEBUG on top of the file to see dev_dbg messages. I'll try
to find a micron flash in the meantime.

Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/