| Message ID | 20190910170621.2064-2-vigneshr@ti.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
| Series | [U-Boot,1/2] spi-nor: spi-nor-ids: Merge "n25q512a" and "mt25qu512a" entries | expand |
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 > <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. 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
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 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@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 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
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 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
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 >
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 >>>>>
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) },