[U-Boot] [PATCH 1/2] spi-nor: spi-nor-ids: Merge "n25q512a" and "mt25qu512a" entries
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) },
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) },
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@lists.denx.de https://lists.denx.de/listinfo/u-boot
-----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@lists.denx.de; Tom Rini trini@konsulko.com; Eugeniy Paltsev Eugeniy.Paltsev@synopsys.com; Alexey.Brodkin@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
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@lists.denx.de; Tom Rini trini@konsulko.com; Eugeniy Paltsev Eugeniy.Paltsev@synopsys.com; Alexey.Brodkin@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@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Ashish, Simon,
On 11/09/19 3:11 PM, Simon Goldschmidt wrote:
Ashish Kumar <ashish.kumar@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@lists.denx.de <mailto:u-boot@lists.denx.de>; Tom > Rini <trini@konsulko.com <mailto:trini@konsulko.com>>; Eugeniy Paltsev > <Eugeniy.Paltsev@synopsys.com <mailto:Eugeniy.Paltsev@synopsys.com>>; Alexey.Brodkin@synopsys.com <mailto:Alexey.Brodkin@synopsys.com>; Ashish > Kumar <ashish.kumar@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@lists.denx.de <mailto:U-Boot@lists.denx.de> https://lists.denx.de/listinfo/u-boot
-----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@lists.denx.de; Alexey.Brodkin@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@nxp.com mailto: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 <mailto:vigneshr@ti.com>>; u-boot@lists.denx.de <mailto:u-boot@lists.denx.de>; Tom > Rini <trini@konsulko.com <mailto:trini@konsulko.com>>; EugeniyPaltsev
> <Eugeniy.Paltsev@synopsys.com <mailto:Eugeniy.Paltsev@synopsys.com>>;Alexey.Brodkin@synopsys.com
<mailto:Alexey.Brodkin@synopsys.com>; Ashish > Kumar <ashish.kumar@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 setSPI_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@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&data=02%7C01%7Cashish.kumar%40nxp.co
m%7C5531cc6a339141ded6cc08d7369fbe9d%7C686ea1d3bc2b4c6fa92cd99c5c 30163
5%7C0%7C0%7C637037932040085697&sdata=1%2BbqG6OBWOLedplM1 19W7E%2Bgp
XlN1wasXZR3AJgzYaM%3D&reserved=0
-- Regards Vignesh
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@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&data=02%7C01%7Cashish.kumar%40nxp.co
m%7C5531cc6a339141ded6cc08d7369fbe9d%7C686ea1d3bc2b4c6fa92cd99c5c 30163
5%7C0%7C0%7C637037932040085697&sdata=1%2BbqG6OBWOLedplM1 19W7E%2Bgp
XlN1wasXZR3AJgzYaM%3D&reserved=0
-- Regards Vignesh
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@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@lists.denx.de <mailto:u-boot@lists.denx.de>; Tom > Rini <trini@konsulko.com <mailto:trini@konsulko.com>>; Eugeniy Paltsev > <Eugeniy.Paltsev@synopsys.com <mailto:Eugeniy.Paltsev@synopsys.com>>; Alexey.Brodkin@synopsys.com <mailto:Alexey.Brodkin@synopsys.com>; Ashish > Kumar <ashish.kumar@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 setSPI_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@lists.denx.de <mailto:U-Boot@lists.denx.de> https://lists.denx.de/listinfo/u-boot-- Regards Vignesh
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]); +
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
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
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 setSPI_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
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 setSPI_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
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
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
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
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
participants (4)
-
Ashish Kumar -
Simon Goldschmidt -
Tudor.Ambarus＠microchip.com -
Vignesh Raghavendra