[U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size
This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.
Changes in v3: - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params
drivers/mtd/spi/sf_internal.h | 5 ++ drivers/mtd/spi/sf_params.c | 185 ++++++++++++++++++++++-------------------- drivers/mtd/spi/sf_probe.c | 4 + 3 files changed, 104 insertions(+), 90 deletions(-)
Update SST25VF064C read command to RD_EXTN per datasheet. Also change flash sector size to 4KiB to match SECT_4K.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_params.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 30875b3..5482700 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = { {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL, WR_QPP | E_FSR | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SST /* SST */ - {"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF080B", 0xbf258e, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF016B", 0xbf2541, 0x0, 64 * 1024, 32, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF032B", 0xbf254a, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF064C", 0xbf254b, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, - {"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF040B", 0xbf258d, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF080B", 0xbf258e, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF016B", 0xbf2541, 0x0, 4 * 1024, 512, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF032B", 0xbf254a, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF064C", 0xbf254b, 0x0, 4 * 1024, 2048, RD_EXTN, SECT_4K}, + {"SST25WF512", 0xbf2501, 0x0, 4 * 1024, 16, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF010", 0xbf2502, 0x0, 4 * 1024, 32, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF020", 0xbf2503, 0x0, 4 * 1024, 64, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF040", 0xbf2504, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF080", 0xbf2505, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR}, #endif #ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0},
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't * necessarily called a "sector" by the vendor. */ Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.
Linux does follow the same- /* SST -- large erase sizes are "overlays", "sectors" are 4K */ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) }, { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) }, { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
Please check it.
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
Update SST25VF064C read command to RD_EXTN per datasheet. Also change flash sector size to 4KiB to match SECT_4K.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_params.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 30875b3..5482700 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = { {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL, WR_QPP | E_FSR | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SST /* SST */
{"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR},{"SST25VF080B", 0xbf258e, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},{"SST25VF016B", 0xbf2541, 0x0, 64 * 1024, 32, RD_NORM, SECT_4K | SST_WR},{"SST25VF032B", 0xbf254a, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K | SST_WR},{"SST25VF064C", 0xbf254b, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K},{"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, RD_NORM, SECT_4K | SST_WR},{"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, RD_NORM, SECT_4K | SST_WR},{"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, RD_NORM, SECT_4K | SST_WR},{"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR},{"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
{"SST25VF040B", 0xbf258d, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR},{"SST25VF080B", 0xbf258e, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR},{"SST25VF016B", 0xbf2541, 0x0, 4 * 1024, 512, RD_NORM, SECT_4K | SST_WR},{"SST25VF032B", 0xbf254a, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K | SST_WR},{"SST25VF064C", 0xbf254b, 0x0, 4 * 1024, 2048, RD_EXTN, SECT_4K},{"SST25WF512", 0xbf2501, 0x0, 4 * 1024, 16, RD_NORM, SECT_4K | SST_WR},{"SST25WF010", 0xbf2502, 0x0, 4 * 1024, 32, RD_NORM, SECT_4K | SST_WR},{"SST25WF020", 0xbf2503, 0x0, 4 * 1024, 64, RD_NORM, SECT_4K | SST_WR},{"SST25WF040", 0xbf2504, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR},{"SST25WF080", 0xbf2505, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR},#endif #ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0}, -- 1.8.2.1
thanks!
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
- necessarily called a "sector" by the vendor.
*/ Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.
Linux does follow the same- /* SST -- large erase sizes are "overlays", "sectors" are 4K */ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) }, { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) }, { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
Please check it.
Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
Update SST25VF064C read command to RD_EXTN per datasheet. Also change flash sector size to 4KiB to match SECT_4K.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_params.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 30875b3..5482700 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = { {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL, WR_QPP | E_FSR | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SST /* SST */
{"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR},{"SST25VF080B", 0xbf258e, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},{"SST25VF016B", 0xbf2541, 0x0, 64 * 1024, 32, RD_NORM, SECT_4K | SST_WR},{"SST25VF032B", 0xbf254a, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K | SST_WR},{"SST25VF064C", 0xbf254b, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K},{"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, RD_NORM, SECT_4K | SST_WR},{"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, RD_NORM, SECT_4K | SST_WR},{"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, RD_NORM, SECT_4K | SST_WR},{"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR},{"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
{"SST25VF040B", 0xbf258d, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR},{"SST25VF080B", 0xbf258e, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR},{"SST25VF016B", 0xbf2541, 0x0, 4 * 1024, 512, RD_NORM, SECT_4K | SST_WR},{"SST25VF032B", 0xbf254a, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K | SST_WR},{"SST25VF064C", 0xbf254b, 0x0, 4 * 1024, 2048, RD_EXTN, SECT_4K},{"SST25WF512", 0xbf2501, 0x0, 4 * 1024, 16, RD_NORM, SECT_4K | SST_WR},{"SST25WF010", 0xbf2502, 0x0, 4 * 1024, 32, RD_NORM, SECT_4K | SST_WR},{"SST25WF020", 0xbf2503, 0x0, 4 * 1024, 64, RD_NORM, SECT_4K | SST_WR},{"SST25WF040", 0xbf2504, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR},{"SST25WF080", 0xbf2505, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR},#endif #ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0}, --
Regards, Bin
Hi Bin,
On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
- necessarily called a "sector" by the vendor.
*/ Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.
Linux does follow the same- /* SST -- large erase sizes are "overlays", "sectors" are 4K */ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) }, { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) }, { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
Please check it.
Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.
It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use. /* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096 << flash->shift; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768 << flash->shift; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }
And to be honest, these flashes were tested with lowest ie 4KB so even if they do support 64KB, we mentioned on 4KB on 'params->flags' as we tested well with that and it works consistently.
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
Update SST25VF064C read command to RD_EXTN per datasheet. Also change flash sector size to 4KiB to match SECT_4K.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_params.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 30875b3..5482700 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] = { {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL, WR_QPP | E_FSR | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SST /* SST */
{"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR},{"SST25VF080B", 0xbf258e, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},{"SST25VF016B", 0xbf2541, 0x0, 64 * 1024, 32, RD_NORM, SECT_4K | SST_WR},{"SST25VF032B", 0xbf254a, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K | SST_WR},{"SST25VF064C", 0xbf254b, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K},{"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, RD_NORM, SECT_4K | SST_WR},{"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, RD_NORM, SECT_4K | SST_WR},{"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, RD_NORM, SECT_4K | SST_WR},{"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K | SST_WR},{"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
{"SST25VF040B", 0xbf258d, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR},{"SST25VF080B", 0xbf258e, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR},{"SST25VF016B", 0xbf2541, 0x0, 4 * 1024, 512, RD_NORM, SECT_4K | SST_WR},{"SST25VF032B", 0xbf254a, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K | SST_WR},{"SST25VF064C", 0xbf254b, 0x0, 4 * 1024, 2048, RD_EXTN, SECT_4K},{"SST25WF512", 0xbf2501, 0x0, 4 * 1024, 16, RD_NORM, SECT_4K | SST_WR},{"SST25WF010", 0xbf2502, 0x0, 4 * 1024, 32, RD_NORM, SECT_4K | SST_WR},{"SST25WF020", 0xbf2503, 0x0, 4 * 1024, 64, RD_NORM, SECT_4K | SST_WR},{"SST25WF040", 0xbf2504, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR},{"SST25WF080", 0xbf2505, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR},#endif #ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0}, --
thanks!
Hi Jagan,
On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
- necessarily called a "sector" by the vendor.
*/ Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.
Linux does follow the same- /* SST -- large erase sizes are "overlays", "sectors" are 4K */ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) }, { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) }, { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
Please check it.
Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.
It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.
No, it is related. See cmd_sf.c:
static int sf_parse_len_arg(char *arg, ulong *len) { char *ep; char round_up_len; /* indicates if the "+length" form used */ ulong len_arg;
round_up_len = 0; if (*arg == '+') { round_up_len = 1; ++arg; }
len_arg = simple_strtoul(arg, &ep, 16); if (ep == arg || *ep != '\0') return -1;
if (round_up_len && flash->sector_size > 0) *len = ROUND(len_arg, flash->sector_size); else *len = len_arg;
return 1; }
So even you are passing 4KB in the flash params, the 'sf erase' command WILL erase 64KB.
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096 << flash->shift; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768 << flash->shift; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }And to be honest, these flashes were tested with lowest ie 4KB so even if they do support 64KB, we mentioned on 4KB on 'params->flags' as we tested well with that and it works consistently.
Regards, Bin
Hi Bin,
On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
- necessarily called a "sector" by the vendor.
*/ Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.
Linux does follow the same- /* SST -- large erase sizes are "overlays", "sectors" are 4K */ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) }, { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) }, { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
Please check it.
Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.
It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.
No, it is related. See cmd_sf.c:
I'm not getting your point- how could it erase use 64K sector size instead of 4K.
Suppose the sector size is 4K
flash->sector_size = 0x1000 1. erase 4K len flash (it's total erase length)
# sf erase 0x0 0x1000
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1000
*len becomes 0x1000
2. erase 4K+1 len flash
# sf erase 0x0 +0x1001
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1001
*len becomes 0x2000
All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.
static int sf_parse_len_arg(char *arg, ulong *len) { char *ep; char round_up_len; /* indicates if the "+length" form used */ ulong len_arg;
round_up_len = 0; if (*arg == '+') { round_up_len = 1; ++arg; } len_arg = simple_strtoul(arg, &ep, 16); if (ep == arg || *ep != '\0') return -1; if (round_up_len && flash->sector_size > 0) *len = ROUND(len_arg, flash->sector_size); else *len = len_arg; return 1;}
So even you are passing 4KB in the flash params, the 'sf erase' command WILL erase 64KB.
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096 << flash->shift; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768 << flash->shift; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }And to be honest, these flashes were tested with lowest ie 4KB so even if they do support 64KB, we mentioned on 4KB on 'params->flags' as we tested well with that and it works consistently.
thanks!
Hi Jagan,
On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
- necessarily called a "sector" by the vendor.
*/ Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.
Linux does follow the same- /* SST -- large erase sizes are "overlays", "sectors" are 4K */ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) }, { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) }, { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
Please check it.
Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.
It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.
No, it is related. See cmd_sf.c:
I'm not getting your point- how could it erase use 64K sector size instead of 4K.
It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().
Suppose the sector size is 4K
flash->sector_size = 0x1000
- erase 4K len flash (it's total erase length)
# sf erase 0x0 0x1000
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1000
*len becomes 0x1000
- erase 4K+1 len flash
# sf erase 0x0 +0x1001
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1001
*len becomes 0x2000
All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.
Regards, Bin
Hi Bin,
On 22 April 2015 at 12:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
I think you have a different interpretation of sector size here-
/* The size listed here is what works with SPINOR_OP_SE, which isn't
- necessarily called a "sector" by the vendor.
*/ Say for example SST25VF040B has 8 sectors of which each sector size is 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or 64K sector erase through flags.
Linux does follow the same- /* SST -- large erase sizes are "overlays", "sectors" are 4K */ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | SST_WRITE) }, { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) }, { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) }, { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
Please check it.
Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.
It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.
No, it is related. See cmd_sf.c:
I'm not getting your point- how could it erase use 64K sector size instead of 4K.
It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().
We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }
Suppose the sector size is 4K
flash->sector_size = 0x1000
- erase 4K len flash (it's total erase length)
# sf erase 0x0 0x1000
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1000
*len becomes 0x1000
- erase 4K+1 len flash
# sf erase 0x0 +0x1001
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1001
*len becomes 0x2000
All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.
thanks!
Hi Jagan,
On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote: > Hi Bin, > > I think you have a different interpretation of sector size here- > > /* The size listed here is what works with SPINOR_OP_SE, which isn't > * necessarily called a "sector" by the vendor. > */ > Say for example SST25VF040B has 8 sectors of which each sector size is > 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or > 64K sector erase through flags. > > Linux does follow the same- > /* SST -- large erase sizes are "overlays", "sectors" are 4K */ > { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | > SST_WRITE) }, > { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | > SST_WRITE) }, > { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | > SST_WRITE) }, > { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | > SST_WRITE) }, > > Please check it.
Yes, I know this pretty well. And I want to change this behavior, as my cover letter says.
Currently the 'sf erase' command operates on a 64KB granularity, while the actual erase command is 4KB granularity, which is inconsistent and causes confusion.
It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.
No, it is related. See cmd_sf.c:
I'm not getting your point- how could it erase use 64K sector size instead of 4K.
It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().
We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.
You previous email already said: the 'sf erase' command depends on *flash->sector_size*
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }
Here the codes says: *flash->erase_size*
So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
Suppose the sector size is 4K
flash->sector_size = 0x1000
- erase 4K len flash (it's total erase length)
# sf erase 0x0 0x1000
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1000
*len becomes 0x1000
- erase 4K+1 len flash
# sf erase 0x0 +0x1001
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1001
*len becomes 0x2000
All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.
thanks!
Regards, Bin
Hi Bin,
On 22 April 2015 at 12:44, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >> Hi Bin, >> >> I think you have a different interpretation of sector size here- >> >> /* The size listed here is what works with SPINOR_OP_SE, which isn't >> * necessarily called a "sector" by the vendor. >> */ >> Say for example SST25VF040B has 8 sectors of which each sector size is >> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or >> 64K sector erase through flags. >> >> Linux does follow the same- >> /* SST -- large erase sizes are "overlays", "sectors" are 4K */ >> { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | >> SST_WRITE) }, >> { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | >> SST_WRITE) }, >> { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | >> SST_WRITE) }, >> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | >> SST_WRITE) }, >> >> Please check it. > > > Yes, I know this pretty well. And I want to change this behavior, as > my cover letter says. > > Currently the 'sf erase' command operates on a 64KB granularity, while > the actual erase command is 4KB granularity, which is inconsistent and > causes confusion.
It never related to 'sf erase' instead based on the 'params->flags' sf_probe will decide which erase_cmd with erase_size will use.
No, it is related. See cmd_sf.c:
I'm not getting your point- how could it erase use 64K sector size instead of 4K.
It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().
We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.
You previous email already said: the 'sf erase' command depends on *flash->sector_size*
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }Here the codes says: *flash->erase_size*
So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 4096
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 64 * 1024
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
Still have any concerns, please come to IRC for more discussion
Suppose the sector size is 4K
flash->sector_size = 0x1000
- erase 4K len flash (it's total erase length)
# sf erase 0x0 0x1000
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1000
*len becomes 0x1000
- erase 4K+1 len flash
# sf erase 0x0 +0x1001
len_arg = simple_strtoul(arg, &ep, 16); gives - 0x1001
*len becomes 0x2000
All the way when it goes to sf_ops.c erase will take by means of erase_size which is assigned in sf_probe.c based on flags like 4K 32K or 64K.
thanks!
Hi Jagan,
On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:44, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote: > Hi Bin, > > On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>> Hi Bin, >>> >>> I think you have a different interpretation of sector size here- >>> >>> /* The size listed here is what works with SPINOR_OP_SE, which isn't >>> * necessarily called a "sector" by the vendor. >>> */ >>> Say for example SST25VF040B has 8 sectors of which each sector size is >>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or >>> 64K sector erase through flags. >>> >>> Linux does follow the same- >>> /* SST -- large erase sizes are "overlays", "sectors" are 4K */ >>> { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | >>> SST_WRITE) }, >>> { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | >>> SST_WRITE) }, >>> { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | >>> SST_WRITE) }, >>> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | >>> SST_WRITE) }, >>> >>> Please check it. >> >> >> Yes, I know this pretty well. And I want to change this behavior, as >> my cover letter says. >> >> Currently the 'sf erase' command operates on a 64KB granularity, while >> the actual erase command is 4KB granularity, which is inconsistent and >> causes confusion. > > It never related to 'sf erase' instead based on the 'params->flags' > sf_probe will decide which erase_cmd with erase_size will use.
No, it is related. See cmd_sf.c:
I'm not getting your point- how could it erase use 64K sector size instead of 4K.
It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().
We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.
You previous email already said: the 'sf erase' command depends on *flash->sector_size*
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }Here the codes says: *flash->erase_size*
So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 4096
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
sf erase 0 +100. Sorry for the typo. But looks like you are not really reading the codes.
=> sf probe SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB, mapped at ffe00000
=> sf erase 0 +100 SF: 65536 bytes @ 0x0 Erased: OK
Tested on two boards, and both shows 64K was erased.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 64 * 1024
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
Still have any concerns, please come to IRC for more discussion
Regards, Bin
Hi Bin,
On 22 April 2015 at 14:13, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:44, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >> Hi Bin, >> >> On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote: >>> Hi Jagan, >>> >>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>> Hi Bin, >>>> >>>> I think you have a different interpretation of sector size here- >>>> >>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't >>>> * necessarily called a "sector" by the vendor. >>>> */ >>>> Say for example SST25VF040B has 8 sectors of which each sector size is >>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or >>>> 64K sector erase through flags. >>>> >>>> Linux does follow the same- >>>> /* SST -- large erase sizes are "overlays", "sectors" are 4K */ >>>> { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | >>>> SST_WRITE) }, >>>> { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | >>>> SST_WRITE) }, >>>> { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | >>>> SST_WRITE) }, >>>> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | >>>> SST_WRITE) }, >>>> >>>> Please check it. >>> >>> >>> Yes, I know this pretty well. And I want to change this behavior, as >>> my cover letter says. >>> >>> Currently the 'sf erase' command operates on a 64KB granularity, while >>> the actual erase command is 4KB granularity, which is inconsistent and >>> causes confusion. >> >> It never related to 'sf erase' instead based on the 'params->flags' >> sf_probe will decide which erase_cmd with erase_size will use. > > No, it is related. See cmd_sf.c:
I'm not getting your point- how could it erase use 64K sector size instead of 4K.
It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().
We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.
You previous email already said: the 'sf erase' command depends on *flash->sector_size*
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }Here the codes says: *flash->erase_size*
So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 4096
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
sf erase 0 +100. Sorry for the typo. But looks like you are not really reading the codes.
Worked on too-many overclocked issue, sorry for that.
So, something fixed in sf_probe.c will fix this I guess.
=> sf probe SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB, mapped at ffe00000
=> sf erase 0 +100 SF: 65536 bytes @ 0x0 Erased: OK
Tested on two boards, and both shows 64K was erased.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 64 * 1024
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
Still have any concerns, please come to IRC for more discussion
thanks!
Hi Jagan,
On Wed, Apr 22, 2015 at 5:15 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 14:13, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:44, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote: > Hi Bin, > > On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>> Hi Bin, >>> >>> On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote: >>>> Hi Jagan, >>>> >>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>> Hi Bin, >>>>> >>>>> I think you have a different interpretation of sector size here- >>>>> >>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't >>>>> * necessarily called a "sector" by the vendor. >>>>> */ >>>>> Say for example SST25VF040B has 8 sectors of which each sector size is >>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or >>>>> 64K sector erase through flags. >>>>> >>>>> Linux does follow the same- >>>>> /* SST -- large erase sizes are "overlays", "sectors" are 4K */ >>>>> { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | >>>>> SST_WRITE) }, >>>>> { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | >>>>> SST_WRITE) }, >>>>> { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | >>>>> SST_WRITE) }, >>>>> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | >>>>> SST_WRITE) }, >>>>> >>>>> Please check it. >>>> >>>> >>>> Yes, I know this pretty well. And I want to change this behavior, as >>>> my cover letter says. >>>> >>>> Currently the 'sf erase' command operates on a 64KB granularity, while >>>> the actual erase command is 4KB granularity, which is inconsistent and >>>> causes confusion. >>> >>> It never related to 'sf erase' instead based on the 'params->flags' >>> sf_probe will decide which erase_cmd with erase_size will use. >> >> No, it is related. See cmd_sf.c: > > I'm not getting your point- how could it erase use 64K sector size > instead of 4K.
It indeed erases 64K sector size. You need check the logic in spi_flash_validate_params().
We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.
You previous email already said: the 'sf erase' command depends on *flash->sector_size*
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }Here the codes says: *flash->erase_size*
So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 4096
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
sf erase 0 +100. Sorry for the typo. But looks like you are not really reading the codes.
Worked on too-many overclocked issue, sorry for that.
So, something fixed in sf_probe.c will fix this I guess.
Good, you finally got it! So you prefer fixing this inconsistency in sf_probe.c? I guess by overriding flash->sector_size and flash->nr_sectors if SECT_4K?
=> sf probe SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB, mapped at ffe00000
=> sf erase 0 +100 SF: 65536 bytes @ 0x0 Erased: OK
Tested on two boards, and both shows 64K was erased.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 64 * 1024
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
Still have any concerns, please come to IRC for more discussion
As you see I have rebased this patch once for v2/v3 and lots of effort were spent on this series. I remember you said this patch series needs some testing on your side, but this comment shows that you may want to do it in another way. I really hope such comments could be sent months ago. Today I can't even remember all of the details in this series. Luckily I don't lose interest to get this upstream so I kept asking for an update.
Regards, Bin
Hi Bin,
On 22 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 5:15 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 14:13, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 4:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:44, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Apr 22, 2015 at 3:03 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 22 April 2015 at 12:14, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >> Hi Bin, >> >> On 20 April 2015 at 15:02, Bin Meng bmeng.cn@gmail.com wrote: >>> Hi Jagan, >>> >>> On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>> Hi Bin, >>>> >>>> On 17 April 2015 at 07:14, Bin Meng bmeng.cn@gmail.com wrote: >>>>> Hi Jagan, >>>>> >>>>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>> Hi Bin, >>>>>> >>>>>> I think you have a different interpretation of sector size here- >>>>>> >>>>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't >>>>>> * necessarily called a "sector" by the vendor. >>>>>> */ >>>>>> Say for example SST25VF040B has 8 sectors of which each sector size is >>>>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or >>>>>> 64K sector erase through flags. >>>>>> >>>>>> Linux does follow the same- >>>>>> /* SST -- large erase sizes are "overlays", "sectors" are 4K */ >>>>>> { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K | >>>>>> SST_WRITE) }, >>>>>> { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | >>>>>> SST_WRITE) }, >>>>>> { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | >>>>>> SST_WRITE) }, >>>>>> { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | >>>>>> SST_WRITE) }, >>>>>> >>>>>> Please check it. >>>>> >>>>> >>>>> Yes, I know this pretty well. And I want to change this behavior, as >>>>> my cover letter says. >>>>> >>>>> Currently the 'sf erase' command operates on a 64KB granularity, while >>>>> the actual erase command is 4KB granularity, which is inconsistent and >>>>> causes confusion. >>>> >>>> It never related to 'sf erase' instead based on the 'params->flags' >>>> sf_probe will decide which erase_cmd with erase_size will use. >>> >>> No, it is related. See cmd_sf.c: >> >> I'm not getting your point- how could it erase use 64K sector size >> instead of 4K. > > It indeed erases 64K sector size. You need check the logic in > spi_flash_validate_params().
We're assigning erase_size to sector_size only when SECT_4K and SECT_32K and for these erase_size becomes direct values, please check this.
You previous email already said: the 'sf erase' command depends on *flash->sector_size*
/* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; flash->erase_size = 4096; } else if (params->flags & SECT_32K) { flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768; } else { flash->erase_cmd = CMD_ERASE_64K; flash->erase_size = flash->sector_size; }Here the codes says: *flash->erase_size*
So when I give a 'sf erase 0 100' it erase 64KB even if you have SECT_4K.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K | SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 4096
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
sf erase 0 +100. Sorry for the typo. But looks like you are not really reading the codes.
Worked on too-many overclocked issue, sorry for that.
So, something fixed in sf_probe.c will fix this I guess.
Good, you finally got it! So you prefer fixing this inconsistency in sf_probe.c? I guess by overriding flash->sector_size and flash->nr_sectors if SECT_4K?
I'm posting patch.
=> sf probe SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB, mapped at ffe00000
=> sf erase 0 +100 SF: 65536 bytes @ 0x0 Erased: OK
Tested on two boards, and both shows 64K was erased.
Example: "SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, RD_NORM, SST_WR},
sf probe gives sector_size = 64 * 1024 and erase_size = 64 * 1024
sf erase 0 100 sf_parse_len_arg len returns 100 and spi_flash_cmd_erase_ops returns "SF: Erase offset/length not multiple of erase size"
Still have any concerns, please come to IRC for more discussion
As you see I have rebased this patch once for v2/v3 and lots of effort were spent on this series. I remember you said this patch series needs some testing on your side, but this comment shows that you may want to do it in another way. I really hope such comments could be sent months ago. Today I can't even remember all of the details in this series. Luckily I don't lose interest to get this upstream so I kept asking for an update.
Yes - I did some testing for Micron patch at-least and even I post the comment for the same. I have a plan to test the remaining patches as well and in-fact these questions I got it from sst patch(this patch). I agree some delay in my side but as these are core changes and I need to see each and test them respectively, that is my main Job. I'm very much thankful to you for keeping me updates.
thanks!
Update flash sector size to 4KiB as long as flash supports sector erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase command to 50h instead of D8h. Also add AT25DF321A params per datasheet.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_internal.h | 5 +++++ drivers/mtd/spi/sf_params.c | 17 +++++++++-------- drivers/mtd/spi/sf_probe.c | 4 ++++ 3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h index 785f7a9..8010fc5 100644 --- a/drivers/mtd/spi/sf_internal.h +++ b/drivers/mtd/spi/sf_internal.h @@ -106,6 +106,11 @@ enum { #define SPI_FLASH_PAGE_ERASE_TIMEOUT (5 * CONFIG_SYS_HZ) #define SPI_FLASH_SECTOR_ERASE_TIMEOUT (10 * CONFIG_SYS_HZ)
+/* Atmel specific */ +#ifdef CONFIG_SPI_FLASH_ATMEL +# define CMD_ATMEL_BLK_ERASE 0x50 +#endif + /* SST specific */ #ifdef CONFIG_SPI_FLASH_SST # define CMD_SST_BP 0x02 /* Byte Program */ diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 5482700..cc4cd60 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -15,14 +15,15 @@ /* SPI/QSPI flash device params structure */ const struct spi_flash_params spi_flash_params_table[] = { #ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */ - {"AT45DB011D", 0x1f2200, 0x0, 64 * 1024, 4, RD_NORM, SECT_4K}, - {"AT45DB021D", 0x1f2300, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K}, - {"AT45DB041D", 0x1f2400, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K}, - {"AT45DB081D", 0x1f2500, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K}, - {"AT45DB161D", 0x1f2600, 0x0, 64 * 1024, 32, RD_NORM, SECT_4K}, - {"AT45DB321D", 0x1f2700, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K}, - {"AT45DB641D", 0x1f2800, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, - {"AT25DF321", 0x1f4701, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K}, + {"AT45DB011D", 0x1f2200, 0x0, 2 * 1024, 64, RD_NORM, 0}, + {"AT45DB021D", 0x1f2300, 0x0, 2 * 1024, 128, RD_NORM, 0}, + {"AT45DB041D", 0x1f2400, 0x0, 2 * 1024, 256, RD_NORM, 0}, + {"AT45DB081D", 0x1f2500, 0x0, 2 * 1024, 512, RD_NORM, 0}, + {"AT45DB161D", 0x1f2600, 0x0, 4 * 1024, 512, RD_NORM, 0}, + {"AT45DB321D", 0x1f2700, 0x0, 4 * 1024, 1024, RD_NORM, 0}, + {"AT45DB641D", 0x1f2800, 0x0, 2 * 1024, 4096, RD_NORM, 0}, + {"AT25DF321", 0x1f4700, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, + {"AT25DF321A", 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_EON /* EON */ {"EN25Q32B", 0x1c3016, 0x0, 64 * 1024, 64, RD_NORM, 0}, diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c index ce9987f..13fda44 100644 --- a/drivers/mtd/spi/sf_probe.c +++ b/drivers/mtd/spi/sf_probe.c @@ -179,7 +179,11 @@ static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode, flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768 << flash->shift; } else { +#ifdef CONFIG_SPI_FLASH_ATMEL + flash->erase_cmd = CMD_ATMEL_BLK_ERASE; +#else flash->erase_cmd = CMD_ERASE_64K; +#endif flash->erase_size = flash->sector_size; }
Hi Meng,
On 12/10/2014 08:51 PM, Bin Meng wrote:
Update flash sector size to 4KiB as long as flash supports sector erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase command to 50h instead of D8h. Also add AT25DF321A params per datasheet.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_internal.h | 5 +++++ drivers/mtd/spi/sf_params.c | 17 +++++++++-------- drivers/mtd/spi/sf_probe.c | 4 ++++ 3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h index 785f7a9..8010fc5 100644 --- a/drivers/mtd/spi/sf_internal.h +++ b/drivers/mtd/spi/sf_internal.h @@ -106,6 +106,11 @@ enum { #define SPI_FLASH_PAGE_ERASE_TIMEOUT (5 * CONFIG_SYS_HZ) #define SPI_FLASH_SECTOR_ERASE_TIMEOUT (10 * CONFIG_SYS_HZ)
+/* Atmel specific */ +#ifdef CONFIG_SPI_FLASH_ATMEL +# define CMD_ATMEL_BLK_ERASE 0x50 +#endif
- /* SST specific */ #ifdef CONFIG_SPI_FLASH_SST # define CMD_SST_BP 0x02 /* Byte Program */
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 5482700..cc4cd60 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -15,14 +15,15 @@ /* SPI/QSPI flash device params structure */ const struct spi_flash_params spi_flash_params_table[] = { #ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */
- {"AT45DB011D", 0x1f2200, 0x0, 64 * 1024, 4, RD_NORM, SECT_4K},
- {"AT45DB021D", 0x1f2300, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K},
- {"AT45DB041D", 0x1f2400, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K},
- {"AT45DB081D", 0x1f2500, 0x0, 64 * 1024, 16, RD_NORM, SECT_4K},
- {"AT45DB161D", 0x1f2600, 0x0, 64 * 1024, 32, RD_NORM, SECT_4K},
- {"AT45DB321D", 0x1f2700, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K},
- {"AT45DB641D", 0x1f2800, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K},
- {"AT25DF321", 0x1f4701, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K},
- {"AT45DB011D", 0x1f2200, 0x0, 2 * 1024, 64, RD_NORM, 0},
- {"AT45DB021D", 0x1f2300, 0x0, 2 * 1024, 128, RD_NORM, 0},
- {"AT45DB041D", 0x1f2400, 0x0, 2 * 1024, 256, RD_NORM, 0},
- {"AT45DB081D", 0x1f2500, 0x0, 2 * 1024, 512, RD_NORM, 0},
- {"AT45DB161D", 0x1f2600, 0x0, 4 * 1024, 512, RD_NORM, 0},
- {"AT45DB321D", 0x1f2700, 0x0, 4 * 1024, 1024, RD_NORM, 0},
In datasheet, the id is 0x1f2701. Doc number is: 3597Q-DFLASH-6/11. I can not find any new datasheet.
And I test on at91sam9m10g45ek board, it also read as this ID (0x1f2701).
So, if you plan to send new version, can you help add this ID? If not, maybe follow up patch will be better.
Thanks.
- {"AT45DB641D", 0x1f2800, 0x0, 2 * 1024, 4096, RD_NORM, 0},
- {"AT25DF321", 0x1f4700, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K},
- {"AT25DF321A", 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_EON /* EON */ {"EN25Q32B", 0x1c3016, 0x0, 64 * 1024, 64, RD_NORM, 0},
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c index ce9987f..13fda44 100644 --- a/drivers/mtd/spi/sf_probe.c +++ b/drivers/mtd/spi/sf_probe.c @@ -179,7 +179,11 @@ static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode, flash->erase_cmd = CMD_ERASE_32K; flash->erase_size = 32768 << flash->shift; } else { +#ifdef CONFIG_SPI_FLASH_ATMEL
flash->erase_cmd = CMD_ATMEL_BLK_ERASE;+#else flash->erase_cmd = CMD_ERASE_64K; +#endif flash->erase_size = flash->sector_size; }
Best Regards, Bo Shen
Hi Bo,
On Fri, Jan 9, 2015 at 5:27 PM, Bo Shen voice.shen@atmel.com wrote:
Hi Meng,
On 12/10/2014 08:51 PM, Bin Meng wrote:
Update flash sector size to 4KiB as long as flash supports sector erase (20h) command. Correct AT25DF321 JEDEC ID and bulk erase command to 50h instead of D8h. Also add AT25DF321A params per datasheet.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_internal.h | 5 +++++ drivers/mtd/spi/sf_params.c | 17 +++++++++-------- drivers/mtd/spi/sf_probe.c | 4 ++++ 3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h index 785f7a9..8010fc5 100644 --- a/drivers/mtd/spi/sf_internal.h +++ b/drivers/mtd/spi/sf_internal.h @@ -106,6 +106,11 @@ enum { #define SPI_FLASH_PAGE_ERASE_TIMEOUT (5 * CONFIG_SYS_HZ) #define SPI_FLASH_SECTOR_ERASE_TIMEOUT (10 * CONFIG_SYS_HZ)
+/* Atmel specific */ +#ifdef CONFIG_SPI_FLASH_ATMEL +# define CMD_ATMEL_BLK_ERASE 0x50 +#endif
- /* SST specific */ #ifdef CONFIG_SPI_FLASH_SST # define CMD_SST_BP 0x02 /* Byte Program */
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 5482700..cc4cd60 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -15,14 +15,15 @@ /* SPI/QSPI flash device params structure */ const struct spi_flash_params spi_flash_params_table[] = { #ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */
{"AT45DB011D", 0x1f2200, 0x0, 64 * 1024, 4, RD_NORM,SECT_4K},
{"AT45DB021D", 0x1f2300, 0x0, 64 * 1024, 8, RD_NORM,SECT_4K},
{"AT45DB041D", 0x1f2400, 0x0, 64 * 1024, 8, RD_NORM,SECT_4K},
{"AT45DB081D", 0x1f2500, 0x0, 64 * 1024, 16, RD_NORM,SECT_4K},
{"AT45DB161D", 0x1f2600, 0x0, 64 * 1024, 32, RD_NORM,SECT_4K},
{"AT45DB321D", 0x1f2700, 0x0, 64 * 1024, 64, RD_NORM,SECT_4K},
{"AT45DB641D", 0x1f2800, 0x0, 64 * 1024, 128, RD_NORM,SECT_4K},
{"AT25DF321", 0x1f4701, 0x0, 64 * 1024, 64, RD_NORM,SECT_4K},
{"AT45DB011D", 0x1f2200, 0x0, 2 * 1024, 64, RD_NORM,0},
{"AT45DB021D", 0x1f2300, 0x0, 2 * 1024, 128, RD_NORM,0},
{"AT45DB041D", 0x1f2400, 0x0, 2 * 1024, 256, RD_NORM,0},
{"AT45DB081D", 0x1f2500, 0x0, 2 * 1024, 512, RD_NORM,0},
{"AT45DB161D", 0x1f2600, 0x0, 4 * 1024, 512, RD_NORM,0},
{"AT45DB321D", 0x1f2700, 0x0, 4 * 1024, 1024, RD_NORM,0},
In datasheet, the id is 0x1f2701. Doc number is: 3597Q-DFLASH-6/11. I can not find any new datasheet.
And I test on at91sam9m10g45ek board, it also read as this ID (0x1f2701).
So, if you plan to send new version, can you help add this ID? If not, maybe follow up patch will be better.
Yes, I do plan to send a new version. However I am still waiting for Jagan's testing results of this patch series. I checked the AT45DB321D datasheet, the flash ID is indeed 0x1f2701. So the original value on the params table is wrong. I will fix this in the v4 patch.
[snip]
Regards, Bin
Update supported read commands for EON flash parts to RD_EXTN and QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_params.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index cc4cd60..3e5c6e0 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = { {"AT25DF321A", 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_EON /* EON */ - {"EN25Q32B", 0x1c3016, 0x0, 64 * 1024, 64, RD_NORM, 0}, - {"EN25Q64", 0x1c3017, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, - {"EN25Q128B", 0x1c3018, 0x0, 64 * 1024, 256, RD_NORM, 0}, - {"EN25S64", 0x1c3817, 0x0, 64 * 1024, 128, RD_NORM, 0}, + {"EN25Q32B", 0x1c3016, 0x0, 4 * 1024, 1024, RD_EXTN | QUAD_IO_FAST, SECT_4K}, + {"EN25Q64", 0x1c3017, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K}, + {"EN25Q128B", 0x1c3018, 0x0, 4 * 1024, 4096, RD_EXTN | QUAD_IO_FAST, SECT_4K}, + {"EN25S64", 0x1c3817, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */ {"GD25Q64B", 0xc84017, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K},
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
Update supported read commands for EON flash parts to RD_EXTN and QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_params.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index cc4cd60..3e5c6e0 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = { {"AT25DF321A", 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_EON /* EON */
{"EN25Q32B", 0x1c3016, 0x0, 64 * 1024, 64, RD_NORM, 0},{"EN25Q64", 0x1c3017, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K},{"EN25Q128B", 0x1c3018, 0x0, 64 * 1024, 256, RD_NORM, 0},{"EN25S64", 0x1c3817, 0x0, 64 * 1024, 128, RD_NORM, 0},
{"EN25Q32B", 0x1c3016, 0x0, 4 * 1024, 1024, RD_EXTN | QUAD_IO_FAST, SECT_4K},{"EN25Q64", 0x1c3017, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K},{"EN25Q128B", 0x1c3018, 0x0, 4 * 1024, 4096, RD_EXTN | QUAD_IO_FAST, SECT_4K},{"EN25S64", 0x1c3817, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K},
Did you test this QUAD_IO_FAST ?
#endif #ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */ {"GD25Q64B", 0xc84017, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, -- 1.8.2.1
thanks!
Hi Jagan,
On Thu, Dec 11, 2014 at 2:31 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
Update supported read commands for EON flash parts to RD_EXTN and QUAD_IO_FAST per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_params.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index cc4cd60..3e5c6e0 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -26,10 +26,10 @@ const struct spi_flash_params spi_flash_params_table[] = { {"AT25DF321A", 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_EON /* EON */
{"EN25Q32B", 0x1c3016, 0x0, 64 * 1024, 64, RD_NORM, 0},{"EN25Q64", 0x1c3017, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K},{"EN25Q128B", 0x1c3018, 0x0, 64 * 1024, 256, RD_NORM, 0},{"EN25S64", 0x1c3817, 0x0, 64 * 1024, 128, RD_NORM, 0},
{"EN25Q32B", 0x1c3016, 0x0, 4 * 1024, 1024, RD_EXTN | QUAD_IO_FAST, SECT_4K},{"EN25Q64", 0x1c3017, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K},{"EN25Q128B", 0x1c3018, 0x0, 4 * 1024, 4096, RD_EXTN | QUAD_IO_FAST, SECT_4K},{"EN25S64", 0x1c3817, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K},Did you test this QUAD_IO_FAST ?
No because I don't have a board running U-Boot which has an EON flash mounted. These updates are purely based on the flash datasheet.
[snip]
Regards, Bin
Update supported read commands for GigaDevice flash parts to RD_FULL per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 3e5c6e0..de5d438 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -32,8 +32,8 @@ const struct spi_flash_params spi_flash_params_table[] = { {"EN25S64", 0x1c3817, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */ - {"GD25Q64B", 0xc84017, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, - {"GD25LQ32", 0xc86016, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K}, + {"GD25Q64B", 0xc84017, 0x0, 4 * 1024, 2048, RD_FULL, SECT_4K}, + {"GD25LQ32", 0xc86016, 0x0, 4 * 1024, 1024, RD_FULL, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */ {"MX25L2006E", 0xc22012, 0x0, 64 * 1024, 4, RD_NORM, 0},
Update supported read commands for Macronix flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_params.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index de5d438..77aa95b 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -36,16 +36,16 @@ const struct spi_flash_params spi_flash_params_table[] = { {"GD25LQ32", 0xc86016, 0x0, 4 * 1024, 1024, RD_FULL, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */ - {"MX25L2006E", 0xc22012, 0x0, 64 * 1024, 4, RD_NORM, 0}, - {"MX25L4005", 0xc22013, 0x0, 64 * 1024, 8, RD_NORM, 0}, - {"MX25L8005", 0xc22014, 0x0, 64 * 1024, 16, RD_NORM, 0}, - {"MX25L1605D", 0xc22015, 0x0, 64 * 1024, 32, RD_NORM, 0}, - {"MX25L3205D", 0xc22016, 0x0, 64 * 1024, 64, RD_NORM, 0}, - {"MX25L6405D", 0xc22017, 0x0, 64 * 1024, 128, RD_NORM, 0}, - {"MX25L12805", 0xc22018, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, - {"MX25L25635F", 0xc22019, 0x0, 64 * 1024, 512, RD_FULL, WR_QPP}, - {"MX25L51235F", 0xc2201a, 0x0, 64 * 1024, 1024, RD_FULL, WR_QPP}, - {"MX25L12855E", 0xc22618, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, + {"MX25L2006E", 0xc22012, 0x0, 4 * 1024, 64, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"MX25L4005", 0xc22013, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K}, + {"MX25L8005", 0xc22014, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K}, + {"MX25L1605D", 0xc22015, 0x0, 4 * 1024, 512, RD_NORM, SECT_4K}, + {"MX25L3205D", 0xc22016, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, + {"MX25L6405D", 0xc22017, 0x0, 4 * 1024, 2048, RD_NORM, SECT_4K}, + {"MX25L12805", 0xc22018, 0x0, 4 * 1024, 4096, RD_NORM, SECT_4K}, + {"MX25L25635F", 0xc22019, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"MX25L51235F", 0xc2201a, 0x0, 4 * 1024, 16384, RD_FULL, WR_QPP | SECT_4K}, + {"MX25L12855E", 0xc22618, 0x0, 4 * 1024, 4096, RD_NORM | DUAL_IO_FAST | QUAD_IO_FAST, WR_QPP | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SPANSION /* SPANSION */ {"S25FL008A", 0x010213, 0x0, 64 * 1024, 16, RD_NORM, 0},
Update supported read commands for Spansion flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_params.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 77aa95b..5a3a434 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = { {"S25FL016A", 0x010214, 0x0, 64 * 1024, 32, RD_NORM, 0}, {"S25FL032A", 0x010215, 0x0, 64 * 1024, 64, RD_NORM, 0}, {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, RD_NORM, 0}, - {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_FULL, WR_QPP}, - {"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_FULL, WR_QPP}, - {"S25FL032P", 0x010215, 0x4d00, 64 * 1024, 64, RD_FULL, WR_QPP}, - {"S25FL064P", 0x010216, 0x4d00, 64 * 1024, 128, RD_FULL, WR_QPP}, + {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_NORM, 0}, + {"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_NORM, 0}, + {"S25FL032P", 0x010215, 0x4d00, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"S25FL064P", 0x010216, 0x4d00, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, {"S25FL128S_256K", 0x012018, 0x4d00, 256 * 1024, 64, RD_FULL, WR_QPP}, - {"S25FL128S_64K", 0x012018, 0x4d01, 64 * 1024, 256, RD_FULL, WR_QPP}, + {"S25FL128S_64K", 0x012018, 0x4d01, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, {"S25FL256S_256K", 0x010219, 0x4d00, 256 * 1024, 128, RD_FULL, WR_QPP}, - {"S25FL256S_64K", 0x010219, 0x4d01, 64 * 1024, 512, RD_FULL, WR_QPP}, + {"S25FL256S_64K", 0x010219, 0x4d01, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, {"S25FL512S_256K", 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL, WR_QPP}, {"S25FL512S_64K", 0x010220, 0x4d01, 64 * 1024, 1024, RD_FULL, WR_QPP}, {"S25FL512S_512K", 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL, WR_QPP},
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
Update supported read commands for Spansion flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_params.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 77aa95b..5a3a434 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = { {"S25FL016A", 0x010214, 0x0, 64 * 1024, 32, RD_NORM, 0}, {"S25FL032A", 0x010215, 0x0, 64 * 1024, 64, RD_NORM, 0}, {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, RD_NORM, 0},
{"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_FULL, WR_QPP},{"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_FULL, WR_QPP},{"S25FL032P", 0x010215, 0x4d00, 64 * 1024, 64, RD_FULL, WR_QPP},{"S25FL064P", 0x010216, 0x4d00, 64 * 1024, 128, RD_FULL, WR_QPP},
{"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_NORM, 0},{"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_NORM, 0},{"S25FL032P", 0x010215, 0x4d00, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K},{"S25FL064P", 0x010216, 0x4d00, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, {"S25FL128S_256K", 0x012018, 0x4d00, 256 * 1024, 64, RD_FULL, WR_QPP},
{"S25FL128S_64K", 0x012018, 0x4d01, 64 * 1024, 256, RD_FULL, WR_QPP},
{"S25FL128S_64K", 0x012018, 0x4d01, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K},
This is incorrect - 64 is the sector size and it should be 64 * 1024 and 4 * 1024 is not working on my latest test - please verify the same.
{"S25FL256S_256K", 0x010219, 0x4d00, 256 * 1024, 128, RD_FULL, WR_QPP},
{"S25FL256S_64K", 0x010219, 0x4d01, 64 * 1024, 512, RD_FULL, WR_QPP},
{"S25FL256S_64K", 0x010219, 0x4d01, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, {"S25FL512S_256K", 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL, WR_QPP}, {"S25FL512S_64K", 0x010220, 0x4d01, 64 * 1024, 1024, RD_FULL, WR_QPP}, {"S25FL512S_512K", 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL, WR_QPP},-- 1.8.2.1
thanks!
Hi Jagan,
On Thu, Dec 11, 2014 at 4:09 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
Update supported read commands for Spansion flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/mtd/spi/sf_params.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 77aa95b..5a3a434 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -52,14 +52,14 @@ const struct spi_flash_params spi_flash_params_table[] = { {"S25FL016A", 0x010214, 0x0, 64 * 1024, 32, RD_NORM, 0}, {"S25FL032A", 0x010215, 0x0, 64 * 1024, 64, RD_NORM, 0}, {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, RD_NORM, 0},
{"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_FULL, WR_QPP},{"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_FULL, WR_QPP},{"S25FL032P", 0x010215, 0x4d00, 64 * 1024, 64, RD_FULL, WR_QPP},{"S25FL064P", 0x010216, 0x4d00, 64 * 1024, 128, RD_FULL, WR_QPP},
{"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_NORM, 0},{"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_NORM, 0},{"S25FL032P", 0x010215, 0x4d00, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K},{"S25FL064P", 0x010216, 0x4d00, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, {"S25FL128S_256K", 0x012018, 0x4d00, 256 * 1024, 64, RD_FULL, WR_QPP},
{"S25FL128S_64K", 0x012018, 0x4d01, 64 * 1024, 256, RD_FULL, WR_QPP},
{"S25FL128S_64K", 0x012018, 0x4d01, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K},This is incorrect - 64 is the sector size and it should be 64 * 1024 and 4 * 1024 is not working on my latest test - please verify the same.
Good catch! I must have been too tired to go through so many flash datasheets and made a mistake. I will resend v4 to correct S25FL128S_64K and S25FL256S_64K.
{"S25FL256S_256K", 0x010219, 0x4d00, 256 * 1024, 128, RD_FULL, WR_QPP},
{"S25FL256S_64K", 0x010219, 0x4d01, 64 * 1024, 512, RD_FULL, WR_QPP},
{"S25FL256S_64K", 0x010219, 0x4d01, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, {"S25FL512S_256K", 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL, WR_QPP}, {"S25FL512S_64K", 0x010220, 0x4d01, 64 * 1024, 1024, RD_FULL, WR_QPP}, {"S25FL512S_512K", 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL, WR_QPP},-- 1.8.2.1
thanks!
Jagan.
Regards, Bin
Update supported read commands for Micron flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_params.c | 46 ++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 5a3a434..034d092 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -65,29 +65,29 @@ const struct spi_flash_params spi_flash_params_table[] = { {"S25FL512S_512K", 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL, WR_QPP}, #endif #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ - {"M25P10", 0x202011, 0x0, 32 * 1024, 4, RD_NORM, 0}, - {"M25P20", 0x202012, 0x0, 64 * 1024, 4, RD_NORM, 0}, - {"M25P40", 0x202013, 0x0, 64 * 1024, 8, RD_NORM, 0}, - {"M25P80", 0x202014, 0x0, 64 * 1024, 16, RD_NORM, 0}, - {"M25P16", 0x202015, 0x0, 64 * 1024, 32, RD_NORM, 0}, - {"M25PE16", 0x208015, 0x1000, 64 * 1024, 32, RD_NORM, 0}, - {"M25PX16", 0x207115, 0x1000, 64 * 1024, 32, RD_EXTN, 0}, - {"M25P32", 0x202016, 0x0, 64 * 1024, 64, RD_NORM, 0}, - {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, 0}, - {"M25P128", 0x202018, 0x0, 256 * 1024, 64, RD_NORM, 0}, - {"M25PX64", 0x207117, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, - {"N25Q32", 0x20ba16, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q32A", 0x20bb16, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q64", 0x20ba17, 0x0, 64 * 1024, 128, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q64A", 0x20bb17, 0x0, 64 * 1024, 128, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q128", 0x20ba18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, - {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, - {"N25Q256", 0x20ba19, 0x0, 64 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, RD_FULL, WR_QPP | E_FSR | SECT_4K}, - {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, RD_FULL, WR_QPP | E_FSR | SECT_4K}, - {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, RD_FULL, WR_QPP | E_FSR | SECT_4K}, - {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"M25P10", 0x202011, 0x0, 32 * 1024, 4, RD_NORM, 0}, + {"M25P20", 0x202012, 0x0, 64 * 1024, 4, RD_NORM, 0}, + {"M25P40", 0x202013, 0x0, 64 * 1024, 8, RD_NORM, 0}, + {"M25P80", 0x202014, 0x0, 64 * 1024, 16, RD_NORM, 0}, + {"M25P16", 0x202015, 0x0, 64 * 1024, 32, RD_NORM, 0}, + {"M25PE16", 0x208015, 0x1000, 4 * 1024, 512, RD_NORM, SECT_4K}, + {"M25PX16", 0x207115, 0x1000, 4 * 1024, 512, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"M25P32", 0x202016, 0x0, 64 * 1024, 64, RD_NORM, 0}, + {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, 0}, + {"M25P128", 0x202018, 0x0, 256 * 1024, 64, RD_NORM, 0}, + {"M25PX64", 0x207117, 0x0, 4 * 1024, 2048, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"N25Q32", 0x20ba16, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q32A", 0x20bb16, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q64", 0x20ba17, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q64A", 0x20bb17, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q128", 0x20ba18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, + {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, + {"N25Q256", 0x20ba19, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q256A", 0x20bb19, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q512", 0x20ba20, 0x0, 4 * 1024, 16384, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"N25Q512A", 0x20bb20, 0x0, 4 * 1024, 16384, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"N25Q1024", 0x20ba21, 0x0, 4 * 1024, 32768, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"N25Q1024A", 0x20bb21, 0x0, 4 * 1024, 32768, RD_FULL, WR_QPP | E_FSR | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SST /* SST */ {"SST25VF040B", 0xbf258d, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR},
Update supported read commands for Winbond flash parts per datasheet. Also update flash sector size to 4KiB as long as flash supports sector erase (20h) command. Add W25X10, W25X20, W25X80 params per datasheet.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/mtd/spi/sf_params.c | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 034d092..735dd54 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -102,24 +102,27 @@ const struct spi_flash_params spi_flash_params_table[] = { {"SST25WF080", 0xbf2505, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR}, #endif #ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ - {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0}, - {"W25P16", 0xef2015, 0x0, 64 * 1024, 32, RD_NORM, 0}, - {"W25P32", 0xef2016, 0x0, 64 * 1024, 64, RD_NORM, 0}, - {"W25X40", 0xef3013, 0x0, 64 * 1024, 8, RD_NORM, SECT_4K}, - {"W25X16", 0xef3015, 0x0, 64 * 1024, 32, RD_NORM, SECT_4K}, - {"W25X32", 0xef3016, 0x0, 64 * 1024, 64, RD_NORM, SECT_4K}, - {"W25X64", 0xef3017, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, - {"W25Q80BL", 0xef4014, 0x0, 64 * 1024, 16, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q16CL", 0xef4015, 0x0, 64 * 1024, 32, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q32BV", 0xef4016, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q64CV", 0xef4017, 0x0, 64 * 1024, 128, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q128BV", 0xef4018, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q256", 0xef4019, 0x0, 64 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q80BW", 0xef5014, 0x0, 64 * 1024, 16, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q16DW", 0xef6015, 0x0, 64 * 1024, 32, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q32DW", 0xef6016, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q64DW", 0xef6017, 0x0, 64 * 1024, 128, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q128FW", 0xef6018, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, + {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0}, + {"W25P16", 0xef2015, 0x0, 64 * 1024, 32, RD_NORM, 0}, + {"W25P32", 0xef2016, 0x0, 64 * 1024, 64, RD_NORM, 0}, + {"W25X10", 0xef3011, 0x0, 4 * 1024, 32, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X20", 0xef3012, 0x0, 4 * 1024, 64, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X40", 0xef3013, 0x0, 4 * 1024, 128, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X80", 0xef3014, 0x0, 4 * 1024, 256, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X16", 0xef3015, 0x0, 4 * 1024, 512, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X32", 0xef3016, 0x0, 4 * 1024, 1024, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X64", 0xef3017, 0x0, 4 * 1024, 2048, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25Q80BL", 0xef4014, 0x0, 4 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q16CL", 0xef4015, 0x0, 4 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q32BV", 0xef4016, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q64CV", 0xef4017, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q128BV", 0xef4018, 0x0, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q256", 0xef4019, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q80BW", 0xef5014, 0x0, 4 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q16DW", 0xef6015, 0x0, 4 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q32DW", 0xef6016, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q64DW", 0xef6017, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q128FW", 0xef6018, 0x0, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, #endif {}, /* Empty entry to terminate the list */ /*
Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
drivers/mtd/spi/sf_params.c | 169 ++++++++++++++++++++++---------------------- 1 file changed, 85 insertions(+), 84 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 735dd54..b5177ad 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -2,6 +2,7 @@ * SPI flash Params table * * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc. + * Copyright (C) 2014 Bin Meng bmeng.cn@gmail.com * * SPDX-License-Identifier: GPL-2.0+ */ @@ -15,25 +16,25 @@ /* SPI/QSPI flash device params structure */ const struct spi_flash_params spi_flash_params_table[] = { #ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */ - {"AT45DB011D", 0x1f2200, 0x0, 2 * 1024, 64, RD_NORM, 0}, - {"AT45DB021D", 0x1f2300, 0x0, 2 * 1024, 128, RD_NORM, 0}, - {"AT45DB041D", 0x1f2400, 0x0, 2 * 1024, 256, RD_NORM, 0}, - {"AT45DB081D", 0x1f2500, 0x0, 2 * 1024, 512, RD_NORM, 0}, - {"AT45DB161D", 0x1f2600, 0x0, 4 * 1024, 512, RD_NORM, 0}, - {"AT45DB321D", 0x1f2700, 0x0, 4 * 1024, 1024, RD_NORM, 0}, - {"AT45DB641D", 0x1f2800, 0x0, 2 * 1024, 4096, RD_NORM, 0}, - {"AT25DF321", 0x1f4700, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, - {"AT25DF321A", 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, + {"AT45DB011D", 0x1f2200, 0x0, 2 * 1024, 64, RD_NORM, 0}, + {"AT45DB021D", 0x1f2300, 0x0, 2 * 1024, 128, RD_NORM, 0}, + {"AT45DB041D", 0x1f2400, 0x0, 2 * 1024, 256, RD_NORM, 0}, + {"AT45DB081D", 0x1f2500, 0x0, 2 * 1024, 512, RD_NORM, 0}, + {"AT45DB161D", 0x1f2600, 0x0, 4 * 1024, 512, RD_NORM, 0}, + {"AT45DB321D", 0x1f2700, 0x0, 4 * 1024, 1024, RD_NORM, 0}, + {"AT45DB641D", 0x1f2800, 0x0, 2 * 1024, 4096, RD_NORM, 0}, + {"AT25DF321", 0x1f4700, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, + {"AT25DF321A", 0x1f4701, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_EON /* EON */ - {"EN25Q32B", 0x1c3016, 0x0, 4 * 1024, 1024, RD_EXTN | QUAD_IO_FAST, SECT_4K}, - {"EN25Q64", 0x1c3017, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K}, - {"EN25Q128B", 0x1c3018, 0x0, 4 * 1024, 4096, RD_EXTN | QUAD_IO_FAST, SECT_4K}, - {"EN25S64", 0x1c3817, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K}, + {"EN25Q32B", 0x1c3016, 0x0, 4 * 1024, 1024, RD_EXTN | QUAD_IO_FAST, SECT_4K}, + {"EN25Q64", 0x1c3017, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K}, + {"EN25Q128B", 0x1c3018, 0x0, 4 * 1024, 4096, RD_EXTN | QUAD_IO_FAST, SECT_4K}, + {"EN25S64", 0x1c3817, 0x0, 4 * 1024, 2048, RD_EXTN | QUAD_IO_FAST, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */ - {"GD25Q64B", 0xc84017, 0x0, 4 * 1024, 2048, RD_FULL, SECT_4K}, - {"GD25LQ32", 0xc86016, 0x0, 4 * 1024, 1024, RD_FULL, SECT_4K}, + {"GD25Q64B", 0xc84017, 0x0, 4 * 1024, 2048, RD_FULL, SECT_4K}, + {"GD25LQ32", 0xc86016, 0x0, 4 * 1024, 1024, RD_FULL, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */ {"MX25L2006E", 0xc22012, 0x0, 4 * 1024, 64, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, @@ -48,81 +49,81 @@ const struct spi_flash_params spi_flash_params_table[] = { {"MX25L12855E", 0xc22618, 0x0, 4 * 1024, 4096, RD_NORM | DUAL_IO_FAST | QUAD_IO_FAST, WR_QPP | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SPANSION /* SPANSION */ - {"S25FL008A", 0x010213, 0x0, 64 * 1024, 16, RD_NORM, 0}, - {"S25FL016A", 0x010214, 0x0, 64 * 1024, 32, RD_NORM, 0}, - {"S25FL032A", 0x010215, 0x0, 64 * 1024, 64, RD_NORM, 0}, - {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, RD_NORM, 0}, - {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_NORM, 0}, - {"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_NORM, 0}, - {"S25FL032P", 0x010215, 0x4d00, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, - {"S25FL064P", 0x010216, 0x4d00, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, - {"S25FL128S_256K", 0x012018, 0x4d00, 256 * 1024, 64, RD_FULL, WR_QPP}, - {"S25FL128S_64K", 0x012018, 0x4d01, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, - {"S25FL256S_256K", 0x010219, 0x4d00, 256 * 1024, 128, RD_FULL, WR_QPP}, - {"S25FL256S_64K", 0x010219, 0x4d01, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, - {"S25FL512S_256K", 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL, WR_QPP}, - {"S25FL512S_64K", 0x010220, 0x4d01, 64 * 1024, 1024, RD_FULL, WR_QPP}, - {"S25FL512S_512K", 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL, WR_QPP}, + {"S25FL008A", 0x010213, 0x0, 64 * 1024, 16, RD_NORM, 0}, + {"S25FL016A", 0x010214, 0x0, 64 * 1024, 32, RD_NORM, 0}, + {"S25FL032A", 0x010215, 0x0, 64 * 1024, 64, RD_NORM, 0}, + {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, RD_NORM, 0}, + {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_NORM, 0}, + {"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_NORM, 0}, + {"S25FL032P", 0x010215, 0x4d00, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"S25FL064P", 0x010216, 0x4d00, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"S25FL128S_256K", 0x012018, 0x4d00, 256 * 1024, 64, RD_FULL, WR_QPP}, + {"S25FL128S_64K", 0x012018, 0x4d01, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, + {"S25FL256S_256K", 0x010219, 0x4d00, 256 * 1024, 128, RD_FULL, WR_QPP}, + {"S25FL256S_64K", 0x010219, 0x4d01, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"S25FL512S_256K", 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL, WR_QPP}, + {"S25FL512S_64K", 0x010220, 0x4d01, 64 * 1024, 1024, RD_FULL, WR_QPP}, + {"S25FL512S_512K", 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL, WR_QPP}, #endif #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ - {"M25P10", 0x202011, 0x0, 32 * 1024, 4, RD_NORM, 0}, - {"M25P20", 0x202012, 0x0, 64 * 1024, 4, RD_NORM, 0}, - {"M25P40", 0x202013, 0x0, 64 * 1024, 8, RD_NORM, 0}, - {"M25P80", 0x202014, 0x0, 64 * 1024, 16, RD_NORM, 0}, - {"M25P16", 0x202015, 0x0, 64 * 1024, 32, RD_NORM, 0}, - {"M25PE16", 0x208015, 0x1000, 4 * 1024, 512, RD_NORM, SECT_4K}, - {"M25PX16", 0x207115, 0x1000, 4 * 1024, 512, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"M25P32", 0x202016, 0x0, 64 * 1024, 64, RD_NORM, 0}, - {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, 0}, - {"M25P128", 0x202018, 0x0, 256 * 1024, 64, RD_NORM, 0}, - {"M25PX64", 0x207117, 0x0, 4 * 1024, 2048, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"N25Q32", 0x20ba16, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q32A", 0x20bb16, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q64", 0x20ba17, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q64A", 0x20bb17, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q128", 0x20ba18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, - {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, - {"N25Q256", 0x20ba19, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q256A", 0x20bb19, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, - {"N25Q512", 0x20ba20, 0x0, 4 * 1024, 16384, RD_FULL, WR_QPP | E_FSR | SECT_4K}, - {"N25Q512A", 0x20bb20, 0x0, 4 * 1024, 16384, RD_FULL, WR_QPP | E_FSR | SECT_4K}, - {"N25Q1024", 0x20ba21, 0x0, 4 * 1024, 32768, RD_FULL, WR_QPP | E_FSR | SECT_4K}, - {"N25Q1024A", 0x20bb21, 0x0, 4 * 1024, 32768, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"M25P10", 0x202011, 0x0, 32 * 1024, 4, RD_NORM, 0}, + {"M25P20", 0x202012, 0x0, 64 * 1024, 4, RD_NORM, 0}, + {"M25P40", 0x202013, 0x0, 64 * 1024, 8, RD_NORM, 0}, + {"M25P80", 0x202014, 0x0, 64 * 1024, 16, RD_NORM, 0}, + {"M25P16", 0x202015, 0x0, 64 * 1024, 32, RD_NORM, 0}, + {"M25PE16", 0x208015, 0x1000, 4 * 1024, 512, RD_NORM, SECT_4K}, + {"M25PX16", 0x207115, 0x1000, 4 * 1024, 512, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"M25P32", 0x202016, 0x0, 64 * 1024, 64, RD_NORM, 0}, + {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, 0}, + {"M25P128", 0x202018, 0x0, 256 * 1024, 64, RD_NORM, 0}, + {"M25PX64", 0x207117, 0x0, 4 * 1024, 2048, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"N25Q32", 0x20ba16, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q32A", 0x20bb16, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q64", 0x20ba17, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q64A", 0x20bb17, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q128", 0x20ba18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, + {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL, WR_QPP}, + {"N25Q256", 0x20ba19, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q256A", 0x20bb19, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"N25Q512", 0x20ba20, 0x0, 4 * 1024, 16384, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"N25Q512A", 0x20bb20, 0x0, 4 * 1024, 16384, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"N25Q1024", 0x20ba21, 0x0, 4 * 1024, 32768, RD_FULL, WR_QPP | E_FSR | SECT_4K}, + {"N25Q1024A", 0x20bb21, 0x0, 4 * 1024, 32768, RD_FULL, WR_QPP | E_FSR | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SST /* SST */ - {"SST25VF040B", 0xbf258d, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF080B", 0xbf258e, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF016B", 0xbf2541, 0x0, 4 * 1024, 512, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF032B", 0xbf254a, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K | SST_WR}, - {"SST25VF064C", 0xbf254b, 0x0, 4 * 1024, 2048, RD_EXTN, SECT_4K}, - {"SST25WF512", 0xbf2501, 0x0, 4 * 1024, 16, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF010", 0xbf2502, 0x0, 4 * 1024, 32, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF020", 0xbf2503, 0x0, 4 * 1024, 64, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF040", 0xbf2504, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR}, - {"SST25WF080", 0xbf2505, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF040B", 0xbf258d, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF080B", 0xbf258e, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF016B", 0xbf2541, 0x0, 4 * 1024, 512, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF032B", 0xbf254a, 0x0, 4 * 1024, 1024, RD_NORM, SECT_4K | SST_WR}, + {"SST25VF064C", 0xbf254b, 0x0, 4 * 1024, 2048, RD_EXTN, SECT_4K}, + {"SST25WF512", 0xbf2501, 0x0, 4 * 1024, 16, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF010", 0xbf2502, 0x0, 4 * 1024, 32, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF020", 0xbf2503, 0x0, 4 * 1024, 64, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF040", 0xbf2504, 0x0, 4 * 1024, 128, RD_NORM, SECT_4K | SST_WR}, + {"SST25WF080", 0xbf2505, 0x0, 4 * 1024, 256, RD_NORM, SECT_4K | SST_WR}, #endif #ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ - {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0}, - {"W25P16", 0xef2015, 0x0, 64 * 1024, 32, RD_NORM, 0}, - {"W25P32", 0xef2016, 0x0, 64 * 1024, 64, RD_NORM, 0}, - {"W25X10", 0xef3011, 0x0, 4 * 1024, 32, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"W25X20", 0xef3012, 0x0, 4 * 1024, 64, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"W25X40", 0xef3013, 0x0, 4 * 1024, 128, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"W25X80", 0xef3014, 0x0, 4 * 1024, 256, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"W25X16", 0xef3015, 0x0, 4 * 1024, 512, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"W25X32", 0xef3016, 0x0, 4 * 1024, 1024, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"W25X64", 0xef3017, 0x0, 4 * 1024, 2048, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, - {"W25Q80BL", 0xef4014, 0x0, 4 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q16CL", 0xef4015, 0x0, 4 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q32BV", 0xef4016, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q64CV", 0xef4017, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q128BV", 0xef4018, 0x0, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q256", 0xef4019, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q80BW", 0xef5014, 0x0, 4 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q16DW", 0xef6015, 0x0, 4 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q32DW", 0xef6016, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q64DW", 0xef6017, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, - {"W25Q128FW", 0xef6018, 0x0, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, + {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, RD_NORM, 0}, + {"W25P16", 0xef2015, 0x0, 64 * 1024, 32, RD_NORM, 0}, + {"W25P32", 0xef2016, 0x0, 64 * 1024, 64, RD_NORM, 0}, + {"W25X10", 0xef3011, 0x0, 4 * 1024, 32, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X20", 0xef3012, 0x0, 4 * 1024, 64, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X40", 0xef3013, 0x0, 4 * 1024, 128, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X80", 0xef3014, 0x0, 4 * 1024, 256, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X16", 0xef3015, 0x0, 4 * 1024, 512, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X32", 0xef3016, 0x0, 4 * 1024, 1024, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25X64", 0xef3017, 0x0, 4 * 1024, 2048, RD_NORM | DUAL_OUTPUT_FAST, SECT_4K}, + {"W25Q80BL", 0xef4014, 0x0, 4 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q16CL", 0xef4015, 0x0, 4 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q32BV", 0xef4016, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q64CV", 0xef4017, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q128BV", 0xef4018, 0x0, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q256", 0xef4019, 0x0, 4 * 1024, 8192, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q80BW", 0xef5014, 0x0, 4 * 1024, 256, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q16DW", 0xef6015, 0x0, 4 * 1024, 512, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q32DW", 0xef6016, 0x0, 4 * 1024, 1024, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q64DW", 0xef6017, 0x0, 4 * 1024, 2048, RD_FULL, WR_QPP | SECT_4K}, + {"W25Q128FW", 0xef6018, 0x0, 4 * 1024, 4096, RD_FULL, WR_QPP | SECT_4K}, #endif {}, /* Empty entry to terminate the list */ /*
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.
Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params
Thanks for the updates - have you verified these changes?
drivers/mtd/spi/sf_internal.h | 5 ++ drivers/mtd/spi/sf_params.c | 185 ++++++++++++++++++++++-------------------- drivers/mtd/spi/sf_probe.c | 4 + 3 files changed, 104 insertions(+), 90 deletions(-)
-- 1.8.2.1
thanks!
Hi Jagan,
On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.
Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params
Thanks for the updates - have you verified these changes?
I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.
drivers/mtd/spi/sf_internal.h | 5 ++ drivers/mtd/spi/sf_params.c | 185 ++++++++++++++++++++++-------------------- drivers/mtd/spi/sf_probe.c | 4 + 3 files changed, 104 insertions(+), 90 deletions(-)
-- 1.8.2.1
thanks!
Jagan.
Regards, Bin
Hi Bin,
On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.
Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params
Thanks for the updates - have you verified these changes?
I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.
Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.
Let me know your inputs?
drivers/mtd/spi/sf_internal.h | 5 ++ drivers/mtd/spi/sf_params.c | 185 ++++++++++++++++++++++-------------------- drivers/mtd/spi/sf_probe.c | 4 + 3 files changed, 104 insertions(+), 90 deletions(-)
thanks!
Hi Jagan,
On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.
Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params
Thanks for the updates - have you verified these changes?
I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.
Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.
Let me know your inputs?
I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.
Regards, Bin
Hi Jagan,
On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.
Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params
Thanks for the updates - have you verified these changes?
I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.
Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.
Let me know your inputs?
I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.
Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.
Regards, Bin
On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote:
This series update SPI flash supported read commands per datasheet in the flash params table, and change flash sector size to 4KiB as long as flash supports sector erase (20h) command, to ensure 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when given SECT_4K.
Changes in v3:
- Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/
Bin Meng (9): sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params
Thanks for the updates - have you verified these changes?
I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.
Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.
Let me know your inputs?
I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.
Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.
I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.
thanks!
Hi Jagan,
On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: > This series update SPI flash supported read commands per datasheet > in the flash params table, and change flash sector size to 4KiB as > long as flash supports sector erase (20h) command, to ensure > 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when > given SECT_4K. > > Changes in v3: > - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ > > > Bin Meng (9): > sf: Update SST flash params > sf: Update Atmel flash params > sf: Update EON flash params > sf: Update GigaDevice flash params > sf: Update Macronix flash params > sf: Update Spansion flash params > sf: Update Micron flash params > sf: Update Winbond flash params > sf: Give proper spacing between flash table params
Thanks for the updates - have you verified these changes?
I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.
Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.
Let me know your inputs?
I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.
Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.
I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.
You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.
Regards, Bin
On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: > Hi Bin, > > On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >> This series update SPI flash supported read commands per datasheet >> in the flash params table, and change flash sector size to 4KiB as >> long as flash supports sector erase (20h) command, to ensure >> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >> given SECT_4K. >> >> Changes in v3: >> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >> >> >> Bin Meng (9): >> sf: Update SST flash params >> sf: Update Atmel flash params >> sf: Update EON flash params >> sf: Update GigaDevice flash params >> sf: Update Macronix flash params >> sf: Update Spansion flash params >> sf: Update Micron flash params >> sf: Update Winbond flash params >> sf: Give proper spacing between flash table params > > Thanks for the updates - have you verified these changes?
I verified some, but not all of these flash parts. The update is based on flash datasheet, so if something is broken, eg before this series the flash advertises only READ_NORM and after my series it is changed to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very likely that the SPI controller driver has some bugs when supporting QUAD_IO_FAST.
Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.
Let me know your inputs?
I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.
Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.
I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.
You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.
Yes - about testing.
thanks!
Hi Jagan,
On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi Bin,
On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >> Hi Bin, >> >> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>> This series update SPI flash supported read commands per datasheet >>> in the flash params table, and change flash sector size to 4KiB as >>> long as flash supports sector erase (20h) command, to ensure >>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>> given SECT_4K. >>> >>> Changes in v3: >>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>> >>> >>> Bin Meng (9): >>> sf: Update SST flash params >>> sf: Update Atmel flash params >>> sf: Update EON flash params >>> sf: Update GigaDevice flash params >>> sf: Update Macronix flash params >>> sf: Update Spansion flash params >>> sf: Update Micron flash params >>> sf: Update Winbond flash params >>> sf: Give proper spacing between flash table params >> >> Thanks for the updates - have you verified these changes? > > I verified some, but not all of these flash parts. The update is based > on flash datasheet, so if something is broken, eg before this series > the flash advertises only READ_NORM and after my series it is changed > to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very > likely that the SPI controller driver has some bugs when supporting > QUAD_IO_FAST.
Since these updates were tested before, I will skip these for this PR. Will test all the rest (except these) and send the PR soon.
Let me know your inputs?
I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.
Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.
I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.
You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.
Yes - about testing.
Ping? What about your test results about this patch series?
Regards, Bin
On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: > Hi Bin, > > On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>> Hi Bin, >>> >>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>> This series update SPI flash supported read commands per datasheet >>>> in the flash params table, and change flash sector size to 4KiB as >>>> long as flash supports sector erase (20h) command, to ensure >>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>> given SECT_4K. >>>> >>>> Changes in v3: >>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>> >>>> >>>> Bin Meng (9): >>>> sf: Update SST flash params >>>> sf: Update Atmel flash params >>>> sf: Update EON flash params >>>> sf: Update GigaDevice flash params >>>> sf: Update Macronix flash params >>>> sf: Update Spansion flash params >>>> sf: Update Micron flash params >>>> sf: Update Winbond flash params >>>> sf: Give proper spacing between flash table params >>> >>> Thanks for the updates - have you verified these changes? >> >> I verified some, but not all of these flash parts. The update is based >> on flash datasheet, so if something is broken, eg before this series >> the flash advertises only READ_NORM and after my series it is changed >> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >> likely that the SPI controller driver has some bugs when supporting >> QUAD_IO_FAST. > > Since these updates were tested before, I will skip these for this PR. > Will test all the rest (except these) and send the PR soon. > > Let me know your inputs?
I am fine, as long as this PR will not contains other commits which modify the same sf_params.c to introduce more flash support. We can test these updates and if everything looks fine, apply these first and ask other commits to rebase on this series to introduce more flash support.
Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.
I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.
You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.
Yes - about testing.
Ping? What about your test results about this patch series?
Some were pending - Will comment, pls- wait.
thanks!
Hi Jagan,
On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >> Hi Bin, >> >> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>> Hi Jagan, >>> >>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>> Hi Bin, >>>> >>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>> This series update SPI flash supported read commands per datasheet >>>>> in the flash params table, and change flash sector size to 4KiB as >>>>> long as flash supports sector erase (20h) command, to ensure >>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>> given SECT_4K. >>>>> >>>>> Changes in v3: >>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>> >>>>> >>>>> Bin Meng (9): >>>>> sf: Update SST flash params >>>>> sf: Update Atmel flash params >>>>> sf: Update EON flash params >>>>> sf: Update GigaDevice flash params >>>>> sf: Update Macronix flash params >>>>> sf: Update Spansion flash params >>>>> sf: Update Micron flash params >>>>> sf: Update Winbond flash params >>>>> sf: Give proper spacing between flash table params >>>> >>>> Thanks for the updates - have you verified these changes? >>> >>> I verified some, but not all of these flash parts. The update is based >>> on flash datasheet, so if something is broken, eg before this series >>> the flash advertises only READ_NORM and after my series it is changed >>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>> likely that the SPI controller driver has some bugs when supporting >>> QUAD_IO_FAST. >> >> Since these updates were tested before, I will skip these for this PR. >> Will test all the rest (except these) and send the PR soon. >> >> Let me know your inputs? > > I am fine, as long as this PR will not contains other commits which > modify the same sf_params.c to introduce more flash support. We can > test these updates and if everything looks fine, apply these first and > ask other commits to rebase on this series to introduce more flash > support. >
Do you have any additional comments about this patch series besides the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send the v4.
I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.
You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.
Yes - about testing.
Ping? What about your test results about this patch series?
Some were pending - Will comment, pls- wait.
thanks!
I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?
Regards, Bin
Hi Jagan,
On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>> Hi Bin, >>> >>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>> Hi Jagan, >>>> >>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>> Hi Bin, >>>>> >>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>> This series update SPI flash supported read commands per datasheet >>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>> given SECT_4K. >>>>>> >>>>>> Changes in v3: >>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>> >>>>>> >>>>>> Bin Meng (9): >>>>>> sf: Update SST flash params >>>>>> sf: Update Atmel flash params >>>>>> sf: Update EON flash params >>>>>> sf: Update GigaDevice flash params >>>>>> sf: Update Macronix flash params >>>>>> sf: Update Spansion flash params >>>>>> sf: Update Micron flash params >>>>>> sf: Update Winbond flash params >>>>>> sf: Give proper spacing between flash table params >>>>> >>>>> Thanks for the updates - have you verified these changes? >>>> >>>> I verified some, but not all of these flash parts. The update is based >>>> on flash datasheet, so if something is broken, eg before this series >>>> the flash advertises only READ_NORM and after my series it is changed >>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>> likely that the SPI controller driver has some bugs when supporting >>>> QUAD_IO_FAST. >>> >>> Since these updates were tested before, I will skip these for this PR. >>> Will test all the rest (except these) and send the PR soon. >>> >>> Let me know your inputs? >> >> I am fine, as long as this PR will not contains other commits which >> modify the same sf_params.c to introduce more flash support. We can >> test these updates and if everything looks fine, apply these first and >> ask other commits to rebase on this series to introduce more flash >> support. >> > > Do you have any additional comments about this patch series besides > the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send > the v4.
I'm thinking about the other flashes too, since these params were taken from previous working and Linux mtd.
You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.
Yes - about testing.
Ping? What about your test results about this patch series?
Some were pending - Will comment, pls- wait.
thanks!
I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?
Could you respond this? I wonder if this series could be merged in before MW is closed.
Regards, Bin
+Tom
Hi Jagan,
On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote: > On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >>> Hi Jagan, >>> >>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>> Hi Bin, >>>> >>>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>>> Hi Jagan, >>>>> >>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>> Hi Bin, >>>>>> >>>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>> This series update SPI flash supported read commands per datasheet >>>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>>> given SECT_4K. >>>>>>> >>>>>>> Changes in v3: >>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>>> >>>>>>> >>>>>>> Bin Meng (9): >>>>>>> sf: Update SST flash params >>>>>>> sf: Update Atmel flash params >>>>>>> sf: Update EON flash params >>>>>>> sf: Update GigaDevice flash params >>>>>>> sf: Update Macronix flash params >>>>>>> sf: Update Spansion flash params >>>>>>> sf: Update Micron flash params >>>>>>> sf: Update Winbond flash params >>>>>>> sf: Give proper spacing between flash table params >>>>>> >>>>>> Thanks for the updates - have you verified these changes? >>>>> >>>>> I verified some, but not all of these flash parts. The update is based >>>>> on flash datasheet, so if something is broken, eg before this series >>>>> the flash advertises only READ_NORM and after my series it is changed >>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>>> likely that the SPI controller driver has some bugs when supporting >>>>> QUAD_IO_FAST. >>>> >>>> Since these updates were tested before, I will skip these for this PR. >>>> Will test all the rest (except these) and send the PR soon. >>>> >>>> Let me know your inputs? >>> >>> I am fine, as long as this PR will not contains other commits which >>> modify the same sf_params.c to introduce more flash support. We can >>> test these updates and if everything looks fine, apply these first and >>> ask other commits to rebase on this series to introduce more flash >>> support. >>> >> >> Do you have any additional comments about this patch series besides >> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send >> the v4. > > I'm thinking about the other flashes too, since these params were taken from > previous working and Linux mtd. >
You mean 'thinking about' or 'testing'? I should say previously they might not be 100% working as per datasheet some flash params currently are apparently wrong.
Yes - about testing.
Ping? What about your test results about this patch series?
Some were pending - Will comment, pls- wait.
thanks!
I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?
Could you respond this? I wonder if this series could be merged in before MW is closed.
I feel that you did not work on this. Can you please respond with any comments?
Regards, Bin
On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
+Tom
Hi Jagan,
On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >> On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: >>> Hi Jagan, >>> >>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >>>> Hi Jagan, >>>> >>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>> Hi Bin, >>>>> >>>>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>>>> Hi Jagan, >>>>>> >>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>> Hi Bin, >>>>>>> >>>>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>> This series update SPI flash supported read commands per datasheet >>>>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>>>> given SECT_4K. >>>>>>>> >>>>>>>> Changes in v3: >>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>>>> >>>>>>>> >>>>>>>> Bin Meng (9): >>>>>>>> sf: Update SST flash params >>>>>>>> sf: Update Atmel flash params >>>>>>>> sf: Update EON flash params >>>>>>>> sf: Update GigaDevice flash params >>>>>>>> sf: Update Macronix flash params >>>>>>>> sf: Update Spansion flash params >>>>>>>> sf: Update Micron flash params >>>>>>>> sf: Update Winbond flash params >>>>>>>> sf: Give proper spacing between flash table params >>>>>>> >>>>>>> Thanks for the updates - have you verified these changes? >>>>>> >>>>>> I verified some, but not all of these flash parts. The update is based >>>>>> on flash datasheet, so if something is broken, eg before this series >>>>>> the flash advertises only READ_NORM and after my series it is changed >>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>>>> likely that the SPI controller driver has some bugs when supporting >>>>>> QUAD_IO_FAST. >>>>> >>>>> Since these updates were tested before, I will skip these for this PR. >>>>> Will test all the rest (except these) and send the PR soon. >>>>> >>>>> Let me know your inputs? >>>> >>>> I am fine, as long as this PR will not contains other commits which >>>> modify the same sf_params.c to introduce more flash support. We can >>>> test these updates and if everything looks fine, apply these first and >>>> ask other commits to rebase on this series to introduce more flash >>>> support. >>>> >>> >>> Do you have any additional comments about this patch series besides >>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send >>> the v4. >> >> I'm thinking about the other flashes too, since these params were taken from >> previous working and Linux mtd. >> > > You mean 'thinking about' or 'testing'? I should say previously they > might not be 100% working as per datasheet some flash params currently > are apparently wrong.
Yes - about testing.
Ping? What about your test results about this patch series?
Some were pending - Will comment, pls- wait.
thanks!
I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?
Could you respond this? I wonder if this series could be merged in before MW is closed.
I feel that you did not work on this. Can you please respond with any comments?
Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!
Hi Tom,
On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
+Tom
Hi Jagan,
On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote: > On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>> On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: >>>> Hi Jagan, >>>> >>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >>>>> Hi Jagan, >>>>> >>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>> Hi Bin, >>>>>> >>>>>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>> Hi Jagan, >>>>>>> >>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>> This series update SPI flash supported read commands per datasheet >>>>>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>>>>> given SECT_4K. >>>>>>>>> >>>>>>>>> Changes in v3: >>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Bin Meng (9): >>>>>>>>> sf: Update SST flash params >>>>>>>>> sf: Update Atmel flash params >>>>>>>>> sf: Update EON flash params >>>>>>>>> sf: Update GigaDevice flash params >>>>>>>>> sf: Update Macronix flash params >>>>>>>>> sf: Update Spansion flash params >>>>>>>>> sf: Update Micron flash params >>>>>>>>> sf: Update Winbond flash params >>>>>>>>> sf: Give proper spacing between flash table params >>>>>>>> >>>>>>>> Thanks for the updates - have you verified these changes? >>>>>>> >>>>>>> I verified some, but not all of these flash parts. The update is based >>>>>>> on flash datasheet, so if something is broken, eg before this series >>>>>>> the flash advertises only READ_NORM and after my series it is changed >>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>>>>> likely that the SPI controller driver has some bugs when supporting >>>>>>> QUAD_IO_FAST. >>>>>> >>>>>> Since these updates were tested before, I will skip these for this PR. >>>>>> Will test all the rest (except these) and send the PR soon. >>>>>> >>>>>> Let me know your inputs? >>>>> >>>>> I am fine, as long as this PR will not contains other commits which >>>>> modify the same sf_params.c to introduce more flash support. We can >>>>> test these updates and if everything looks fine, apply these first and >>>>> ask other commits to rebase on this series to introduce more flash >>>>> support. >>>>> >>>> >>>> Do you have any additional comments about this patch series besides >>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send >>>> the v4. >>> >>> I'm thinking about the other flashes too, since these params were taken from >>> previous working and Linux mtd. >>> >> >> You mean 'thinking about' or 'testing'? I should say previously they >> might not be 100% working as per datasheet some flash params currently >> are apparently wrong. > > Yes - about testing. >
Ping? What about your test results about this patch series?
Some were pending - Will comment, pls- wait.
thanks!
I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?
Could you respond this? I wonder if this series could be merged in before MW is closed.
I feel that you did not work on this. Can you please respond with any comments?
Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!
--
Thanks for checking. Here you are:
http://patchwork.ozlabs.org/patch/419633/ http://patchwork.ozlabs.org/patch/419634/ http://patchwork.ozlabs.org/patch/419635/ http://patchwork.ozlabs.org/patch/419636/ http://patchwork.ozlabs.org/patch/419637/ http://patchwork.ozlabs.org/patch/419638/ http://patchwork.ozlabs.org/patch/419639/ http://patchwork.ozlabs.org/patch/419640/ http://patchwork.ozlabs.org/patch/419641/
They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.
Regards, Bin
On 4 March 2015 at 09:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
+Tom
Hi Jagan,
On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >> On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote: >>> Hi Jagan, >>> >>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>> On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>> Hi Jagan, >>>>> >>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >>>>>> Hi Jagan, >>>>>> >>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>> Hi Bin, >>>>>>> >>>>>>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>> Hi Jagan, >>>>>>>> >>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>>> Hi Bin, >>>>>>>>> >>>>>>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>>> This series update SPI flash supported read commands per datasheet >>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>>>>>> given SECT_4K. >>>>>>>>>> >>>>>>>>>> Changes in v3: >>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bin Meng (9): >>>>>>>>>> sf: Update SST flash params >>>>>>>>>> sf: Update Atmel flash params >>>>>>>>>> sf: Update EON flash params >>>>>>>>>> sf: Update GigaDevice flash params >>>>>>>>>> sf: Update Macronix flash params >>>>>>>>>> sf: Update Spansion flash params >>>>>>>>>> sf: Update Micron flash params >>>>>>>>>> sf: Update Winbond flash params >>>>>>>>>> sf: Give proper spacing between flash table params >>>>>>>>> >>>>>>>>> Thanks for the updates - have you verified these changes? >>>>>>>> >>>>>>>> I verified some, but not all of these flash parts. The update is based >>>>>>>> on flash datasheet, so if something is broken, eg before this series >>>>>>>> the flash advertises only READ_NORM and after my series it is changed >>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>>>>>> likely that the SPI controller driver has some bugs when supporting >>>>>>>> QUAD_IO_FAST. >>>>>>> >>>>>>> Since these updates were tested before, I will skip these for this PR. >>>>>>> Will test all the rest (except these) and send the PR soon. >>>>>>> >>>>>>> Let me know your inputs? >>>>>> >>>>>> I am fine, as long as this PR will not contains other commits which >>>>>> modify the same sf_params.c to introduce more flash support. We can >>>>>> test these updates and if everything looks fine, apply these first and >>>>>> ask other commits to rebase on this series to introduce more flash >>>>>> support. >>>>>> >>>>> >>>>> Do you have any additional comments about this patch series besides >>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send >>>>> the v4. >>>> >>>> I'm thinking about the other flashes too, since these params were taken from >>>> previous working and Linux mtd. >>>> >>> >>> You mean 'thinking about' or 'testing'? I should say previously they >>> might not be 100% working as per datasheet some flash params currently >>> are apparently wrong. >> >> Yes - about testing. >> > > Ping? What about your test results about this patch series?
Some were pending - Will comment, pls- wait.
thanks!
I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?
Could you respond this? I wonder if this series could be merged in before MW is closed.
I feel that you did not work on this. Can you please respond with any comments?
Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!
--
Thanks for checking. Here you are:
http://patchwork.ozlabs.org/patch/419633/ http://patchwork.ozlabs.org/patch/419634/ http://patchwork.ozlabs.org/patch/419635/ http://patchwork.ozlabs.org/patch/419636/ http://patchwork.ozlabs.org/patch/419637/ http://patchwork.ozlabs.org/patch/419638/ http://patchwork.ozlabs.org/patch/419639/ http://patchwork.ozlabs.org/patch/419640/ http://patchwork.ozlabs.org/patch/419641/
They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.
Sorry that I'm in long vacations which is less possible in mailing. As these changes are very crucial, I keep waiting the same.
I will be back on March, end - if still need an urgent sync-up on these changes Tom or Simon please look at the same.
thanks!
Hi Jagan,
On Fri, Mar 6, 2015 at 1:43 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 4 March 2015 at 09:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
+Tom
Hi Jagan,
On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote: > On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>> On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote: >>>> Hi Jagan, >>>> >>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>> On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>> Hi Jagan, >>>>>> >>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>> Hi Jagan, >>>>>>> >>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>> Hi Jagan, >>>>>>>>> >>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>>>> Hi Bin, >>>>>>>>>> >>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>>>> This series update SPI flash supported read commands per datasheet >>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>>>>>>> given SECT_4K. >>>>>>>>>>> >>>>>>>>>>> Changes in v3: >>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bin Meng (9): >>>>>>>>>>> sf: Update SST flash params >>>>>>>>>>> sf: Update Atmel flash params >>>>>>>>>>> sf: Update EON flash params >>>>>>>>>>> sf: Update GigaDevice flash params >>>>>>>>>>> sf: Update Macronix flash params >>>>>>>>>>> sf: Update Spansion flash params >>>>>>>>>>> sf: Update Micron flash params >>>>>>>>>>> sf: Update Winbond flash params >>>>>>>>>>> sf: Give proper spacing between flash table params >>>>>>>>>> >>>>>>>>>> Thanks for the updates - have you verified these changes? >>>>>>>>> >>>>>>>>> I verified some, but not all of these flash parts. The update is based >>>>>>>>> on flash datasheet, so if something is broken, eg before this series >>>>>>>>> the flash advertises only READ_NORM and after my series it is changed >>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>>>>>>> likely that the SPI controller driver has some bugs when supporting >>>>>>>>> QUAD_IO_FAST. >>>>>>>> >>>>>>>> Since these updates were tested before, I will skip these for this PR. >>>>>>>> Will test all the rest (except these) and send the PR soon. >>>>>>>> >>>>>>>> Let me know your inputs? >>>>>>> >>>>>>> I am fine, as long as this PR will not contains other commits which >>>>>>> modify the same sf_params.c to introduce more flash support. We can >>>>>>> test these updates and if everything looks fine, apply these first and >>>>>>> ask other commits to rebase on this series to introduce more flash >>>>>>> support. >>>>>>> >>>>>> >>>>>> Do you have any additional comments about this patch series besides >>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send >>>>>> the v4. >>>>> >>>>> I'm thinking about the other flashes too, since these params were taken from >>>>> previous working and Linux mtd. >>>>> >>>> >>>> You mean 'thinking about' or 'testing'? I should say previously they >>>> might not be 100% working as per datasheet some flash params currently >>>> are apparently wrong. >>> >>> Yes - about testing. >>> >> >> Ping? What about your test results about this patch series? > > Some were pending - Will comment, pls- wait. > > thanks! > --
I still don't see any additional comments. Looking at the history this patch series has been sitting there for months. Would you please let me know what you think about this series?
Could you respond this? I wonder if this series could be merged in before MW is closed.
I feel that you did not work on this. Can you please respond with any comments?
Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!
--
Thanks for checking. Here you are:
http://patchwork.ozlabs.org/patch/419633/ http://patchwork.ozlabs.org/patch/419634/ http://patchwork.ozlabs.org/patch/419635/ http://patchwork.ozlabs.org/patch/419636/ http://patchwork.ozlabs.org/patch/419637/ http://patchwork.ozlabs.org/patch/419638/ http://patchwork.ozlabs.org/patch/419639/ http://patchwork.ozlabs.org/patch/419640/ http://patchwork.ozlabs.org/patch/419641/
They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.
Sorry that I'm in long vacations which is less possible in mailing. As these changes are very crucial, I keep waiting the same.
What are you waiting for? Do you mean you have some sort of testing out there in the background and you don't have complete test result yet?
I will be back on March, end - if still need an urgent sync-up on these changes Tom or Simon please look at the same.
OK, so this series will for sure miss the v2015.04 release (it already missed the v2015.01 release before)
Regards, Bin
On 6 March 2015 at 06:30, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Mar 6, 2015 at 1:43 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 4 March 2015 at 09:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
+Tom
Hi Jagan,
On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >> On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote: >>> Hi Jagan, >>> >>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>> On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote: >>>>> Hi Jagan, >>>>> >>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>> On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>> Hi Jagan, >>>>>>> >>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>> Hi Jagan, >>>>>>>> >>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>>> Hi Bin, >>>>>>>>> >>>>>>>>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>>> Hi Jagan, >>>>>>>>>> >>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>>>>> Hi Bin, >>>>>>>>>>> >>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>>>>> This series update SPI flash supported read commands per datasheet >>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>>>>>>>> given SECT_4K. >>>>>>>>>>>> >>>>>>>>>>>> Changes in v3: >>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Bin Meng (9): >>>>>>>>>>>> sf: Update SST flash params >>>>>>>>>>>> sf: Update Atmel flash params >>>>>>>>>>>> sf: Update EON flash params >>>>>>>>>>>> sf: Update GigaDevice flash params >>>>>>>>>>>> sf: Update Macronix flash params >>>>>>>>>>>> sf: Update Spansion flash params >>>>>>>>>>>> sf: Update Micron flash params >>>>>>>>>>>> sf: Update Winbond flash params >>>>>>>>>>>> sf: Give proper spacing between flash table params >>>>>>>>>>> >>>>>>>>>>> Thanks for the updates - have you verified these changes? >>>>>>>>>> >>>>>>>>>> I verified some, but not all of these flash parts. The update is based >>>>>>>>>> on flash datasheet, so if something is broken, eg before this series >>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed >>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>>>>>>>> likely that the SPI controller driver has some bugs when supporting >>>>>>>>>> QUAD_IO_FAST. >>>>>>>>> >>>>>>>>> Since these updates were tested before, I will skip these for this PR. >>>>>>>>> Will test all the rest (except these) and send the PR soon. >>>>>>>>> >>>>>>>>> Let me know your inputs? >>>>>>>> >>>>>>>> I am fine, as long as this PR will not contains other commits which >>>>>>>> modify the same sf_params.c to introduce more flash support. We can >>>>>>>> test these updates and if everything looks fine, apply these first and >>>>>>>> ask other commits to rebase on this series to introduce more flash >>>>>>>> support. >>>>>>>> >>>>>>> >>>>>>> Do you have any additional comments about this patch series besides >>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send >>>>>>> the v4. >>>>>> >>>>>> I'm thinking about the other flashes too, since these params were taken from >>>>>> previous working and Linux mtd. >>>>>> >>>>> >>>>> You mean 'thinking about' or 'testing'? I should say previously they >>>>> might not be 100% working as per datasheet some flash params currently >>>>> are apparently wrong. >>>> >>>> Yes - about testing. >>>> >>> >>> Ping? What about your test results about this patch series? >> >> Some were pending - Will comment, pls- wait. >> >> thanks! >> -- > > I still don't see any additional comments. Looking at the history this > patch series has been sitting there for months. Would you please let > me know what you think about this series? >
Could you respond this? I wonder if this series could be merged in before MW is closed.
I feel that you did not work on this. Can you please respond with any comments?
Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!
--
Thanks for checking. Here you are:
http://patchwork.ozlabs.org/patch/419633/ http://patchwork.ozlabs.org/patch/419634/ http://patchwork.ozlabs.org/patch/419635/ http://patchwork.ozlabs.org/patch/419636/ http://patchwork.ozlabs.org/patch/419637/ http://patchwork.ozlabs.org/patch/419638/ http://patchwork.ozlabs.org/patch/419639/ http://patchwork.ozlabs.org/patch/419640/ http://patchwork.ozlabs.org/patch/419641/
They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.
Sorry that I'm in long vacations which is less possible in mailing. As these changes are very crucial, I keep waiting the same.
What are you waiting for? Do you mean you have some sort of testing out there in the background and you don't have complete test result yet?
I mean I did some testing, and moved my wedding vacations(currently IN) I will look at it after 25 March, if still you feel these are urgent.
Please test it all possible flashes (atleast once) then may be Tom/Simon will look those (if possible I will comment on testings).
I do have some flashes on my hand to verify but currently I'm busy with my vacations, once I switch back to work may be will look at and finalize the same.
I will be back on March, end - if still need an urgent sync-up on these changes Tom or Simon please look at the same.
OK, so this series will for sure miss the v2015.04 release (it already missed the v2015.01 release before)
thanks!
Hi Jagan,
On Fri, Mar 6, 2015 at 6:21 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 6 March 2015 at 06:30, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Fri, Mar 6, 2015 at 1:43 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
On 4 March 2015 at 09:02, Bin Meng bmeng.cn@gmail.com wrote:
Hi Tom,
On Wed, Mar 4, 2015 at 6:52 AM, Tom Rini trini@konsulko.com wrote:
On Tue, Mar 03, 2015 at 04:31:44PM +0800, Bin Meng wrote:
+Tom
Hi Jagan,
On Tue, Jan 27, 2015 at 9:50 PM, Bin Meng bmeng.cn@gmail.com wrote: > Hi Jagan, > > On Sat, Jan 24, 2015 at 6:34 PM, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Mon, Jan 12, 2015 at 2:52 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>> On 12 January 2015 at 09:12, Bin Meng bmeng.cn@gmail.com wrote: >>>> Hi Jagan, >>>> >>>> On Wed, Dec 17, 2014 at 4:39 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>> On 17 December 2014 at 13:32, Bin Meng bmeng.cn@gmail.com wrote: >>>>>> Hi Jagan, >>>>>> >>>>>> On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>> On 15 December 2014 at 19:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>> Hi Jagan, >>>>>>>> >>>>>>>> On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>> Hi Jagan, >>>>>>>>> >>>>>>>>> On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>>>> Hi Bin, >>>>>>>>>> >>>>>>>>>> On 11 December 2014 at 08:34, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>>>> Hi Jagan, >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.teki@gmail.com wrote: >>>>>>>>>>>> Hi Bin, >>>>>>>>>>>> >>>>>>>>>>>> On 10 December 2014 at 18:21, Bin Meng bmeng.cn@gmail.com wrote: >>>>>>>>>>>>> This series update SPI flash supported read commands per datasheet >>>>>>>>>>>>> in the flash params table, and change flash sector size to 4KiB as >>>>>>>>>>>>> long as flash supports sector erase (20h) command, to ensure >>>>>>>>>>>>> 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when >>>>>>>>>>>>> given SECT_4K. >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in v3: >>>>>>>>>>>>> - Rebase with Jagan's patch series @ http://patchwork.ozlabs.org/patch/419154/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Bin Meng (9): >>>>>>>>>>>>> sf: Update SST flash params >>>>>>>>>>>>> sf: Update Atmel flash params >>>>>>>>>>>>> sf: Update EON flash params >>>>>>>>>>>>> sf: Update GigaDevice flash params >>>>>>>>>>>>> sf: Update Macronix flash params >>>>>>>>>>>>> sf: Update Spansion flash params >>>>>>>>>>>>> sf: Update Micron flash params >>>>>>>>>>>>> sf: Update Winbond flash params >>>>>>>>>>>>> sf: Give proper spacing between flash table params >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the updates - have you verified these changes? >>>>>>>>>>> >>>>>>>>>>> I verified some, but not all of these flash parts. The update is based >>>>>>>>>>> on flash datasheet, so if something is broken, eg before this series >>>>>>>>>>> the flash advertises only READ_NORM and after my series it is changed >>>>>>>>>>> to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very >>>>>>>>>>> likely that the SPI controller driver has some bugs when supporting >>>>>>>>>>> QUAD_IO_FAST. >>>>>>>>>> >>>>>>>>>> Since these updates were tested before, I will skip these for this PR. >>>>>>>>>> Will test all the rest (except these) and send the PR soon. >>>>>>>>>> >>>>>>>>>> Let me know your inputs? >>>>>>>>> >>>>>>>>> I am fine, as long as this PR will not contains other commits which >>>>>>>>> modify the same sf_params.c to introduce more flash support. We can >>>>>>>>> test these updates and if everything looks fine, apply these first and >>>>>>>>> ask other commits to rebase on this series to introduce more flash >>>>>>>>> support. >>>>>>>>> >>>>>>>> >>>>>>>> Do you have any additional comments about this patch series besides >>>>>>>> the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send >>>>>>>> the v4. >>>>>>> >>>>>>> I'm thinking about the other flashes too, since these params were taken from >>>>>>> previous working and Linux mtd. >>>>>>> >>>>>> >>>>>> You mean 'thinking about' or 'testing'? I should say previously they >>>>>> might not be 100% working as per datasheet some flash params currently >>>>>> are apparently wrong. >>>>> >>>>> Yes - about testing. >>>>> >>>> >>>> Ping? What about your test results about this patch series? >>> >>> Some were pending - Will comment, pls- wait. >>> >>> thanks! >>> -- >> >> I still don't see any additional comments. Looking at the history this >> patch series has been sitting there for months. Would you please let >> me know what you think about this series? >> > > Could you respond this? I wonder if this series could be merged in > before MW is closed. >
I feel that you did not work on this. Can you please respond with any comments?
Indeed. This looks like a fairly trivial sync-up, can you shoot me all of the patchwork links and I'll take a look? Thanks!
--
Thanks for checking. Here you are:
http://patchwork.ozlabs.org/patch/419633/ http://patchwork.ozlabs.org/patch/419634/ http://patchwork.ozlabs.org/patch/419635/ http://patchwork.ozlabs.org/patch/419636/ http://patchwork.ozlabs.org/patch/419637/ http://patchwork.ozlabs.org/patch/419638/ http://patchwork.ozlabs.org/patch/419639/ http://patchwork.ozlabs.org/patch/419640/ http://patchwork.ozlabs.org/patch/419641/
They might not be applied cleanly now due to the significant delay since it was originally posted to the mailing list. So far Jagan pointed out only one issue and he said he would continue looking into the patches but I did not receive any feedback for months.
Sorry that I'm in long vacations which is less possible in mailing. As these changes are very crucial, I keep waiting the same.
What are you waiting for? Do you mean you have some sort of testing out there in the background and you don't have complete test result yet?
I mean I did some testing, and moved my wedding vacations(currently IN) I will look at it after 25 March, if still you feel these are urgent.
Please test it all possible flashes (atleast once) then may be Tom/Simon will look those (if possible I will comment on testings).
I do have some flashes on my hand to verify but currently I'm busy with my vacations, once I switch back to work may be will look at and finalize the same.
I will be back on March, end - if still need an urgent sync-up on these changes Tom or Simon please look at the same.
OK, so this series will for sure miss the v2015.04 release (it already missed the v2015.01 release before)
I see you are back. Any further comments before I rebase and give another spin?
Regards, Bin
participants (4)
-
Bin Meng -
Bo Shen -
Jagan Teki -
Tom Rini