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

[Vignesh Raghavendra]

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.

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