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

[Simon Goldschmidt]

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.

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