[U-Boot] [PATCH 1/2] spi-nor: spi-nor-ids: Merge "n25q512a" and "mt25qu512a" entries

[U-Boot] [PATCH 1/2] spi-nor: spi-nor-ids: Merge "n25q512a" and "mt25qu512a" entries

[Vignesh Raghavendra]

mt25qu512a is just a rebranded name for n25q512a. All the 6 bytes of JEDEC
ID bytes are same for mt25qu512a and n25q512a.
Commit 8385520f2931 ("mtd: spi: Add flash property for Micron mt25qu512a")
added new entry for mt25qu512a before n25q512a entry. So on older boards
with n25q512a "sf probe" now shows flash name as mt25qu512a. This creates
confusion with users who used to seeing n25q512a and are not aware of
the fact that both flashes are the same. Therefore fix this by renaming
name to "mt25qu512a (n25q512a)" so as to make it clear that flash
detected may be either of them.

With that we can have single entry for n25q512a and mt25qu512a.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
 drivers/mtd/spi/spi-nor-ids.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a3920ba520e0..f32a6c7d464b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -163,9 +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 | SPI_NOR_4B_OPCODES) },
 	{ INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
-	{ 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("mt25qu512a (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("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

[U-Boot] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Vignesh Raghavendra]

Not all variants of n25q256* and n25q512* support 4 Byte stateless
addressing opcodes and there is no easy way to discover at runtime
whether the flash supports this feature or not.
Therefore don't set SPI_NOR_4B_OPCODES for these flashes.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
For n25q512ax3:
Tested-by: Eugeniy Paltsev <paltsev@synopsys.com>
---
 drivers/mtd/spi/spi-nor-ids.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index f32a6c7d464b..5a7fe07c8309 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
-	{ INFO("mt25qu512a (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("mt25qu512a (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

[U-Boot] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

Vignesh Raghavendra <vigneshr@ti.com> schrieb am Di., 10. Sep. 2019, 19:07:

> Not all variants of n25q256* and n25q512* support 4 Byte stateless
> addressing opcodes and there is no easy way to discover at runtime
> whether the flash supports this feature or not.
> Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
>

I have one of those that supports 4 Byte opposes and would be glad if I
could use them. Is there any chance of flagging the devicetree or something
that enables them?

Regards,
Simon


> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> For n25q512ax3:
> Tested-by: Eugeniy Paltsev <paltsev@synopsys.com>
> ---
>  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index f32a6c7d464b..5a7fe07c8309 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
> -       { INFO("mt25qu512a (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("mt25qu512a (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
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Ashish Kumar]

> -----Original Message-----
> From: Vignesh Raghavendra <vigneshr@ti.com>
> Sent: Tuesday, September 10, 2019 10:36 PM
> To: Jagan Teki <jagan@openedev.com>
> Cc: Vignesh Raghavendra <vigneshr@ti.com>; u-boot at lists.denx.de; Tom
> Rini <trini@konsulko.com>; Eugeniy Paltsev
> <Eugeniy.Paltsev@synopsys.com>; Alexey.Brodkin at synopsys.com; Ashish
> Kumar <ashish.kumar@nxp.com>
> Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> 
> Caution: EXT Email
> 
> Not all variants of n25q256* and n25q512* support 4 Byte stateless
> addressing opcodes and there is no easy way to discover at runtime whether
> the flash supports this feature or not.
> Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
Hi Vignesh, 

I think it will be good to keep it here and disable this for boards by using not set flag in config
Like
# SPI_NOR_4B_OPCODES is not set

Regards
Ashish 
> 
> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> For n25q512ax3:
> Tested-by: Eugeniy Paltsev <paltsev@synopsys.com>
> ---
>  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index f32a6c7d464b..5a7fe07c8309 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
> -       { INFO("mt25qu512a (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("mt25qu512a (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

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

Ashish Kumar <ashish.kumar@nxp.com> schrieb am Mi., 11. Sep. 2019, 10:49:

>
>
> > -----Original Message-----
> > From: Vignesh Raghavendra <vigneshr@ti.com>
> > Sent: Tuesday, September 10, 2019 10:36 PM
> > To: Jagan Teki <jagan@openedev.com>
> > Cc: Vignesh Raghavendra <vigneshr@ti.com>; u-boot at lists.denx.de; Tom
> > Rini <trini@konsulko.com>; Eugeniy Paltsev
> > <Eugeniy.Paltsev@synopsys.com>; Alexey.Brodkin at synopsys.com; Ashish
> > Kumar <ashish.kumar@nxp.com>
> > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> >
> > Caution: EXT Email
> >
> > Not all variants of n25q256* and n25q512* support 4 Byte stateless
> > addressing opcodes and there is no easy way to discover at runtime
> whether
> > the flash supports this feature or not.
> > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
> Hi Vignesh,
>
> I think it will be good to keep it here and disable this for boards by
> using not set flag in config
> Like
> # SPI_NOR_4B_OPCODES is not set
>

I'd prefer to take this patch, as this is what Linux does. I think it's
better to have an opt-in option. That way, all chips work with the default
settings (even if that means some chips don't use 4 baste opcodes even if
they could).

Still, so we have such an op-in possibility to enable 4 byte opcodes on
these chips?

Regards,
Simon


> Regards
> Ashish
> >
> > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> For n25q512ax3:
> > Tested-by: Eugeniy Paltsev <paltsev@synopsys.com>
> > ---
> >  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c
> b/drivers/mtd/spi/spi-nor-ids.c
> > index f32a6c7d464b..5a7fe07c8309 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
> > -       { INFO("mt25qu512a (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("mt25qu512a (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
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Vignesh Raghavendra]

Hi Ashish, Simon,

On 11/09/19 3:11 PM, Simon Goldschmidt wrote:
> 
> 
> Ashish Kumar <ashish.kumar at nxp.com <mailto:ashish.kumar@nxp.com>>
> schrieb am Mi., 11. Sep. 2019, 10:49:
> 
> 
> 
>     > -----Original Message-----
>     > From: Vignesh Raghavendra <vigneshr at ti.com <mailto:vigneshr@ti.com>>
>     > Sent: Tuesday, September 10, 2019 10:36 PM
>     > To: Jagan Teki <jagan at openedev.com <mailto:jagan@openedev.com>>
>     > Cc: Vignesh Raghavendra <vigneshr@ti.com
>     <mailto:vigneshr@ti.com>>; u-boot at lists.denx.de
>     <mailto:u-boot@lists.denx.de>; Tom
>     > Rini <trini at konsulko.com <mailto:trini@konsulko.com>>; Eugeniy Paltsev
>     > <Eugeniy.Paltsev@synopsys.com
>     <mailto:Eugeniy.Paltsev@synopsys.com>>; Alexey.Brodkin at synopsys.com
>     <mailto:Alexey.Brodkin@synopsys.com>; Ashish
>     > Kumar <ashish.kumar at nxp.com <mailto:ashish.kumar@nxp.com>>
>     > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
>     > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
>     >
>     > Caution: EXT Email
>     >
>     > Not all variants of n25q256* and n25q512* support 4 Byte stateless
>     > addressing opcodes and there is no easy way to discover at runtime
>     whether
>     > the flash supports this feature or not.
>     > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
>     Hi Vignesh,
> 
>     I think it will be good to keep it here and disable this for boards
>     by using not set flag in config
>     Like
>     # SPI_NOR_4B_OPCODES is not set
> 

SPI_NOR_4B_OPCODES is not a config option. Are you suggesting to add
one? config options don't scale well especially when same defconfig is
used for multiple boards that potentially have different flashes

> 
> I'd prefer to take this patch, as this is what Linux does. 

No, this is not what Linux does. There is no opt-in or opt-out option.
Decision to use 4 byte opcode is done at runtime based on flash that's
detected. Either based on info->flags for that part or by parsing SFDP
table. There is no config option of DT option to force 4 byte addressing

> I think it's better to have an opt-in option. That way, all chips work with the
> default settings (even if that means some chips don't use 4 baste
> opcodes even if they could).
> 

One solution would be to look at SFDP tables of two variants of flash
and see if there are any differences that can be used as a clue.

Simon,
Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
flash that you have?

I have asked Eugeniy to provide dumps from his flash on the other
thread. Lets see if something stands out.

Regards
Vignesh

> Still, so we have such an op-in possibility to enable 4 byte opcodes on
> these chips?
> 
> Regards,
> Simon
> 
> 
>     Regards
>     Ashish
>     >
>     > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com
>     <mailto:vigneshr@ti.com>> For n25q512ax3:
>     > Tested-by: Eugeniy Paltsev <paltsev@synopsys.com
>     <mailto:paltsev@synopsys.com>>
>     > ---
>     >  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
>     >  1 file changed, 3 insertions(+), 3 deletions(-)
>     >
>     > diff --git a/drivers/mtd/spi/spi-nor-ids.c
>     b/drivers/mtd/spi/spi-nor-ids.c
>     > index f32a6c7d464b..5a7fe07c8309 100644
>     > --- a/drivers/mtd/spi/spi-nor-ids.c
>     > +++ b/drivers/mtd/spi/spi-nor-ids.c
>     > @@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
>     > -       { INFO("mt25qu512a (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("mt25qu512a (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
> 
>     _______________________________________________
>     U-Boot mailing list
>     U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
>     https://lists.denx.de/listinfo/u-boot
> 

-- 
Regards
Vignesh

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Ashish Kumar]

> -----Original Message-----
> From: Vignesh Raghavendra <vigneshr@ti.com>
> Sent: Wednesday, September 11, 2019 3:37 PM
> To: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>; Ashish Kumar
> <ashish.kumar@nxp.com>
> Cc: Jagan Teki <jagan@openedev.com>; u-boot at lists.denx.de;
> Alexey.Brodkin at synopsys.com; Eugeniy Paltsev
> <Eugeniy.Paltsev@synopsys.com>; Tom Rini <trini@konsulko.com>
> Subject: Re: [U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> 
> Caution: EXT Email
> 
> Hi Ashish, Simon,
> 
> On 11/09/19 3:11 PM, Simon Goldschmidt wrote:
> >
> >
> > Ashish Kumar <ashish.kumar at nxp.com <mailto:ashish.kumar@nxp.com>>
> > schrieb am Mi., 11. Sep. 2019, 10:49:
> >
> >
> >
> >     > -----Original Message-----
> >     > From: Vignesh Raghavendra <vigneshr@ti.com
> <mailto:vigneshr@ti.com>>
> >     > Sent: Tuesday, September 10, 2019 10:36 PM
> >     > To: Jagan Teki <jagan@openedev.com
> <mailto:jagan@openedev.com>>
> >     > Cc: Vignesh Raghavendra <vigneshr@ti.com
> >     <mailto:vigneshr@ti.com>>; u-boot at lists.denx.de
> >     <mailto:u-boot@lists.denx.de>; Tom
> >     > Rini <trini at konsulko.com <mailto:trini@konsulko.com>>; Eugeniy
> Paltsev
> >     > <Eugeniy.Paltsev@synopsys.com
> >     <mailto:Eugeniy.Paltsev@synopsys.com>>;
> Alexey.Brodkin at synopsys.com
> >     <mailto:Alexey.Brodkin@synopsys.com>; Ashish
> >     > Kumar <ashish.kumar at nxp.com <mailto:ashish.kumar@nxp.com>>
> >     > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> >     > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> >     >
> >     > Caution: EXT Email
> >     >
> >     > Not all variants of n25q256* and n25q512* support 4 Byte stateless
> >     > addressing opcodes and there is no easy way to discover at runtime
> >     whether
> >     > the flash supports this feature or not.
> >     > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
> >     Hi Vignesh,
> >
> >     I think it will be good to keep it here and disable this for boards
> >     by using not set flag in config
> >     Like
> >     # SPI_NOR_4B_OPCODES is not set
> >
> 
> SPI_NOR_4B_OPCODES is not a config option. Are you suggesting to add
> one? config options don't scale well especially when same defconfig is used
> for multiple boards that potentially have different flashes
> 
> >
> > I'd prefer to take this patch, as this is what Linux does.
> 
> No, this is not what Linux does. There is no opt-in or opt-out option.
> Decision to use 4 byte opcode is done at runtime based on flash that's
> detected. Either based on info->flags for that part or by parsing SFDP table.
> There is no config option of DT option to force 4 byte addressing
> 
> > I think it's better to have an opt-in option. That way, all chips work
> > with the default settings (even if that means some chips don't use 4
> > baste opcodes even if they could).
> >
> 
> One solution would be to look at SFDP tables of two variants of flash and see
> if there are any differences that can be used as a clue.
> 
> Simon,
> Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
> flash that you have?
> 
> I have asked Eugeniy to provide dumps from his flash on the other thread.
> Lets see if something stands out.
Hi Vignesh, Eugeniy,

Could you please provide me dump for n25q512a which consists of all 6 JEDEC id bytes.
I had initiated mail chain with MICRON FAE, and they suggest that extended id may be different for
n25q512a  from mt25qu512a.

I have dumped JEDEC ID from mt25qu512a "20, bb, 20, 10, 44, 00" , the second last byte is supposed to be different as per FAE.

Bit 6 
device
Generation
1 = 2nd
generation

Regards
Ashish 
> 
> Regards
> Vignesh
> 
> > Still, so we have such an op-in possibility to enable 4 byte opcodes
> > on these chips?
> >
> > Regards,
> > Simon
> >
> >
> >     Regards
> >     Ashish
> >     >
> >     > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com
> >     <mailto:vigneshr@ti.com>> For n25q512ax3:
> >     > Tested-by: Eugeniy Paltsev <paltsev@synopsys.com
> >     <mailto:paltsev@synopsys.com>>
> >     > ---
> >     >  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
> >     >  1 file changed, 3 insertions(+), 3 deletions(-)
> >     >
> >     > diff --git a/drivers/mtd/spi/spi-nor-ids.c
> >     b/drivers/mtd/spi/spi-nor-ids.c
> >     > index f32a6c7d464b..5a7fe07c8309 100644
> >     > --- a/drivers/mtd/spi/spi-nor-ids.c
> >     > +++ b/drivers/mtd/spi/spi-nor-ids.c
> >     > @@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
> >     > -       { INFO("mt25qu512a (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("mt25qu512a (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
> >
> >     _______________________________________________
> >     U-Boot mailing list
> >     U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.denx.de%2Flistinfo%2Fu-
> boot&amp;data=02%7C01%7Cashish.kumar%40nxp.co
> >
> m%7C5531cc6a339141ded6cc08d7369fbe9d%7C686ea1d3bc2b4c6fa92cd99c5c
> 30163
> >
> 5%7C0%7C0%7C637037932040085697&amp;sdata=1%2BbqG6OBWOLedplM1
> 19W7E%2Bgp
> > XlN1wasXZR3AJgzYaM%3D&amp;reserved=0
> >
> 
> --
> Regards
> Vignesh

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Vignesh Raghavendra]

Hi Ashish,

On 23/09/19 2:37 PM, Ashish Kumar wrote:
> 
[...]
>> Lets see if something stands out.
> Hi Vignesh, Eugeniy,
> 
> Could you please provide me dump for n25q512a which consists of all 6 JEDEC id bytes.
> I had initiated mail chain with MICRON FAE, and they suggest that extended id may be different for
> n25q512a  from mt25qu512a.
> 
> I have dumped JEDEC ID from mt25qu512a "20, bb, 20, 10, 44, 00" , the second last byte is supposed to be different as per FAE.
> 
> Bit 6 
> device
> Generation
> 1 = 2nd
> generation
> 

Thats great! Thanks for getting that information!

From Eugeniy's debug dumps in other mail chain, I see JEDEC ID of that flash is:
 " 20 ba 20 10 00 00" (does not support 4 byte addressing opcodes)

So these variants can be differentiated quite easily. I will send out a series fixing those entries.

Regards
Vignesh

> Regards
> Ashish 
>>
>> Regards
>> Vignesh
>>
>>> Still, so we have such an op-in possibility to enable 4 byte opcodes
>>> on these chips?
>>>
>>> Regards,
>>> Simon
>>>
>>>
>>>     Regards
>>>     Ashish
>>>     >
>>>     > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com
>>>     <mailto:vigneshr@ti.com>> For n25q512ax3:
>>>     > Tested-by: Eugeniy Paltsev <paltsev@synopsys.com
>>>     <mailto:paltsev@synopsys.com>>
>>>     > ---
>>>     >  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
>>>     >  1 file changed, 3 insertions(+), 3 deletions(-)
>>>     >
>>>     > diff --git a/drivers/mtd/spi/spi-nor-ids.c
>>>     b/drivers/mtd/spi/spi-nor-ids.c
>>>     > index f32a6c7d464b..5a7fe07c8309 100644
>>>     > --- a/drivers/mtd/spi/spi-nor-ids.c
>>>     > +++ b/drivers/mtd/spi/spi-nor-ids.c
>>>     > @@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
>>>     > -       { INFO("mt25qu512a (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("mt25qu512a (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
>>>
>>>     _______________________________________________
>>>     U-Boot mailing list
>>>     U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
>>>
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>>> s.denx.de%2Flistinfo%2Fu-
>> boot&amp;data=02%7C01%7Cashish.kumar%40nxp.co
>>>
>> m%7C5531cc6a339141ded6cc08d7369fbe9d%7C686ea1d3bc2b4c6fa92cd99c5c
>> 30163
>>>
>> 5%7C0%7C0%7C637037932040085697&amp;sdata=1%2BbqG6OBWOLedplM1
>> 19W7E%2Bgp
>>> XlN1wasXZR3AJgzYaM%3D&amp;reserved=0
>>>
>>
>> --
>> Regards
>> Vignesh

-- 
Regards
Vignesh

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

On Wed, Sep 11, 2019 at 12:06 PM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>
> Hi Ashish, Simon,
>
> On 11/09/19 3:11 PM, Simon Goldschmidt wrote:
> >
> >
> > Ashish Kumar <ashish.kumar at nxp.com <mailto:ashish.kumar@nxp.com>>
> > schrieb am Mi., 11. Sep. 2019, 10:49:
> >
> >
> >
> >     > -----Original Message-----
> >     > From: Vignesh Raghavendra <vigneshr at ti.com <mailto:vigneshr@ti.com>>
> >     > Sent: Tuesday, September 10, 2019 10:36 PM
> >     > To: Jagan Teki <jagan at openedev.com <mailto:jagan@openedev.com>>
> >     > Cc: Vignesh Raghavendra <vigneshr@ti.com
> >     <mailto:vigneshr@ti.com>>; u-boot at lists.denx.de
> >     <mailto:u-boot@lists.denx.de>; Tom
> >     > Rini <trini at konsulko.com <mailto:trini@konsulko.com>>; Eugeniy Paltsev
> >     > <Eugeniy.Paltsev@synopsys.com
> >     <mailto:Eugeniy.Paltsev@synopsys.com>>; Alexey.Brodkin at synopsys.com
> >     <mailto:Alexey.Brodkin@synopsys.com>; Ashish
> >     > Kumar <ashish.kumar at nxp.com <mailto:ashish.kumar@nxp.com>>
> >     > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> >     > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> >     >
> >     > Caution: EXT Email
> >     >
> >     > Not all variants of n25q256* and n25q512* support 4 Byte stateless
> >     > addressing opcodes and there is no easy way to discover at runtime
> >     whether
> >     > the flash supports this feature or not.
> >     > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
> >     Hi Vignesh,
> >
> >     I think it will be good to keep it here and disable this for boards
> >     by using not set flag in config
> >     Like
> >     # SPI_NOR_4B_OPCODES is not set
> >
>
> SPI_NOR_4B_OPCODES is not a config option. Are you suggesting to add
> one? config options don't scale well especially when same defconfig is
> used for multiple boards that potentially have different flashes
>
> >
> > I'd prefer to take this patch, as this is what Linux does.
>
> No, this is not what Linux does. There is no opt-in or opt-out option.
> Decision to use 4 byte opcode is done at runtime based on flash that's
> detected. Either based on info->flags for that part or by parsing SFDP
> table. There is no config option of DT option to force 4 byte addressing
>
> > I think it's better to have an opt-in option. That way, all chips work with the
> > default settings (even if that means some chips don't use 4 baste
> > opcodes even if they could).
> >
>
> One solution would be to look at SFDP tables of two variants of flash
> and see if there are any differences that can be used as a clue.
>
> Simon,
> Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
> flash that you have?

I have a n251256a with JEDEC ID 20, ba, 19, 10, 44, 00.
According to the docs, it should support 4-byte opcodes.

How would I dump the SFDP tables?

Regards,
Simon

>
> I have asked Eugeniy to provide dumps from his flash on the other
> thread. Lets see if something stands out.
>
> Regards
> Vignesh
>
> > Still, so we have such an op-in possibility to enable 4 byte opcodes on
> > these chips?
> >
> > Regards,
> > Simon
> >
> >
> >     Regards
> >     Ashish
> >     >
> >     > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com
> >     <mailto:vigneshr@ti.com>> For n25q512ax3:
> >     > Tested-by: Eugeniy Paltsev <paltsev@synopsys.com
> >     <mailto:paltsev@synopsys.com>>
> >     > ---
> >     >  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
> >     >  1 file changed, 3 insertions(+), 3 deletions(-)
> >     >
> >     > diff --git a/drivers/mtd/spi/spi-nor-ids.c
> >     b/drivers/mtd/spi/spi-nor-ids.c
> >     > index f32a6c7d464b..5a7fe07c8309 100644
> >     > --- a/drivers/mtd/spi/spi-nor-ids.c
> >     > +++ b/drivers/mtd/spi/spi-nor-ids.c
> >     > @@ -161,10 +161,10 @@ 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("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 | SPI_NOR_4B_OPCODES) },
> >     > -       { INFO("mt25qu512a (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("mt25qu512a (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
> >
> >     _______________________________________________
> >     U-Boot mailing list
> >     U-Boot at lists.denx.de <mailto:U-Boot@lists.denx.de>
> >     https://lists.denx.de/listinfo/u-boot
> >
>
> --
> Regards
> Vignesh

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Tudor.Ambarus at microchip.com]

Hi, Simon,

On 09/23/2019 12:30 PM, Simon Goldschmidt wrote:
> How would I dump the SFDP tables?

this should do it. Make sure SPI_FLASH_SFDP_SUPPORT is selected in menuconfig.

Cheers,
ta

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 1acff745d1a2..7062f31226bf 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1680,6 +1680,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
        for (i = 0; i < BFPT_DWORD_MAX; i++)
                bfpt.dwords[i] = le32_to_cpu(bfpt.dwords[i]);

+       for (i = 0; i < BFPT_DWORD_MAX; i++)
+               dev_err(nor->dev, "bfpt.dwords[%d] = %08x\n", i,
+                       bfpt.dwords[i]);
+

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

Hi ,

On Mon, Sep 23, 2019 at 11:38 AM <Tudor.Ambarus@microchip.com> wrote:
>
> Hi, Simon,
>
> On 09/23/2019 12:30 PM, Simon Goldschmidt wrote:
> > How would I dump the SFDP tables?
>
> this should do it. Make sure SPI_FLASH_SFDP_SUPPORT is selected in menuconfig.
>
> Cheers,
> ta
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 1acff745d1a2..7062f31226bf 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -1680,6 +1680,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>         for (i = 0; i < BFPT_DWORD_MAX; i++)
>                 bfpt.dwords[i] = le32_to_cpu(bfpt.dwords[i]);
>
> +       for (i = 0; i < BFPT_DWORD_MAX; i++)
> +               dev_err(nor->dev, "bfpt.dwords[%d] = %08x\n", i,
> +                       bfpt.dwords[i]);
> +

Unfortunately, that didn't work. It exits early when parsing the signature:
I get 0xffdddfdf instead of 0x50444653...

Regards,
Simon

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

Hi,

On Mon, Sep 23, 2019 at 12:49 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> Hi ,
>
> On Mon, Sep 23, 2019 at 11:38 AM <Tudor.Ambarus@microchip.com> wrote:
> >
> > Hi, Simon,
> >
> > On 09/23/2019 12:30 PM, Simon Goldschmidt wrote:
> > > How would I dump the SFDP tables?
> >
> > this should do it. Make sure SPI_FLASH_SFDP_SUPPORT is selected in menuconfig.
> >
> > Cheers,
> > ta
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index 1acff745d1a2..7062f31226bf 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -1680,6 +1680,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
> >         for (i = 0; i < BFPT_DWORD_MAX; i++)
> >                 bfpt.dwords[i] = le32_to_cpu(bfpt.dwords[i]);
> >
> > +       for (i = 0; i < BFPT_DWORD_MAX; i++)
> > +               dev_err(nor->dev, "bfpt.dwords[%d] = %08x\n", i,
> > +                       bfpt.dwords[i]);
> > +
>
> Unfortunately, that didn't work. It exits early when parsing the signature:
> I get 0xffdddfdf instead of 0x50444653...

OK, so after setting cadence qspi driver back to 'spi-rx-bus-width = <1>'
(thanks Vignesh), here's the ID and SFDP dump for my n25q256a:

JEDEC id bytes: 20, ba, 19, 10, 44, 00

bfpt.dwords[0] = fffb20e5
bfpt.dwords[1] = 0fffffff
bfpt.dwords[2] = 6b27eb29
bfpt.dwords[3] = bb273b27
bfpt.dwords[4] = ffffffff
bfpt.dwords[5] = bb27ffff
bfpt.dwords[6] = eb29ffff
bfpt.dwords[7] = d810200c
bfpt.dwords[8] = 0000520f
bfpt.dwords[9] = 00994a24
bfpt.dwords[10] = d4038e8b
bfpt.dwords[11] = 382701ac
bfpt.dwords[12] = 757a757a
bfpt.dwords[13] = 5cd5bdfb
bfpt.dwords[14] = ff820f4a
bfpt.dwords[15] = 363dbd81

Regards,
Simon

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Tudor.Ambarus at microchip.com]

Hi, Simon,

On 09/23/2019 12:30 PM, Simon Goldschmidt wrote:

cut

>>>     > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
>>>     > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
>>>     >
>>>     > Caution: EXT Email
>>>     >
>>>     > Not all variants of n25q256* and n25q512* support 4 Byte stateless
>>>     > addressing opcodes and there is no easy way to discover at runtime
>>>     whether
>>>     > the flash supports this feature or not.
>>>     > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
>>>     Hi Vignesh,
>>>
>>>     I think it will be good to keep it here and disable this for boards
>>>     by using not set flag in config
>>>     Like
>>>     # SPI_NOR_4B_OPCODES is not set
>>>
>>
>> SPI_NOR_4B_OPCODES is not a config option. Are you suggesting to add
>> one? config options don't scale well especially when same defconfig is
>> used for multiple boards that potentially have different flashes
>>
>>>
>>> I'd prefer to take this patch, as this is what Linux does.
>>
>> No, this is not what Linux does. There is no opt-in or opt-out option.
>> Decision to use 4 byte opcode is done at runtime based on flash that's
>> detected. Either based on info->flags for that part or by parsing SFDP
>> table. There is no config option of DT option to force 4 byte addressing
>>
>>> I think it's better to have an opt-in option. That way, all chips work with the
>>> default settings (even if that means some chips don't use 4 baste
>>> opcodes even if they could).
>>>
>>
>> One solution would be to look at SFDP tables of two variants of flash
>> and see if there are any differences that can be used as a clue.
>>
>> Simon,
>> Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
>> flash that you have?
> 
> I have a n251256a with JEDEC ID 20, ba, 19, 10, 44, 00.

Is this a n25q256a or a MT25QL256ABA? We want to check if there are n25q256a
flashes that have the 6th bit of the Extended Device Id set to one or not.
According to n25q256a datasheet the bit 6 is reserved (which probably translates
to being zero), while on MT25QL256ABA is set to one.

Cheers,
ta

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

Hi Tudor,

On Tue, Sep 24, 2019 at 1:36 PM <Tudor.Ambarus@microchip.com> wrote:
>
> Hi, Simon,
>
> On 09/23/2019 12:30 PM, Simon Goldschmidt wrote:
>
> cut
>
> >>>     > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> >>>     > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> >>>     >
> >>>     > Caution: EXT Email
> >>>     >
> >>>     > Not all variants of n25q256* and n25q512* support 4 Byte stateless
> >>>     > addressing opcodes and there is no easy way to discover at runtime
> >>>     whether
> >>>     > the flash supports this feature or not.
> >>>     > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
> >>>     Hi Vignesh,
> >>>
> >>>     I think it will be good to keep it here and disable this for boards
> >>>     by using not set flag in config
> >>>     Like
> >>>     # SPI_NOR_4B_OPCODES is not set
> >>>
> >>
> >> SPI_NOR_4B_OPCODES is not a config option. Are you suggesting to add
> >> one? config options don't scale well especially when same defconfig is
> >> used for multiple boards that potentially have different flashes
> >>
> >>>
> >>> I'd prefer to take this patch, as this is what Linux does.
> >>
> >> No, this is not what Linux does. There is no opt-in or opt-out option.
> >> Decision to use 4 byte opcode is done at runtime based on flash that's
> >> detected. Either based on info->flags for that part or by parsing SFDP
> >> table. There is no config option of DT option to force 4 byte addressing
> >>
> >>> I think it's better to have an opt-in option. That way, all chips work with the
> >>> default settings (even if that means some chips don't use 4 baste
> >>> opcodes even if they could).
> >>>
> >>
> >> One solution would be to look at SFDP tables of two variants of flash
> >> and see if there are any differences that can be used as a clue.
> >>
> >> Simon,
> >> Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
> >> flash that you have?
> >
> > I have a n251256a with JEDEC ID 20, ba, 19, 10, 44, 00.
>
> Is this a n25q256a or a MT25QL256ABA? We want to check if there are n25q256a
> flashes that have the 6th bit of the Extended Device Id set to one or not.
> According to n25q256a datasheet the bit 6 is reserved (which probably translates
> to being zero), while on MT25QL256ABA is set to one.

Right, this really is a MT25QL256ABA, I guess. I'm not quite familiar with the
print on the housing, sorry. We had both and here, it's probably the MT, not
the nq.

I also wasn't really aware of the differences between those two, sorry.

Regards,
Simon

>
> Cheers,
> ta
>

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Vignesh Raghavendra]

Simon,

On 24-Sep-19 5:15 PM, Simon Goldschmidt wrote:
> Hi Tudor,
> 
> On Tue, Sep 24, 2019 at 1:36 PM <Tudor.Ambarus@microchip.com> wrote:
>>
[...]

>>>>
>>>> Simon,
>>>> Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
>>>> flash that you have?
>>>
>>> I have a n251256a with JEDEC ID 20, ba, 19, 10, 44, 00.
>>
>> Is this a n25q256a or a MT25QL256ABA? We want to check if there are n25q256a
>> flashes that have the 6th bit of the Extended Device Id set to one or not.
>> According to n25q256a datasheet the bit 6 is reserved (which probably translates
>> to being zero), while on MT25QL256ABA is set to one.
> 
> Right, this really is a MT25QL256ABA, I guess. I'm not quite familiar with the
> print on the housing, sorry. We had both and here, it's probably the MT, not
> the nq.
> 

But, do you have access to n25q variants? And does that support 4 Byte
addressing opcode? What does its JEDEC ID read?

> I also wasn't really aware of the differences between those two, sorry.
> 
> Regards,
> Simon
> 
>>
>> Cheers,
>> ta
>>

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

Hi Vignesh,

On Tue, Sep 24, 2019 at 1:54 PM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>
> Simon,
>
> On 24-Sep-19 5:15 PM, Simon Goldschmidt wrote:
> > Hi Tudor,
> >
> > On Tue, Sep 24, 2019 at 1:36 PM <Tudor.Ambarus@microchip.com> wrote:
> >>
> [...]
>
> >>>>
> >>>> Simon,
> >>>> Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
> >>>> flash that you have?
> >>>
> >>> I have a n251256a with JEDEC ID 20, ba, 19, 10, 44, 00.
> >>
> >> Is this a n25q256a or a MT25QL256ABA? We want to check if there are n25q256a
> >> flashes that have the 6th bit of the Extended Device Id set to one or not.
> >> According to n25q256a datasheet the bit 6 is reserved (which probably translates
> >> to being zero), while on MT25QL256ABA is set to one.
> >
> > Right, this really is a MT25QL256ABA, I guess. I'm not quite familiar with the
> > print on the housing, sorry. We had both and here, it's probably the MT, not
> > the nq.
> >
>
> But, do you have access to n25q variants? And does that support 4 Byte
> addressing opcode? What does its JEDEC ID read?

No, at the moment I don't. I'll see if I can get hold of one.

Regards,
Simon

>
> > I also wasn't really aware of the differences between those two, sorry.
> >
> > Regards,
> > Simon
> >
> >>
> >> Cheers,
> >> ta
> >>

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

On Tue, Sep 24, 2019 at 2:08 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> Hi Vignesh,
>
> On Tue, Sep 24, 2019 at 1:54 PM Vignesh Raghavendra <vigneshr@ti.com> wrote:
> >
> > Simon,
> >
> > On 24-Sep-19 5:15 PM, Simon Goldschmidt wrote:
> > > Hi Tudor,
> > >
> > > On Tue, Sep 24, 2019 at 1:36 PM <Tudor.Ambarus@microchip.com> wrote:
> > >>
> > [...]
> >
> > >>>>
> > >>>> Simon,
> > >>>> Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
> > >>>> flash that you have?
> > >>>
> > >>> I have a n251256a with JEDEC ID 20, ba, 19, 10, 44, 00.
> > >>
> > >> Is this a n25q256a or a MT25QL256ABA? We want to check if there are n25q256a
> > >> flashes that have the 6th bit of the Extended Device Id set to one or not.
> > >> According to n25q256a datasheet the bit 6 is reserved (which probably translates
> > >> to being zero), while on MT25QL256ABA is set to one.
> > >
> > > Right, this really is a MT25QL256ABA, I guess. I'm not quite familiar with the
> > > print on the housing, sorry. We had both and here, it's probably the MT, not
> > > the nq.
> > >
> >
> > But, do you have access to n25q variants? And does that support 4 Byte
> > addressing opcode? What does its JEDEC ID read?
>
> No, at the moment I don't. I'll see if I can get hold of one.

Ok, so I found a board with an n25q256a and tested that as well as the
Altera/Intel EPCQ256N (on socfpga_socrateds) and both read the same ID and
SFDP:

JEDEC id bytes: 20, ba, 19, 10, 00, 00
bfpt.dwords[0] = fffb20e5
bfpt.dwords[1] = 0fffffff
bfpt.dwords[2] = 6b27eb29
bfpt.dwords[3] = bb273b08
bfpt.dwords[4] = ffffffff
bfpt.dwords[5] = bb27ffff
bfpt.dwords[6] = eb29ffff
bfpt.dwords[7] = d810200c
bfpt.dwords[8] = 00000000
bfpt.dwords[9] = 00000000
bfpt.dwords[10] = 00000000
bfpt.dwords[11] = 00000000
bfpt.dwords[12] = 00000000
bfpt.dwords[13] = 00000000
bfpt.dwords[14] = 00000000
bfpt.dwords[15] = 00000000
SF: Detected n25q256a with page size 256 Bytes, erase size 64 KiB, total 32 MiB

I don't know whether one of these supports 4 byte opcodes, but I guess it's
safe to say the 5th byte 0x44 is an mt25 which supports 4 byte opcodes.

Do you plan to port this series to Linux, too?

Regards,
Simon

>
> Regards,
> Simon
>
> >
> > > I also wasn't really aware of the differences between those two, sorry.
> > >
> > > Regards,
> > > Simon
> > >
> > >>
> > >> Cheers,
> > >> ta
> > >>

[U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Vignesh Raghavendra]

Hi,

On 25/09/19 4:37 PM, Simon Goldschmidt wrote:
> On Tue, Sep 24, 2019 at 2:08 PM Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
>>
[...]
>>>
>>> But, do you have access to n25q variants? And does that support 4 Byte
>>> addressing opcode? What does its JEDEC ID read?
>>
>> No, at the moment I don't. I'll see if I can get hold of one.
> 
> Ok, so I found a board with an n25q256a and tested that as well as the
> Altera/Intel EPCQ256N (on socfpga_socrateds) and both read the same ID and
> SFDP:
> 
> JEDEC id bytes: 20, ba, 19, 10, 00, 00
> bfpt.dwords[0] = fffb20e5
> bfpt.dwords[1] = 0fffffff
> bfpt.dwords[2] = 6b27eb29
> bfpt.dwords[3] = bb273b08
> bfpt.dwords[4] = ffffffff
> bfpt.dwords[5] = bb27ffff
> bfpt.dwords[6] = eb29ffff
> bfpt.dwords[7] = d810200c
> bfpt.dwords[8] = 00000000
> bfpt.dwords[9] = 00000000
> bfpt.dwords[10] = 00000000
> bfpt.dwords[11] = 00000000
> bfpt.dwords[12] = 00000000
> bfpt.dwords[13] = 00000000
> bfpt.dwords[14] = 00000000
> bfpt.dwords[15] = 00000000
> SF: Detected n25q256a with page size 256 Bytes, erase size 64 KiB, total 32 MiB
> 

Thanks for the logs!

> I don't know whether one of these supports 4 byte opcodes, but I guess it's
> safe to say the 5th byte 0x44 is an mt25 which supports 4 byte opcodes.
> 

There is a way to test if flash supports 4 byte addressing opcodes:

With plain U-Boot master (without any of my patches) that has SPI_NOR_4B_OPCODES
set for n25q256a try following:

	sf erase 0x0 0x10000 /* erase one sector at 0x0 */
	sf erase 0x1000000 0x1000 /* erase one sector at 16M */
	sf write <address of random data>  0x1000000 0x100 /* write a page of data at 16M */
	sf read addr1  0x1000000 0x100 /* read back */
	md.b addr1

In case flash does not understand 4 byte addressing opcode, its possible
that data written to flash may wrap and be written to 0x0-0x10000. 
So readback and see if 0x0 is still all 0xffs:

	sf read addr1  0x0 0x100
	md.b addr1

So if first md.b shows valid data and second md.b shows all 0xffs then flash supports 4 byte addressing opcode

Regards
Vignesh

> Do you plan to port this series to Linux, too?
> 
> Regards,
> Simon
> 
>>
>> Regards,
>> Simon
>>
>>>
>>>> I also wasn't really aware of the differences between those two, sorry.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>>
>>>>> Cheers,
>>>>> ta
>>>>>

-- 
Regards
Vignesh