From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Wed, 25 Sep 2019 10:27:58 +0200 Subject: [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512* In-Reply-To: <96a00dff-b711-8a7c-b354-61dad5cbed36@ti.com> References: <20190924055617.20397-1-vigneshr@ti.com> <20190924055617.20397-4-vigneshr@ti.com> <87f177e7-eecf-4c3c-9d9b-ac1a1418e9c0@microchip.com> <96a00dff-b711-8a7c-b354-61dad5cbed36@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Vignesh, On Wed, Sep 25, 2019 at 10:20 AM Vignesh Raghavendra 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 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 > >>> --- > >>> 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