* [PATCH v2 0/6] mtd: spi-nor: introduce die erase
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
The patch set is just compiled tested as I don't have a multi die flash
at hand. Takahiro and Fabio, please test the series and let me know if
it works on your side.
This will be followed by the removal of SNOR_F_NO_OP_CHIP_ERASE and
implicitly of the old xilinx SPI NOR driver, but let's take it all in
small bites.
v2:
- iterate over all dices instead of erasing just one
- consider address of die erase command
- fix default value of nor->params->die_erase_opcode
- introduce spi_nor_erase_dice
Fabio Estevam (1):
mtd: spi-nor: micron-st: Add support for mt25qu01g
Tudor Ambarus (5):
mtd: spi-nor: use kernel sized types instead of c99 types
mtd: spi-nor: add erase die (chip) capability
mtd: spi-nor: spansion: enable die erase for multi die flashes
mtd: spi-nor: micron-st: enable die erase for multi die flashes
mtd: spi-nor: remove NO_CHIP_ERASE flag
drivers/mtd/spi-nor/atmel.c | 16 ++---
drivers/mtd/spi-nor/core.c | 112 +++++++++++++++++++++-----------
drivers/mtd/spi-nor/core.h | 22 +++----
drivers/mtd/spi-nor/debugfs.c | 2 +-
drivers/mtd/spi-nor/micron-st.c | 47 ++++++++++++--
drivers/mtd/spi-nor/spansion.c | 4 +-
drivers/mtd/spi-nor/sst.c | 6 +-
drivers/mtd/spi-nor/swp.c | 25 ++++---
8 files changed, 153 insertions(+), 81 deletions(-)
--
2.42.0.820.g83a721a137-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH v2 0/6] mtd: spi-nor: introduce die erase
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
The patch set is just compiled tested as I don't have a multi die flash
at hand. Takahiro and Fabio, please test the series and let me know if
it works on your side.
This will be followed by the removal of SNOR_F_NO_OP_CHIP_ERASE and
implicitly of the old xilinx SPI NOR driver, but let's take it all in
small bites.
v2:
- iterate over all dices instead of erasing just one
- consider address of die erase command
- fix default value of nor->params->die_erase_opcode
- introduce spi_nor_erase_dice
Fabio Estevam (1):
mtd: spi-nor: micron-st: Add support for mt25qu01g
Tudor Ambarus (5):
mtd: spi-nor: use kernel sized types instead of c99 types
mtd: spi-nor: add erase die (chip) capability
mtd: spi-nor: spansion: enable die erase for multi die flashes
mtd: spi-nor: micron-st: enable die erase for multi die flashes
mtd: spi-nor: remove NO_CHIP_ERASE flag
drivers/mtd/spi-nor/atmel.c | 16 ++---
drivers/mtd/spi-nor/core.c | 112 +++++++++++++++++++++-----------
drivers/mtd/spi-nor/core.h | 22 +++----
drivers/mtd/spi-nor/debugfs.c | 2 +-
drivers/mtd/spi-nor/micron-st.c | 47 ++++++++++++--
drivers/mtd/spi-nor/spansion.c | 4 +-
drivers/mtd/spi-nor/sst.c | 6 +-
drivers/mtd/spi-nor/swp.c | 25 ++++---
8 files changed, 153 insertions(+), 81 deletions(-)
--
2.42.0.820.g83a721a137-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* [PATCH v2 1/6] mtd: spi-nor: use kernel sized types instead of c99 types
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 14:58 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
The kernel offers and prefers the kernel sized types instead of the c99
types when not in the uapi directory, use them.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/atmel.c | 16 +++++++---------
drivers/mtd/spi-nor/core.c | 5 ++---
drivers/mtd/spi-nor/core.h | 6 +++---
drivers/mtd/spi-nor/sst.c | 6 +++---
drivers/mtd/spi-nor/swp.c | 25 ++++++++++++-------------
5 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
index e13b8d2dd50a..45d1153a04a0 100644
--- a/drivers/mtd/spi-nor/atmel.c
+++ b/drivers/mtd/spi-nor/atmel.c
@@ -16,12 +16,12 @@
* is to unlock the whole flash array on startup. Therefore, we have to support
* exactly this operation.
*/
-static int at25fs_nor_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int at25fs_nor_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
-static int at25fs_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int at25fs_nor_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
int ret;
@@ -37,7 +37,7 @@ static int at25fs_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
return ret;
}
-static int at25fs_nor_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int at25fs_nor_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
@@ -69,7 +69,7 @@ static const struct spi_nor_fixups at25fs_nor_fixups = {
* Return: 0 on success, -error otherwise.
*/
static int atmel_nor_set_global_protection(struct spi_nor *nor, loff_t ofs,
- uint64_t len, bool is_protect)
+ u64 len, bool is_protect)
{
int ret;
u8 sr;
@@ -118,20 +118,18 @@ static int atmel_nor_set_global_protection(struct spi_nor *nor, loff_t ofs,
return spi_nor_write_sr(nor, nor->bouncebuf, 1);
}
-static int atmel_nor_global_protect(struct spi_nor *nor, loff_t ofs,
- uint64_t len)
+static int atmel_nor_global_protect(struct spi_nor *nor, loff_t ofs, u64 len)
{
return atmel_nor_set_global_protection(nor, ofs, len, true);
}
-static int atmel_nor_global_unprotect(struct spi_nor *nor, loff_t ofs,
- uint64_t len)
+static int atmel_nor_global_unprotect(struct spi_nor *nor, loff_t ofs, u64 len)
{
return atmel_nor_set_global_protection(nor, ofs, len, false);
}
static int atmel_nor_is_global_protected(struct spi_nor *nor, loff_t ofs,
- uint64_t len)
+ u64 len)
{
int ret;
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 1c443fe568cf..25a64c65717d 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1799,8 +1799,7 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
- u32 addr, len;
- uint32_t rem;
+ u32 addr, len, rem;
int ret;
dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
@@ -2146,7 +2145,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
if (is_power_of_2(page_size)) {
page_offset = addr & (page_size - 1);
} else {
- uint64_t aux = addr;
+ u64 aux = addr;
page_offset = do_div(aux, page_size);
}
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 93cd2fc3606d..a456042379ee 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -293,9 +293,9 @@ struct spi_nor_erase_map {
* @is_locked: check if a region of the SPI NOR is completely locked
*/
struct spi_nor_locking_ops {
- int (*lock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
- int (*unlock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
- int (*is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
+ int (*lock)(struct spi_nor *nor, loff_t ofs, u64 len);
+ int (*unlock)(struct spi_nor *nor, loff_t ofs, u64 len);
+ int (*is_locked)(struct spi_nor *nor, loff_t ofs, u64 len);
};
/**
diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
index 44d2a546bf17..180b7390690c 100644
--- a/drivers/mtd/spi-nor/sst.c
+++ b/drivers/mtd/spi-nor/sst.c
@@ -13,12 +13,12 @@
#define SST26VF_CR_BPNV BIT(3)
-static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
-static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
int ret;
@@ -38,7 +38,7 @@ static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
return spi_nor_global_block_unlock(nor);
}
-static int sst26vf_nor_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int sst26vf_nor_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
index 585813310ee1..e48c3cff247a 100644
--- a/drivers/mtd/spi-nor/swp.c
+++ b/drivers/mtd/spi-nor/swp.c
@@ -53,7 +53,7 @@ static u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor)
}
static void spi_nor_get_locked_range_sr(struct spi_nor *nor, u8 sr, loff_t *ofs,
- uint64_t *len)
+ u64 *len)
{
struct mtd_info *mtd = &nor->mtd;
u64 min_prot_len;
@@ -90,10 +90,10 @@ static void spi_nor_get_locked_range_sr(struct spi_nor *nor, u8 sr, loff_t *ofs,
* (if @locked is false); false otherwise.
*/
static bool spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
- uint64_t len, u8 sr, bool locked)
+ u64 len, u8 sr, bool locked)
{
loff_t lock_offs, lock_offs_max, offs_max;
- uint64_t lock_len;
+ u64 lock_len;
if (!len)
return true;
@@ -111,14 +111,13 @@ static bool spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
return (ofs >= lock_offs_max) || (offs_max <= lock_offs);
}
-static bool spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
- u8 sr)
+static bool spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, u64 len, u8 sr)
{
return spi_nor_check_lock_status_sr(nor, ofs, len, sr, true);
}
-static bool spi_nor_is_unlocked_sr(struct spi_nor *nor, loff_t ofs,
- uint64_t len, u8 sr)
+static bool spi_nor_is_unlocked_sr(struct spi_nor *nor, loff_t ofs, u64 len,
+ u8 sr)
{
return spi_nor_check_lock_status_sr(nor, ofs, len, sr, false);
}
@@ -156,7 +155,7 @@ static bool spi_nor_is_unlocked_sr(struct spi_nor *nor, loff_t ofs,
*
* Returns negative on errors, 0 on success.
*/
-static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
struct mtd_info *mtd = &nor->mtd;
u64 min_prot_len;
@@ -246,7 +245,7 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
*
* Returns negative on errors, 0 on success.
*/
-static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
struct mtd_info *mtd = &nor->mtd;
u64 min_prot_len;
@@ -331,7 +330,7 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
* Returns 1 if entire region is locked, 0 if any portion is unlocked, and
* negative on errors.
*/
-static int spi_nor_sr_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int spi_nor_sr_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
{
int ret;
@@ -353,7 +352,7 @@ void spi_nor_init_default_locking_ops(struct spi_nor *nor)
nor->params->locking_ops = &spi_nor_sr_locking_ops;
}
-static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, u64 len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
@@ -368,7 +367,7 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
return ret;
}
-static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, u64 len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
@@ -383,7 +382,7 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
return ret;
}
-static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, u64 len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
--
2.42.0.820.g83a721a137-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 1/6] mtd: spi-nor: use kernel sized types instead of c99 types
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
The kernel offers and prefers the kernel sized types instead of the c99
types when not in the uapi directory, use them.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/atmel.c | 16 +++++++---------
drivers/mtd/spi-nor/core.c | 5 ++---
drivers/mtd/spi-nor/core.h | 6 +++---
drivers/mtd/spi-nor/sst.c | 6 +++---
drivers/mtd/spi-nor/swp.c | 25 ++++++++++++-------------
5 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
index e13b8d2dd50a..45d1153a04a0 100644
--- a/drivers/mtd/spi-nor/atmel.c
+++ b/drivers/mtd/spi-nor/atmel.c
@@ -16,12 +16,12 @@
* is to unlock the whole flash array on startup. Therefore, we have to support
* exactly this operation.
*/
-static int at25fs_nor_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int at25fs_nor_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
-static int at25fs_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int at25fs_nor_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
int ret;
@@ -37,7 +37,7 @@ static int at25fs_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
return ret;
}
-static int at25fs_nor_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int at25fs_nor_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
@@ -69,7 +69,7 @@ static const struct spi_nor_fixups at25fs_nor_fixups = {
* Return: 0 on success, -error otherwise.
*/
static int atmel_nor_set_global_protection(struct spi_nor *nor, loff_t ofs,
- uint64_t len, bool is_protect)
+ u64 len, bool is_protect)
{
int ret;
u8 sr;
@@ -118,20 +118,18 @@ static int atmel_nor_set_global_protection(struct spi_nor *nor, loff_t ofs,
return spi_nor_write_sr(nor, nor->bouncebuf, 1);
}
-static int atmel_nor_global_protect(struct spi_nor *nor, loff_t ofs,
- uint64_t len)
+static int atmel_nor_global_protect(struct spi_nor *nor, loff_t ofs, u64 len)
{
return atmel_nor_set_global_protection(nor, ofs, len, true);
}
-static int atmel_nor_global_unprotect(struct spi_nor *nor, loff_t ofs,
- uint64_t len)
+static int atmel_nor_global_unprotect(struct spi_nor *nor, loff_t ofs, u64 len)
{
return atmel_nor_set_global_protection(nor, ofs, len, false);
}
static int atmel_nor_is_global_protected(struct spi_nor *nor, loff_t ofs,
- uint64_t len)
+ u64 len)
{
int ret;
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 1c443fe568cf..25a64c65717d 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1799,8 +1799,7 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
- u32 addr, len;
- uint32_t rem;
+ u32 addr, len, rem;
int ret;
dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
@@ -2146,7 +2145,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
if (is_power_of_2(page_size)) {
page_offset = addr & (page_size - 1);
} else {
- uint64_t aux = addr;
+ u64 aux = addr;
page_offset = do_div(aux, page_size);
}
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 93cd2fc3606d..a456042379ee 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -293,9 +293,9 @@ struct spi_nor_erase_map {
* @is_locked: check if a region of the SPI NOR is completely locked
*/
struct spi_nor_locking_ops {
- int (*lock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
- int (*unlock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
- int (*is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
+ int (*lock)(struct spi_nor *nor, loff_t ofs, u64 len);
+ int (*unlock)(struct spi_nor *nor, loff_t ofs, u64 len);
+ int (*is_locked)(struct spi_nor *nor, loff_t ofs, u64 len);
};
/**
diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
index 44d2a546bf17..180b7390690c 100644
--- a/drivers/mtd/spi-nor/sst.c
+++ b/drivers/mtd/spi-nor/sst.c
@@ -13,12 +13,12 @@
#define SST26VF_CR_BPNV BIT(3)
-static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int sst26vf_nor_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
-static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
int ret;
@@ -38,7 +38,7 @@ static int sst26vf_nor_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
return spi_nor_global_block_unlock(nor);
}
-static int sst26vf_nor_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int sst26vf_nor_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
{
return -EOPNOTSUPP;
}
diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
index 585813310ee1..e48c3cff247a 100644
--- a/drivers/mtd/spi-nor/swp.c
+++ b/drivers/mtd/spi-nor/swp.c
@@ -53,7 +53,7 @@ static u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor)
}
static void spi_nor_get_locked_range_sr(struct spi_nor *nor, u8 sr, loff_t *ofs,
- uint64_t *len)
+ u64 *len)
{
struct mtd_info *mtd = &nor->mtd;
u64 min_prot_len;
@@ -90,10 +90,10 @@ static void spi_nor_get_locked_range_sr(struct spi_nor *nor, u8 sr, loff_t *ofs,
* (if @locked is false); false otherwise.
*/
static bool spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
- uint64_t len, u8 sr, bool locked)
+ u64 len, u8 sr, bool locked)
{
loff_t lock_offs, lock_offs_max, offs_max;
- uint64_t lock_len;
+ u64 lock_len;
if (!len)
return true;
@@ -111,14 +111,13 @@ static bool spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
return (ofs >= lock_offs_max) || (offs_max <= lock_offs);
}
-static bool spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
- u8 sr)
+static bool spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, u64 len, u8 sr)
{
return spi_nor_check_lock_status_sr(nor, ofs, len, sr, true);
}
-static bool spi_nor_is_unlocked_sr(struct spi_nor *nor, loff_t ofs,
- uint64_t len, u8 sr)
+static bool spi_nor_is_unlocked_sr(struct spi_nor *nor, loff_t ofs, u64 len,
+ u8 sr)
{
return spi_nor_check_lock_status_sr(nor, ofs, len, sr, false);
}
@@ -156,7 +155,7 @@ static bool spi_nor_is_unlocked_sr(struct spi_nor *nor, loff_t ofs,
*
* Returns negative on errors, 0 on success.
*/
-static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
struct mtd_info *mtd = &nor->mtd;
u64 min_prot_len;
@@ -246,7 +245,7 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
*
* Returns negative on errors, 0 on success.
*/
-static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
struct mtd_info *mtd = &nor->mtd;
u64 min_prot_len;
@@ -331,7 +330,7 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
* Returns 1 if entire region is locked, 0 if any portion is unlocked, and
* negative on errors.
*/
-static int spi_nor_sr_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+static int spi_nor_sr_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
{
int ret;
@@ -353,7 +352,7 @@ void spi_nor_init_default_locking_ops(struct spi_nor *nor)
nor->params->locking_ops = &spi_nor_sr_locking_ops;
}
-static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, u64 len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
@@ -368,7 +367,7 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
return ret;
}
-static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, u64 len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
@@ -383,7 +382,7 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
return ret;
}
-static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, u64 len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
--
2.42.0.820.g83a721a137-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 14:58 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
JESD216 defines a chip as a die, one and the other are the same thing.
JESD216 clarifies that the chip erase time defined in BFPT dword(11)
applies separately to each die for multi-die devices in which the dice
are individually accessed. Based on this, update the
spi_nor_erase_chip() method to support multi-die devices.
For now, benefit of the die erase when addr and len are aligned with die
size. This could be improved however for the uniform and non-uniform
erases cases to use the die erase when possible. For example if one
requests that an erase of a 2 die device starting from the last 64KB of
the first die to the end of the flash size, we could use just 2
commands, a 64KB erase and a die erase. This improvement is left as an
exercise for the reader, as I don't have multi die flashes at hand.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/core.c | 104 +++++++++++++++++++++++-----------
drivers/mtd/spi-nor/core.h | 8 ++-
drivers/mtd/spi-nor/debugfs.c | 2 +-
3 files changed, 78 insertions(+), 36 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 25a64c65717d..ac2651e76285 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1065,19 +1065,25 @@ static int spi_nor_read_sr2(struct spi_nor *nor, u8 *sr2)
*
* Return: 0 on success, -errno otherwise.
*/
-static int spi_nor_erase_chip(struct spi_nor *nor)
+static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t die_size)
{
+ bool multi_die = nor->mtd.size == die_size;
int ret;
- dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
+ dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
if (nor->spimem) {
- struct spi_mem_op op = SPI_NOR_CHIP_ERASE_OP;
+ struct spi_mem_op op =
+ SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
+ nor->addr_nbytes, addr, multi_die);
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
+ if (multi_die)
+ return -EOPNOTSUPP;
+
ret = spi_nor_controller_ops_write_reg(nor,
SPINOR_OP_CHIP_ERASE,
NULL, 0);
@@ -1792,6 +1798,51 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len)
return ret;
}
+static int spi_nor_erase_dice(struct spi_nor *nor, loff_t addr,
+ size_t len, size_t die_size)
+{
+ unsigned long timeout;
+ int ret;
+
+ /*
+ * Scale the timeout linearly with the size of the flash, with
+ * a minimum calibrated to an old 2MB flash. We could try to
+ * pull these from CFI/SFDP, but these values should be good
+ * enough for now.
+ */
+ timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES,
+ CHIP_ERASE_2MB_READY_WAIT_JIFFIES *
+ (unsigned long)(nor->mtd.size / SZ_2M));
+
+ do {
+ ret = spi_nor_lock_device(nor);
+ if (ret)
+ return ret;
+
+ ret = spi_nor_write_enable(nor);
+ if (ret) {
+ spi_nor_unlock_device(nor);
+ return ret;
+ }
+
+ ret = spi_nor_erase_die(nor, addr, die_size);
+
+ spi_nor_unlock_device(nor);
+ if (ret)
+ return ret;
+
+ ret = spi_nor_wait_till_ready_with_timeout(nor, timeout);
+ if (ret)
+ return ret;
+
+ addr += die_size;
+ len -= die_size;
+
+ } while (len);
+
+ return 0;
+}
+
/*
* Erase an address range on the nor chip. The address range may extend
* one or more erase sectors. Return an error if there is a problem erasing.
@@ -1799,7 +1850,10 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
+ u8 n_dice = nor->params->n_dice;
+ bool multi_die_erase = false;
u32 addr, len, rem;
+ size_t die_size;
int ret;
dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
@@ -1814,39 +1868,22 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
addr = instr->addr;
len = instr->len;
+ if (n_dice) {
+ die_size = div_u64(mtd->size, n_dice);
+ if (len == die_size && (addr & (die_size - 1)))
+ multi_die_erase = true;
+ } else {
+ die_size = mtd->size;
+ }
+
ret = spi_nor_prep_and_lock_pe(nor, instr->addr, instr->len);
if (ret)
return ret;
- /* whole-chip erase? */
- if (len == mtd->size && !(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) {
- unsigned long timeout;
-
- ret = spi_nor_lock_device(nor);
- if (ret)
- goto erase_err;
-
- ret = spi_nor_write_enable(nor);
- if (ret) {
- spi_nor_unlock_device(nor);
- goto erase_err;
- }
-
- ret = spi_nor_erase_chip(nor);
- spi_nor_unlock_device(nor);
- if (ret)
- goto erase_err;
-
- /*
- * Scale the timeout linearly with the size of the flash, with
- * a minimum calibrated to an old 2MB flash. We could try to
- * pull these from CFI/SFDP, but these values should be good
- * enough for now.
- */
- timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES,
- CHIP_ERASE_2MB_READY_WAIT_JIFFIES *
- (unsigned long)(mtd->size / SZ_2M));
- ret = spi_nor_wait_till_ready_with_timeout(nor, timeout);
+ /* chip (die) erase? */
+ if ((len == mtd->size && !(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) ||
+ multi_die_erase) {
+ ret = spi_nor_erase_dice(nor, addr, len, die_size);
if (ret)
goto erase_err;
@@ -2902,6 +2939,9 @@ static int spi_nor_late_init_params(struct spi_nor *nor)
return ret;
}
+ if (!nor->params->die_erase_opcode)
+ nor->params->die_erase_opcode = SPINOR_OP_CHIP_ERASE;
+
/* Default method kept for backward compatibility. */
if (!params->set_4byte_addr_mode)
params->set_4byte_addr_mode = spi_nor_set_4byte_addr_mode_brwr;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index a456042379ee..b43ea2d49e74 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -85,9 +85,9 @@
SPI_MEM_OP_NO_DUMMY, \
SPI_MEM_OP_NO_DATA)
-#define SPI_NOR_CHIP_ERASE_OP \
- SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_CHIP_ERASE, 0), \
- SPI_MEM_OP_NO_ADDR, \
+#define SPI_NOR_DIE_ERASE_OP(opcode, addr_nbytes, addr, dice) \
+ SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), \
+ SPI_MEM_OP_ADDR(dice ? addr_nbytes : 0, addr, 0), \
SPI_MEM_OP_NO_DUMMY, \
SPI_MEM_OP_NO_DATA)
@@ -362,6 +362,7 @@ struct spi_nor_otp {
* command in octal DTR mode.
* @n_banks: number of banks.
* @n_dice: number of dice in the flash memory.
+ * @die_erase_opcode: die erase opcode. Defaults to SPINOR_OP_CHIP_ERASE.
* @vreg_offset: volatile register offset for each die.
* @hwcaps: describes the read and page program hardware
* capabilities.
@@ -399,6 +400,7 @@ struct spi_nor_flash_parameter {
u8 rdsr_addr_nbytes;
u8 n_banks;
u8 n_dice;
+ u8 die_erase_opcode;
u32 *vreg_offset;
struct spi_nor_hwcaps hwcaps;
diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c
index 6e163cb5b478..2dbda6b6938a 100644
--- a/drivers/mtd/spi-nor/debugfs.c
+++ b/drivers/mtd/spi-nor/debugfs.c
@@ -138,7 +138,7 @@ static int spi_nor_params_show(struct seq_file *s, void *data)
if (!(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) {
string_get_size(params->size, 1, STRING_UNITS_2, buf, sizeof(buf));
- seq_printf(s, " %02x (%s)\n", SPINOR_OP_CHIP_ERASE, buf);
+ seq_printf(s, " %02x (%s)\n", nor->params->die_erase_opcode, buf);
}
seq_puts(s, "\nsector map\n");
--
2.42.0.820.g83a721a137-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
JESD216 defines a chip as a die, one and the other are the same thing.
JESD216 clarifies that the chip erase time defined in BFPT dword(11)
applies separately to each die for multi-die devices in which the dice
are individually accessed. Based on this, update the
spi_nor_erase_chip() method to support multi-die devices.
For now, benefit of the die erase when addr and len are aligned with die
size. This could be improved however for the uniform and non-uniform
erases cases to use the die erase when possible. For example if one
requests that an erase of a 2 die device starting from the last 64KB of
the first die to the end of the flash size, we could use just 2
commands, a 64KB erase and a die erase. This improvement is left as an
exercise for the reader, as I don't have multi die flashes at hand.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/core.c | 104 +++++++++++++++++++++++-----------
drivers/mtd/spi-nor/core.h | 8 ++-
drivers/mtd/spi-nor/debugfs.c | 2 +-
3 files changed, 78 insertions(+), 36 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 25a64c65717d..ac2651e76285 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1065,19 +1065,25 @@ static int spi_nor_read_sr2(struct spi_nor *nor, u8 *sr2)
*
* Return: 0 on success, -errno otherwise.
*/
-static int spi_nor_erase_chip(struct spi_nor *nor)
+static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t die_size)
{
+ bool multi_die = nor->mtd.size == die_size;
int ret;
- dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
+ dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
if (nor->spimem) {
- struct spi_mem_op op = SPI_NOR_CHIP_ERASE_OP;
+ struct spi_mem_op op =
+ SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
+ nor->addr_nbytes, addr, multi_die);
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
+ if (multi_die)
+ return -EOPNOTSUPP;
+
ret = spi_nor_controller_ops_write_reg(nor,
SPINOR_OP_CHIP_ERASE,
NULL, 0);
@@ -1792,6 +1798,51 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len)
return ret;
}
+static int spi_nor_erase_dice(struct spi_nor *nor, loff_t addr,
+ size_t len, size_t die_size)
+{
+ unsigned long timeout;
+ int ret;
+
+ /*
+ * Scale the timeout linearly with the size of the flash, with
+ * a minimum calibrated to an old 2MB flash. We could try to
+ * pull these from CFI/SFDP, but these values should be good
+ * enough for now.
+ */
+ timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES,
+ CHIP_ERASE_2MB_READY_WAIT_JIFFIES *
+ (unsigned long)(nor->mtd.size / SZ_2M));
+
+ do {
+ ret = spi_nor_lock_device(nor);
+ if (ret)
+ return ret;
+
+ ret = spi_nor_write_enable(nor);
+ if (ret) {
+ spi_nor_unlock_device(nor);
+ return ret;
+ }
+
+ ret = spi_nor_erase_die(nor, addr, die_size);
+
+ spi_nor_unlock_device(nor);
+ if (ret)
+ return ret;
+
+ ret = spi_nor_wait_till_ready_with_timeout(nor, timeout);
+ if (ret)
+ return ret;
+
+ addr += die_size;
+ len -= die_size;
+
+ } while (len);
+
+ return 0;
+}
+
/*
* Erase an address range on the nor chip. The address range may extend
* one or more erase sectors. Return an error if there is a problem erasing.
@@ -1799,7 +1850,10 @@ static int spi_nor_erase_multi_sectors(struct spi_nor *nor, u64 addr, u32 len)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
+ u8 n_dice = nor->params->n_dice;
+ bool multi_die_erase = false;
u32 addr, len, rem;
+ size_t die_size;
int ret;
dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
@@ -1814,39 +1868,22 @@ static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
addr = instr->addr;
len = instr->len;
+ if (n_dice) {
+ die_size = div_u64(mtd->size, n_dice);
+ if (len == die_size && (addr & (die_size - 1)))
+ multi_die_erase = true;
+ } else {
+ die_size = mtd->size;
+ }
+
ret = spi_nor_prep_and_lock_pe(nor, instr->addr, instr->len);
if (ret)
return ret;
- /* whole-chip erase? */
- if (len == mtd->size && !(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) {
- unsigned long timeout;
-
- ret = spi_nor_lock_device(nor);
- if (ret)
- goto erase_err;
-
- ret = spi_nor_write_enable(nor);
- if (ret) {
- spi_nor_unlock_device(nor);
- goto erase_err;
- }
-
- ret = spi_nor_erase_chip(nor);
- spi_nor_unlock_device(nor);
- if (ret)
- goto erase_err;
-
- /*
- * Scale the timeout linearly with the size of the flash, with
- * a minimum calibrated to an old 2MB flash. We could try to
- * pull these from CFI/SFDP, but these values should be good
- * enough for now.
- */
- timeout = max(CHIP_ERASE_2MB_READY_WAIT_JIFFIES,
- CHIP_ERASE_2MB_READY_WAIT_JIFFIES *
- (unsigned long)(mtd->size / SZ_2M));
- ret = spi_nor_wait_till_ready_with_timeout(nor, timeout);
+ /* chip (die) erase? */
+ if ((len == mtd->size && !(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) ||
+ multi_die_erase) {
+ ret = spi_nor_erase_dice(nor, addr, len, die_size);
if (ret)
goto erase_err;
@@ -2902,6 +2939,9 @@ static int spi_nor_late_init_params(struct spi_nor *nor)
return ret;
}
+ if (!nor->params->die_erase_opcode)
+ nor->params->die_erase_opcode = SPINOR_OP_CHIP_ERASE;
+
/* Default method kept for backward compatibility. */
if (!params->set_4byte_addr_mode)
params->set_4byte_addr_mode = spi_nor_set_4byte_addr_mode_brwr;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index a456042379ee..b43ea2d49e74 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -85,9 +85,9 @@
SPI_MEM_OP_NO_DUMMY, \
SPI_MEM_OP_NO_DATA)
-#define SPI_NOR_CHIP_ERASE_OP \
- SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_CHIP_ERASE, 0), \
- SPI_MEM_OP_NO_ADDR, \
+#define SPI_NOR_DIE_ERASE_OP(opcode, addr_nbytes, addr, dice) \
+ SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), \
+ SPI_MEM_OP_ADDR(dice ? addr_nbytes : 0, addr, 0), \
SPI_MEM_OP_NO_DUMMY, \
SPI_MEM_OP_NO_DATA)
@@ -362,6 +362,7 @@ struct spi_nor_otp {
* command in octal DTR mode.
* @n_banks: number of banks.
* @n_dice: number of dice in the flash memory.
+ * @die_erase_opcode: die erase opcode. Defaults to SPINOR_OP_CHIP_ERASE.
* @vreg_offset: volatile register offset for each die.
* @hwcaps: describes the read and page program hardware
* capabilities.
@@ -399,6 +400,7 @@ struct spi_nor_flash_parameter {
u8 rdsr_addr_nbytes;
u8 n_banks;
u8 n_dice;
+ u8 die_erase_opcode;
u32 *vreg_offset;
struct spi_nor_hwcaps hwcaps;
diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c
index 6e163cb5b478..2dbda6b6938a 100644
--- a/drivers/mtd/spi-nor/debugfs.c
+++ b/drivers/mtd/spi-nor/debugfs.c
@@ -138,7 +138,7 @@ static int spi_nor_params_show(struct seq_file *s, void *data)
if (!(nor->flags & SNOR_F_NO_OP_CHIP_ERASE)) {
string_get_size(params->size, 1, STRING_UNITS_2, buf, sizeof(buf));
- seq_printf(s, " %02x (%s)\n", SPINOR_OP_CHIP_ERASE, buf);
+ seq_printf(s, " %02x (%s)\n", nor->params->die_erase_opcode, buf);
}
seq_puts(s, "\nsector map\n");
--
2.42.0.820.g83a721a137-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 3/6] mtd: spi-nor: spansion: enable die erase for multi die flashes
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 14:58 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
Enable die erase for spansion multi die flashes.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/spansion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 12921344373d..6cc237c24e07 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -17,6 +17,7 @@
#define SPINOR_OP_CLSR 0x30 /* Clear status register 1 */
#define SPINOR_OP_CLPEF 0x82 /* Clear program/erase failure flags */
+#define SPINOR_OP_CYPRESS_DIE_ERASE 0x61 /* Chip (die) erase */
#define SPINOR_OP_RD_ANY_REG 0x65 /* Read any register */
#define SPINOR_OP_WR_ANY_REG 0x71 /* Write any register */
#define SPINOR_REG_CYPRESS_VREG 0x00800000
@@ -644,6 +645,7 @@ static int s25hx_t_late_init(struct spi_nor *nor)
params->ready = cypress_nor_sr_ready_and_clear;
cypress_nor_ecc_init(nor);
+ params->die_erase_opcode = SPINOR_OP_CYPRESS_DIE_ERASE;
return 0;
}
@@ -933,7 +935,6 @@ static const struct flash_info spansion_nor_parts[] = {
.id = SNOR_ID(0x34, 0x2a, 0x1c, 0x0f, 0x00, 0x90),
.name = "s25hl02gt",
.mfr_flags = USE_CLPEF,
- .flags = NO_CHIP_ERASE,
.fixups = &s25hx_t_fixups
}, {
.id = SNOR_ID(0x34, 0x2b, 0x19, 0x0f, 0x08, 0x90),
@@ -954,7 +955,6 @@ static const struct flash_info spansion_nor_parts[] = {
.id = SNOR_ID(0x34, 0x2b, 0x1c, 0x0f, 0x00, 0x90),
.name = "s25hs02gt",
.mfr_flags = USE_CLPEF,
- .flags = NO_CHIP_ERASE,
.fixups = &s25hx_t_fixups
}, {
.id = SNOR_ID(0x34, 0x5a, 0x1a),
--
2.42.0.820.g83a721a137-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 3/6] mtd: spi-nor: spansion: enable die erase for multi die flashes
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
Enable die erase for spansion multi die flashes.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/spansion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 12921344373d..6cc237c24e07 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -17,6 +17,7 @@
#define SPINOR_OP_CLSR 0x30 /* Clear status register 1 */
#define SPINOR_OP_CLPEF 0x82 /* Clear program/erase failure flags */
+#define SPINOR_OP_CYPRESS_DIE_ERASE 0x61 /* Chip (die) erase */
#define SPINOR_OP_RD_ANY_REG 0x65 /* Read any register */
#define SPINOR_OP_WR_ANY_REG 0x71 /* Write any register */
#define SPINOR_REG_CYPRESS_VREG 0x00800000
@@ -644,6 +645,7 @@ static int s25hx_t_late_init(struct spi_nor *nor)
params->ready = cypress_nor_sr_ready_and_clear;
cypress_nor_ecc_init(nor);
+ params->die_erase_opcode = SPINOR_OP_CYPRESS_DIE_ERASE;
return 0;
}
@@ -933,7 +935,6 @@ static const struct flash_info spansion_nor_parts[] = {
.id = SNOR_ID(0x34, 0x2a, 0x1c, 0x0f, 0x00, 0x90),
.name = "s25hl02gt",
.mfr_flags = USE_CLPEF,
- .flags = NO_CHIP_ERASE,
.fixups = &s25hx_t_fixups
}, {
.id = SNOR_ID(0x34, 0x2b, 0x19, 0x0f, 0x08, 0x90),
@@ -954,7 +955,6 @@ static const struct flash_info spansion_nor_parts[] = {
.id = SNOR_ID(0x34, 0x2b, 0x1c, 0x0f, 0x00, 0x90),
.name = "s25hs02gt",
.mfr_flags = USE_CLPEF,
- .flags = NO_CHIP_ERASE,
.fixups = &s25hx_t_fixups
}, {
.id = SNOR_ID(0x34, 0x5a, 0x1a),
--
2.42.0.820.g83a721a137-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 4/6] mtd: spi-nor: micron-st: enable die erase for multi die flashes
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 14:58 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
Enable die erase for multi die flashes, it will speed the erase time.
Link: https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_1gb_3v_65nm.pdf?rev=b6eba74759984f749f8c039bc5bc47b7
Link: https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_l_02g_cbb_0.pdf?rev=43f7f66fc8da4d7d901b35fa51284c8f
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/micron-st.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 8920547c12bf..ab8a53f0c99f 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -11,6 +11,7 @@
/* flash_info mfr_flag. Used to read proprietary FSR register. */
#define USE_FSR BIT(0)
+#define SPINOR_OP_MT_DIE_ERASE 0xc4 /* Chip (die) erase opcode */
#define SPINOR_OP_RDFSR 0x70 /* Read flag status register */
#define SPINOR_OP_CLFSR 0x50 /* Clear flag status register */
#define SPINOR_OP_MT_DTR_RD 0xfd /* Fast Read opcode in DTR mode */
@@ -192,6 +193,24 @@ static struct spi_nor_fixups mt25qu512a_fixups = {
.post_bfpt = mt25qu512a_post_bfpt_fixup,
};
+static int st_nor_four_die_late_init(struct spi_nor *nor)
+{
+ struct spi_nor_flash_parameter *params = nor->params;
+
+ params->die_erase_opcode = SPINOR_OP_MT_DIE_ERASE;
+ params->n_dice = 4;
+
+ return 0;
+}
+
+static struct spi_nor_fixups n25q00_fixups = {
+ .late_init = st_nor_four_die_late_init,
+};
+
+static struct spi_nor_fixups mt25q02_fixups = {
+ .late_init = st_nor_four_die_late_init,
+};
+
static const struct flash_info st_nor_parts[] = {
{
.name = "m25p05-nonjedec",
@@ -366,16 +385,17 @@ static const struct flash_info st_nor_parts[] = {
.name = "n25q00",
.size = SZ_128M,
.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
- SPI_NOR_BP3_SR_BIT6 | NO_CHIP_ERASE,
+ SPI_NOR_BP3_SR_BIT6,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &n25q00_fixups,
}, {
.id = SNOR_ID(0x20, 0xba, 0x22),
.name = "mt25ql02g",
.size = SZ_256M,
- .flags = NO_CHIP_ERASE,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &mt25q02_fixups,
}, {
.id = SNOR_ID(0x20, 0xbb, 0x15),
.name = "n25q016a",
@@ -433,16 +453,16 @@ static const struct flash_info st_nor_parts[] = {
.id = SNOR_ID(0x20, 0xbb, 0x21),
.name = "n25q00a",
.size = SZ_128M,
- .flags = NO_CHIP_ERASE,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &n25q00_fixups,
}, {
.id = SNOR_ID(0x20, 0xbb, 0x22),
.name = "mt25qu02g",
.size = SZ_256M,
- .flags = NO_CHIP_ERASE,
.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &mt25q02_fixups,
}
};
--
2.42.0.820.g83a721a137-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 4/6] mtd: spi-nor: micron-st: enable die erase for multi die flashes
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
Enable die erase for multi die flashes, it will speed the erase time.
Link: https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_1gb_3v_65nm.pdf?rev=b6eba74759984f749f8c039bc5bc47b7
Link: https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_l_02g_cbb_0.pdf?rev=43f7f66fc8da4d7d901b35fa51284c8f
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/micron-st.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 8920547c12bf..ab8a53f0c99f 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -11,6 +11,7 @@
/* flash_info mfr_flag. Used to read proprietary FSR register. */
#define USE_FSR BIT(0)
+#define SPINOR_OP_MT_DIE_ERASE 0xc4 /* Chip (die) erase opcode */
#define SPINOR_OP_RDFSR 0x70 /* Read flag status register */
#define SPINOR_OP_CLFSR 0x50 /* Clear flag status register */
#define SPINOR_OP_MT_DTR_RD 0xfd /* Fast Read opcode in DTR mode */
@@ -192,6 +193,24 @@ static struct spi_nor_fixups mt25qu512a_fixups = {
.post_bfpt = mt25qu512a_post_bfpt_fixup,
};
+static int st_nor_four_die_late_init(struct spi_nor *nor)
+{
+ struct spi_nor_flash_parameter *params = nor->params;
+
+ params->die_erase_opcode = SPINOR_OP_MT_DIE_ERASE;
+ params->n_dice = 4;
+
+ return 0;
+}
+
+static struct spi_nor_fixups n25q00_fixups = {
+ .late_init = st_nor_four_die_late_init,
+};
+
+static struct spi_nor_fixups mt25q02_fixups = {
+ .late_init = st_nor_four_die_late_init,
+};
+
static const struct flash_info st_nor_parts[] = {
{
.name = "m25p05-nonjedec",
@@ -366,16 +385,17 @@ static const struct flash_info st_nor_parts[] = {
.name = "n25q00",
.size = SZ_128M,
.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
- SPI_NOR_BP3_SR_BIT6 | NO_CHIP_ERASE,
+ SPI_NOR_BP3_SR_BIT6,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &n25q00_fixups,
}, {
.id = SNOR_ID(0x20, 0xba, 0x22),
.name = "mt25ql02g",
.size = SZ_256M,
- .flags = NO_CHIP_ERASE,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &mt25q02_fixups,
}, {
.id = SNOR_ID(0x20, 0xbb, 0x15),
.name = "n25q016a",
@@ -433,16 +453,16 @@ static const struct flash_info st_nor_parts[] = {
.id = SNOR_ID(0x20, 0xbb, 0x21),
.name = "n25q00a",
.size = SZ_128M,
- .flags = NO_CHIP_ERASE,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &n25q00_fixups,
}, {
.id = SNOR_ID(0x20, 0xbb, 0x22),
.name = "mt25qu02g",
.size = SZ_256M,
- .flags = NO_CHIP_ERASE,
.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ .fixups = &mt25q02_fixups,
}
};
--
2.42.0.820.g83a721a137-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 5/6] mtd: spi-nor: remove NO_CHIP_ERASE flag
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 14:58 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
There's no flash using it and we'd like to rely instead on SFDP data,
thus remove it.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/core.c | 3 ---
drivers/mtd/spi-nor/core.h | 8 +++-----
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ac2651e76285..af8f3fc30256 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2886,9 +2886,6 @@ static void spi_nor_init_flags(struct spi_nor *nor)
nor->flags |= SNOR_F_HAS_SR_BP3_BIT6;
}
- if (flags & NO_CHIP_ERASE)
- nor->flags |= SNOR_F_NO_OP_CHIP_ERASE;
-
if (flags & SPI_NOR_RWW && nor->params->n_banks > 1 &&
!nor->controller_ops)
nor->flags |= SNOR_F_RWW;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index b43ea2d49e74..29ed67725b18 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -489,7 +489,6 @@ struct spi_nor_id {
* Usually these will power-up in a write-protected
* state.
* SPI_NOR_NO_ERASE: no erase command needed.
- * NO_CHIP_ERASE: chip does not support chip erase.
* SPI_NOR_NO_FR: can't do fastread.
* SPI_NOR_QUAD_PP: flash supports Quad Input Page Program.
* SPI_NOR_RWW: flash supports reads while write.
@@ -539,10 +538,9 @@ struct flash_info {
#define SPI_NOR_BP3_SR_BIT6 BIT(4)
#define SPI_NOR_SWP_IS_VOLATILE BIT(5)
#define SPI_NOR_NO_ERASE BIT(6)
-#define NO_CHIP_ERASE BIT(7)
-#define SPI_NOR_NO_FR BIT(8)
-#define SPI_NOR_QUAD_PP BIT(9)
-#define SPI_NOR_RWW BIT(10)
+#define SPI_NOR_NO_FR BIT(7)
+#define SPI_NOR_QUAD_PP BIT(8)
+#define SPI_NOR_RWW BIT(9)
u8 no_sfdp_flags;
#define SPI_NOR_SKIP_SFDP BIT(0)
--
2.42.0.820.g83a721a137-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 5/6] mtd: spi-nor: remove NO_CHIP_ERASE flag
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
There's no flash using it and we'd like to rely instead on SFDP data,
thus remove it.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/core.c | 3 ---
drivers/mtd/spi-nor/core.h | 8 +++-----
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ac2651e76285..af8f3fc30256 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2886,9 +2886,6 @@ static void spi_nor_init_flags(struct spi_nor *nor)
nor->flags |= SNOR_F_HAS_SR_BP3_BIT6;
}
- if (flags & NO_CHIP_ERASE)
- nor->flags |= SNOR_F_NO_OP_CHIP_ERASE;
-
if (flags & SPI_NOR_RWW && nor->params->n_banks > 1 &&
!nor->controller_ops)
nor->flags |= SNOR_F_RWW;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index b43ea2d49e74..29ed67725b18 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -489,7 +489,6 @@ struct spi_nor_id {
* Usually these will power-up in a write-protected
* state.
* SPI_NOR_NO_ERASE: no erase command needed.
- * NO_CHIP_ERASE: chip does not support chip erase.
* SPI_NOR_NO_FR: can't do fastread.
* SPI_NOR_QUAD_PP: flash supports Quad Input Page Program.
* SPI_NOR_RWW: flash supports reads while write.
@@ -539,10 +538,9 @@ struct flash_info {
#define SPI_NOR_BP3_SR_BIT6 BIT(4)
#define SPI_NOR_SWP_IS_VOLATILE BIT(5)
#define SPI_NOR_NO_ERASE BIT(6)
-#define NO_CHIP_ERASE BIT(7)
-#define SPI_NOR_NO_FR BIT(8)
-#define SPI_NOR_QUAD_PP BIT(9)
-#define SPI_NOR_RWW BIT(10)
+#define SPI_NOR_NO_FR BIT(7)
+#define SPI_NOR_QUAD_PP BIT(8)
+#define SPI_NOR_RWW BIT(9)
u8 no_sfdp_flags;
#define SPI_NOR_SKIP_SFDP BIT(0)
--
2.42.0.820.g83a721a137-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 6/6] mtd: spi-nor: micron-st: Add support for mt25qu01g
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 14:58 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
From: Fabio Estevam <festevam@denx.de>
Add support for the MT25QU01G 128MB Micron Serial NOR Flash Memory
model.
Datasheet:
https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
Tested on a i.MX8MP based board:
# dmesg | grep spi-nor
spi-nor spi0.0: mt25qu01g (131072 Kbytes)
# cat /proc/mtd
dev: size erasesize name
mtd0: 08000000 00001000 "30bb0000.spi"
~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/jedec_id
20bb21104400
~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/manufacturer
st
~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/partname
mt25qu01g
~# xxd -p /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
53464450060101ff00060110300000ff84000102800000ffffffffffffff
ffffffffffffffffffffffffffffffffffffe520fbffffffff3f29eb276b
273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e
03e1ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff
ffffffffffffffffffe7ffff21dcffff
~# md5sum /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
9d28d1b11de8b15ba9152644219d9a78 /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
Signed-off-by: Fabio Estevam <festevam@denx.de>
[ta: introduce die erase]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/micron-st.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index ab8a53f0c99f..42daa2116752 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -203,10 +203,24 @@ static int st_nor_four_die_late_init(struct spi_nor *nor)
return 0;
}
+static int st_nor_two_die_late_init(struct spi_nor *nor)
+{
+ struct spi_nor_flash_parameter *params = nor->params;
+
+ params->die_erase_opcode = SPINOR_OP_MT_DIE_ERASE;
+ params->n_dice = 2;
+
+ return 0;
+}
+
static struct spi_nor_fixups n25q00_fixups = {
.late_init = st_nor_four_die_late_init,
};
+static struct spi_nor_fixups mt25q01_fixups = {
+ .late_init = st_nor_two_die_late_init,
+};
+
static struct spi_nor_fixups mt25q02_fixups = {
.late_init = st_nor_four_die_late_init,
};
@@ -449,6 +463,11 @@ static const struct flash_info st_nor_parts[] = {
SPI_NOR_BP3_SR_BIT6,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ }, {
+ .id = SNOR_ID(0x20, 0xbb, 0x21, 0x10, 0x44, 0x00),
+ .name = "mt25qu01g",
+ .mfr_flags = USE_FSR,
+ .fixups = &mt25q01_fixups,
}, {
.id = SNOR_ID(0x20, 0xbb, 0x21),
.name = "n25q00a",
--
2.42.0.820.g83a721a137-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* [PATCH v2 6/6] mtd: spi-nor: micron-st: Add support for mt25qu01g
@ 2023-11-01 14:58 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 14:58 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard, Tudor Ambarus
From: Fabio Estevam <festevam@denx.de>
Add support for the MT25QU01G 128MB Micron Serial NOR Flash Memory
model.
Datasheet:
https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
Tested on a i.MX8MP based board:
# dmesg | grep spi-nor
spi-nor spi0.0: mt25qu01g (131072 Kbytes)
# cat /proc/mtd
dev: size erasesize name
mtd0: 08000000 00001000 "30bb0000.spi"
~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/jedec_id
20bb21104400
~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/manufacturer
st
~# cat /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/partname
mt25qu01g
~# xxd -p /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
53464450060101ff00060110300000ff84000102800000ffffffffffffff
ffffffffffffffffffffffffffffffffffffe520fbffffffff3f29eb276b
273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e
03e1ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff
ffffffffffffffffffe7ffff21dcffff
~# md5sum /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
9d28d1b11de8b15ba9152644219d9a78 /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
Signed-off-by: Fabio Estevam <festevam@denx.de>
[ta: introduce die erase]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/mtd/spi-nor/micron-st.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index ab8a53f0c99f..42daa2116752 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -203,10 +203,24 @@ static int st_nor_four_die_late_init(struct spi_nor *nor)
return 0;
}
+static int st_nor_two_die_late_init(struct spi_nor *nor)
+{
+ struct spi_nor_flash_parameter *params = nor->params;
+
+ params->die_erase_opcode = SPINOR_OP_MT_DIE_ERASE;
+ params->n_dice = 2;
+
+ return 0;
+}
+
static struct spi_nor_fixups n25q00_fixups = {
.late_init = st_nor_four_die_late_init,
};
+static struct spi_nor_fixups mt25q01_fixups = {
+ .late_init = st_nor_two_die_late_init,
+};
+
static struct spi_nor_fixups mt25q02_fixups = {
.late_init = st_nor_four_die_late_init,
};
@@ -449,6 +463,11 @@ static const struct flash_info st_nor_parts[] = {
SPI_NOR_BP3_SR_BIT6,
.no_sfdp_flags = SECT_4K | SPI_NOR_QUAD_READ,
.mfr_flags = USE_FSR,
+ }, {
+ .id = SNOR_ID(0x20, 0xbb, 0x21, 0x10, 0x44, 0x00),
+ .name = "mt25qu01g",
+ .mfr_flags = USE_FSR,
+ .fixups = &mt25q01_fixups,
}, {
.id = SNOR_ID(0x20, 0xbb, 0x21),
.name = "n25q00a",
--
2.42.0.820.g83a721a137-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH v2 0/6] mtd: spi-nor: introduce die erase
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 15:54 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-01 15:54 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 01/11/2023 11:58, Tudor Ambarus wrote:
> The patch set is just compiled tested as I don't have a multi die flash
> at hand. Takahiro and Fabio, please test the series and let me know if
> it works on your side.
>
> This will be followed by the removal of SNOR_F_NO_OP_CHIP_ERASE and
> implicitly of the old xilinx SPI NOR driver, but let's take it all in
> small bites.
I tested v2, but erase did not work:
~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 0m0.007s
user 0m0.001s
sys 0m0.006s
~# hexdump -C /dev/mtd0
00000000 d4 a1 8c 16 ad 4d b2 df 3d 2a af c2 ae 0a 8a c1
|.....M..=*......|
00000010 5f 2d 7a 17 9f c3 a4 46 cd f9 80 b8 1e 33 43 25
|_-z....F.....3C%|
00000020 47 dd 81 89 aa 1e b4 aa 26 96 6c 33 74 4f 22 2b
|G.......&.l3tO"+|
....
If you have some debug patch, I can apply it so we can understand the
issue.
Thanks
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 0/6] mtd: spi-nor: introduce die erase
@ 2023-11-01 15:54 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-01 15:54 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 01/11/2023 11:58, Tudor Ambarus wrote:
> The patch set is just compiled tested as I don't have a multi die flash
> at hand. Takahiro and Fabio, please test the series and let me know if
> it works on your side.
>
> This will be followed by the removal of SNOR_F_NO_OP_CHIP_ERASE and
> implicitly of the old xilinx SPI NOR driver, but let's take it all in
> small bites.
I tested v2, but erase did not work:
~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 0m0.007s
user 0m0.001s
sys 0m0.006s
~# hexdump -C /dev/mtd0
00000000 d4 a1 8c 16 ad 4d b2 df 3d 2a af c2 ae 0a 8a c1
|.....M..=*......|
00000010 5f 2d 7a 17 9f c3 a4 46 cd f9 80 b8 1e 33 43 25
|_-z....F.....3C%|
00000020 47 dd 81 89 aa 1e b4 aa 26 96 6c 33 74 4f 22 2b
|G.......&.l3tO"+|
....
If you have some debug patch, I can apply it so we can understand the
issue.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-01 16:04 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 16:04 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
Hi, Fabio,
On 11/1/23 14:58, Tudor Ambarus wrote:
> JESD216 defines a chip as a die, one and the other are the same thing.
> JESD216 clarifies that the chip erase time defined in BFPT dword(11)
> applies separately to each die for multi-die devices in which the dice
> are individually accessed. Based on this, update the
> spi_nor_erase_chip() method to support multi-die devices.
>
> For now, benefit of the die erase when addr and len are aligned with die
> size. This could be improved however for the uniform and non-uniform
> erases cases to use the die erase when possible. For example if one
> requests that an erase of a 2 die device starting from the last 64KB of
> the first die to the end of the flash size, we could use just 2
> commands, a 64KB erase and a die erase. This improvement is left as an
> exercise for the reader, as I don't have multi die flashes at hand.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> drivers/mtd/spi-nor/core.c | 104 +++++++++++++++++++++++-----------
> drivers/mtd/spi-nor/core.h | 8 ++-
> drivers/mtd/spi-nor/debugfs.c | 2 +-
> 3 files changed, 78 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 25a64c65717d..ac2651e76285 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1065,19 +1065,25 @@ static int spi_nor_read_sr2(struct spi_nor *nor, u8 *sr2)
> *
> * Return: 0 on success, -errno otherwise.
> */
> -static int spi_nor_erase_chip(struct spi_nor *nor)
> +static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t die_size)
> {
> + bool multi_die = nor->mtd.size == die_size;
this is wrong, it should have been
bool multi_die = nor->mtd.size != die_size;
Sorry :)
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-01 16:04 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 16:04 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
Hi, Fabio,
On 11/1/23 14:58, Tudor Ambarus wrote:
> JESD216 defines a chip as a die, one and the other are the same thing.
> JESD216 clarifies that the chip erase time defined in BFPT dword(11)
> applies separately to each die for multi-die devices in which the dice
> are individually accessed. Based on this, update the
> spi_nor_erase_chip() method to support multi-die devices.
>
> For now, benefit of the die erase when addr and len are aligned with die
> size. This could be improved however for the uniform and non-uniform
> erases cases to use the die erase when possible. For example if one
> requests that an erase of a 2 die device starting from the last 64KB of
> the first die to the end of the flash size, we could use just 2
> commands, a 64KB erase and a die erase. This improvement is left as an
> exercise for the reader, as I don't have multi die flashes at hand.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> drivers/mtd/spi-nor/core.c | 104 +++++++++++++++++++++++-----------
> drivers/mtd/spi-nor/core.h | 8 ++-
> drivers/mtd/spi-nor/debugfs.c | 2 +-
> 3 files changed, 78 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 25a64c65717d..ac2651e76285 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1065,19 +1065,25 @@ static int spi_nor_read_sr2(struct spi_nor *nor, u8 *sr2)
> *
> * Return: 0 on success, -errno otherwise.
> */
> -static int spi_nor_erase_chip(struct spi_nor *nor)
> +static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t die_size)
> {
> + bool multi_die = nor->mtd.size == die_size;
this is wrong, it should have been
bool multi_die = nor->mtd.size != die_size;
Sorry :)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-01 16:04 ` Tudor Ambarus
@ 2023-11-01 16:17 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-01 16:17 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 01/11/2023 13:04, Tudor Ambarus wrote:
> this is wrong, it should have been
> bool multi_die = nor->mtd.size != die_size;
I applied the following changes on top of v2:
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1067,12 +1067,17 @@ static int spi_nor_read_sr2(struct spi_nor *nor,
u8 *sr2)
*/
static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t
die_size)
{
- bool multi_die = nor->mtd.size == die_size;
+ bool multi_die = nor->mtd.size != die_size;
int ret;
- dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
+ dev_info(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
if (nor->spimem) {
+ dev_info(nor->dev, "***** nor->params->die_erase_opcode:
0x%x\n", nor->params->die_erase_opcode);
+ dev_info(nor->dev, "***** nor->addr_nbytes: %d\n",
nor->addr_nbytes);
+ dev_info(nor->dev, "***** addr 0x%llx\n", addr);
+ dev_info(nor->dev, "***** multi_die: %d\n", multi_die);
+
struct spi_mem_op op =
SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
nor->addr_nbytes, addr,
multi_die);
, but erase is still not working:
~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 14.733446] spi-nor spi0.0: 65536KiB
% complete [ 14.739932] spi-nor spi0.0: *****
nor->params->die_erase_opcode: 0xc4
[ 14.747311] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 14.752402] spi-nor spi0.0: ***** addr 0x0
[ 14.756524] spi-nor spi0.0: ***** multi_die: 1
[ 14.761121] spi-nor spi0.0: 65536KiB
[ 14.764807] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
[ 14.771289] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 14.776369] spi-nor spi0.0: ***** addr 0x4000000
[ 14.781004] spi-nor spi0.0: ***** multi_die: 1
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 0m0.061s
user 0m0.006s
sys 0m0.053s
~# hexdump -C /dev/mtd0
00000000 d4 a1 8c 16 ad 4d b2 df 3d 2a af c2 ae 0a 8a c1
|.....M..=*......|
00000010 5f 2d 7a 17 9f c3 a4 46 cd f9 80 b8 1e 33 43 25
|_-z....F.....3C%|
....
Thanks
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-01 16:17 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-01 16:17 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 01/11/2023 13:04, Tudor Ambarus wrote:
> this is wrong, it should have been
> bool multi_die = nor->mtd.size != die_size;
I applied the following changes on top of v2:
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1067,12 +1067,17 @@ static int spi_nor_read_sr2(struct spi_nor *nor,
u8 *sr2)
*/
static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t
die_size)
{
- bool multi_die = nor->mtd.size == die_size;
+ bool multi_die = nor->mtd.size != die_size;
int ret;
- dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
+ dev_info(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
if (nor->spimem) {
+ dev_info(nor->dev, "***** nor->params->die_erase_opcode:
0x%x\n", nor->params->die_erase_opcode);
+ dev_info(nor->dev, "***** nor->addr_nbytes: %d\n",
nor->addr_nbytes);
+ dev_info(nor->dev, "***** addr 0x%llx\n", addr);
+ dev_info(nor->dev, "***** multi_die: %d\n", multi_die);
+
struct spi_mem_op op =
SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
nor->addr_nbytes, addr,
multi_die);
, but erase is still not working:
~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 14.733446] spi-nor spi0.0: 65536KiB
% complete [ 14.739932] spi-nor spi0.0: *****
nor->params->die_erase_opcode: 0xc4
[ 14.747311] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 14.752402] spi-nor spi0.0: ***** addr 0x0
[ 14.756524] spi-nor spi0.0: ***** multi_die: 1
[ 14.761121] spi-nor spi0.0: 65536KiB
[ 14.764807] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
[ 14.771289] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 14.776369] spi-nor spi0.0: ***** addr 0x4000000
[ 14.781004] spi-nor spi0.0: ***** multi_die: 1
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 0m0.061s
user 0m0.006s
sys 0m0.053s
~# hexdump -C /dev/mtd0
00000000 d4 a1 8c 16 ad 4d b2 df 3d 2a af c2 ae 0a 8a c1
|.....M..=*......|
00000010 5f 2d 7a 17 9f c3 a4 46 cd f9 80 b8 1e 33 43 25
|_-z....F.....3C%|
....
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-01 16:17 ` Fabio Estevam
@ 2023-11-01 17:27 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 17:27 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/1/23 16:17, Fabio Estevam wrote:
> Hi Tudor,
>
Hi!
> On 01/11/2023 13:04, Tudor Ambarus wrote:
>
>> this is wrong, it should have been
>> bool multi_die = nor->mtd.size != die_size;
>
>
> I applied the following changes on top of v2:
>
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1067,12 +1067,17 @@ static int spi_nor_read_sr2(struct spi_nor *nor,
> u8 *sr2)
> */
> static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t
> die_size)
> {
> - bool multi_die = nor->mtd.size == die_size;
> + bool multi_die = nor->mtd.size != die_size;
> int ret;
>
> - dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
> + dev_info(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
>
> if (nor->spimem) {
> + dev_info(nor->dev, "***** nor->params->die_erase_opcode:
> 0x%x\n", nor->params->die_erase_opcode);
> + dev_info(nor->dev, "***** nor->addr_nbytes: %d\n",
> nor->addr_nbytes);
> + dev_info(nor->dev, "***** addr 0x%llx\n", addr);
> + dev_info(nor->dev, "***** multi_die: %d\n", multi_die);
> +
> struct spi_mem_op op =
> SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
> nor->addr_nbytes, addr,
> multi_die);
cool!
> , but erase is still not working:
>>
> ~# time flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 0 [ 14.733446] spi-nor spi0.0: 65536KiB
> % complete [ 14.739932] spi-nor spi0.0: *****
> nor->params->die_erase_opcode: 0xc4
> [ 14.747311] spi-nor spi0.0: ***** nor->addr_nbytes: 4
> [ 14.752402] spi-nor spi0.0: ***** addr 0x0
> [ 14.756524] spi-nor spi0.0: ***** multi_die: 1
> [ 14.761121] spi-nor spi0.0: 65536KiB
> [ 14.764807] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
> [ 14.771289] spi-nor spi0.0: ***** nor->addr_nbytes: 4
> [ 14.776369] spi-nor spi0.0: ***** addr 0x4000000
> [ 14.781004] spi-nor spi0.0: ***** multi_die: 1
> Erasing 131072 Kibyte @ 0 -- 100 % complete
>
> real 0m0.061s
> user 0m0.006s
> sys 0m0.053s
>
> ~# hexdump -C /dev/mtd0
> 00000000 d4 a1 8c 16 ad 4d b2 df 3d 2a af c2 ae 0a 8a c1
> |.....M..=*......|
> 00000010 5f 2d 7a 17 9f c3 a4 46 cd f9 80 b8 1e 33 43 25
> |_-z....F.....3C%|
> ....
Thanks, Fabio. I can't tell what's happening and it's getting late here.
Die erase does not execute if either of the status register BP bits are
set to 1 (some sectors are locked), but that shouldn't be the case I
guess as you could erase the entire flash before. So maybe dump SR/FSR
before and after the chip erase op. Other idea is to dump the spi_mem_op
fields, after spi_nor_spimem_setup_op() is called, maybe I got something
wrong there, but on a short look it seems fine.
I'll re-read this tomorrow. Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-01 17:27 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-01 17:27 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/1/23 16:17, Fabio Estevam wrote:
> Hi Tudor,
>
Hi!
> On 01/11/2023 13:04, Tudor Ambarus wrote:
>
>> this is wrong, it should have been
>> bool multi_die = nor->mtd.size != die_size;
>
>
> I applied the following changes on top of v2:
>
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1067,12 +1067,17 @@ static int spi_nor_read_sr2(struct spi_nor *nor,
> u8 *sr2)
> */
> static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t
> die_size)
> {
> - bool multi_die = nor->mtd.size == die_size;
> + bool multi_die = nor->mtd.size != die_size;
> int ret;
>
> - dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
> + dev_info(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
>
> if (nor->spimem) {
> + dev_info(nor->dev, "***** nor->params->die_erase_opcode:
> 0x%x\n", nor->params->die_erase_opcode);
> + dev_info(nor->dev, "***** nor->addr_nbytes: %d\n",
> nor->addr_nbytes);
> + dev_info(nor->dev, "***** addr 0x%llx\n", addr);
> + dev_info(nor->dev, "***** multi_die: %d\n", multi_die);
> +
> struct spi_mem_op op =
> SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
> nor->addr_nbytes, addr,
> multi_die);
cool!
> , but erase is still not working:
>>
> ~# time flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 0 [ 14.733446] spi-nor spi0.0: 65536KiB
> % complete [ 14.739932] spi-nor spi0.0: *****
> nor->params->die_erase_opcode: 0xc4
> [ 14.747311] spi-nor spi0.0: ***** nor->addr_nbytes: 4
> [ 14.752402] spi-nor spi0.0: ***** addr 0x0
> [ 14.756524] spi-nor spi0.0: ***** multi_die: 1
> [ 14.761121] spi-nor spi0.0: 65536KiB
> [ 14.764807] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
> [ 14.771289] spi-nor spi0.0: ***** nor->addr_nbytes: 4
> [ 14.776369] spi-nor spi0.0: ***** addr 0x4000000
> [ 14.781004] spi-nor spi0.0: ***** multi_die: 1
> Erasing 131072 Kibyte @ 0 -- 100 % complete
>
> real 0m0.061s
> user 0m0.006s
> sys 0m0.053s
>
> ~# hexdump -C /dev/mtd0
> 00000000 d4 a1 8c 16 ad 4d b2 df 3d 2a af c2 ae 0a 8a c1
> |.....M..=*......|
> 00000010 5f 2d 7a 17 9f c3 a4 46 cd f9 80 b8 1e 33 43 25
> |_-z....F.....3C%|
> ....
Thanks, Fabio. I can't tell what's happening and it's getting late here.
Die erase does not execute if either of the status register BP bits are
set to 1 (some sectors are locked), but that shouldn't be the case I
guess as you could erase the entire flash before. So maybe dump SR/FSR
before and after the chip erase op. Other idea is to dump the spi_mem_op
fields, after spi_nor_spimem_setup_op() is called, maybe I got something
wrong there, but on a short look it seems fine.
I'll re-read this tomorrow. Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-01 17:27 ` Tudor Ambarus
@ 2023-11-02 16:43 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 16:43 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 01/11/2023 14:27, Tudor Ambarus wrote:
> Thanks, Fabio. I can't tell what's happening and it's getting late
> here.
> Die erase does not execute if either of the status register BP bits are
> set to 1 (some sectors are locked), but that shouldn't be the case I
> guess as you could erase the entire flash before. So maybe dump SR/FSR
Correct, I could erase the entire flash before.
> before and after the chip erase op. Other idea is to dump the
> spi_mem_op
SR is the same before and after the chip erase operation.
I haven't dumped FSR as I didn't find an easy way to do it from the
core.
> fields, after spi_nor_spimem_setup_op() is called, maybe I got
> something
> wrong there, but on a short look it seems fine.
>
> I'll re-read this tomorrow. Cheers,
Not sure if it helps to give some ideas, but there was an old submission
for die erase support:
http://www.infradead.org/pipermail/linux-mtd/2016-October/069960.html
http://www.infradead.org/pipermail/linux-mtd/2016-October/069961.html
http://www.infradead.org/pipermail/linux-mtd/2016-October/069959.html
Thanks for your help.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 16:43 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 16:43 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 01/11/2023 14:27, Tudor Ambarus wrote:
> Thanks, Fabio. I can't tell what's happening and it's getting late
> here.
> Die erase does not execute if either of the status register BP bits are
> set to 1 (some sectors are locked), but that shouldn't be the case I
> guess as you could erase the entire flash before. So maybe dump SR/FSR
Correct, I could erase the entire flash before.
> before and after the chip erase op. Other idea is to dump the
> spi_mem_op
SR is the same before and after the chip erase operation.
I haven't dumped FSR as I didn't find an easy way to do it from the
core.
> fields, after spi_nor_spimem_setup_op() is called, maybe I got
> something
> wrong there, but on a short look it seems fine.
>
> I'll re-read this tomorrow. Cheers,
Not sure if it helps to give some ideas, but there was an old submission
for die erase support:
http://www.infradead.org/pipermail/linux-mtd/2016-October/069960.html
http://www.infradead.org/pipermail/linux-mtd/2016-October/069961.html
http://www.infradead.org/pipermail/linux-mtd/2016-October/069959.html
Thanks for your help.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 16:43 ` Fabio Estevam
@ 2023-11-02 17:36 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:36 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 16:43, Fabio Estevam wrote:
> Hi Tudor,
Hi, Fabio,
>
> On 01/11/2023 14:27, Tudor Ambarus wrote:
>
>> Thanks, Fabio. I can't tell what's happening and it's getting late here.
>> Die erase does not execute if either of the status register BP bits are
>> set to 1 (some sectors are locked), but that shouldn't be the case I
>> guess as you could erase the entire flash before. So maybe dump SR/FSR
>
> Correct, I could erase the entire flash before.
>
>> before and after the chip erase op. Other idea is to dump the spi_mem_op
>
> SR is the same before and after the chip erase operation.
what value did it have?
>
> I haven't dumped FSR as I didn't find an easy way to do it from the core.
>
>> fields, after spi_nor_spimem_setup_op() is called, maybe I got something
>> wrong there, but on a short look it seems fine.
>>
>> I'll re-read this tomorrow. Cheers,
>
> Not sure if it helps to give some ideas, but there was an old submission
> for die erase support:
> > http://www.infradead.org/pipermail/linux-mtd/2016-October/069960.html
>
> http://www.infradead.org/pipermail/linux-mtd/2016-October/069961.html
>
> http://www.infradead.org/pipermail/linux-mtd/2016-October/069959.html
>
yeah, nothing special here. It reminds me that I could have updated the
uniform and non-uniform erases to use the die erase when possible, but I
was too lazy to do it.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 17:36 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:36 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 16:43, Fabio Estevam wrote:
> Hi Tudor,
Hi, Fabio,
>
> On 01/11/2023 14:27, Tudor Ambarus wrote:
>
>> Thanks, Fabio. I can't tell what's happening and it's getting late here.
>> Die erase does not execute if either of the status register BP bits are
>> set to 1 (some sectors are locked), but that shouldn't be the case I
>> guess as you could erase the entire flash before. So maybe dump SR/FSR
>
> Correct, I could erase the entire flash before.
>
>> before and after the chip erase op. Other idea is to dump the spi_mem_op
>
> SR is the same before and after the chip erase operation.
what value did it have?
>
> I haven't dumped FSR as I didn't find an easy way to do it from the core.
>
>> fields, after spi_nor_spimem_setup_op() is called, maybe I got something
>> wrong there, but on a short look it seems fine.
>>
>> I'll re-read this tomorrow. Cheers,
>
> Not sure if it helps to give some ideas, but there was an old submission
> for die erase support:
> > http://www.infradead.org/pipermail/linux-mtd/2016-October/069960.html
>
> http://www.infradead.org/pipermail/linux-mtd/2016-October/069961.html
>
> http://www.infradead.org/pipermail/linux-mtd/2016-October/069959.html
>
yeah, nothing special here. It reminds me that I could have updated the
uniform and non-uniform erases to use the die erase when possible, but I
was too lazy to do it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 17:36 ` Tudor Ambarus
@ 2023-11-02 17:40 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 17:40 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 02/11/2023 14:36, Tudor Ambarus wrote:
>> SR is the same before and after the chip erase operation.
>
> what value did it have?
[ 35.726305] spi-nor spi0.0: ***** SR before erase: 0x2
[ 35.731543] spi-nor spi0.0: ***** SR after erase: 0x2
If you have some debug patch to dump more information about this issue,
I will be glad to run it here.
Thanks for your help.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 17:40 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 17:40 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 02/11/2023 14:36, Tudor Ambarus wrote:
>> SR is the same before and after the chip erase operation.
>
> what value did it have?
[ 35.726305] spi-nor spi0.0: ***** SR before erase: 0x2
[ 35.731543] spi-nor spi0.0: ***** SR after erase: 0x2
If you have some debug patch to dump more information about this issue,
I will be glad to run it here.
Thanks for your help.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 17:40 ` Fabio Estevam
@ 2023-11-02 17:47 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:47 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 17:40, Fabio Estevam wrote:
> Hi Tudor,
>
> On 02/11/2023 14:36, Tudor Ambarus wrote:
>
>>> SR is the same before and after the chip erase operation.
>>
>> what value did it have?
>
> [ 35.726305] spi-nor spi0.0: ***** SR before erase: 0x2
> [ 35.731543] spi-nor spi0.0: ***** SR after erase: 0x2
>
> If you have some debug patch to dump more information about this issue,
> I will be glad to run it here.
I think I found what I got wrong. Give me few minutes.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 17:47 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:47 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 17:40, Fabio Estevam wrote:
> Hi Tudor,
>
> On 02/11/2023 14:36, Tudor Ambarus wrote:
>
>>> SR is the same before and after the chip erase operation.
>>
>> what value did it have?
>
> [ 35.726305] spi-nor spi0.0: ***** SR before erase: 0x2
> [ 35.731543] spi-nor spi0.0: ***** SR after erase: 0x2
>
> If you have some debug patch to dump more information about this issue,
> I will be glad to run it here.
I think I found what I got wrong. Give me few minutes.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 17:47 ` Tudor Ambarus
@ 2023-11-02 17:54 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:54 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Does this help?
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 05f3e93794bd..54e342a7e73c 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1870,7 +1870,7 @@ static int spi_nor_erase(struct mtd_info *mtd,
struct erase_info *instr)
if (n_dice) {
die_size = div_u64(mtd->size, n_dice);
- if (len == die_size && (addr & (die_size - 1)))
+ if (!(len & (die_size - 1)) && !(addr & (die_size - 1)))
multi_die_erase = true;
} else {
die_size = mtd->size;
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 17:54 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:54 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Does this help?
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 05f3e93794bd..54e342a7e73c 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1870,7 +1870,7 @@ static int spi_nor_erase(struct mtd_info *mtd,
struct erase_info *instr)
if (n_dice) {
die_size = div_u64(mtd->size, n_dice);
- if (len == die_size && (addr & (die_size - 1)))
+ if (!(len & (die_size - 1)) && !(addr & (die_size - 1)))
multi_die_erase = true;
} else {
die_size = mtd->size;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 17:54 ` Tudor Ambarus
@ 2023-11-02 17:59 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:59 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 17:54, Tudor Ambarus wrote:
> Does this help?
>
I guess not, because you used the full flash erase in the first place,
but still a bug. Ok, I'll add some prints.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 17:59 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 17:59 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 17:54, Tudor Ambarus wrote:
> Does this help?
>
I guess not, because you used the full flash erase in the first place,
but still a bug. Ok, I'll add some prints.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 17:59 ` Tudor Ambarus
@ 2023-11-02 18:01 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 18:01 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 02/11/2023 14:59, Tudor Ambarus wrote:
> On 11/2/23 17:54, Tudor Ambarus wrote:
>> Does this help?
>>
>
> I guess not, because you used the full flash erase in the first place,
> but still a bug. Ok, I'll add some prints.
Yes, it did not help:
root@mcde3000a:~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 27.693305] ****** n_dice: 2
% complete [ 27.699053] ****** die_size: 67108864
[ 27.703650] ****** multi_die_erase: 1
[ 27.707342] ****** addr: 0
[ 27.710070] ****** len: 134217728
[ 27.713406] **** Logic addr & (die_size - 1): 0
[ 27.718017] **************** spi_nor_erase_dice 1
[ 27.722793] spi-nor spi0.0: **** Die size is 65536KiB
[ 27.727964] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
[ 27.734430] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 27.739498] spi-nor spi0.0: ***** addr 0x0
[ 27.743614] spi-nor spi0.0: ***** multi_die: 1
[ 27.748094] spi-nor spi0.0: ***** SR before erase: 0x2
[ 27.753278] spi-nor spi0.0: ***** SR after erase: 0x2
[ 27.758387] spi-nor spi0.0: **** Die size is 65536KiB
[ 27.763559] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
[ 27.770017] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 27.775085] spi-nor spi0.0: ***** addr 0x4000000
[ 27.779724] spi-nor spi0.0: ***** multi_die: 1
[ 27.784249] spi-nor spi0.0: ***** SR before erase: 0x2
[ 27.789496] spi-nor spi0.0: ***** SR after erase: 0x2
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 0m0.110s
user 0m0.001s
sys 0m0.107s
root@mcde3000a:~# hexdump /dev/mtd0
0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
0000020 dd47 8981 1eaa aab4 9626 336c 4f74 2b22
....
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 18:01 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 18:01 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 02/11/2023 14:59, Tudor Ambarus wrote:
> On 11/2/23 17:54, Tudor Ambarus wrote:
>> Does this help?
>>
>
> I guess not, because you used the full flash erase in the first place,
> but still a bug. Ok, I'll add some prints.
Yes, it did not help:
root@mcde3000a:~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 27.693305] ****** n_dice: 2
% complete [ 27.699053] ****** die_size: 67108864
[ 27.703650] ****** multi_die_erase: 1
[ 27.707342] ****** addr: 0
[ 27.710070] ****** len: 134217728
[ 27.713406] **** Logic addr & (die_size - 1): 0
[ 27.718017] **************** spi_nor_erase_dice 1
[ 27.722793] spi-nor spi0.0: **** Die size is 65536KiB
[ 27.727964] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
[ 27.734430] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 27.739498] spi-nor spi0.0: ***** addr 0x0
[ 27.743614] spi-nor spi0.0: ***** multi_die: 1
[ 27.748094] spi-nor spi0.0: ***** SR before erase: 0x2
[ 27.753278] spi-nor spi0.0: ***** SR after erase: 0x2
[ 27.758387] spi-nor spi0.0: **** Die size is 65536KiB
[ 27.763559] spi-nor spi0.0: ***** nor->params->die_erase_opcode: 0xc4
[ 27.770017] spi-nor spi0.0: ***** nor->addr_nbytes: 4
[ 27.775085] spi-nor spi0.0: ***** addr 0x4000000
[ 27.779724] spi-nor spi0.0: ***** multi_die: 1
[ 27.784249] spi-nor spi0.0: ***** SR before erase: 0x2
[ 27.789496] spi-nor spi0.0: ***** SR after erase: 0x2
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 0m0.110s
user 0m0.001s
sys 0m0.107s
root@mcde3000a:~# hexdump /dev/mtd0
0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
0000020 dd47 8981 1eaa aab4 9626 336c 4f74 2b22
....
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 18:01 ` Fabio Estevam
@ 2023-11-02 18:21 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 18:21 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 18:01, Fabio Estevam wrote:
> On 02/11/2023 14:59, Tudor Ambarus wrote:
>> On 11/2/23 17:54, Tudor Ambarus wrote:
>>> Does this help?
>>>
>>
>> I guess not, because you used the full flash erase in the first place,
>> but still a bug. Ok, I'll add some prints.
>
> Yes, it did not help:
Let's see what gets to the SPI controller. Which SPI controller do you use?
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index af8f3fc30256..5584bf9cbfd1 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1067,7 +1067,7 @@ static int spi_nor_read_sr2(struct spi_nor *nor,
u8 *sr2)
*/
static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t
die_size)
{
- bool multi_die = nor->mtd.size == die_size;
+ bool multi_die = nor->mtd.size != die_size;
int ret;
dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
@@ -1079,6 +1079,23 @@ static int spi_nor_erase_die(struct spi_nor *nor,
loff_t addr, size_t die_size)
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+ dev_info(nor->dev, "***** nor->reg_proto = 0x%08x \n",
nor->reg_proto);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.cmd.nbytes = 0x%02x \n",
op.cmd.nbytes);
+ dev_info(nor->dev, "***** op.cmd.buswidth = 0x%02x \n",
op.cmd.buswidth);
+ dev_info(nor->dev, "***** op.cmd.opcode = 0x%02x \n",
(u8) op.cmd.opcode);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.addr.nbytes = 0x%02x \n",
op.addr.nbytes);
+ dev_info(nor->dev, "***** op.addr.buswidth = 0x%02x \n",
op.addr.buswidth);
+ dev_info(nor->dev, "***** op.addr.buswidth = 0x%llx \n",
op.addr.val);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.dummy.nbytes = 0x%02x \n",
op.dummy.nbytes);
+ dev_info(nor->dev, "***** op.dummy.buswidth = 0x%02x
\n", op.dummy.buswidth);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.data.buswidth = 0x%02x \n",
op.data.buswidth);
+ dev_info(nor->dev, "***** op.data.nbytes = %d \n",
op.data.nbytes);
+
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
if (multi_die)
@@ -1870,7 +1887,7 @@ static int spi_nor_erase(struct mtd_info *mtd,
struct erase_info *instr)
if (n_dice) {
die_size = div_u64(mtd->size, n_dice);
- if (len == die_size && (addr & (die_size - 1)))
+ if (!(len & (die_size - 1)) && !(addr & (die_size - 1)))
multi_die_erase = true;
} else {
die_size = mtd->size;
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 18:21 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 18:21 UTC (permalink / raw)
To: Fabio Estevam
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 18:01, Fabio Estevam wrote:
> On 02/11/2023 14:59, Tudor Ambarus wrote:
>> On 11/2/23 17:54, Tudor Ambarus wrote:
>>> Does this help?
>>>
>>
>> I guess not, because you used the full flash erase in the first place,
>> but still a bug. Ok, I'll add some prints.
>
> Yes, it did not help:
Let's see what gets to the SPI controller. Which SPI controller do you use?
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index af8f3fc30256..5584bf9cbfd1 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1067,7 +1067,7 @@ static int spi_nor_read_sr2(struct spi_nor *nor,
u8 *sr2)
*/
static int spi_nor_erase_die(struct spi_nor *nor, loff_t addr, size_t
die_size)
{
- bool multi_die = nor->mtd.size == die_size;
+ bool multi_die = nor->mtd.size != die_size;
int ret;
dev_dbg(nor->dev, " %lldKiB\n", (long long)(die_size >> 10));
@@ -1079,6 +1079,23 @@ static int spi_nor_erase_die(struct spi_nor *nor,
loff_t addr, size_t die_size)
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+ dev_info(nor->dev, "***** nor->reg_proto = 0x%08x \n",
nor->reg_proto);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.cmd.nbytes = 0x%02x \n",
op.cmd.nbytes);
+ dev_info(nor->dev, "***** op.cmd.buswidth = 0x%02x \n",
op.cmd.buswidth);
+ dev_info(nor->dev, "***** op.cmd.opcode = 0x%02x \n",
(u8) op.cmd.opcode);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.addr.nbytes = 0x%02x \n",
op.addr.nbytes);
+ dev_info(nor->dev, "***** op.addr.buswidth = 0x%02x \n",
op.addr.buswidth);
+ dev_info(nor->dev, "***** op.addr.buswidth = 0x%llx \n",
op.addr.val);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.dummy.nbytes = 0x%02x \n",
op.dummy.nbytes);
+ dev_info(nor->dev, "***** op.dummy.buswidth = 0x%02x
\n", op.dummy.buswidth);
+ dev_info(nor->dev, "*****\n");
+ dev_info(nor->dev, "***** op.data.buswidth = 0x%02x \n",
op.data.buswidth);
+ dev_info(nor->dev, "***** op.data.nbytes = %d \n",
op.data.nbytes);
+
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
if (multi_die)
@@ -1870,7 +1887,7 @@ static int spi_nor_erase(struct mtd_info *mtd,
struct erase_info *instr)
if (n_dice) {
die_size = div_u64(mtd->size, n_dice);
- if (len == die_size && (addr & (die_size - 1)))
+ if (!(len & (die_size - 1)) && !(addr & (die_size - 1)))
multi_die_erase = true;
} else {
die_size = mtd->size;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 18:21 ` Tudor Ambarus
@ 2023-11-02 18:33 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 18:33 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 02/11/2023 15:21, Tudor Ambarus wrote:
> Let's see what gets to the SPI controller. Which SPI controller do you
> use?
I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
Here is the result:
root@mcde3000a:~# flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
nor->reg_proto = 0x00010101
% complete [ 26.049570] spi-nor spi0.0: *****
[ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 26.069787] spi-nor spi0.0: *****
[ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 26.089368] spi-nor spi0.0: *****
[ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 26.103713] spi-nor spi0.0: *****
[ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 26.123589] spi-nor spi0.0: *****
[ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 26.142956] spi-nor spi0.0: *****
[ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 26.163065] spi-nor spi0.0: *****
[ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 26.177405] spi-nor spi0.0: *****
[ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
root@mcde3000a:~# hexdump /dev/mtd0
0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
....
Thanks
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 18:33 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 18:33 UTC (permalink / raw)
To: Tudor Ambarus
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 02/11/2023 15:21, Tudor Ambarus wrote:
> Let's see what gets to the SPI controller. Which SPI controller do you
> use?
I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
Here is the result:
root@mcde3000a:~# flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
nor->reg_proto = 0x00010101
% complete [ 26.049570] spi-nor spi0.0: *****
[ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 26.069787] spi-nor spi0.0: *****
[ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 26.089368] spi-nor spi0.0: *****
[ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 26.103713] spi-nor spi0.0: *****
[ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 26.123589] spi-nor spi0.0: *****
[ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 26.142956] spi-nor spi0.0: *****
[ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 26.163065] spi-nor spi0.0: *****
[ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 26.177405] spi-nor spi0.0: *****
[ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
root@mcde3000a:~# hexdump /dev/mtd0
0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
....
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 18:33 ` Fabio Estevam
@ 2023-11-02 18:46 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 18:46 UTC (permalink / raw)
To: Fabio Estevam, Takahiro Kuwano
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 18:33, Fabio Estevam wrote:
> On 02/11/2023 15:21, Tudor Ambarus wrote:
>
>> Let's see what gets to the SPI controller. Which SPI controller do you
>> use?
>
> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>
> Here is the result:
>
> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
> nor->reg_proto = 0x00010101
> % complete [ 26.049570] spi-nor spi0.0: *****
> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 26.069787] spi-nor spi0.0: *****
> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> [ 26.089368] spi-nor spi0.0: *****
> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 26.103713] spi-nor spi0.0: *****
> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 26.123589] spi-nor spi0.0: *****
> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 26.142956] spi-nor spi0.0: *****
> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
> [ 26.163065] spi-nor spi0.0: *****
> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 26.177405] spi-nor spi0.0: *****
> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
> Erasing 131072 Kibyte @ 0 -- 100 % complete
>
It looks good ...
> root@mcde3000a:~# hexdump /dev/mtd0
> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
but the patient is dead :). Would be good if Takahiro can test on IFX
too. In the meantime I'll try to find a n25q00, I remember I had one in
the past.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 18:46 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 18:46 UTC (permalink / raw)
To: Fabio Estevam, Takahiro Kuwano
Cc: michael, takahiro.kuwano, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 18:33, Fabio Estevam wrote:
> On 02/11/2023 15:21, Tudor Ambarus wrote:
>
>> Let's see what gets to the SPI controller. Which SPI controller do you
>> use?
>
> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>
> Here is the result:
>
> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
> nor->reg_proto = 0x00010101
> % complete [ 26.049570] spi-nor spi0.0: *****
> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 26.069787] spi-nor spi0.0: *****
> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> [ 26.089368] spi-nor spi0.0: *****
> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 26.103713] spi-nor spi0.0: *****
> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 26.123589] spi-nor spi0.0: *****
> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 26.142956] spi-nor spi0.0: *****
> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
> [ 26.163065] spi-nor spi0.0: *****
> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 26.177405] spi-nor spi0.0: *****
> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
> Erasing 131072 Kibyte @ 0 -- 100 % complete
>
It looks good ...
> root@mcde3000a:~# hexdump /dev/mtd0
> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
but the patient is dead :). Would be good if Takahiro can test on IFX
too. In the meantime I'll try to find a n25q00, I remember I had one in
the past.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 18:46 ` Tudor Ambarus
@ 2023-11-02 18:56 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 18:56 UTC (permalink / raw)
To: Fabio Estevam, Takahiro Kuwano
Cc: michael, pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
On 11/2/23 18:46, Tudor Ambarus wrote:
>
>
> On 11/2/23 18:33, Fabio Estevam wrote:
>> On 02/11/2023 15:21, Tudor Ambarus wrote:
>>
>>> Let's see what gets to the SPI controller. Which SPI controller do you
>>> use?
>>
>> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>>
>> Here is the result:
>>
>> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
>> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
>> nor->reg_proto = 0x00010101
>> % complete [ 26.049570] spi-nor spi0.0: *****
>> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.069787] spi-nor spi0.0: *****
>> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>> [ 26.089368] spi-nor spi0.0: *****
>> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.103713] spi-nor spi0.0: *****
>> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
>> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 26.123589] spi-nor spi0.0: *****
>> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.142956] spi-nor spi0.0: *****
>> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>> [ 26.163065] spi-nor spi0.0: *****
>> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.177405] spi-nor spi0.0: *****
>> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
>> Erasing 131072 Kibyte @ 0 -- 100 % complete
>>
>
> It looks good ...
>
>> root@mcde3000a:~# hexdump /dev/mtd0
>> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
>> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
>
> but the patient is dead :). Would be good if Takahiro can test on IFX
> too. In the meantime I'll try to find a n25q00, I remember I had one in
> the past.
Let's try something else:
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 5584bf9cbfd1..a0af7a7eb727 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1074,7 +1074,7 @@ static int spi_nor_erase_die(struct spi_nor *nor,
loff_t addr, size_t die_size)
if (nor->spimem) {
struct spi_mem_op op =
- SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
+ SPI_NOR_DIE_ERASE_OP(nor->erase_opcode,
nor->addr_nbytes, addr,
multi_die);
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
I expect that with this the first sector from each die will be erased.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 18:56 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-02 18:56 UTC (permalink / raw)
To: Fabio Estevam, Takahiro Kuwano
Cc: michael, pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
On 11/2/23 18:46, Tudor Ambarus wrote:
>
>
> On 11/2/23 18:33, Fabio Estevam wrote:
>> On 02/11/2023 15:21, Tudor Ambarus wrote:
>>
>>> Let's see what gets to the SPI controller. Which SPI controller do you
>>> use?
>>
>> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>>
>> Here is the result:
>>
>> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
>> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
>> nor->reg_proto = 0x00010101
>> % complete [ 26.049570] spi-nor spi0.0: *****
>> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.069787] spi-nor spi0.0: *****
>> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>> [ 26.089368] spi-nor spi0.0: *****
>> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.103713] spi-nor spi0.0: *****
>> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
>> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 26.123589] spi-nor spi0.0: *****
>> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.142956] spi-nor spi0.0: *****
>> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>> [ 26.163065] spi-nor spi0.0: *****
>> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.177405] spi-nor spi0.0: *****
>> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
>> Erasing 131072 Kibyte @ 0 -- 100 % complete
>>
>
> It looks good ...
>
>> root@mcde3000a:~# hexdump /dev/mtd0
>> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
>> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
>
> but the patient is dead :). Would be good if Takahiro can test on IFX
> too. In the meantime I'll try to find a n25q00, I remember I had one in
> the past.
Let's try something else:
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 5584bf9cbfd1..a0af7a7eb727 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1074,7 +1074,7 @@ static int spi_nor_erase_die(struct spi_nor *nor,
loff_t addr, size_t die_size)
if (nor->spimem) {
struct spi_mem_op op =
- SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
+ SPI_NOR_DIE_ERASE_OP(nor->erase_opcode,
nor->addr_nbytes, addr,
multi_die);
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
I expect that with this the first sector from each die will be erased.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 18:56 ` Tudor Ambarus
@ 2023-11-02 21:42 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 21:42 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 02/11/2023 15:56, Tudor Ambarus wrote:
> Let's try something else:
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 5584bf9cbfd1..a0af7a7eb727 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1074,7 +1074,7 @@ static int spi_nor_erase_die(struct spi_nor *nor,
> loff_t addr, size_t die_size)
>
> if (nor->spimem) {
> struct spi_mem_op op =
> -
> SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
> + SPI_NOR_DIE_ERASE_OP(nor->erase_opcode,
> nor->addr_nbytes, addr,
> multi_die);
>
> spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>
> I expect that with this the first sector from each die will be erased.
You are right. This is exactly what happens with this change:
First die:
~# hexdump /dev/mtd0
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000 9231 efb8 d664 d77b 231c 3522 d7e8 4f6e
Second die:
~# hexdump -s 0x4000000 /dev/mtd0
4000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
4010000 0418 0518 60a0 9214 2411 2004 c144 9e2b
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-02 21:42 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-02 21:42 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 02/11/2023 15:56, Tudor Ambarus wrote:
> Let's try something else:
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 5584bf9cbfd1..a0af7a7eb727 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1074,7 +1074,7 @@ static int spi_nor_erase_die(struct spi_nor *nor,
> loff_t addr, size_t die_size)
>
> if (nor->spimem) {
> struct spi_mem_op op =
> -
> SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
> + SPI_NOR_DIE_ERASE_OP(nor->erase_opcode,
> nor->addr_nbytes, addr,
> multi_die);
>
> spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>
> I expect that with this the first sector from each die will be erased.
You are right. This is exactly what happens with this change:
First die:
~# hexdump /dev/mtd0
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000 9231 efb8 d664 d77b 231c 3522 d7e8 4f6e
Second die:
~# hexdump -s 0x4000000 /dev/mtd0
4000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
4010000 0418 0518 60a0 9214 2411 2004 c144 9e2b
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 21:42 ` Fabio Estevam
@ 2023-11-03 11:47 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 11:47 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 21:42, Fabio Estevam wrote:
> On 02/11/2023 15:56, Tudor Ambarus wrote:
>
>> Let's try something else:
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 5584bf9cbfd1..a0af7a7eb727 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -1074,7 +1074,7 @@ static int spi_nor_erase_die(struct spi_nor *nor,
>> loff_t addr, size_t die_size)
>>
>> if (nor->spimem) {
>> struct spi_mem_op op =
>> -
>> SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
>> + SPI_NOR_DIE_ERASE_OP(nor->erase_opcode,
>> nor->addr_nbytes, addr,
>> multi_die);
>>
>> spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>>
>> I expect that with this the first sector from each die will be erased.
>
> You are right. This is exactly what happens with this change:
>
> First die:
>
> ~# hexdump /dev/mtd0
> 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0010000 9231 efb8 d664 d77b 231c 3522 d7e8 4f6e
>
> Second die:
>
> ~# hexdump -s 0x4000000 /dev/mtd0
> 4000000 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 4010000 0418 0518 60a0 9214 2411 2004 c144 9e2b
I think I know what happens with your flash. Please try the debug patch
from https://github.com/ambarus/linux-0day.git
spi-nor/next-die-erase-v2-debug.
I assume your flash works in 3-byte mode. The die erase cmd needs an
extended register in 3-byte mode otherwise is ignored. Please try the
patch and let me know if it works.
Reading the datasheet I found out that
"The device supports 3-byte addressing (default), with A[23:0] input
during address cycle. After any READ command is executed, the device
will output data from the selected address. After the boundary is
reached, the device will start reading again from the beginning."
So I expect up to now we tested just the first die, all tests in 3-byte
mode. Thus when we wanted to do a cross-die test, reading from the last
2 MB of first die to the first 2MB of the second die, what we actually
did was to read the last and the first 2MB of the first die.
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 11:47 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 11:47 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/2/23 21:42, Fabio Estevam wrote:
> On 02/11/2023 15:56, Tudor Ambarus wrote:
>
>> Let's try something else:
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 5584bf9cbfd1..a0af7a7eb727 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -1074,7 +1074,7 @@ static int spi_nor_erase_die(struct spi_nor *nor,
>> loff_t addr, size_t die_size)
>>
>> if (nor->spimem) {
>> struct spi_mem_op op =
>> -
>> SPI_NOR_DIE_ERASE_OP(nor->params->die_erase_opcode,
>> + SPI_NOR_DIE_ERASE_OP(nor->erase_opcode,
>> nor->addr_nbytes, addr,
>> multi_die);
>>
>> spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>>
>> I expect that with this the first sector from each die will be erased.
>
> You are right. This is exactly what happens with this change:
>
> First die:
>
> ~# hexdump /dev/mtd0
> 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0010000 9231 efb8 d664 d77b 231c 3522 d7e8 4f6e
>
> Second die:
>
> ~# hexdump -s 0x4000000 /dev/mtd0
> 4000000 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 4010000 0418 0518 60a0 9214 2411 2004 c144 9e2b
I think I know what happens with your flash. Please try the debug patch
from https://github.com/ambarus/linux-0day.git
spi-nor/next-die-erase-v2-debug.
I assume your flash works in 3-byte mode. The die erase cmd needs an
extended register in 3-byte mode otherwise is ignored. Please try the
patch and let me know if it works.
Reading the datasheet I found out that
"The device supports 3-byte addressing (default), with A[23:0] input
during address cycle. After any READ command is executed, the device
will output data from the selected address. After the boundary is
reached, the device will start reading again from the beginning."
So I expect up to now we tested just the first die, all tests in 3-byte
mode. Thus when we wanted to do a cross-die test, reading from the last
2 MB of first die to the first 2MB of the second die, what we actually
did was to read the last and the first 2MB of the first die.
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 11:47 ` Tudor Ambarus
@ 2023-11-03 12:30 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 12:30 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 03/11/2023 08:47, Tudor Ambarus wrote:
> I think I know what happens with your flash. Please try the debug patch
> from https://github.com/ambarus/linux-0day.git
> spi-nor/next-die-erase-v2-debug.
>
> I assume your flash works in 3-byte mode. The die erase cmd needs an
> extended register in 3-byte mode otherwise is ignored. Please try the
> patch and let me know if it works.
Progress: with this one, I see that the whole flash was erased:
~# flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 39.865773] spi-nor spi0.0: *****
nor->reg_proto = 0x00010101
% complete [ 39.874441] spi-nor spi0.0: *****
[ 39.878712] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 39.883983] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 39.889402] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 39.894648] spi-nor spi0.0: *****
[ 39.897979] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 39.903309] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 39.908810] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 39.914226] spi-nor spi0.0: *****
[ 39.917558] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 39.922981] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 39.928570] spi-nor spi0.0: *****
[ 39.931905] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 39.937403] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 157.398677] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 157.404543] spi-nor spi0.0: *****
[ 157.407878] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 157.413133] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 157.418549] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 157.423799] spi-nor spi0.0: *****
[ 157.427130] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 157.432461] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 157.437963] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 157.443900] spi-nor spi0.0: *****
[ 157.447229] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 157.452648] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 157.458239] spi-nor spi0.0: *****
[ 157.461558] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 157.467066] spi-nor spi0.0: ***** op.data.nbytes = 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
~# hexdump /dev/mtd0
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
8000000
The problem I see is that the erase operation was super slow.
Please see the timestamps to get an idea.
Is this slow-erase behavior expected? Please note that the
SPI controller on the i.MX8MP does not have DMA support at the moment.
Thanks!
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 12:30 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 12:30 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
Hi Tudor,
On 03/11/2023 08:47, Tudor Ambarus wrote:
> I think I know what happens with your flash. Please try the debug patch
> from https://github.com/ambarus/linux-0day.git
> spi-nor/next-die-erase-v2-debug.
>
> I assume your flash works in 3-byte mode. The die erase cmd needs an
> extended register in 3-byte mode otherwise is ignored. Please try the
> patch and let me know if it works.
Progress: with this one, I see that the whole flash was erased:
~# flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 39.865773] spi-nor spi0.0: *****
nor->reg_proto = 0x00010101
% complete [ 39.874441] spi-nor spi0.0: *****
[ 39.878712] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 39.883983] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 39.889402] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 39.894648] spi-nor spi0.0: *****
[ 39.897979] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 39.903309] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 39.908810] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 39.914226] spi-nor spi0.0: *****
[ 39.917558] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 39.922981] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 39.928570] spi-nor spi0.0: *****
[ 39.931905] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 39.937403] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 157.398677] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 157.404543] spi-nor spi0.0: *****
[ 157.407878] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 157.413133] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 157.418549] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 157.423799] spi-nor spi0.0: *****
[ 157.427130] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 157.432461] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 157.437963] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 157.443900] spi-nor spi0.0: *****
[ 157.447229] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 157.452648] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 157.458239] spi-nor spi0.0: *****
[ 157.461558] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 157.467066] spi-nor spi0.0: ***** op.data.nbytes = 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
~# hexdump /dev/mtd0
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
8000000
The problem I see is that the erase operation was super slow.
Please see the timestamps to get an idea.
Is this slow-erase behavior expected? Please note that the
SPI controller on the i.MX8MP does not have DMA support at the moment.
Thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 12:30 ` Fabio Estevam
@ 2023-11-03 12:53 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 12:53 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 09:30, Fabio Estevam wrote:
> The problem I see is that the erase operation was super slow.
>
> Please see the timestamps to get an idea.
>
> Is this slow-erase behavior expected? Please note that the
> SPI controller on the i.MX8MP does not have DMA support at the moment.
Measuring the time it takes to erase the whole flash:
root@mcde3000a:~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 1502.857687] spi-nor spi0.0: *****
nor->reg_proto = 0x00010101
% complete [ 1502.866354] spi-nor spi0.0: *****
[ 1502.870631] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 1502.875891] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 1502.881311] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 1502.886559] spi-nor spi0.0: *****
[ 1502.889888] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 1502.895220] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 1502.900724] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 1502.906141] spi-nor spi0.0: *****
[ 1502.909474] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 1502.914899] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 1502.920489] spi-nor spi0.0: *****
[ 1502.923823] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 1502.929323] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 1620.329673] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 1620.335538] spi-nor spi0.0: *****
[ 1620.338869] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 1620.344127] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 1620.349543] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 1620.354791] spi-nor spi0.0: *****
[ 1620.358123] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 1620.363452] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 1620.368953] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 1620.374890] spi-nor spi0.0: *****
[ 1620.378229] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 1620.383646] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 1620.389234] spi-nor spi0.0: *****
[ 1620.392566] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 1620.398068] spi-nor spi0.0: ***** op.data.nbytes = 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 3m56.795s
user 0m0.001s
sys 3m15.840s
Originally, I was also getting around 4 minutes to erase the whole
flash,
so the erase-die performance is comparable to the erase one sector at
time.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 12:53 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 12:53 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 09:30, Fabio Estevam wrote:
> The problem I see is that the erase operation was super slow.
>
> Please see the timestamps to get an idea.
>
> Is this slow-erase behavior expected? Please note that the
> SPI controller on the i.MX8MP does not have DMA support at the moment.
Measuring the time it takes to erase the whole flash:
root@mcde3000a:~# time flash_erase /dev/mtd0 0 0
Erasing 131072 Kibyte @ 0 -- 0 [ 1502.857687] spi-nor spi0.0: *****
nor->reg_proto = 0x00010101
% complete [ 1502.866354] spi-nor spi0.0: *****
[ 1502.870631] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 1502.875891] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 1502.881311] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 1502.886559] spi-nor spi0.0: *****
[ 1502.889888] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 1502.895220] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 1502.900724] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 1502.906141] spi-nor spi0.0: *****
[ 1502.909474] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 1502.914899] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 1502.920489] spi-nor spi0.0: *****
[ 1502.923823] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 1502.929323] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 1620.329673] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 1620.335538] spi-nor spi0.0: *****
[ 1620.338869] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 1620.344127] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 1620.349543] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 1620.354791] spi-nor spi0.0: *****
[ 1620.358123] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 1620.363452] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 1620.368953] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 1620.374890] spi-nor spi0.0: *****
[ 1620.378229] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 1620.383646] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 1620.389234] spi-nor spi0.0: *****
[ 1620.392566] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 1620.398068] spi-nor spi0.0: ***** op.data.nbytes = 0
Erasing 131072 Kibyte @ 0 -- 100 % complete
real 3m56.795s
user 0m0.001s
sys 3m15.840s
Originally, I was also getting around 4 minutes to erase the whole
flash,
so the erase-die performance is comparable to the erase one sector at
time.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 12:53 ` Fabio Estevam
@ 2023-11-03 13:26 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 13:26 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/3/23 12:53, Fabio Estevam wrote:
> On 03/11/2023 09:30, Fabio Estevam wrote:
>
>> The problem I see is that the erase operation was super slow.
>>
>> Please see the timestamps to get an idea.
>>
>> Is this slow-erase behavior expected? Please note that the
No.
>> SPI controller on the i.MX8MP does not have DMA support at the moment.
We don't use DMA for erases, it doesn't matter whether you use DMA or not.
>
> Measuring the time it takes to erase the whole flash:
>
> root@mcde3000a:~# time flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 0 [ 1502.857687] spi-nor spi0.0: *****
> nor->reg_proto = 0x00010101
> % complete [ 1502.866354] spi-nor spi0.0: *****
> [ 1502.870631] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 1502.875891] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 1502.881311] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 1502.886559] spi-nor spi0.0: *****
> [ 1502.889888] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 1502.895220] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 1502.900724] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> [ 1502.906141] spi-nor spi0.0: *****
> [ 1502.909474] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 1502.914899] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 1502.920489] spi-nor spi0.0: *****
> [ 1502.923823] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 1502.929323] spi-nor spi0.0: ***** op.data.nbytes = 0
> [ 1620.329673] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 1620.335538] spi-nor spi0.0: *****
> [ 1620.338869] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 1620.344127] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 1620.349543] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 1620.354791] spi-nor spi0.0: *****
> [ 1620.358123] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 1620.363452] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 1620.368953] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
> [ 1620.374890] spi-nor spi0.0: *****
> [ 1620.378229] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 1620.383646] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 1620.389234] spi-nor spi0.0: *****
> [ 1620.392566] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 1620.398068] spi-nor spi0.0: ***** op.data.nbytes = 0
> Erasing 131072 Kibyte @ 0 -- 100 % complete
>
> real 3m56.795s
> user 0m0.001s
> sys 3m15.840s
>
> Originally, I was also getting around 4 minutes to erase the whole flash,
> so the erase-die performance is comparable to the erase one sector at time.
>
Which version of mtd-utils are you using? I guess the flash-erase
utility is written in a bad way. Please use the following while I check
what flash_erase is doing:
time mtd_debug erase /dev/mtd0 0 134217728
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 13:26 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 13:26 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/3/23 12:53, Fabio Estevam wrote:
> On 03/11/2023 09:30, Fabio Estevam wrote:
>
>> The problem I see is that the erase operation was super slow.
>>
>> Please see the timestamps to get an idea.
>>
>> Is this slow-erase behavior expected? Please note that the
No.
>> SPI controller on the i.MX8MP does not have DMA support at the moment.
We don't use DMA for erases, it doesn't matter whether you use DMA or not.
>
> Measuring the time it takes to erase the whole flash:
>
> root@mcde3000a:~# time flash_erase /dev/mtd0 0 0
> Erasing 131072 Kibyte @ 0 -- 0 [ 1502.857687] spi-nor spi0.0: *****
> nor->reg_proto = 0x00010101
> % complete [ 1502.866354] spi-nor spi0.0: *****
> [ 1502.870631] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 1502.875891] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 1502.881311] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 1502.886559] spi-nor spi0.0: *****
> [ 1502.889888] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 1502.895220] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 1502.900724] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> [ 1502.906141] spi-nor spi0.0: *****
> [ 1502.909474] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 1502.914899] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 1502.920489] spi-nor spi0.0: *****
> [ 1502.923823] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 1502.929323] spi-nor spi0.0: ***** op.data.nbytes = 0
> [ 1620.329673] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 1620.335538] spi-nor spi0.0: *****
> [ 1620.338869] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 1620.344127] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 1620.349543] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 1620.354791] spi-nor spi0.0: *****
> [ 1620.358123] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 1620.363452] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 1620.368953] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
> [ 1620.374890] spi-nor spi0.0: *****
> [ 1620.378229] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 1620.383646] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 1620.389234] spi-nor spi0.0: *****
> [ 1620.392566] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 1620.398068] spi-nor spi0.0: ***** op.data.nbytes = 0
> Erasing 131072 Kibyte @ 0 -- 100 % complete
>
> real 3m56.795s
> user 0m0.001s
> sys 3m15.840s
>
> Originally, I was also getting around 4 minutes to erase the whole flash,
> so the erase-die performance is comparable to the erase one sector at time.
>
Which version of mtd-utils are you using? I guess the flash-erase
utility is written in a bad way. Please use the following while I check
what flash_erase is doing:
time mtd_debug erase /dev/mtd0 0 134217728
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 13:26 ` Tudor Ambarus
@ 2023-11-03 13:37 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 13:37 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 10:26, Tudor Ambarus wrote:
> Which version of mtd-utils are you using? I guess the flash-erase
mtd-utils 2.1.5
> utility is written in a bad way. Please use the following while I check
> what flash_erase is doing:
>
> time mtd_debug erase /dev/mtd0 0 134217728
"mtd_debug erase" gives the same time as well:
root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
[ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 4322.120861] spi-nor spi0.0: *****
[ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 4322.140154] spi-nor spi0.0: *****
[ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 4322.159761] spi-nor spi0.0: *****
[ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 4322.174118] spi-nor spi0.0: *****
[ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 4439.971920] spi-nor spi0.0: *****
[ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 4439.991174] spi-nor spi0.0: *****
[ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 4440.011272] spi-nor spi0.0: *****
[ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 4440.025606] spi-nor spi0.0: *****
[ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 3m57.384s
user 0m0.005s
sys 3m35.211s
Thanks
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 13:37 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 13:37 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 10:26, Tudor Ambarus wrote:
> Which version of mtd-utils are you using? I guess the flash-erase
mtd-utils 2.1.5
> utility is written in a bad way. Please use the following while I check
> what flash_erase is doing:
>
> time mtd_debug erase /dev/mtd0 0 134217728
"mtd_debug erase" gives the same time as well:
root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
[ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 4322.120861] spi-nor spi0.0: *****
[ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 4322.140154] spi-nor spi0.0: *****
[ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
[ 4322.159761] spi-nor spi0.0: *****
[ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 4322.174118] spi-nor spi0.0: *****
[ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
[ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
[ 4439.971920] spi-nor spi0.0: *****
[ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
[ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
[ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
[ 4439.991174] spi-nor spi0.0: *****
[ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
[ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
[ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
[ 4440.011272] spi-nor spi0.0: *****
[ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
[ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
[ 4440.025606] spi-nor spi0.0: *****
[ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
[ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 3m57.384s
user 0m0.005s
sys 3m35.211s
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 13:37 ` Fabio Estevam
@ 2023-11-03 13:48 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 13:48 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03.11.2023 15:37, Fabio Estevam wrote:
> On 03/11/2023 10:26, Tudor Ambarus wrote:
>
>> Which version of mtd-utils are you using? I guess the flash-erase
>
> mtd-utils 2.1.5
>
>> utility is written in a bad way. Please use the following while I check
>> what flash_erase is doing:
>>
>> time mtd_debug erase /dev/mtd0 0 134217728
>
> "mtd_debug erase" gives the same time as well:
>
> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 4322.120861] spi-nor spi0.0: *****
> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 4322.140154] spi-nor spi0.0: *****
> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> [ 4322.159761] spi-nor spi0.0: *****
> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 4322.174118] spi-nor spi0.0: *****
> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 4439.971920] spi-nor spi0.0: *****
> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 4439.991174] spi-nor spi0.0: *****
> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
> [ 4440.011272] spi-nor spi0.0: *****
> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 4440.025606] spi-nor spi0.0: *****
> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x00000000 in flash
>
> real 3m57.384s
> user 0m0.005s
> sys 3m35.211s
>
Yep, it's strange, we'll have to check what's happening. I found my
n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
defines how long the erase die should take, see BFPT dword 11. You can
start with that.
# time mtd_debug erase /dev/mtd1 0 134217728
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x0
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x2000000
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x4000000
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x6000000
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 0m5.485s
user 0m0.000s
sys 0m5.461s
# hexdump /dev/mtd1
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
8000000
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 13:48 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 13:48 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03.11.2023 15:37, Fabio Estevam wrote:
> On 03/11/2023 10:26, Tudor Ambarus wrote:
>
>> Which version of mtd-utils are you using? I guess the flash-erase
>
> mtd-utils 2.1.5
>
>> utility is written in a bad way. Please use the following while I check
>> what flash_erase is doing:
>>
>> time mtd_debug erase /dev/mtd0 0 134217728
>
> "mtd_debug erase" gives the same time as well:
>
> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 4322.120861] spi-nor spi0.0: *****
> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 4322.140154] spi-nor spi0.0: *****
> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> [ 4322.159761] spi-nor spi0.0: *****
> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 4322.174118] spi-nor spi0.0: *****
> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> [ 4439.971920] spi-nor spi0.0: *****
> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
> [ 4439.991174] spi-nor spi0.0: *****
> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
> [ 4440.011272] spi-nor spi0.0: *****
> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> [ 4440.025606] spi-nor spi0.0: *****
> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x00000000 in flash
>
> real 3m57.384s
> user 0m0.005s
> sys 3m35.211s
>
Yep, it's strange, we'll have to check what's happening. I found my
n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
defines how long the erase die should take, see BFPT dword 11. You can
start with that.
# time mtd_debug erase /dev/mtd1 0 134217728
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x0
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x2000000
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x4000000
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
spi-nor spi1.0: ***** nor->reg_proto = 0x00010101
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.cmd.nbytes = 0x01
spi-nor spi1.0: ***** op.cmd.buswidth = 0x01
spi-nor spi1.0: ***** op.cmd.opcode = 0xc4
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.addr.nbytes = 0x04
spi-nor spi1.0: ***** op.addr.buswidth = 0x01
spi-nor spi1.0: ***** op.addr.buswidth = 0x6000000
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.dummy.nbytes = 0x00
spi-nor spi1.0: ***** op.dummy.buswidth = 0x00
spi-nor spi1.0: *****
spi-nor spi1.0: ***** op.data.buswidth = 0x00
spi-nor spi1.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 0m5.485s
user 0m0.000s
sys 0m5.461s
# hexdump /dev/mtd1
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
8000000
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 13:48 ` Tudor Ambarus
@ 2023-11-03 14:16 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 14:16 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 10:48, Tudor Ambarus wrote:
> Yep, it's strange, we'll have to check what's happening. I found my
> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
> defines how long the erase die should take, see BFPT dword 11. You can
> start with that.
Where does BFPT dword 11 reside inside SFDP?
~# hexdump -C
/sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
00000000 53 46 44 50 06 01 01 ff 00 06 01 10 30 00 00 ff
|SFDP........0...|
00000010 84 00 01 02 80 00 00 ff ff ff ff ff ff ff ff ff
|................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
00000030 e5 20 fb ff ff ff ff 3f 29 eb 27 6b 27 3b 27 bb |.
.....?).'k';'.|
00000040 ff ff ff ff ff ff 27 bb ff ff 29 eb 0c 20 10 d8
|......'...).. ..|
00000050 0f 52 00 00 24 4a 99 00 8b 8e 03 e1 ac 01 27 38
|.R..$J........'8|
00000060 7a 75 7a 75 fb bd d5 5c 4a 0f 82 ff 81 bd 3d 36
|zuzu...\J.....=6|
00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
00000080 ff e7 ff ff 21 dc ff ff |....!...|
00000088
Do we need a fixup to tell the erase die to be faster?
I haven't found the 'BFPT' term in the JEDEC spec.
> real 0m5.485s
> user 0m0.000s
> sys 0m5.461s
Before erasing, did the flash contain 128MB of random data on your test?
On my tests, when the flash contains 128MB of random data, the first
erase
takes 4 minutes. Subsequent erases take only 2 seconds.
Thanks
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 14:16 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 14:16 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 10:48, Tudor Ambarus wrote:
> Yep, it's strange, we'll have to check what's happening. I found my
> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
> defines how long the erase die should take, see BFPT dword 11. You can
> start with that.
Where does BFPT dword 11 reside inside SFDP?
~# hexdump -C
/sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
00000000 53 46 44 50 06 01 01 ff 00 06 01 10 30 00 00 ff
|SFDP........0...|
00000010 84 00 01 02 80 00 00 ff ff ff ff ff ff ff ff ff
|................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
00000030 e5 20 fb ff ff ff ff 3f 29 eb 27 6b 27 3b 27 bb |.
.....?).'k';'.|
00000040 ff ff ff ff ff ff 27 bb ff ff 29 eb 0c 20 10 d8
|......'...).. ..|
00000050 0f 52 00 00 24 4a 99 00 8b 8e 03 e1 ac 01 27 38
|.R..$J........'8|
00000060 7a 75 7a 75 fb bd d5 5c 4a 0f 82 ff 81 bd 3d 36
|zuzu...\J.....=6|
00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
00000080 ff e7 ff ff 21 dc ff ff |....!...|
00000088
Do we need a fixup to tell the erase die to be faster?
I haven't found the 'BFPT' term in the JEDEC spec.
> real 0m5.485s
> user 0m0.000s
> sys 0m5.461s
Before erasing, did the flash contain 128MB of random data on your test?
On my tests, when the flash contains 128MB of random data, the first
erase
takes 4 minutes. Subsequent erases take only 2 seconds.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 14:16 ` Fabio Estevam
@ 2023-11-03 14:37 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 14:37 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03.11.2023 16:16, Fabio Estevam wrote:
> On 03/11/2023 10:48, Tudor Ambarus wrote:
>
>> Yep, it's strange, we'll have to check what's happening. I found my
>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>> defines how long the erase die should take, see BFPT dword 11. You can
>> start with that.
>
> Where does BFPT dword 11 reside inside SFDP?
BFPT stands for Basic Flash Parameter Table. BFPT is the first table of
SFDP. Please compare the standard with the dump. We haven't written yet
an utility to decode the SFDP data.
>
> ~# hexdump -C
> /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
> 00000000 53 46 44 50 06 01 01 ff 00 06 01 10 30 00 00 ff
> |SFDP........0...|
> 00000010 84 00 01 02 80 00 00 ff ff ff ff ff ff ff ff ff
> |................|
> 00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000030 e5 20 fb ff ff ff ff 3f 29 eb 27 6b 27 3b 27 bb |.
> .....?).'k';'.|
> 00000040 ff ff ff ff ff ff 27 bb ff ff 29 eb 0c 20 10 d8
> |......'...).. ..|
> 00000050 0f 52 00 00 24 4a 99 00 8b 8e 03 e1 ac 01 27 38
> |.R..$J........'8|
> 00000060 7a 75 7a 75 fb bd d5 5c 4a 0f 82 ff 81 bd 3d 36
> |zuzu...\J.....=6|
> 00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000080 ff e7 ff ff 21 dc ff ff |....!...|
> 00000088
>
> Do we need a fixup to tell the erase die to be faster?
no. We can retrieve the erase time from BFPT and use it to narrow the
wait time.
>
> I haven't found the 'BFPT' term in the JEDEC spec.
>
>> real 0m5.485s
>> user 0m0.000s
>> sys 0m5.461s
>
> Before erasing, did the flash contain 128MB of random data on your test?
not everywhere
>
> On my tests, when the flash contains 128MB of random data, the first erase
> takes 4 minutes. Subsequent erases take only 2 seconds.
>
I confirm I see the same behavior on n25q00 flash.
Erased 134217728 bytes from address 0x00000000 in flash
real 3m49.082s
user 0m0.000s
sys 3m48.485s
I'll continue to investigate this at a best effort rate, expect for some
delays, I'm handling SPI NOR mostly in my spare time. Happy to guide you
though. You may join #mtd irc channel for short questions, see where it
is in the MAINTAINERS file.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 14:37 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-03 14:37 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03.11.2023 16:16, Fabio Estevam wrote:
> On 03/11/2023 10:48, Tudor Ambarus wrote:
>
>> Yep, it's strange, we'll have to check what's happening. I found my
>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>> defines how long the erase die should take, see BFPT dword 11. You can
>> start with that.
>
> Where does BFPT dword 11 reside inside SFDP?
BFPT stands for Basic Flash Parameter Table. BFPT is the first table of
SFDP. Please compare the standard with the dump. We haven't written yet
an utility to decode the SFDP data.
>
> ~# hexdump -C
> /sys/devices/platform/soc@0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/spi-nor/sfdp
> 00000000 53 46 44 50 06 01 01 ff 00 06 01 10 30 00 00 ff
> |SFDP........0...|
> 00000010 84 00 01 02 80 00 00 ff ff ff ff ff ff ff ff ff
> |................|
> 00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000030 e5 20 fb ff ff ff ff 3f 29 eb 27 6b 27 3b 27 bb |.
> .....?).'k';'.|
> 00000040 ff ff ff ff ff ff 27 bb ff ff 29 eb 0c 20 10 d8
> |......'...).. ..|
> 00000050 0f 52 00 00 24 4a 99 00 8b 8e 03 e1 ac 01 27 38
> |.R..$J........'8|
> 00000060 7a 75 7a 75 fb bd d5 5c 4a 0f 82 ff 81 bd 3d 36
> |zuzu...\J.....=6|
> 00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> |................|
> 00000080 ff e7 ff ff 21 dc ff ff |....!...|
> 00000088
>
> Do we need a fixup to tell the erase die to be faster?
no. We can retrieve the erase time from BFPT and use it to narrow the
wait time.
>
> I haven't found the 'BFPT' term in the JEDEC spec.
>
>> real 0m5.485s
>> user 0m0.000s
>> sys 0m5.461s
>
> Before erasing, did the flash contain 128MB of random data on your test?
not everywhere
>
> On my tests, when the flash contains 128MB of random data, the first erase
> takes 4 minutes. Subsequent erases take only 2 seconds.
>
I confirm I see the same behavior on n25q00 flash.
Erased 134217728 bytes from address 0x00000000 in flash
real 3m49.082s
user 0m0.000s
sys 3m48.485s
I'll continue to investigate this at a best effort rate, expect for some
delays, I'm handling SPI NOR mostly in my spare time. Happy to guide you
though. You may join #mtd irc channel for short questions, see where it
is in the MAINTAINERS file.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 14:37 ` Tudor Ambarus
@ 2023-11-03 14:58 ` Fabio Estevam
-1 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 14:58 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 11:37, Tudor Ambarus wrote:
> I confirm I see the same behavior on n25q00 flash.
> Erased 134217728 bytes from address 0x00000000 in flash
>
> real 3m49.082s
> user 0m0.000s
> sys 3m48.485s
>
> I'll continue to investigate this at a best effort rate, expect for
> some
> delays, I'm handling SPI NOR mostly in my spare time. Happy to guide
> you
> though. You may join #mtd irc channel for short questions, see where it
> is in the MAINTAINERS file.
Thanks, Tudor.
Reading the datasheet at:
https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
The last entry of Table 49 shows:
512Mb bulk erase time: Typ: 153 s Max: 460 s
512Mb corresponds to the size of one die.
mt25qu01g has two dies so the bulk erase time would be from 306 to 920 s
(5 to 15 minutes!)
It seems that there is not much we can do about this long erase time.
Is my understanding correct?
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-03 14:58 ` Fabio Estevam
0 siblings, 0 replies; 82+ messages in thread
From: Fabio Estevam @ 2023-11-03 14:58 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 03/11/2023 11:37, Tudor Ambarus wrote:
> I confirm I see the same behavior on n25q00 flash.
> Erased 134217728 bytes from address 0x00000000 in flash
>
> real 3m49.082s
> user 0m0.000s
> sys 3m48.485s
>
> I'll continue to investigate this at a best effort rate, expect for
> some
> delays, I'm handling SPI NOR mostly in my spare time. Happy to guide
> you
> though. You may join #mtd irc channel for short questions, see where it
> is in the MAINTAINERS file.
Thanks, Tudor.
Reading the datasheet at:
https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
The last entry of Table 49 shows:
512Mb bulk erase time: Typ: 153 s Max: 460 s
512Mb corresponds to the size of one die.
mt25qu01g has two dies so the bulk erase time would be from 306 to 920 s
(5 to 15 minutes!)
It seems that there is not much we can do about this long erase time.
Is my understanding correct?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 13:48 ` Tudor Ambarus
@ 2023-11-06 9:34 ` Michael Walle
-1 siblings, 0 replies; 82+ messages in thread
From: Michael Walle @ 2023-11-06 9:34 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
Am 2023-11-03 14:48, schrieb Tudor Ambarus:
> On 03.11.2023 15:37, Fabio Estevam wrote:
>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>
>>> Which version of mtd-utils are you using? I guess the flash-erase
>>
>> mtd-utils 2.1.5
>>
>>> utility is written in a bad way. Please use the following while I
>>> check
>>> what flash_erase is doing:
>>>
>>> time mtd_debug erase /dev/mtd0 0 134217728
>>
>> "mtd_debug erase" gives the same time as well:
>>
>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 4322.120861] spi-nor spi0.0: *****
>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 4322.140154] spi-nor spi0.0: *****
>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>> [ 4322.159761] spi-nor spi0.0: *****
>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 4322.174118] spi-nor spi0.0: *****
>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 4439.971920] spi-nor spi0.0: *****
>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 4439.991174] spi-nor spi0.0: *****
>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>> [ 4440.011272] spi-nor spi0.0: *****
>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 4440.025606] spi-nor spi0.0: *****
>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>> Erased 134217728 bytes from address 0x00000000 in flash
>>
>> real 3m57.384s
>> user 0m0.005s
>> sys 3m35.211s
>>
>
> Yep, it's strange, we'll have to check what's happening. I found my
> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
> defines how long the erase die should take, see BFPT dword 11. You can
> start with that.
Had the flash some contents or was it all-ff? Maybe the Micron flash
will
check if all bytes are one and will skip the erase.
Die/Chip erases will take much longer most of the time and are
comparable
to individual sector erases (as Fabio also found out). You'll probably
just save the overhead of the indivudal commands.
I've looked at the N25Q00AA datasheet and the erase time there is 153s
(typ) for *one* die.
-michael
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-06 9:34 ` Michael Walle
0 siblings, 0 replies; 82+ messages in thread
From: Michael Walle @ 2023-11-06 9:34 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
Am 2023-11-03 14:48, schrieb Tudor Ambarus:
> On 03.11.2023 15:37, Fabio Estevam wrote:
>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>
>>> Which version of mtd-utils are you using? I guess the flash-erase
>>
>> mtd-utils 2.1.5
>>
>>> utility is written in a bad way. Please use the following while I
>>> check
>>> what flash_erase is doing:
>>>
>>> time mtd_debug erase /dev/mtd0 0 134217728
>>
>> "mtd_debug erase" gives the same time as well:
>>
>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 4322.120861] spi-nor spi0.0: *****
>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 4322.140154] spi-nor spi0.0: *****
>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>> [ 4322.159761] spi-nor spi0.0: *****
>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 4322.174118] spi-nor spi0.0: *****
>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 4439.971920] spi-nor spi0.0: *****
>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 4439.991174] spi-nor spi0.0: *****
>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>> [ 4440.011272] spi-nor spi0.0: *****
>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 4440.025606] spi-nor spi0.0: *****
>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>> Erased 134217728 bytes from address 0x00000000 in flash
>>
>> real 3m57.384s
>> user 0m0.005s
>> sys 3m35.211s
>>
>
> Yep, it's strange, we'll have to check what's happening. I found my
> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
> defines how long the erase die should take, see BFPT dword 11. You can
> start with that.
Had the flash some contents or was it all-ff? Maybe the Micron flash
will
check if all bytes are one and will skip the erase.
Die/Chip erases will take much longer most of the time and are
comparable
to individual sector erases (as Fabio also found out). You'll probably
just save the overhead of the indivudal commands.
I've looked at the N25Q00AA datasheet and the erase time there is 153s
(typ) for *one* die.
-michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-06 9:34 ` Michael Walle
@ 2023-11-06 14:23 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-06 14:23 UTC (permalink / raw)
To: Michael Walle
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
On 11/6/23 09:34, Michael Walle wrote:
> Am 2023-11-03 14:48, schrieb Tudor Ambarus:
>> On 03.11.2023 15:37, Fabio Estevam wrote:
>>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>>
>>>> Which version of mtd-utils are you using? I guess the flash-erase
>>>
>>> mtd-utils 2.1.5
>>>
>>>> utility is written in a bad way. Please use the following while I check
>>>> what flash_erase is doing:
>>>>
>>>> time mtd_debug erase /dev/mtd0 0 134217728
>>>
>>> "mtd_debug erase" gives the same time as well:
>>>
>>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>> [ 4322.120861] spi-nor spi0.0: *****
>>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 4322.140154] spi-nor spi0.0: *****
>>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>> [ 4322.159761] spi-nor spi0.0: *****
>>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 4322.174118] spi-nor spi0.0: *****
>>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>> [ 4439.971920] spi-nor spi0.0: *****
>>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 4439.991174] spi-nor spi0.0: *****
>>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>> [ 4440.011272] spi-nor spi0.0: *****
>>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 4440.025606] spi-nor spi0.0: *****
>>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> Erased 134217728 bytes from address 0x00000000 in flash
>>>
>>> real 3m57.384s
>>> user 0m0.005s
>>> sys 3m35.211s
>>>
>>
>> Yep, it's strange, we'll have to check what's happening. I found my
>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>> defines how long the erase die should take, see BFPT dword 11. You can
>> start with that.
>
> Had the flash some contents or was it all-ff? Maybe the Micron flash will
> check if all bytes are one and will skip the erase.
it had some contents, but not different than 0xff
>
> Die/Chip erases will take much longer most of the time and are comparable
> to individual sector erases (as Fabio also found out). You'll probably
> just save the overhead of the indivudal commands.
There is a speed benefit in using die erase instead of individual sector
erases.
>
> I've looked at the N25Q00AA datasheet and the erase time there is 153s
> (typ) for *one* die.
>
you mean mt25q. Table 49 in
https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
Each die has 64MB. A die is composed of either 16384 4KB sectors or 2048
sectors of 32KB.
4KB typical erase time is 0.05s, thus a die will be erased in 819.2s.
32KB typical erase time is 0.1s, thus a die will be erased in 204.8s.
die erase typical erase time is 153s.
4K max erase time is 0.4s, thus a die will be erased in 6553.6s
32KB max erase time is 1, thus a die will be erased in 2048s.
die erase max time is 460s.
so you might say that 32KB typical erase time might be comparable to a
die erase command when erasing an entire die with 32KB erases, but even
so, it should be preferable to use die erase cmd. Instead of sending a
write enable followed by a sector erase command for each sector, you
could instead use a single write enable followed by a single die erase
command.
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-06 14:23 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-06 14:23 UTC (permalink / raw)
To: Michael Walle
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
On 11/6/23 09:34, Michael Walle wrote:
> Am 2023-11-03 14:48, schrieb Tudor Ambarus:
>> On 03.11.2023 15:37, Fabio Estevam wrote:
>>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>>
>>>> Which version of mtd-utils are you using? I guess the flash-erase
>>>
>>> mtd-utils 2.1.5
>>>
>>>> utility is written in a bad way. Please use the following while I check
>>>> what flash_erase is doing:
>>>>
>>>> time mtd_debug erase /dev/mtd0 0 134217728
>>>
>>> "mtd_debug erase" gives the same time as well:
>>>
>>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>> [ 4322.120861] spi-nor spi0.0: *****
>>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 4322.140154] spi-nor spi0.0: *****
>>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>> [ 4322.159761] spi-nor spi0.0: *****
>>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 4322.174118] spi-nor spi0.0: *****
>>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>> [ 4439.971920] spi-nor spi0.0: *****
>>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 4439.991174] spi-nor spi0.0: *****
>>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>> [ 4440.011272] spi-nor spi0.0: *****
>>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 4440.025606] spi-nor spi0.0: *****
>>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> Erased 134217728 bytes from address 0x00000000 in flash
>>>
>>> real 3m57.384s
>>> user 0m0.005s
>>> sys 3m35.211s
>>>
>>
>> Yep, it's strange, we'll have to check what's happening. I found my
>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>> defines how long the erase die should take, see BFPT dword 11. You can
>> start with that.
>
> Had the flash some contents or was it all-ff? Maybe the Micron flash will
> check if all bytes are one and will skip the erase.
it had some contents, but not different than 0xff
>
> Die/Chip erases will take much longer most of the time and are comparable
> to individual sector erases (as Fabio also found out). You'll probably
> just save the overhead of the indivudal commands.
There is a speed benefit in using die erase instead of individual sector
erases.
>
> I've looked at the N25Q00AA datasheet and the erase time there is 153s
> (typ) for *one* die.
>
you mean mt25q. Table 49 in
https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
Each die has 64MB. A die is composed of either 16384 4KB sectors or 2048
sectors of 32KB.
4KB typical erase time is 0.05s, thus a die will be erased in 819.2s.
32KB typical erase time is 0.1s, thus a die will be erased in 204.8s.
die erase typical erase time is 153s.
4K max erase time is 0.4s, thus a die will be erased in 6553.6s
32KB max erase time is 1, thus a die will be erased in 2048s.
die erase max time is 460s.
so you might say that 32KB typical erase time might be comparable to a
die erase command when erasing an entire die with 32KB erases, but even
so, it should be preferable to use die erase cmd. Instead of sending a
write enable followed by a sector erase command for each sector, you
could instead use a single write enable followed by a single die erase
command.
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-03 14:58 ` Fabio Estevam
@ 2023-11-06 14:24 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-06 14:24 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/3/23 14:58, Fabio Estevam wrote:
> On 03/11/2023 11:37, Tudor Ambarus wrote:
>
>> I confirm I see the same behavior on n25q00 flash.
>> Erased 134217728 bytes from address 0x00000000 in flash
>>
>> real 3m49.082s
>> user 0m0.000s
>> sys 3m48.485s
>>
>> I'll continue to investigate this at a best effort rate, expect for some
>> delays, I'm handling SPI NOR mostly in my spare time. Happy to guide you
>> though. You may join #mtd irc channel for short questions, see where it
>> is in the MAINTAINERS file.
>
> Thanks, Tudor.
>
> Reading the datasheet at:
> https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
>
> The last entry of Table 49 shows:
>
> 512Mb bulk erase time: Typ: 153 s Max: 460 s
>
> 512Mb corresponds to the size of one die.
>
> mt25qu01g has two dies so the bulk erase time would be from 306 to 920 s
> (5 to 15 minutes!)
>
> It seems that there is not much we can do about this long erase time.
>
> Is my understanding correct?
Yes, I find your understanding correct.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-06 14:24 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-06 14:24 UTC (permalink / raw)
To: Fabio Estevam
Cc: Takahiro Kuwano, michael, pratyush, linux-mtd, linux-arm-kernel,
bacem.daassi, miquel.raynal, richard
On 11/3/23 14:58, Fabio Estevam wrote:
> On 03/11/2023 11:37, Tudor Ambarus wrote:
>
>> I confirm I see the same behavior on n25q00 flash.
>> Erased 134217728 bytes from address 0x00000000 in flash
>>
>> real 3m49.082s
>> user 0m0.000s
>> sys 3m48.485s
>>
>> I'll continue to investigate this at a best effort rate, expect for some
>> delays, I'm handling SPI NOR mostly in my spare time. Happy to guide you
>> though. You may join #mtd irc channel for short questions, see where it
>> is in the MAINTAINERS file.
>
> Thanks, Tudor.
>
> Reading the datasheet at:
> https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
>
> The last entry of Table 49 shows:
>
> 512Mb bulk erase time: Typ: 153 s Max: 460 s
>
> 512Mb corresponds to the size of one die.
>
> mt25qu01g has two dies so the bulk erase time would be from 306 to 920 s
> (5 to 15 minutes!)
>
> It seems that there is not much we can do about this long erase time.
>
> Is my understanding correct?
Yes, I find your understanding correct.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-06 14:23 ` Tudor Ambarus
@ 2023-11-06 14:56 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-06 14:56 UTC (permalink / raw)
To: Michael Walle
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
On 11/6/23 14:23, Tudor Ambarus wrote:
> it had some contents, but not different than 0xff
*not all different*
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-06 14:56 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-06 14:56 UTC (permalink / raw)
To: Michael Walle
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
On 11/6/23 14:23, Tudor Ambarus wrote:
> it had some contents, but not different than 0xff
*not all different*
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-02 18:46 ` Tudor Ambarus
@ 2023-11-08 8:06 ` Takahiro Kuwano
-1 siblings, 0 replies; 82+ messages in thread
From: Takahiro Kuwano @ 2023-11-08 8:06 UTC (permalink / raw)
To: Tudor Ambarus, Fabio Estevam, Takahiro Kuwano
Cc: michael, pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
Hi,
On 11/3/2023 3:46 AM, Tudor Ambarus wrote:
>
>
> On 11/2/23 18:33, Fabio Estevam wrote:
>> On 02/11/2023 15:21, Tudor Ambarus wrote:
>>
>>> Let's see what gets to the SPI controller. Which SPI controller do you
>>> use?
>>
>> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>>
>> Here is the result:
>>
>> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
>> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
>> nor->reg_proto = 0x00010101
>> % complete [ 26.049570] spi-nor spi0.0: *****
>> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.069787] spi-nor spi0.0: *****
>> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>> [ 26.089368] spi-nor spi0.0: *****
>> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.103713] spi-nor spi0.0: *****
>> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
>> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 26.123589] spi-nor spi0.0: *****
>> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.142956] spi-nor spi0.0: *****
>> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>> [ 26.163065] spi-nor spi0.0: *****
>> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.177405] spi-nor spi0.0: *****
>> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
>> Erasing 131072 Kibyte @ 0 -- 100 % complete
>>
>
> It looks good ...
>
>> root@mcde3000a:~# hexdump /dev/mtd0
>> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
>> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
>
> but the patient is dead :). Would be good if Takahiro can test on IFX
> too. In the meantime I'll try to find a n25q00, I remember I had one in
> the past.
>
With your spi-nor/next-die-erase-v2-debug in linux-0day, die erase for IFX part
(s25hs02gt) is working. Here is the log.
1st die:
zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 7m 47.92s
user 0m 0.00s
sys 7m 47.92s
2nd die:
zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x08000000 in flash
real 7m 44.97s
user 0m 0.00s
sys 7m 44.96s
Both dice at once:
zynq> time mtd_debug erase /dev/mtd0 0x0 0x10000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 268435456 bytes from address 0x00000000 in flash
real 15m 44.17s
user 0m 0.00s
sys 15m 44.15s
Infineon SEMPER flash family has 'blank check' feature that skips erase ops
if the sector is already erased. It can be enabled by setting CFR3[5]=1.
After enabling this, the subsequent erase times are reduced.
1st die:
zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 0m 6.84s
user 0m 0.00s
sys 0m 6.84s
2nd die:
zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x08000000 in flash
real 0m 6.70s
user 0m 0.00s
sys 0m 6.70s
Both dice at once:
zynq> time mtd_debug erase /dev/mtd0 0 0x10000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 268435456 bytes from address 0x00000000 in flash
real 0m 13.54s
user 0m 0.00s
sys 0m 13.54s
Thanks,
Takahiro
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-08 8:06 ` Takahiro Kuwano
0 siblings, 0 replies; 82+ messages in thread
From: Takahiro Kuwano @ 2023-11-08 8:06 UTC (permalink / raw)
To: Tudor Ambarus, Fabio Estevam, Takahiro Kuwano
Cc: michael, pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
Hi,
On 11/3/2023 3:46 AM, Tudor Ambarus wrote:
>
>
> On 11/2/23 18:33, Fabio Estevam wrote:
>> On 02/11/2023 15:21, Tudor Ambarus wrote:
>>
>>> Let's see what gets to the SPI controller. Which SPI controller do you
>>> use?
>>
>> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>>
>> Here is the result:
>>
>> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
>> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
>> nor->reg_proto = 0x00010101
>> % complete [ 26.049570] spi-nor spi0.0: *****
>> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.069787] spi-nor spi0.0: *****
>> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>> [ 26.089368] spi-nor spi0.0: *****
>> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.103713] spi-nor spi0.0: *****
>> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
>> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>> [ 26.123589] spi-nor spi0.0: *****
>> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>> [ 26.142956] spi-nor spi0.0: *****
>> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>> [ 26.163065] spi-nor spi0.0: *****
>> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>> [ 26.177405] spi-nor spi0.0: *****
>> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
>> Erasing 131072 Kibyte @ 0 -- 100 % complete
>>
>
> It looks good ...
>
>> root@mcde3000a:~# hexdump /dev/mtd0
>> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
>> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
>
> but the patient is dead :). Would be good if Takahiro can test on IFX
> too. In the meantime I'll try to find a n25q00, I remember I had one in
> the past.
>
With your spi-nor/next-die-erase-v2-debug in linux-0day, die erase for IFX part
(s25hs02gt) is working. Here is the log.
1st die:
zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 7m 47.92s
user 0m 0.00s
sys 7m 47.92s
2nd die:
zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x08000000 in flash
real 7m 44.97s
user 0m 0.00s
sys 7m 44.96s
Both dice at once:
zynq> time mtd_debug erase /dev/mtd0 0x0 0x10000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 268435456 bytes from address 0x00000000 in flash
real 15m 44.17s
user 0m 0.00s
sys 15m 44.15s
Infineon SEMPER flash family has 'blank check' feature that skips erase ops
if the sector is already erased. It can be enabled by setting CFR3[5]=1.
After enabling this, the subsequent erase times are reduced.
1st die:
zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x00000000 in flash
real 0m 6.84s
user 0m 0.00s
sys 0m 6.84s
2nd die:
zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 134217728 bytes from address 0x08000000 in flash
real 0m 6.70s
user 0m 0.00s
sys 0m 6.70s
Both dice at once:
zynq> time mtd_debug erase /dev/mtd0 0 0x10000000
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x0
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
spi-nor spi0.0: ***** op.cmd.opcode = 0x61
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.addr.nbytes = 0x04
spi-nor spi0.0: ***** op.addr.buswidth = 0x01
spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
spi-nor spi0.0: *****
spi-nor spi0.0: ***** op.data.buswidth = 0x00
spi-nor spi0.0: ***** op.data.nbytes = 0
Erased 268435456 bytes from address 0x00000000 in flash
real 0m 13.54s
user 0m 0.00s
sys 0m 13.54s
Thanks,
Takahiro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-08 8:06 ` Takahiro Kuwano
@ 2023-11-08 8:54 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-08 8:54 UTC (permalink / raw)
To: Takahiro Kuwano, Fabio Estevam, Takahiro Kuwano
Cc: michael, pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
On 11/8/23 08:06, Takahiro Kuwano wrote:
> Hi,
>
> On 11/3/2023 3:46 AM, Tudor Ambarus wrote:
>>
>>
>> On 11/2/23 18:33, Fabio Estevam wrote:
>>> On 02/11/2023 15:21, Tudor Ambarus wrote:
>>>
>>>> Let's see what gets to the SPI controller. Which SPI controller do you
>>>> use?
>>>
>>> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>>>
>>> Here is the result:
>>>
>>> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
>>> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
>>> nor->reg_proto = 0x00010101
>>> % complete [ 26.049570] spi-nor spi0.0: *****
>>> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 26.069787] spi-nor spi0.0: *****
>>> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>> [ 26.089368] spi-nor spi0.0: *****
>>> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 26.103713] spi-nor spi0.0: *****
>>> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>> [ 26.123589] spi-nor spi0.0: *****
>>> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 26.142956] spi-nor spi0.0: *****
>>> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>> [ 26.163065] spi-nor spi0.0: *****
>>> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 26.177405] spi-nor spi0.0: *****
>>> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> Erasing 131072 Kibyte @ 0 -- 100 % complete
>>>
>>
>> It looks good ...
>>
>>> root@mcde3000a:~# hexdump /dev/mtd0
>>> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
>>> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
>>
>> but the patient is dead :). Would be good if Takahiro can test on IFX
>> too. In the meantime I'll try to find a n25q00, I remember I had one in
>> the past.
>>
> With your spi-nor/next-die-erase-v2-debug in linux-0day, die erase for IFX part
> (s25hs02gt) is working. Here is the log.
>
> 1st die:
>
> zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x00000000 in flash
> real 7m 47.92s
> user 0m 0.00s
> sys 7m 47.92s
>
>
> 2nd die:
>
> zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x08000000 in flash
> real 7m 44.97s
> user 0m 0.00s
> sys 7m 44.96s
>
>
> Both dice at once:
>
> zynq> time mtd_debug erase /dev/mtd0 0x0 0x10000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 268435456 bytes from address 0x00000000 in flash
> real 15m 44.17s
> user 0m 0.00s
> sys 15m 44.15s
>
great
>
> Infineon SEMPER flash family has 'blank check' feature that skips erase ops
> if the sector is already erased. It can be enabled by setting CFR3[5]=1.
> After enabling this, the subsequent erase times are reduced.
>
> 1st die:
>
> zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x00000000 in flash
> real 0m 6.84s
> user 0m 0.00s
> sys 0m 6.84s
>
>
> 2nd die:
>
> zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x08000000 in flash
> real 0m 6.70s
> user 0m 0.00s
> sys 0m 6.70s
>
>
> Both dice at once:
>
> zynq> time mtd_debug erase /dev/mtd0 0 0x10000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 268435456 bytes from address 0x00000000 in flash
> real 0m 13.54s
> user 0m 0.00s
> sys 0m 13.54s
>
wonderful, thanks Takahiro! I'll send a v3.
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-08 8:54 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-08 8:54 UTC (permalink / raw)
To: Takahiro Kuwano, Fabio Estevam, Takahiro Kuwano
Cc: michael, pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
On 11/8/23 08:06, Takahiro Kuwano wrote:
> Hi,
>
> On 11/3/2023 3:46 AM, Tudor Ambarus wrote:
>>
>>
>> On 11/2/23 18:33, Fabio Estevam wrote:
>>> On 02/11/2023 15:21, Tudor Ambarus wrote:
>>>
>>>> Let's see what gets to the SPI controller. Which SPI controller do you
>>>> use?
>>>
>>> I am using i.MX8MP, which has drivers/spi/spi-nxp-fspi.c.
>>>
>>> Here is the result:
>>>
>>> root@mcde3000a:~# flash_erase /dev/mtd0 0 0
>>> Erasing 131072 Kibyte @ 0 -- 0 [ 26.040903] spi-nor spi0.0: *****
>>> nor->reg_proto = 0x00010101
>>> % complete [ 26.049570] spi-nor spi0.0: *****
>>> [ 26.053849] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 26.059118] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 26.064539] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 26.069787] spi-nor spi0.0: *****
>>> [ 26.073118] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 26.078451] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 26.083949] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>> [ 26.089368] spi-nor spi0.0: *****
>>> [ 26.092699] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 26.098123] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 26.103713] spi-nor spi0.0: *****
>>> [ 26.107045] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 26.112549] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> [ 26.117727] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>> [ 26.123589] spi-nor spi0.0: *****
>>> [ 26.127012] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>> [ 26.132274] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>> [ 26.137706] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>> [ 26.142956] spi-nor spi0.0: *****
>>> [ 26.146290] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>> [ 26.151625] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>> [ 26.157132] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>> [ 26.163065] spi-nor spi0.0: *****
>>> [ 26.166402] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>> [ 26.171815] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>> [ 26.177405] spi-nor spi0.0: *****
>>> [ 26.180737] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>> [ 26.186241] spi-nor spi0.0: ***** op.data.nbytes = 0
>>> Erasing 131072 Kibyte @ 0 -- 100 % complete
>>>
>>
>> It looks good ...
>>
>>> root@mcde3000a:~# hexdump /dev/mtd0
>>> 0000000 a1d4 168c 4dad dfb2 2a3d c2af 0aae c18a
>>> 0000010 2d5f 177a c39f 46a4 f9cd b880 331e 2543
>>
>> but the patient is dead :). Would be good if Takahiro can test on IFX
>> too. In the meantime I'll try to find a n25q00, I remember I had one in
>> the past.
>>
> With your spi-nor/next-die-erase-v2-debug in linux-0day, die erase for IFX part
> (s25hs02gt) is working. Here is the log.
>
> 1st die:
>
> zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x00000000 in flash
> real 7m 47.92s
> user 0m 0.00s
> sys 7m 47.92s
>
>
> 2nd die:
>
> zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x08000000 in flash
> real 7m 44.97s
> user 0m 0.00s
> sys 7m 44.96s
>
>
> Both dice at once:
>
> zynq> time mtd_debug erase /dev/mtd0 0x0 0x10000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 268435456 bytes from address 0x00000000 in flash
> real 15m 44.17s
> user 0m 0.00s
> sys 15m 44.15s
>
great
>
> Infineon SEMPER flash family has 'blank check' feature that skips erase ops
> if the sector is already erased. It can be enabled by setting CFR3[5]=1.
> After enabling this, the subsequent erase times are reduced.
>
> 1st die:
>
> zynq> time mtd_debug erase /dev/mtd0 0 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x00000000 in flash
> real 0m 6.84s
> user 0m 0.00s
> sys 0m 6.84s
>
>
> 2nd die:
>
> zynq> time mtd_debug erase /dev/mtd0 0x8000000 0x8000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 134217728 bytes from address 0x08000000 in flash
> real 0m 6.70s
> user 0m 0.00s
> sys 0m 6.70s
>
>
> Both dice at once:
>
> zynq> time mtd_debug erase /dev/mtd0 0 0x10000000
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x0
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
> spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
> spi-nor spi0.0: ***** op.cmd.opcode = 0x61
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.addr.nbytes = 0x04
> spi-nor spi0.0: ***** op.addr.buswidth = 0x01
> spi-nor spi0.0: ***** op.addr.buswidth = 0x8000000
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
> spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
> spi-nor spi0.0: *****
> spi-nor spi0.0: ***** op.data.buswidth = 0x00
> spi-nor spi0.0: ***** op.data.nbytes = 0
> Erased 268435456 bytes from address 0x00000000 in flash
> real 0m 13.54s
> user 0m 0.00s
> sys 0m 13.54s
>
wonderful, thanks Takahiro! I'll send a v3.
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-06 14:23 ` Tudor Ambarus
@ 2023-11-09 9:09 ` Michael Walle
-1 siblings, 0 replies; 82+ messages in thread
From: Michael Walle @ 2023-11-09 9:09 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
Am 2023-11-06 15:23, schrieb Tudor Ambarus:
> On 11/6/23 09:34, Michael Walle wrote:
>> Am 2023-11-03 14:48, schrieb Tudor Ambarus:
>>> On 03.11.2023 15:37, Fabio Estevam wrote:
>>>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>>>
>>>>> Which version of mtd-utils are you using? I guess the flash-erase
>>>>
>>>> mtd-utils 2.1.5
>>>>
>>>>> utility is written in a bad way. Please use the following while I
>>>>> check
>>>>> what flash_erase is doing:
>>>>>
>>>>> time mtd_debug erase /dev/mtd0 0 134217728
>>>>
>>>> "mtd_debug erase" gives the same time as well:
>>>>
>>>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>>>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>> [ 4322.120861] spi-nor spi0.0: *****
>>>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>> [ 4322.140154] spi-nor spi0.0: *****
>>>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>>> [ 4322.159761] spi-nor spi0.0: *****
>>>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>> [ 4322.174118] spi-nor spi0.0: *****
>>>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>> [ 4439.971920] spi-nor spi0.0: *****
>>>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>> [ 4439.991174] spi-nor spi0.0: *****
>>>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>>> [ 4440.011272] spi-nor spi0.0: *****
>>>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>> [ 4440.025606] spi-nor spi0.0: *****
>>>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>> Erased 134217728 bytes from address 0x00000000 in flash
>>>>
>>>> real 3m57.384s
>>>> user 0m0.005s
>>>> sys 3m35.211s
>>>>
>>>
>>> Yep, it's strange, we'll have to check what's happening. I found my
>>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>>> defines how long the erase die should take, see BFPT dword 11. You
>>> can
>>> start with that.
>>
>> Had the flash some contents or was it all-ff? Maybe the Micron flash
>> will
>> check if all bytes are one and will skip the erase.
>
> it had some contents, but not different than 0xff
>>
>> Die/Chip erases will take much longer most of the time and are
>> comparable
>> to individual sector erases (as Fabio also found out). You'll probably
>> just save the overhead of the indivudal commands.
>
> There is a speed benefit in using die erase instead of individual
> sector
> erases.
>>
>> I've looked at the N25Q00AA datasheet and the erase time there is 153s
>> (typ) for *one* die.
>>
>
> you mean mt25q. Table 49 in
> https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
>
>
> Each die has 64MB. A die is composed of either 16384 4KB sectors or
> 2048
> sectors of 32KB.
>
> 4KB typical erase time is 0.05s, thus a die will be erased in 819.2s.
> 32KB typical erase time is 0.1s, thus a die will be erased in 204.8s.
> die erase typical erase time is 153s.
>
> 4K max erase time is 0.4s, thus a die will be erased in 6553.6s
> 32KB max erase time is 1, thus a die will be erased in 2048s.
> die erase max time is 460s.
>
> so you might say that 32KB typical erase time might be comparable to a
> die erase command when erasing an entire die with 32KB erases, but even
> so, it should be preferable to use die erase cmd. Instead of sending a
> write enable followed by a sector erase command for each sector, you
> could instead use a single write enable followed by a single die erase
> command.
I was just implying that your 5s chip erase time sounded unlikely.
I'm also still undecided on the use of a chip/die erase command. How
often is a flash erased entirely? I don't think very often, maybe during
board manufacturing. And is that worth the (maintenance) efforts?
Anyway, I won't stand in the way if you insist.
Nobody commented on that so far: The jedec spec doesn't say anything
about the chip/die erase command, right? There is a flag which
indicates wether the chip has one (in 8d8d8d mode) and there is a field
for its erase time, but not *what* the actual command is. Such a pity,
esp. because the die erase now differs among vendors.. whereas the chip
erase command seems to be common among vendors.
Btw. if we want to speed the erase up we should make use of the erase
regions. AFAIK, at the moment we do (slow) 4k erases most of the time
because distros have this kernel option enabled.
-michael
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-09 9:09 ` Michael Walle
0 siblings, 0 replies; 82+ messages in thread
From: Michael Walle @ 2023-11-09 9:09 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
Am 2023-11-06 15:23, schrieb Tudor Ambarus:
> On 11/6/23 09:34, Michael Walle wrote:
>> Am 2023-11-03 14:48, schrieb Tudor Ambarus:
>>> On 03.11.2023 15:37, Fabio Estevam wrote:
>>>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>>>
>>>>> Which version of mtd-utils are you using? I guess the flash-erase
>>>>
>>>> mtd-utils 2.1.5
>>>>
>>>>> utility is written in a bad way. Please use the following while I
>>>>> check
>>>>> what flash_erase is doing:
>>>>>
>>>>> time mtd_debug erase /dev/mtd0 0 134217728
>>>>
>>>> "mtd_debug erase" gives the same time as well:
>>>>
>>>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>>>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>> [ 4322.120861] spi-nor spi0.0: *****
>>>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>> [ 4322.140154] spi-nor spi0.0: *****
>>>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>>> [ 4322.159761] spi-nor spi0.0: *****
>>>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>> [ 4322.174118] spi-nor spi0.0: *****
>>>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>> [ 4439.971920] spi-nor spi0.0: *****
>>>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>> [ 4439.991174] spi-nor spi0.0: *****
>>>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>>> [ 4440.011272] spi-nor spi0.0: *****
>>>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>> [ 4440.025606] spi-nor spi0.0: *****
>>>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>> Erased 134217728 bytes from address 0x00000000 in flash
>>>>
>>>> real 3m57.384s
>>>> user 0m0.005s
>>>> sys 3m35.211s
>>>>
>>>
>>> Yep, it's strange, we'll have to check what's happening. I found my
>>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>>> defines how long the erase die should take, see BFPT dword 11. You
>>> can
>>> start with that.
>>
>> Had the flash some contents or was it all-ff? Maybe the Micron flash
>> will
>> check if all bytes are one and will skip the erase.
>
> it had some contents, but not different than 0xff
>>
>> Die/Chip erases will take much longer most of the time and are
>> comparable
>> to individual sector erases (as Fabio also found out). You'll probably
>> just save the overhead of the indivudal commands.
>
> There is a speed benefit in using die erase instead of individual
> sector
> erases.
>>
>> I've looked at the N25Q00AA datasheet and the erase time there is 153s
>> (typ) for *one* die.
>>
>
> you mean mt25q. Table 49 in
> https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
>
>
> Each die has 64MB. A die is composed of either 16384 4KB sectors or
> 2048
> sectors of 32KB.
>
> 4KB typical erase time is 0.05s, thus a die will be erased in 819.2s.
> 32KB typical erase time is 0.1s, thus a die will be erased in 204.8s.
> die erase typical erase time is 153s.
>
> 4K max erase time is 0.4s, thus a die will be erased in 6553.6s
> 32KB max erase time is 1, thus a die will be erased in 2048s.
> die erase max time is 460s.
>
> so you might say that 32KB typical erase time might be comparable to a
> die erase command when erasing an entire die with 32KB erases, but even
> so, it should be preferable to use die erase cmd. Instead of sending a
> write enable followed by a sector erase command for each sector, you
> could instead use a single write enable followed by a single die erase
> command.
I was just implying that your 5s chip erase time sounded unlikely.
I'm also still undecided on the use of a chip/die erase command. How
often is a flash erased entirely? I don't think very often, maybe during
board manufacturing. And is that worth the (maintenance) efforts?
Anyway, I won't stand in the way if you insist.
Nobody commented on that so far: The jedec spec doesn't say anything
about the chip/die erase command, right? There is a flag which
indicates wether the chip has one (in 8d8d8d mode) and there is a field
for its erase time, but not *what* the actual command is. Such a pity,
esp. because the die erase now differs among vendors.. whereas the chip
erase command seems to be common among vendors.
Btw. if we want to speed the erase up we should make use of the erase
regions. AFAIK, at the moment we do (slow) 4k erases most of the time
because distros have this kernel option enabled.
-michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re (subset): [PATCH v2 0/6] mtd: spi-nor: introduce die erase
2023-11-01 14:58 ` Tudor Ambarus
@ 2023-11-15 6:10 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-15 6:10 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano, Tudor Ambarus
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
On Wed, 01 Nov 2023 14:58:47 +0000, Tudor Ambarus wrote:
> The patch set is just compiled tested as I don't have a multi die flash
> at hand. Takahiro and Fabio, please test the series and let me know if
> it works on your side.
>
> This will be followed by the removal of SNOR_F_NO_OP_CHIP_ERASE and
> implicitly of the old xilinx SPI NOR driver, but let's take it all in
> small bites.
>
> [...]
Applied to git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git,
spi-nor/next branch. Thanks!
[1/6] mtd: spi-nor: use kernel sized types instead of c99 types
https://git.kernel.org/mtd/c/075ede8d20f8
Cheers,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re (subset): [PATCH v2 0/6] mtd: spi-nor: introduce die erase
@ 2023-11-15 6:10 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-15 6:10 UTC (permalink / raw)
To: michael, festevam, takahiro.kuwano, Tudor Ambarus
Cc: pratyush, linux-mtd, linux-arm-kernel, bacem.daassi,
miquel.raynal, richard
On Wed, 01 Nov 2023 14:58:47 +0000, Tudor Ambarus wrote:
> The patch set is just compiled tested as I don't have a multi die flash
> at hand. Takahiro and Fabio, please test the series and let me know if
> it works on your side.
>
> This will be followed by the removal of SNOR_F_NO_OP_CHIP_ERASE and
> implicitly of the old xilinx SPI NOR driver, but let's take it all in
> small bites.
>
> [...]
Applied to git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git,
spi-nor/next branch. Thanks!
[1/6] mtd: spi-nor: use kernel sized types instead of c99 types
https://git.kernel.org/mtd/c/075ede8d20f8
Cheers,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
2023-11-09 9:09 ` Michael Walle
@ 2023-11-15 7:06 ` Tudor Ambarus
-1 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-15 7:06 UTC (permalink / raw)
To: Michael Walle
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
On 09.11.2023 11:09, Michael Walle wrote:
> Am 2023-11-06 15:23, schrieb Tudor Ambarus:
>> On 11/6/23 09:34, Michael Walle wrote:
>>> Am 2023-11-03 14:48, schrieb Tudor Ambarus:
>>>> On 03.11.2023 15:37, Fabio Estevam wrote:
>>>>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>>>>
>>>>>> Which version of mtd-utils are you using? I guess the flash-erase
>>>>>
>>>>> mtd-utils 2.1.5
>>>>>
>>>>>> utility is written in a bad way. Please use the following while I
>>>>>> check
>>>>>> what flash_erase is doing:
>>>>>>
>>>>>> time mtd_debug erase /dev/mtd0 0 134217728
>>>>>
>>>>> "mtd_debug erase" gives the same time as well:
>>>>>
>>>>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>>>>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>>> [ 4322.120861] spi-nor spi0.0: *****
>>>>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>>> [ 4322.140154] spi-nor spi0.0: *****
>>>>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>>>> [ 4322.159761] spi-nor spi0.0: *****
>>>>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>>> [ 4322.174118] spi-nor spi0.0: *****
>>>>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>>> [ 4439.971920] spi-nor spi0.0: *****
>>>>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>>> [ 4439.991174] spi-nor spi0.0: *****
>>>>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>>>> [ 4440.011272] spi-nor spi0.0: *****
>>>>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>>> [ 4440.025606] spi-nor spi0.0: *****
>>>>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>>> Erased 134217728 bytes from address 0x00000000 in flash
>>>>>
>>>>> real 3m57.384s
>>>>> user 0m0.005s
>>>>> sys 3m35.211s
>>>>>
>>>>
>>>> Yep, it's strange, we'll have to check what's happening. I found my
>>>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>>>> defines how long the erase die should take, see BFPT dword 11. You can
>>>> start with that.
>>>
>>> Had the flash some contents or was it all-ff? Maybe the Micron flash
>>> will
>>> check if all bytes are one and will skip the erase.
>>
>> it had some contents, but not different than 0xff
>>>
>>> Die/Chip erases will take much longer most of the time and are
>>> comparable
>>> to individual sector erases (as Fabio also found out). You'll probably
>>> just save the overhead of the indivudal commands.
>>
>> There is a speed benefit in using die erase instead of individual sector
>> erases.
>>>
>>> I've looked at the N25Q00AA datasheet and the erase time there is 153s
>>> (typ) for *one* die.
>>>
>>
>> you mean mt25q. Table 49 in
>> https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
>>
>>
>> Each die has 64MB. A die is composed of either 16384 4KB sectors or 2048
>> sectors of 32KB.
>>
>> 4KB typical erase time is 0.05s, thus a die will be erased in 819.2s.
>> 32KB typical erase time is 0.1s, thus a die will be erased in 204.8s.
>> die erase typical erase time is 153s.
>>
>> 4K max erase time is 0.4s, thus a die will be erased in 6553.6s
>> 32KB max erase time is 1, thus a die will be erased in 2048s.
>> die erase max time is 460s.
>>
>> so you might say that 32KB typical erase time might be comparable to a
>> die erase command when erasing an entire die with 32KB erases, but even
>> so, it should be preferable to use die erase cmd. Instead of sending a
>> write enable followed by a sector erase command for each sector, you
>> could instead use a single write enable followed by a single die erase
>> command.
>
> I was just implying that your 5s chip erase time sounded unlikely.
>
> I'm also still undecided on the use of a chip/die erase command. How
> often is a flash erased entirely? I don't think very often, maybe during
> board manufacturing. And is that worth the (maintenance) efforts?
>
> Anyway, I won't stand in the way if you insist.
I don't insist, but I feel it is worth it, yes. We have some speed
improvement and we should benefit of it.
>
> Nobody commented on that so far: The jedec spec doesn't say anything
> about the chip/die erase command, right? There is a flag which
> indicates wether the chip has one (in 8d8d8d mode) and there is a field
> for its erase time, but not *what* the actual command is. Such a pity,
jesd216 mentions die erase, but does not provide an opcode for it. Check
BFPT dword 11, bits 30:24, "Chip Erase, Typical time", it says:
"Typical time to erase one chip (die). User must poll device busy to
determine if the operation has completed. For a device consisting of
multiple dies, that are individually accessed, the time is for each die
to which a chip erase command is applied."
So when a flash consists of a single die, this is the erase time for the
full chip (die) erase, and when it consists of multiple dies, it's the
die erase time. Chip and die are the same thing.
> esp. because the die erase now differs among vendors.. whereas the chip
> erase command seems to be common among vendors.
Indeed we saw that the die erase opcode differs among vendors, nothing
that we can do about it now. But we can handle it in software, no big deal.
>
> Btw. if we want to speed the erase up we should make use of the erase
> regions. AFAIK, at the moment we do (slow) 4k erases most of the time
> because distros have this kernel option enabled.
>
yes, I know, there were some attempts and the main concern was how it
will cope with what filesystems are requiring. Anyway, different topic
that needs some thought.
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability
@ 2023-11-15 7:06 ` Tudor Ambarus
0 siblings, 0 replies; 82+ messages in thread
From: Tudor Ambarus @ 2023-11-15 7:06 UTC (permalink / raw)
To: Michael Walle
Cc: Fabio Estevam, Takahiro Kuwano, pratyush, linux-mtd,
linux-arm-kernel, bacem.daassi, miquel.raynal, richard
On 09.11.2023 11:09, Michael Walle wrote:
> Am 2023-11-06 15:23, schrieb Tudor Ambarus:
>> On 11/6/23 09:34, Michael Walle wrote:
>>> Am 2023-11-03 14:48, schrieb Tudor Ambarus:
>>>> On 03.11.2023 15:37, Fabio Estevam wrote:
>>>>> On 03/11/2023 10:26, Tudor Ambarus wrote:
>>>>>
>>>>>> Which version of mtd-utils are you using? I guess the flash-erase
>>>>>
>>>>> mtd-utils 2.1.5
>>>>>
>>>>>> utility is written in a bad way. Please use the following while I
>>>>>> check
>>>>>> what flash_erase is doing:
>>>>>>
>>>>>> time mtd_debug erase /dev/mtd0 0 134217728
>>>>>
>>>>> "mtd_debug erase" gives the same time as well:
>>>>>
>>>>> root@mcde3000a:~# time mtd_debug erase /dev/mtd0 0 134217728
>>>>> [ 4322.114967] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>>> [ 4322.120861] spi-nor spi0.0: *****
>>>>> [ 4322.124210] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>>> [ 4322.129478] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>>> [ 4322.134903] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>>> [ 4322.140154] spi-nor spi0.0: *****
>>>>> [ 4322.143491] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>>> [ 4322.148831] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>>> [ 4322.154341] spi-nor spi0.0: ***** op.addr.buswidth = 0x0
>>>>> [ 4322.159761] spi-nor spi0.0: *****
>>>>> [ 4322.163098] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>>> [ 4322.168524] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>>> [ 4322.174118] spi-nor spi0.0: *****
>>>>> [ 4322.177439] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>>> [ 4322.182948] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>>> [ 4439.966060] spi-nor spi0.0: ***** nor->reg_proto = 0x00010101
>>>>> [ 4439.971920] spi-nor spi0.0: *****
>>>>> [ 4439.975252] spi-nor spi0.0: ***** op.cmd.nbytes = 0x01
>>>>> [ 4439.980511] spi-nor spi0.0: ***** op.cmd.buswidth = 0x01
>>>>> [ 4439.985928] spi-nor spi0.0: ***** op.cmd.opcode = 0xc4
>>>>> [ 4439.991174] spi-nor spi0.0: *****
>>>>> [ 4439.994504] spi-nor spi0.0: ***** op.addr.nbytes = 0x04
>>>>> [ 4439.999834] spi-nor spi0.0: ***** op.addr.buswidth = 0x01
>>>>> [ 4440.005335] spi-nor spi0.0: ***** op.addr.buswidth = 0x4000000
>>>>> [ 4440.011272] spi-nor spi0.0: *****
>>>>> [ 4440.014604] spi-nor spi0.0: ***** op.dummy.nbytes = 0x00
>>>>> [ 4440.020018] spi-nor spi0.0: ***** op.dummy.buswidth = 0x00
>>>>> [ 4440.025606] spi-nor spi0.0: *****
>>>>> [ 4440.028937] spi-nor spi0.0: ***** op.data.buswidth = 0x00
>>>>> [ 4440.034438] spi-nor spi0.0: ***** op.data.nbytes = 0
>>>>> Erased 134217728 bytes from address 0x00000000 in flash
>>>>>
>>>>> real 3m57.384s
>>>>> user 0m0.005s
>>>>> sys 3m35.211s
>>>>>
>>>>
>>>> Yep, it's strange, we'll have to check what's happening. I found my
>>>> n25q00 flash, on my side all its 4 dice are erased in 5 sec. SFDP
>>>> defines how long the erase die should take, see BFPT dword 11. You can
>>>> start with that.
>>>
>>> Had the flash some contents or was it all-ff? Maybe the Micron flash
>>> will
>>> check if all bytes are one and will skip the erase.
>>
>> it had some contents, but not different than 0xff
>>>
>>> Die/Chip erases will take much longer most of the time and are
>>> comparable
>>> to individual sector erases (as Fabio also found out). You'll probably
>>> just save the overhead of the indivudal commands.
>>
>> There is a speed benefit in using die erase instead of individual sector
>> erases.
>>>
>>> I've looked at the N25Q00AA datasheet and the erase time there is 153s
>>> (typ) for *one* die.
>>>
>>
>> you mean mt25q. Table 49 in
>> https://www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_01g_bbb_0.pdf
>>
>>
>> Each die has 64MB. A die is composed of either 16384 4KB sectors or 2048
>> sectors of 32KB.
>>
>> 4KB typical erase time is 0.05s, thus a die will be erased in 819.2s.
>> 32KB typical erase time is 0.1s, thus a die will be erased in 204.8s.
>> die erase typical erase time is 153s.
>>
>> 4K max erase time is 0.4s, thus a die will be erased in 6553.6s
>> 32KB max erase time is 1, thus a die will be erased in 2048s.
>> die erase max time is 460s.
>>
>> so you might say that 32KB typical erase time might be comparable to a
>> die erase command when erasing an entire die with 32KB erases, but even
>> so, it should be preferable to use die erase cmd. Instead of sending a
>> write enable followed by a sector erase command for each sector, you
>> could instead use a single write enable followed by a single die erase
>> command.
>
> I was just implying that your 5s chip erase time sounded unlikely.
>
> I'm also still undecided on the use of a chip/die erase command. How
> often is a flash erased entirely? I don't think very often, maybe during
> board manufacturing. And is that worth the (maintenance) efforts?
>
> Anyway, I won't stand in the way if you insist.
I don't insist, but I feel it is worth it, yes. We have some speed
improvement and we should benefit of it.
>
> Nobody commented on that so far: The jedec spec doesn't say anything
> about the chip/die erase command, right? There is a flag which
> indicates wether the chip has one (in 8d8d8d mode) and there is a field
> for its erase time, but not *what* the actual command is. Such a pity,
jesd216 mentions die erase, but does not provide an opcode for it. Check
BFPT dword 11, bits 30:24, "Chip Erase, Typical time", it says:
"Typical time to erase one chip (die). User must poll device busy to
determine if the operation has completed. For a device consisting of
multiple dies, that are individually accessed, the time is for each die
to which a chip erase command is applied."
So when a flash consists of a single die, this is the erase time for the
full chip (die) erase, and when it consists of multiple dies, it's the
die erase time. Chip and die are the same thing.
> esp. because the die erase now differs among vendors.. whereas the chip
> erase command seems to be common among vendors.
Indeed we saw that the die erase opcode differs among vendors, nothing
that we can do about it now. But we can handle it in software, no big deal.
>
> Btw. if we want to speed the erase up we should make use of the erase
> regions. AFAIK, at the moment we do (slow) 4k erases most of the time
> because distros have this kernel option enabled.
>
yes, I know, there were some attempts and the main concern was how it
will cope with what filesystems are requiring. Anyway, different topic
that needs some thought.
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 82+ messages in thread
end of thread, other threads:[~2023-11-15 7:06 UTC | newest]
Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-01 14:58 [PATCH v2 0/6] mtd: spi-nor: introduce die erase Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 1/6] mtd: spi-nor: use kernel sized types instead of c99 types Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 2/6] mtd: spi-nor: add erase die (chip) capability Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 16:04 ` Tudor Ambarus
2023-11-01 16:04 ` Tudor Ambarus
2023-11-01 16:17 ` Fabio Estevam
2023-11-01 16:17 ` Fabio Estevam
2023-11-01 17:27 ` Tudor Ambarus
2023-11-01 17:27 ` Tudor Ambarus
2023-11-02 16:43 ` Fabio Estevam
2023-11-02 16:43 ` Fabio Estevam
2023-11-02 17:36 ` Tudor Ambarus
2023-11-02 17:36 ` Tudor Ambarus
2023-11-02 17:40 ` Fabio Estevam
2023-11-02 17:40 ` Fabio Estevam
2023-11-02 17:47 ` Tudor Ambarus
2023-11-02 17:47 ` Tudor Ambarus
2023-11-02 17:54 ` Tudor Ambarus
2023-11-02 17:54 ` Tudor Ambarus
2023-11-02 17:59 ` Tudor Ambarus
2023-11-02 17:59 ` Tudor Ambarus
2023-11-02 18:01 ` Fabio Estevam
2023-11-02 18:01 ` Fabio Estevam
2023-11-02 18:21 ` Tudor Ambarus
2023-11-02 18:21 ` Tudor Ambarus
2023-11-02 18:33 ` Fabio Estevam
2023-11-02 18:33 ` Fabio Estevam
2023-11-02 18:46 ` Tudor Ambarus
2023-11-02 18:46 ` Tudor Ambarus
2023-11-02 18:56 ` Tudor Ambarus
2023-11-02 18:56 ` Tudor Ambarus
2023-11-02 21:42 ` Fabio Estevam
2023-11-02 21:42 ` Fabio Estevam
2023-11-03 11:47 ` Tudor Ambarus
2023-11-03 11:47 ` Tudor Ambarus
2023-11-03 12:30 ` Fabio Estevam
2023-11-03 12:30 ` Fabio Estevam
2023-11-03 12:53 ` Fabio Estevam
2023-11-03 12:53 ` Fabio Estevam
2023-11-03 13:26 ` Tudor Ambarus
2023-11-03 13:26 ` Tudor Ambarus
2023-11-03 13:37 ` Fabio Estevam
2023-11-03 13:37 ` Fabio Estevam
2023-11-03 13:48 ` Tudor Ambarus
2023-11-03 13:48 ` Tudor Ambarus
2023-11-03 14:16 ` Fabio Estevam
2023-11-03 14:16 ` Fabio Estevam
2023-11-03 14:37 ` Tudor Ambarus
2023-11-03 14:37 ` Tudor Ambarus
2023-11-03 14:58 ` Fabio Estevam
2023-11-03 14:58 ` Fabio Estevam
2023-11-06 14:24 ` Tudor Ambarus
2023-11-06 14:24 ` Tudor Ambarus
2023-11-06 9:34 ` Michael Walle
2023-11-06 9:34 ` Michael Walle
2023-11-06 14:23 ` Tudor Ambarus
2023-11-06 14:23 ` Tudor Ambarus
2023-11-06 14:56 ` Tudor Ambarus
2023-11-06 14:56 ` Tudor Ambarus
2023-11-09 9:09 ` Michael Walle
2023-11-09 9:09 ` Michael Walle
2023-11-15 7:06 ` Tudor Ambarus
2023-11-15 7:06 ` Tudor Ambarus
2023-11-08 8:06 ` Takahiro Kuwano
2023-11-08 8:06 ` Takahiro Kuwano
2023-11-08 8:54 ` Tudor Ambarus
2023-11-08 8:54 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 3/6] mtd: spi-nor: spansion: enable die erase for multi die flashes Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 4/6] mtd: spi-nor: micron-st: " Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 5/6] mtd: spi-nor: remove NO_CHIP_ERASE flag Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 14:58 ` [PATCH v2 6/6] mtd: spi-nor: micron-st: Add support for mt25qu01g Tudor Ambarus
2023-11-01 14:58 ` Tudor Ambarus
2023-11-01 15:54 ` [PATCH v2 0/6] mtd: spi-nor: introduce die erase Fabio Estevam
2023-11-01 15:54 ` Fabio Estevam
2023-11-15 6:10 ` Re (subset): " Tudor Ambarus
2023-11-15 6:10 ` Tudor Ambarus
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.