[U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*

[Vignesh Raghavendra]

On 25/09/19 1:57 PM, Simon Goldschmidt wrote:
> Hi Vignesh,
> 
> On Wed, Sep 25, 2019 at 10:20 AM Vignesh Raghavendra <vigneshr at ti.com> wrote:
>>
>> Simon,
>>
>> On 24/09/19 5:54 PM, Tudor.Ambarus at microchip.com wrote:
>>> Hi, Simon,
>>>
>>> On 09/24/2019 02:47 PM, Simon Goldschmidt wrote:
>>>> External E-Mail
>>>>
>>>>
>>>> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr at ti.com> wrote:
>>>>>
>>>>> Newer variants of n25q256* and n25q512* flashes support 4 Byte
>>>>> addressing opcodes. Add entries for the same. These flashes Bit 6 set in
>>>>> 5th byte of READ ID response.
>>>>>
>>>>> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
>>>>> ---
>>>>>  drivers/mtd/spi/spi-nor-ids.c | 3 +++
>>>>>  1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
>>>>> index 967537eafb55..0074073b123a 100644
>>>>> --- a/drivers/mtd/spi/spi-nor-ids.c
>>>>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>>>>> @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
>>>>>         { INFO("n25q064a",    0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>>         { INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>>         { INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
>>>>> +       { INFO6("n25q256a",    0x20ba19, 0x104400, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>>>>
>>>> From the discussion in the other thread, this should probably be named
>>>> "mt25-something"? Seems like the 0x44 in the 5th byte wouldn't be found in the
>>>> n25q256a?
>>>>
>>
>> Sorry, I thought mt25 parts are also marked as n25q based on your
>> replies.. For now, I believe we can assume all devices with 0x44 in the
>> 5th byte are mt25 parts and support 4 byte opcodes. Will next v2 with
>> this assumptions.
> 
> Well, that's my fault. Seems I mixed up the parts here. Our switch to mt25 was
> earlier than I had thought and I was using boards with mt25 where I thought I
> had n25q before me... Sorry for the confusion!
> 
> I can however not tell you if all mt25 chips support 4 byte opcodes. The ones
> I have do though.
> 
> Oh, and there are also Altera/Intel EPCQ devices (e.g. on the socfpga_socrates)
> that are reported as n25q256a. I'd have to look at them as well to see if 4
> byte opcodes are supported and what the full ID is.
> 

I will go ahead and post patches with mt25* in the name. If we find
parts with same ID code but sold as n25q* we can rename the entries or
add new ones if ID codes are different.

Regards
Vignesh

> Regards,
> Simon
> 
>>
>> Regards
>> Vignesh
>>
>>>
>>> Probably yes, but the ultimate test would be to dump all the JEDEC ID bytes from
>>> the n25q256a flash, with code similar to that from below. It's not the first
>>> time that we see manufacturers messing with the JEDEC IDs or with the SFDP
>>> tables. It would be really helpful if you can dump the JEDEC ID bytes on a n25q256a.
>>>
>>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>>> index 1acff745d1a2..0be3496c5367 100644
>>> --- a/drivers/mtd/spi/spi-nor-core.c
>>> +++ b/drivers/mtd/spi/spi-nor-core.c
>>> @@ -885,13 +885,16 @@ static const struct flash_info *spi_nor_read_id(struct
>>> spi_nor *nor)
>>>         info = spi_nor_ids;
>>>         for (; info->name; info++) {
>>>                 if (info->id_len) {
>>> -                       if (!memcmp(info->id, id, info->id_len))
>>> +                       if (!memcmp(info->id, id, info->id_len)) {
>>> +                               dev_err(nor->dev, "JEDEC id bytes: %*ph\n",
>>> +                                       SPI_NOR_MAX_ID_LEN, id);
>>>                                 return info;
>>> +                       }
>>>                 }
>>>         }
>>>
>>> -       dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
>>> -               id[0], id[1], id[2]);
>>> +        dev_err(nor->dev, "unrecognized JEDEC id bytes: %*ph\n",
>>> +                SPI_NOR_MAX_ID_LEN, id);
>>>         return ERR_PTR(-ENODEV);
>>>  }
>>>
>>
>> --
>> Regards
>> Vignesh

-- 
Regards
Vignesh