* [U-Boot] [PATCH RFT 1/3] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*
2019-09-24 5:56 [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512* Vignesh Raghavendra
@ 2019-09-24 5:56 ` Vignesh Raghavendra
2019-09-24 5:56 ` [U-Boot] [PATCH RFT 2/3] spi-nor: spi-nor-ids: Rename mt25qu512a entry Vignesh Raghavendra
` (3 subsequent siblings)
4 siblings, 0 replies; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-24 5:56 UTC (permalink / raw)
To: u-boot
Older variants of n25q256* and n25q512* do not support 4 Byte stateless
addressing opcodes. Therefore drop SPI_NOR_4B_OPCODES flag from these
entries.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
drivers/mtd/spi/spi-nor-ids.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a3920ba520e0..6f7386db4226 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -161,12 +161,12 @@ 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) },
- { INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+ { INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ) },
{ INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+ { INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
+ { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
{ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25qu02g", 0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
--
2.23.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 2/3] spi-nor: spi-nor-ids: Rename mt25qu512a entry
2019-09-24 5:56 [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512* Vignesh Raghavendra
2019-09-24 5:56 ` [U-Boot] [PATCH RFT 1/3] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256* Vignesh Raghavendra
@ 2019-09-24 5:56 ` Vignesh Raghavendra
2019-09-24 5:56 ` [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512* Vignesh Raghavendra
` (2 subsequent siblings)
4 siblings, 0 replies; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-24 5:56 UTC (permalink / raw)
To: u-boot
mt25qu512a is just a rebranded name for n25q512a. All the 6 bytes of JEDEC
ID bytes are same for mt25qu512a and n25q512a. Therefore rename
mt25qu512a to "mt25qu512a (n25q512a)", so that its much clearer to user.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
drivers/mtd/spi/spi-nor-ids.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 6f7386db4226..967537eafb55 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -163,7 +163,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_QUAD_READ) },
{ INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ) },
- { INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024,
+ { INFO6("mt25qu512a (n25q512a)", 0x20bb20, 0x104400, 64 * 1024, 1024,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
{ INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
--
2.23.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
2019-09-24 5:56 [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512* Vignesh Raghavendra
2019-09-24 5:56 ` [U-Boot] [PATCH RFT 1/3] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256* Vignesh Raghavendra
2019-09-24 5:56 ` [U-Boot] [PATCH RFT 2/3] spi-nor: spi-nor-ids: Rename mt25qu512a entry Vignesh Raghavendra
@ 2019-09-24 5:56 ` Vignesh Raghavendra
2019-09-24 11:47 ` Simon Goldschmidt
2019-09-24 7:02 ` [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 " Simon Goldschmidt
2019-09-24 17:23 ` Eugeniy Paltsev
4 siblings, 1 reply; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-24 5:56 UTC (permalink / raw)
To: u-boot
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@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) },
{ INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { INFO6("n25q256ax1", 0x20bb19, 0x104400, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ) },
{ INFO6("mt25qu512a (n25q512a)", 0x20bb20, 0x104400, 64 * 1024, 1024,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
+ { INFO6("n25q512ax3", 0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
{ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
--
2.23.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
2019-09-24 5:56 ` [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512* Vignesh Raghavendra
@ 2019-09-24 11:47 ` Simon Goldschmidt
2019-09-24 11:49 ` Simon Goldschmidt
2019-09-24 12:24 ` Tudor.Ambarus at microchip.com
0 siblings, 2 replies; 21+ messages in thread
From: Simon Goldschmidt @ 2019-09-24 11:47 UTC (permalink / raw)
To: u-boot
On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@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@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?
Regards,
Simon
> { INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + { INFO6("n25q256ax1", 0x20bb19, 0x104400, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ) },
> { INFO6("mt25qu512a (n25q512a)", 0x20bb20, 0x104400, 64 * 1024, 1024,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> { INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> + { INFO6("n25q512ax3", 0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> { INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> --
> 2.23.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
2019-09-24 11:47 ` Simon Goldschmidt
@ 2019-09-24 11:49 ` Simon Goldschmidt
2019-09-24 12:24 ` Tudor.Ambarus at microchip.com
1 sibling, 0 replies; 21+ messages in thread
From: Simon Goldschmidt @ 2019-09-24 11:49 UTC (permalink / raw)
To: u-boot
+Tudor Ambarus (from discussion in https://patchwork.ozlabs.org/patch/1160501/)
On Tue, Sep 24, 2019 at 1:47 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@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@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?
>
> Regards,
> Simon
>
> > { INFO("n25q256a", 0x20ba19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > + { INFO6("n25q256ax1", 0x20bb19, 0x104400, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> > { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_QUAD_READ) },
> > { INFO6("mt25qu512a (n25q512a)", 0x20bb20, 0x104400, 64 * 1024, 1024,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> > { INFO("n25q512a", 0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> > + { INFO6("n25q512ax3", 0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> > { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> > { INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > --
> > 2.23.0
> >
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
2019-09-24 11:47 ` Simon Goldschmidt
2019-09-24 11:49 ` Simon Goldschmidt
@ 2019-09-24 12:24 ` Tudor.Ambarus at microchip.com
2019-09-25 8:21 ` Vignesh Raghavendra
1 sibling, 1 reply; 21+ messages in thread
From: Tudor.Ambarus at microchip.com @ 2019-09-24 12:24 UTC (permalink / raw)
To: u-boot
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@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@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?
>
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);
}
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
2019-09-24 12:24 ` Tudor.Ambarus at microchip.com
@ 2019-09-25 8:21 ` Vignesh Raghavendra
2019-09-25 8:27 ` Simon Goldschmidt
0 siblings, 1 reply; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-25 8:21 UTC (permalink / raw)
To: u-boot
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@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@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
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
2019-09-25 8:21 ` Vignesh Raghavendra
@ 2019-09-25 8:27 ` Simon Goldschmidt
2019-09-25 9:09 ` Vignesh Raghavendra
0 siblings, 1 reply; 21+ messages in thread
From: Simon Goldschmidt @ 2019-09-25 8:27 UTC (permalink / raw)
To: u-boot
Hi Vignesh,
On Wed, Sep 25, 2019 at 10:20 AM Vignesh Raghavendra <vigneshr@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@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@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
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512*
2019-09-25 8:27 ` Simon Goldschmidt
@ 2019-09-25 9:09 ` Vignesh Raghavendra
0 siblings, 0 replies; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-25 9:09 UTC (permalink / raw)
To: u-boot
On 25/09/19 1:57 PM, Simon Goldschmidt wrote:
> Hi Vignesh,
>
> On Wed, Sep 25, 2019 at 10:20 AM Vignesh Raghavendra <vigneshr@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@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@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 5:56 [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512* Vignesh Raghavendra
` (2 preceding siblings ...)
2019-09-24 5:56 ` [U-Boot] [PATCH RFT 3/3] spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and n25q512* Vignesh Raghavendra
@ 2019-09-24 7:02 ` Simon Goldschmidt
2019-09-24 8:00 ` Vignesh Raghavendra
2019-09-24 9:23 ` Tudor.Ambarus at microchip.com
2019-09-24 17:23 ` Eugeniy Paltsev
4 siblings, 2 replies; 21+ messages in thread
From: Simon Goldschmidt @ 2019-09-24 7:02 UTC (permalink / raw)
To: u-boot
Hi Vignesh,
On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>
> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
> n25q256* and n25q512* and adds entries for newer variants of those
> flashes that support 4 Byte opcodes.
>
> I don't have the flash devices. So its only compile tested.
>
> Ashish, Simon,
>
> I would greatly appreciate if you could test these patches and make sure
> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
As written in my last mail, I currently cannot get SFDP to work on my board:
I keep getting 0xffdddfdf instead of 0x50444653 (SFDP_SIGNATURE).
Any idea for a reason of that? That device I have here seems to be equipped
with an MT25QL256ABA, but that should not be an issue, I think.
Regards,
Simon
>
> Euginey,
>
> Could you test this series on top of latest u-boot master and confirm
> that your test cases still work?
>
> Regards
> Vignesh
>
> Vignesh Raghavendra (3):
> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
> n25q256*
> spi-nor: spi-nor-ids: Rename mt25qu512a entry
> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
> n25q512*
>
> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> --
> 2.23.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 7:02 ` [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 " Simon Goldschmidt
@ 2019-09-24 8:00 ` Vignesh Raghavendra
2019-09-24 8:43 ` Simon Goldschmidt
2019-09-24 9:23 ` Tudor.Ambarus at microchip.com
1 sibling, 1 reply; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-24 8:00 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 24/09/19 12:32 PM, Simon Goldschmidt wrote:
> Hi Vignesh,
>
> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>
>> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
>> n25q256* and n25q512* and adds entries for newer variants of those
>> flashes that support 4 Byte opcodes.
>>
>> I don't have the flash devices. So its only compile tested.
>>
>> Ashish, Simon,
>>
>> I would greatly appreciate if you could test these patches and make sure
>> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
>> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
>
> As written in my last mail, I currently cannot get SFDP to work on my board:
> I keep getting 0xffdddfdf instead of 0x50444653 (SFDP_SIGNATURE).
>
Did it ever work on your board ie did you test it when you were testing
my patches porting SPI NOR framework from kernel?
What's the controller driver? Cadence QSPI?
Regards
Vignesh
> Any idea for a reason of that? That device I have here seems to be equipped
> with an MT25QL256ABA, but that should not be an issue, I think.
>
> Regards,
> Simon
>
>>
>> Euginey,
>>
>> Could you test this series on top of latest u-boot master and confirm
>> that your test cases still work?
>>
>> Regards
>> Vignesh
>>
>> Vignesh Raghavendra (3):
>> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
>> n25q256*
>> spi-nor: spi-nor-ids: Rename mt25qu512a entry
>> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
>> n25q512*
>>
>> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> --
>> 2.23.0
>>
--
Regards
Vignesh
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 8:00 ` Vignesh Raghavendra
@ 2019-09-24 8:43 ` Simon Goldschmidt
2019-09-24 9:17 ` Vignesh Raghavendra
0 siblings, 1 reply; 21+ messages in thread
From: Simon Goldschmidt @ 2019-09-24 8:43 UTC (permalink / raw)
To: u-boot
HI Vignesh,
On Tue, Sep 24, 2019 at 9:59 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>
> Hi Simon,
>
> On 24/09/19 12:32 PM, Simon Goldschmidt wrote:
> > Hi Vignesh,
> >
> > On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
> >>
> >> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
> >> n25q256* and n25q512* and adds entries for newer variants of those
> >> flashes that support 4 Byte opcodes.
> >>
> >> I don't have the flash devices. So its only compile tested.
> >>
> >> Ashish, Simon,
> >>
> >> I would greatly appreciate if you could test these patches and make sure
> >> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
> >> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
> >
> > As written in my last mail, I currently cannot get SFDP to work on my board:
> > I keep getting 0xffdddfdf instead of 0x50444653 (SFDP_SIGNATURE).
> >
>
> Did it ever work on your board ie did you test it when you were testing
> my patches porting SPI NOR framework from kernel?
I tested that series on the EBV Socrates (socfpga_socrates), while this is our
custom board. It is similar, but the flash chips are different. So
unfortunately, I don't know if it ever worked...
I'll try to run this series on socfpga_socrates soon.
>
> What's the controller driver? Cadence QSPI?
Yes.
Regards,
Simon
>
> Regards
> Vignesh
>
> > Any idea for a reason of that? That device I have here seems to be equipped
> > with an MT25QL256ABA, but that should not be an issue, I think.
> >
> > Regards,
> > Simon
> >
> >>
> >> Euginey,
> >>
> >> Could you test this series on top of latest u-boot master and confirm
> >> that your test cases still work?
> >>
> >> Regards
> >> Vignesh
> >>
> >> Vignesh Raghavendra (3):
> >> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
> >> n25q256*
> >> spi-nor: spi-nor-ids: Rename mt25qu512a entry
> >> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
> >> n25q512*
> >>
> >> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
> >> 1 file changed, 8 insertions(+), 5 deletions(-)
> >>
> >> --
> >> 2.23.0
> >>
>
> --
> Regards
> Vignesh
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 8:43 ` Simon Goldschmidt
@ 2019-09-24 9:17 ` Vignesh Raghavendra
2019-09-24 9:23 ` Simon Goldschmidt
0 siblings, 1 reply; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-24 9:17 UTC (permalink / raw)
To: u-boot
On 24/09/19 2:13 PM, Simon Goldschmidt wrote:
> HI Vignesh,
>
> On Tue, Sep 24, 2019 at 9:59 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>
>> Hi Simon,
>>
>> On 24/09/19 12:32 PM, Simon Goldschmidt wrote:
>>> Hi Vignesh,
>>>
>>> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>>>
>>>> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
>>>> n25q256* and n25q512* and adds entries for newer variants of those
>>>> flashes that support 4 Byte opcodes.
>>>>
>>>> I don't have the flash devices. So its only compile tested.
>>>>
>>>> Ashish, Simon,
>>>>
>>>> I would greatly appreciate if you could test these patches and make sure
>>>> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
>>>> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
>>>
>>> As written in my last mail, I currently cannot get SFDP to work on my board:
>>> I keep getting 0xffdddfdf instead of 0x50444653 (SFDP_SIGNATURE).
>>>
>>
>> Did it ever work on your board ie did you test it when you were testing
>> my patches porting SPI NOR framework from kernel?
>
> I tested that series on the EBV Socrates (socfpga_socrates), while this is our
> custom board. It is similar, but the flash chips are different. So
> unfortunately, I don't know if it ever worked...
>
> I'll try to run this series on socfpga_socrates soon.
>
>>
>> What's the controller driver? Cadence QSPI?
>
> Yes.
What does the DT snippet for flash node looks like?
I think cadence QSPI is broken for SFDP if it has:
spi-rx-bus-width = <4>;
Driver does:
if (rx_width & SPI_RX_QUAD)
/* Instruction and address at DQ0, data at DQ0-3. */
rd_reg |= CQSPI_INST_TYPE_QUAD << CQSPI_REG_RD_INSTR_TYPE_DATA_LSB;
So, driver tries to execute SFDP command in 1-1-4 mode which is wrong.
For now try setting spi-rx-bus-width to 1 and see if SFDP works (of course this not the fix)
I have patches[1] to convert this driver to implement spi-mem framework which should help in fixing this issues.
Will post them probably@the start of merge window after some more testing. If you have time, please give it a try
[1] https://github.com/r-vignesh/u-boot.git branch: cqspi
Regards
Vignesh
>
> Regards,
> Simon
>
>>
>> Regards
>> Vignesh
>>
>>> Any idea for a reason of that? That device I have here seems to be equipped
>>> with an MT25QL256ABA, but that should not be an issue, I think.
>>>
>>> Regards,
>>> Simon
>>>
>>>>
>>>> Euginey,
>>>>
>>>> Could you test this series on top of latest u-boot master and confirm
>>>> that your test cases still work?
>>>>
>>>> Regards
>>>> Vignesh
>>>>
>>>> Vignesh Raghavendra (3):
>>>> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
>>>> n25q256*
>>>> spi-nor: spi-nor-ids: Rename mt25qu512a entry
>>>> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
>>>> n25q512*
>>>>
>>>> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
>>>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>>>
>>>> --
>>>> 2.23.0
>>>>
>>
>> --
>> Regards
>> Vignesh
--
Regards
Vignesh
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 9:17 ` Vignesh Raghavendra
@ 2019-09-24 9:23 ` Simon Goldschmidt
0 siblings, 0 replies; 21+ messages in thread
From: Simon Goldschmidt @ 2019-09-24 9:23 UTC (permalink / raw)
To: u-boot
Hi Vignesh,
On Tue, Sep 24, 2019 at 11:17 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>
>
>
> On 24/09/19 2:13 PM, Simon Goldschmidt wrote:
> > HI Vignesh,
> >
> > On Tue, Sep 24, 2019 at 9:59 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 24/09/19 12:32 PM, Simon Goldschmidt wrote:
> >>> Hi Vignesh,
> >>>
> >>> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
> >>>>
> >>>> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
> >>>> n25q256* and n25q512* and adds entries for newer variants of those
> >>>> flashes that support 4 Byte opcodes.
> >>>>
> >>>> I don't have the flash devices. So its only compile tested.
> >>>>
> >>>> Ashish, Simon,
> >>>>
> >>>> I would greatly appreciate if you could test these patches and make sure
> >>>> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
> >>>> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
> >>>
> >>> As written in my last mail, I currently cannot get SFDP to work on my board:
> >>> I keep getting 0xffdddfdf instead of 0x50444653 (SFDP_SIGNATURE).
> >>>
> >>
> >> Did it ever work on your board ie did you test it when you were testing
> >> my patches porting SPI NOR framework from kernel?
> >
> > I tested that series on the EBV Socrates (socfpga_socrates), while this is our
> > custom board. It is similar, but the flash chips are different. So
> > unfortunately, I don't know if it ever worked...
> >
> > I'll try to run this series on socfpga_socrates soon.
> >
> >>
> >> What's the controller driver? Cadence QSPI?
> >
> > Yes.
>
> What does the DT snippet for flash node looks like?
> I think cadence QSPI is broken for SFDP if it has:
>
> spi-rx-bus-width = <4>;
>
> Driver does:
>
> if (rx_width & SPI_RX_QUAD)
> /* Instruction and address at DQ0, data at DQ0-3. */
> rd_reg |= CQSPI_INST_TYPE_QUAD << CQSPI_REG_RD_INSTR_TYPE_DATA_LSB;
>
> So, driver tries to execute SFDP command in 1-1-4 mode which is wrong.
> For now try setting spi-rx-bus-width to 1 and see if SFDP works (of course this not the fix)
Right. That makes it work, thanks. I'll send the SFDP tables dump in the other
thread.
Plus I can now test this series :-)
>
> I have patches[1] to convert this driver to implement spi-mem framework which should help in fixing this issues.
> Will post them probably at the start of merge window after some more testing. If you have time, please give it a try
>
> [1] https://github.com/r-vignesh/u-boot.git branch: cqspi
Oh, cool. That was on my list for some time now, but I haven't gotten around
to even starting it.
Regards,
Simon
>
> Regards
> Vignesh
>
>
> >
> > Regards,
> > Simon
> >
> >>
> >> Regards
> >> Vignesh
> >>
> >>> Any idea for a reason of that? That device I have here seems to be equipped
> >>> with an MT25QL256ABA, but that should not be an issue, I think.
> >>>
> >>> Regards,
> >>> Simon
> >>>
> >>>>
> >>>> Euginey,
> >>>>
> >>>> Could you test this series on top of latest u-boot master and confirm
> >>>> that your test cases still work?
> >>>>
> >>>> Regards
> >>>> Vignesh
> >>>>
> >>>> Vignesh Raghavendra (3):
> >>>> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
> >>>> n25q256*
> >>>> spi-nor: spi-nor-ids: Rename mt25qu512a entry
> >>>> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
> >>>> n25q512*
> >>>>
> >>>> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
> >>>> 1 file changed, 8 insertions(+), 5 deletions(-)
> >>>>
> >>>> --
> >>>> 2.23.0
> >>>>
> >>
> >> --
> >> Regards
> >> Vignesh
>
> --
> Regards
> Vignesh
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 7:02 ` [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 " Simon Goldschmidt
2019-09-24 8:00 ` Vignesh Raghavendra
@ 2019-09-24 9:23 ` Tudor.Ambarus at microchip.com
2019-09-24 9:27 ` Simon Goldschmidt
1 sibling, 1 reply; 21+ messages in thread
From: Tudor.Ambarus at microchip.com @ 2019-09-24 9:23 UTC (permalink / raw)
To: u-boot
Hi, Simon,
On 09/24/2019 10:02 AM, Simon Goldschmidt wrote:
> External E-Mail
>
>
> Hi Vignesh,
>
> On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>
>> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
>> n25q256* and n25q512* and adds entries for newer variants of those
>> flashes that support 4 Byte opcodes.
>>
>> I don't have the flash devices. So its only compile tested.
>>
>> Ashish, Simon,
>>
>> I would greatly appreciate if you could test these patches and make sure
>> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
>> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
>
> As written in my last mail, I currently cannot get SFDP to work on my board:
> I keep getting 0xffdddfdf instead of 0x50444653 (SFDP_SIGNATURE).
>
> Any idea for a reason of that? That device I have here seems to be equipped
> with an MT25QL256ABA, but that should not be an issue, I think.
Can you please check what's written on the chip itself? Usually manufacturers
write the chip name, and then the week and the year in the form week||year. Ex
4214, where week is 42 and the year 2014.
MT25QL256ABA datasheet says that: "Beginning
week 42 (2014), Micron's MT25Q production parts will include SFDP data that aligns
with revision 1.6."
So maybe earlier versions don't have sfdp support?
Also, can you try this kind of patch? Let's dump the sfdp header.
SPI_FLASH_SFDP_SUPPORT has to be selected.
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 1acff745d1a2..7e93be90fc09 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1815,14 +1815,22 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
{
const struct sfdp_parameter_header *param_header, *bfpt_header;
struct sfdp_parameter_header *param_headers = NULL;
- struct sfdp_header header;
+ struct sfdp_header header = {};
+ u32 *sfdp_table = (u32 *)&header;
size_t psize;
int i, err;
/* Get the SFDP header. */
err = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);
- if (err < 0)
+ if (err < 0) {
+ dev_err(nor->dev, "spi_nor_read_sfdp err = %d\n", err);
return err;
+ }
+
+ for (i = 0; i < sizeof(header) / sizeof(u32); i++) {
+ sfdp_table[i] = le32_to_cpu(sfdp_table[i]);
+ dev_err(nor->dev, "sfdp_table[%d] = %08x\n", i, sfdp_table[i]);
+ }
>
> Regards,
> Simon
>
>>
>> Euginey,
>>
>> Could you test this series on top of latest u-boot master and confirm
>> that your test cases still work?
>>
>> Regards
>> Vignesh
>>
>> Vignesh Raghavendra (3):
>> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
>> n25q256*
>> spi-nor: spi-nor-ids: Rename mt25qu512a entry
>> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
>> n25q512*
>>
>> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> --
>> 2.23.0
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
^ permalink raw reply related [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 9:23 ` Tudor.Ambarus at microchip.com
@ 2019-09-24 9:27 ` Simon Goldschmidt
0 siblings, 0 replies; 21+ messages in thread
From: Simon Goldschmidt @ 2019-09-24 9:27 UTC (permalink / raw)
To: u-boot
Hi Tudor,
On Tue, Sep 24, 2019 at 11:23 AM <Tudor.Ambarus@microchip.com> wrote:
>
> Hi, Simon,
>
> On 09/24/2019 10:02 AM, Simon Goldschmidt wrote:
> > External E-Mail
> >
> >
> > Hi Vignesh,
> >
> > On Tue, Sep 24, 2019 at 7:55 AM Vignesh Raghavendra <vigneshr@ti.com> wrote:
> >>
> >> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
> >> n25q256* and n25q512* and adds entries for newer variants of those
> >> flashes that support 4 Byte opcodes.
> >>
> >> I don't have the flash devices. So its only compile tested.
> >>
> >> Ashish, Simon,
> >>
> >> I would greatly appreciate if you could test these patches and make sure
> >> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
> >> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
> >
> > As written in my last mail, I currently cannot get SFDP to work on my board:
> > I keep getting 0xffdddfdf instead of 0x50444653 (SFDP_SIGNATURE).
> >
> > Any idea for a reason of that? That device I have here seems to be equipped
> > with an MT25QL256ABA, but that should not be an issue, I think.
>
> Can you please check what's written on the chip itself? Usually manufacturers
> write the chip name, and then the week and the year in the form week||year. Ex
> 4214, where week is 42 and the year 2014.
>
> MT25QL256ABA datasheet says that: "Beginning
> week 42 (2014), Micron's MT25Q production parts will include SFDP data that aligns
> with revision 1.6."
>
> So maybe earlier versions don't have sfdp support?
Problem solved. It was a driver issue, not a chip issue (see last mails).
Regards,
Simon
>
> Also, can you try this kind of patch? Let's dump the sfdp header.
> SPI_FLASH_SFDP_SUPPORT has to be selected.
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 1acff745d1a2..7e93be90fc09 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -1815,14 +1815,22 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> {
> const struct sfdp_parameter_header *param_header, *bfpt_header;
> struct sfdp_parameter_header *param_headers = NULL;
> - struct sfdp_header header;
> + struct sfdp_header header = {};
> + u32 *sfdp_table = (u32 *)&header;
> size_t psize;
> int i, err;
>
> /* Get the SFDP header. */
> err = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);
> - if (err < 0)
> + if (err < 0) {
> + dev_err(nor->dev, "spi_nor_read_sfdp err = %d\n", err);
> return err;
> + }
> +
> + for (i = 0; i < sizeof(header) / sizeof(u32); i++) {
> + sfdp_table[i] = le32_to_cpu(sfdp_table[i]);
> + dev_err(nor->dev, "sfdp_table[%d] = %08x\n", i, sfdp_table[i]);
> + }
>
>
> >
> > Regards,
> > Simon
> >
> >>
> >> Euginey,
> >>
> >> Could you test this series on top of latest u-boot master and confirm
> >> that your test cases still work?
> >>
> >> Regards
> >> Vignesh
> >>
> >> Vignesh Raghavendra (3):
> >> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
> >> n25q256*
> >> spi-nor: spi-nor-ids: Rename mt25qu512a entry
> >> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
> >> n25q512*
> >>
> >> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
> >> 1 file changed, 8 insertions(+), 5 deletions(-)
> >>
> >> --
> >> 2.23.0
> >>
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> >
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 5:56 [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512* Vignesh Raghavendra
` (3 preceding siblings ...)
2019-09-24 7:02 ` [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 " Simon Goldschmidt
@ 2019-09-24 17:23 ` Eugeniy Paltsev
2019-09-25 8:11 ` Vignesh Raghavendra
4 siblings, 1 reply; 21+ messages in thread
From: Eugeniy Paltsev @ 2019-09-24 17:23 UTC (permalink / raw)
To: u-boot
Hi Vignesh,
I've check this patches on top of 31e086e460f.
The read/write/erase seems to work.
However, as I can see 'sf protect lock' doesn't work - it finish successfully but the area remains unlocked.
As I remember It worked with old u-boot spi-nor code, but I need to check it.
---
Eugeniy Paltsev
________________________________________
From: Vignesh Raghavendra <vigneshr@ti.com>
Sent: Tuesday, September 24, 2019 08:56
To: Jagan Teki; Eugeniy Paltsev; Ashish Kumar; Simon Goldschmidt
Cc: Vignesh Raghavendra; u-boot at lists.denx.de; Tom Rini; Alexey Brodkin
Subject: [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
n25q256* and n25q512* and adds entries for newer variants of those
flashes that support 4 Byte opcodes.
I don't have the flash devices. So its only compile tested.
Ashish, Simon,
I would greatly appreciate if you could test these patches and make sure
4 Byte opcodes are being used. (Probably by enabling/adding prints to
cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
Euginey,
Could you test this series on top of latest u-boot master and confirm
that your test cases still work?
Regards
Vignesh
Vignesh Raghavendra (3):
spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
n25q256*
spi-nor: spi-nor-ids: Rename mt25qu512a entry
spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
n25q512*
drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--
2.23.0
^ permalink raw reply [flat|nested] 21+ messages in thread* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-24 17:23 ` Eugeniy Paltsev
@ 2019-09-25 8:11 ` Vignesh Raghavendra
2019-10-07 14:46 ` Eugeniy Paltsev
0 siblings, 1 reply; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-09-25 8:11 UTC (permalink / raw)
To: u-boot
On 24/09/19 10:53 PM, Eugeniy Paltsev wrote:
> Hi Vignesh,
>
> I've check this patches on top of 31e086e460f.
> The read/write/erase seems to work.
>
> However, as I can see 'sf protect lock' doesn't work - it finish successfully but the area remains unlocked.
Did you verify that area is indeed unlocked by writing data and then reading it back?
I was able to find a board with mt25qu512a which is same as n25q512a in terms of locking
I see it works fine:
=> sf probe
SF: Detected n25q512a with page size 256 Bytes, erase size 4 KiB, total 64 MiB
=> sf protect lock 0 0x4000000; echo $?
0
=> sf write 0x82000000 0x3FF0000 0x100
device 0 offset 0x3ff0000, size 0x100
SF: 256 bytes @ 0x3ff0000 Written: ERROR -5
If you still see failures wrt locking, could you provide debug logs from
spi_mem_exec_op() (in drivers/spi/spi-mem.c) just like last time?
Regards
Vignesh
> As I remember It worked with old u-boot spi-nor code, but I need to check it.
>
> ---
> Eugeniy Paltsev
>
>
> ________________________________________
> From: Vignesh Raghavendra <vigneshr@ti.com>
> Sent: Tuesday, September 24, 2019 08:56
> To: Jagan Teki; Eugeniy Paltsev; Ashish Kumar; Simon Goldschmidt
> Cc: Vignesh Raghavendra; u-boot at lists.denx.de; Tom Rini; Alexey Brodkin
> Subject: [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
>
> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
> n25q256* and n25q512* and adds entries for newer variants of those
> flashes that support 4 Byte opcodes.
>
> I don't have the flash devices. So its only compile tested.
>
> Ashish, Simon,
>
> I would greatly appreciate if you could test these patches and make sure
> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
>
> Euginey,
>
> Could you test this series on top of latest u-boot master and confirm
> that your test cases still work?
>
> Regards
> Vignesh
>
> Vignesh Raghavendra (3):
> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
> n25q256*
> spi-nor: spi-nor-ids: Rename mt25qu512a entry
> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
> n25q512*
>
> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> --
> 2.23.0
>
--
Regards
Vignesh
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-09-25 8:11 ` Vignesh Raghavendra
@ 2019-10-07 14:46 ` Eugeniy Paltsev
2019-10-09 11:48 ` Vignesh Raghavendra
0 siblings, 1 reply; 21+ messages in thread
From: Eugeniy Paltsev @ 2019-10-07 14:46 UTC (permalink / raw)
To: u-boot
Hi Vignesh,
I've tested your "[U-Boot,RFT,v2,0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing " series
applies on the latest master (879396a2405).
'axs103_defconfig' was used without changes.
Probe/read/write/erase work for n25q512ax3.
Lock/unlock don't work, so here is debug log:
(I've tried to run lock/unlock after unlock/lock and write/erase after lock, so I guess it will cover all combinations useful for debug)
--------------------->8--------------------------
AXS# sf probe && echo OK
9f | [6B in] 20 ba 20 10 00 00 [ret 0]
06 | [0B -] [ret 0]
b7 | [0B -] [ret 0]
04 | [0B -] [ret 0]
SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
OK
AXS# sf protect lock 0x0 0x4000000 && echo OK
05 | [1B in] 9c [ret 0]
OK
AXS# mw 0x81000000 0 5 && sf write 0x81000000 0x180000 0x10 && echo OK
device 0 offset 0x180000, size 0x10
06 | [0B -] [ret 0]
02 00 18 00 00 | [16B out] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ret 0]
05 | [1B in] 9c [ret 0]
70 | [1B in] 81 [ret 0]
SF: 16 bytes @ 0x180000 Written: OK
OK
AXS# sf protect unlock 0x0 0x4000000 && echo OK
05 | [1B in] 9c [ret 0]
06 | [0B -] [ret 0]
01 | [1B out] 00 [ret 0]
05 | [1B in] 00 [ret 0]
70 | [1B in] 81 [ret 0]
05 | [1B in] 00 [ret 0]
OK
AXS# sf protect lock 0x0 0x4000000 && echo OK
05 | [1B in] 00 [ret 0]
06 | [0B -] [ret 0]
01 | [1B out] 9c [ret 0]
05 | [1B in] 9c [ret 0]
70 | [1B in] 81 [ret 0]
05 | [1B in] 9c [ret 0]
OK
AXS# sf protect lock 0x0 0x4000000 && echo OK
05 | [1B in] 9c [ret 0]
OK
AXS#
AXS#
AXS# sf protect unlock 0x0 0x4000000 && echo OK
05 | [1B in] 9c [ret 0]
06 | [0B -] [ret 0]
01 | [1B out] 00 [ret 0]
05 | [1B in] 00 [ret 0]
70 | [1B in] 81 [ret 0]
05 | [1B in] 00 [ret 0]
OK
AXS# sf protect unlock 0x0 0x4000000 && echo OK
05 | [1B in] 00 [ret 0]
OK
AXS#
AXS#
AXS# sf protect lock 0x0 0x4000000 && echo OK
05 | [1B in] 00 [ret 0]
06 | [0B -] [ret 0]
01 | [1B out] 9c [ret 0]
05 | [1B in] 9c [ret 0]
70 | [1B in] 81 [ret 0]
05 | [1B in] 9c [ret 0]
OK
AXS# sf erase 0x180000 0x1000 && echo OK
06 | [0B -] [ret 0]
20 00 18 00 00 | [0B -] [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9f [ret 0]
70 | [1B in] 01 [ret 0]
05 | [1B in] 9c [ret 0]
70 | [1B in] 81 [ret 0]
04 | [0B -] [ret 0]
SF: 4096 bytes @ 0x180000 Erased: OK
OK
AXS# sf read 0x81000000 0x180000 0x10 && md.b 0x81000000 0x10 && echo OK
device 0 offset 0x180000, size 0x10
0b 00 18 00 00 | [16B in] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ret 0]
SF: 16 bytes @ 0x180000 Read: OK
81000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
OK
AXS# mw 0x81000000 0 5 && sf write 0x81000000 0x180000 0x10 && echo OK
device 0 offset 0x180000, size 0x10
06 | [0B -] [ret 0]
02 00 18 00 00 | [16B out] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ret 0]
05 | [1B in] 9c [ret 0]
70 | [1B in] 81 [ret 0]
SF: 16 bytes @ 0x180000 Written: OK
OK
AXS# sf read 0x81000000 0x180000 0x10 && echo OK
device 0 offset 0x180000, size 0x10
0b 00 18 00 00 | [16B in] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ret 0]
SF: 16 bytes @ 0x180000 Read: OK
OK
--------------------->8--------------------------
---
Eugeniy Paltsev
________________________________________
From: Vignesh Raghavendra <vigneshr@ti.com>
Sent: Wednesday, September 25, 2019 11:11
To: Eugeniy Paltsev; Jagan Teki; Ashish Kumar; Simon Goldschmidt
Cc: u-boot at lists.denx.de; Tom Rini; Alexey Brodkin
Subject: Re: [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
On 24/09/19 10:53 PM, Eugeniy Paltsev wrote:
> Hi Vignesh,
>
> I've check this patches on top of 31e086e460f.
> The read/write/erase seems to work.
>
> However, as I can see 'sf protect lock' doesn't work - it finish successfully but the area remains unlocked.
Did you verify that area is indeed unlocked by writing data and then reading it back?
I was able to find a board with mt25qu512a which is same as n25q512a in terms of locking
I see it works fine:
=> sf probe
SF: Detected n25q512a with page size 256 Bytes, erase size 4 KiB, total 64 MiB
=> sf protect lock 0 0x4000000; echo $?
0
=> sf write 0x82000000 0x3FF0000 0x100
device 0 offset 0x3ff0000, size 0x100
SF: 256 bytes @ 0x3ff0000 Written: ERROR -5
If you still see failures wrt locking, could you provide debug logs from
spi_mem_exec_op() (in drivers/spi/spi-mem.c) just like last time?
Regards
Vignesh
> As I remember It worked with old u-boot spi-nor code, but I need to check it.
>
> ---
> Eugeniy Paltsev
>
>
> ________________________________________
> From: Vignesh Raghavendra <vigneshr@ti.com>
> Sent: Tuesday, September 24, 2019 08:56
> To: Jagan Teki; Eugeniy Paltsev; Ashish Kumar; Simon Goldschmidt
> Cc: Vignesh Raghavendra; u-boot at lists.denx.de; Tom Rini; Alexey Brodkin
> Subject: [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
>
> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
> n25q256* and n25q512* and adds entries for newer variants of those
> flashes that support 4 Byte opcodes.
>
> I don't have the flash devices. So its only compile tested.
>
> Ashish, Simon,
>
> I would greatly appreciate if you could test these patches and make sure
> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
>
> Euginey,
>
> Could you test this series on top of latest u-boot master and confirm
> that your test cases still work?
>
> Regards
> Vignesh
>
> Vignesh Raghavendra (3):
> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
> n25q256*
> spi-nor: spi-nor-ids: Rename mt25qu512a entry
> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
> n25q512*
>
> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> --
> 2.23.0
>
--
Regards
Vignesh
^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
2019-10-07 14:46 ` Eugeniy Paltsev
@ 2019-10-09 11:48 ` Vignesh Raghavendra
0 siblings, 0 replies; 21+ messages in thread
From: Vignesh Raghavendra @ 2019-10-09 11:48 UTC (permalink / raw)
To: u-boot
Hi Eugeniy,
On 07/10/19 8:16 PM, Eugeniy Paltsev wrote:
> Hi Vignesh,
>
> I've tested your "[U-Boot,RFT,v2,0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing " series
> applies on the latest master (879396a2405).
> 'axs103_defconfig' was used without changes.
> > Probe/read/write/erase work for n25q512ax3.
>
Thanks for the testing!
> Lock/unlock don't work, so here is debug log:
> (I've tried to run lock/unlock after unlock/lock and write/erase after lock, so I guess it will cover all combinations useful for debug)
>
> --------------------->8--------------------------
> AXS# sf probe && echo OK
> 9f | [6B in] 20 ba 20 10 00 00 [ret 0]
> 06 | [0B -] [ret 0]
> b7 | [0B -] [ret 0]
> 04 | [0B -] [ret 0]
> SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
> OK
> AXS# sf protect lock 0x0 0x4000000 && echo OK
> 05 | [1B in] 9c [ret 0]
> OK
You are trying to lock entire 64MB space. Per Data sheet of flash, this
requires setting BP3-BP0 bits in Status register. But only BP2-BP0 are set
Neither the old framework nor current framework (or even Linux kernel)
supports handling of BP3 bit. So this failure is _not a regression_.
In this particular case, U-Boot code sets only BP2-BP0 when asked to
lock entire 64MB range. But this effectively locks sectors 960 to 1023.
Regards
Vignesh
> AXS# mw 0x81000000 0 5 && sf write 0x81000000 0x180000 0x10 && echo OK
> device 0 offset 0x180000, size 0x10
> 06 | [0B -] [ret 0]
> 02 00 18 00 00 | [16B out] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ret 0]
> 05 | [1B in] 9c [ret 0]
> 70 | [1B in] 81 [ret 0]
> SF: 16 bytes @ 0x180000 Written: OK
> OK
> AXS# sf protect unlock 0x0 0x4000000 && echo OK
> 05 | [1B in] 9c [ret 0]
> 06 | [0B -] [ret 0]
> 01 | [1B out] 00 [ret 0]
> 05 | [1B in] 00 [ret 0]
> 70 | [1B in] 81 [ret 0]
> 05 | [1B in] 00 [ret 0]
> OK
> AXS# sf protect lock 0x0 0x4000000 && echo OK
> 05 | [1B in] 00 [ret 0]
> 06 | [0B -] [ret 0]
> 01 | [1B out] 9c [ret 0]
> 05 | [1B in] 9c [ret 0]
> 70 | [1B in] 81 [ret 0]
> 05 | [1B in] 9c [ret 0]
> OK
> AXS# sf protect lock 0x0 0x4000000 && echo OK
> 05 | [1B in] 9c [ret 0]
> OK
> AXS#
> AXS#
> AXS# sf protect unlock 0x0 0x4000000 && echo OK
> 05 | [1B in] 9c [ret 0]
> 06 | [0B -] [ret 0]
> 01 | [1B out] 00 [ret 0]
> 05 | [1B in] 00 [ret 0]
> 70 | [1B in] 81 [ret 0]
> 05 | [1B in] 00 [ret 0]
> OK
> AXS# sf protect unlock 0x0 0x4000000 && echo OK
> 05 | [1B in] 00 [ret 0]
> OK
> AXS#
> AXS#
> AXS# sf protect lock 0x0 0x4000000 && echo OK
> 05 | [1B in] 00 [ret 0]
> 06 | [0B -] [ret 0]
> 01 | [1B out] 9c [ret 0]
> 05 | [1B in] 9c [ret 0]
> 70 | [1B in] 81 [ret 0]
> 05 | [1B in] 9c [ret 0]
> OK
> AXS# sf erase 0x180000 0x1000 && echo OK
> 06 | [0B -] [ret 0]
> 20 00 18 00 00 | [0B -] [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9f [ret 0]
> 70 | [1B in] 01 [ret 0]
> 05 | [1B in] 9c [ret 0]
> 70 | [1B in] 81 [ret 0]
> 04 | [0B -] [ret 0]
> SF: 4096 bytes @ 0x180000 Erased: OK
> OK
> AXS# sf read 0x81000000 0x180000 0x10 && md.b 0x81000000 0x10 && echo OK
> device 0 offset 0x180000, size 0x10
> 0b 00 18 00 00 | [16B in] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ret 0]
> SF: 16 bytes @ 0x180000 Read: OK
> 81000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
> OK
> AXS# mw 0x81000000 0 5 && sf write 0x81000000 0x180000 0x10 && echo OK
> device 0 offset 0x180000, size 0x10
> 06 | [0B -] [ret 0]
> 02 00 18 00 00 | [16B out] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ret 0]
> 05 | [1B in] 9c [ret 0]
> 70 | [1B in] 81 [ret 0]
> SF: 16 bytes @ 0x180000 Written: OK
> OK
> AXS# sf read 0x81000000 0x180000 0x10 && echo OK
> device 0 offset 0x180000, size 0x10
> 0b 00 18 00 00 | [16B in] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ret 0]
> SF: 16 bytes @ 0x180000 Read: OK
> OK
> --------------------->8--------------------------
>
> ---
> Eugeniy Paltsev
>
> ________________________________________
> From: Vignesh Raghavendra <vigneshr@ti.com>
> Sent: Wednesday, September 25, 2019 11:11
> To: Eugeniy Paltsev; Jagan Teki; Ashish Kumar; Simon Goldschmidt
> Cc: u-boot at lists.denx.de; Tom Rini; Alexey Brodkin
> Subject: Re: [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
>
>
>
> On 24/09/19 10:53 PM, Eugeniy Paltsev wrote:
>> Hi Vignesh,
>>
>> I've check this patches on top of 31e086e460f.
>> The read/write/erase seems to work.
>>
>> However, as I can see 'sf protect lock' doesn't work - it finish successfully but the area remains unlocked.
>
> Did you verify that area is indeed unlocked by writing data and then reading it back?
> I was able to find a board with mt25qu512a which is same as n25q512a in terms of locking
> I see it works fine:
>
> => sf probe
> SF: Detected n25q512a with page size 256 Bytes, erase size 4 KiB, total 64 MiB
> => sf protect lock 0 0x4000000; echo $?
> 0
> => sf write 0x82000000 0x3FF0000 0x100
> device 0 offset 0x3ff0000, size 0x100
> SF: 256 bytes @ 0x3ff0000 Written: ERROR -5
>
> If you still see failures wrt locking, could you provide debug logs from
> spi_mem_exec_op() (in drivers/spi/spi-mem.c) just like last time?
>
>
> Regards
> Vignesh
>
>> As I remember It worked with old u-boot spi-nor code, but I need to check it.
>>
>> ---
>> Eugeniy Paltsev
>>
>>
>> ________________________________________
>> From: Vignesh Raghavendra <vigneshr@ti.com>
>> Sent: Tuesday, September 24, 2019 08:56
>> To: Jagan Teki; Eugeniy Paltsev; Ashish Kumar; Simon Goldschmidt
>> Cc: Vignesh Raghavendra; u-boot at lists.denx.de; Tom Rini; Alexey Brodkin
>> Subject: [PATCH RFT 0/3] spi-nor: spi-nor-ids: Fix 4 Byte addressing for n25q256 and n25q512*
>>
>> This series removes SPI_NOR_4B_OPCODES flags from legacy variants of
>> n25q256* and n25q512* and adds entries for newer variants of those
>> flashes that support 4 Byte opcodes.
>>
>> I don't have the flash devices. So its only compile tested.
>>
>> Ashish, Simon,
>>
>> I would greatly appreciate if you could test these patches and make sure
>> 4 Byte opcodes are being used. (Probably by enabling/adding prints to
>> cmd->opcode in spi_mem_exec_op() in drivers/spi/spi-mem.c
>>
>> Euginey,
>>
>> Could you test this series on top of latest u-boot master and confirm
>> that your test cases still work?
>>
>> Regards
>> Vignesh
>>
>> Vignesh Raghavendra (3):
>> spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and
>> n25q256*
>> spi-nor: spi-nor-ids: Rename mt25qu512a entry
>> spi-nor: spi-nor-ids: Add entries for newer variants of n25q256* and
>> n25q512*
>>
>> drivers/mtd/spi/spi-nor-ids.c | 13 ++++++++-----
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> --
>> 2.23.0
>>
>
> --
> Regards
> Vignesh
>
--
Regards
Vignesh
^ permalink raw reply [flat|nested] 21+ messages in thread