* [PATCH v1 0/2] Add octal DTR support for Macronix flash
@ 2023-07-25 2:23 Jaime Liao
2023-07-25 2:23 ` [PATCH v1 1/2] mtd: spi-nor: add Octal " Jaime Liao
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Jaime Liao @ 2023-07-25 2:23 UTC (permalink / raw)
To: linux-mtd, tudor.ambarus, pratyush, michael, miquel.raynal
Cc: leoyu, JaimeLiao
From: JaimeLiao <jaimeliao.tw@gmail.com>
This series add method for Macronix Octal DTR Eable/Disable
and add Macronix Octal flash support.
JaimeLiao (2):
mtd: spi-nor: add Octal DTR support for Macronix flash
mtd: spi-nor: add support for Macronix Octal flash
drivers/mtd/spi-nor/macronix.c | 104 +++++++++++++++++++++++++++++++++
1 file changed, 104 insertions(+)
--
2.25.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH v1 1/2] mtd: spi-nor: add Octal DTR support for Macronix flash 2023-07-25 2:23 [PATCH v1 0/2] Add octal DTR support for Macronix flash Jaime Liao @ 2023-07-25 2:23 ` Jaime Liao 2023-07-25 7:16 ` Michael Walle 2023-07-25 2:23 ` [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash Jaime Liao 2023-07-25 8:01 ` [PATCH v1 0/2] Add octal DTR support for Macronix flash Tudor Ambarus 2 siblings, 1 reply; 16+ messages in thread From: Jaime Liao @ 2023-07-25 2:23 UTC (permalink / raw) To: linux-mtd, tudor.ambarus, pratyush, michael, miquel.raynal Cc: leoyu, JaimeLiao From: JaimeLiao <jaimeliao.tw@gmail.com> Enable Octal DTR mode with 20 dummy cycles to allow running at the maximum supported frequency for adding Macronix flash in Octal DTR mode. Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> Co-authored-by: Tudor Ambarus <tudor.ambarus@linaro.org> --- drivers/mtd/spi-nor/macronix.c | 77 ++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c index 04888258e891..9010b81e098f 100644 --- a/drivers/mtd/spi-nor/macronix.c +++ b/drivers/mtd/spi-nor/macronix.c @@ -8,6 +8,12 @@ #include "core.h" +#define SPINOR_OP_RD_CR2 0x71 /* Read configuration register 2 */ +#define SPINOR_OP_WR_CR2 0x72 /* Write configuration register 2 */ +#define SPINOR_REG_MXIC_CR2_MODE 0x00000000 /* For setting octal DTR mode */ +#define SPINOR_REG_MXIC_OPI_DTR_EN 0x2 /* Enable Octal DTR */ +#define SPINOR_REG_MXIC_SPI_EN 0x0 /* Enable SPI */ + static int mx25l25635_post_bfpt_fixups(struct spi_nor *nor, const struct sfdp_parameter_header *bfpt_header, @@ -32,6 +38,76 @@ static const struct spi_nor_fixups mx25l25635_fixups = { .post_bfpt = mx25l25635_post_bfpt_fixups, }; +/** + * spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix flashes. + * @nor: pointer to a 'struct spi_nor' + * @enable: whether to enable Octal DTR or switch back to SPI + * + * Return: 0 on success, -errno otherwise. + */ +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor, bool enable) +{ + struct spi_mem_op op; + u8 *buf = nor->bouncebuf, i; + int ret; + + /* Set/unset the octal and DTR enable bits. */ + ret = spi_nor_write_enable(nor); + if (ret) + return ret; + + if (enable) { + buf[0] = SPINOR_REG_MXIC_OPI_DTR_EN; + } else { + /* + * The register is 1-byte wide, but 1-byte transactions are not + * allowed in 8D-8D-8D mode. Since there is no register at the + * next location, just initialize the value to 0 and let the + * transaction go on. + */ + buf[0] = SPINOR_REG_MXIC_SPI_EN; + buf[1] = 0x0; + } + + op = (struct spi_mem_op) + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1), + SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1), + SPI_MEM_OP_NO_DUMMY, + SPI_MEM_OP_DATA_OUT(enable ? 1 : 2, buf, 1)); + + if (!enable) + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); + + ret = spi_mem_exec_op(nor->spimem, &op); + if (ret) + return ret; + + /* Read flash ID to make sure the switch was successful. */ + op = (struct spi_mem_op) + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1), + SPI_MEM_OP_ADDR(enable ? 4 : 0, 0, 1), + SPI_MEM_OP_DUMMY(enable ? 4 : 0, 1), + SPI_MEM_OP_DATA_IN(SPI_NOR_MAX_ID_LEN, buf, 1)); + + if (enable) + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); + + ret = spi_mem_exec_op(nor->spimem, &op); + if (ret) + return ret; + + if (enable) { + for (i = 0; i < nor->info->id_len; i++) + if (buf[i * 2] != nor->info->id[i]) + return -EINVAL; + } else { + if (memcmp(buf, nor->info->id, nor->info->id_len)) + return -EINVAL; + } + + return 0; +} + static const struct flash_info macronix_nor_parts[] = { /* Macronix */ { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1) @@ -108,6 +184,7 @@ static const struct flash_info macronix_nor_parts[] = { static void macronix_nor_default_init(struct spi_nor *nor) { nor->params->quad_enable = spi_nor_sr1_bit6_quad_enable; + nor->params->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable; } static void macronix_nor_late_init(struct spi_nor *nor) -- 2.25.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] mtd: spi-nor: add Octal DTR support for Macronix flash 2023-07-25 2:23 ` [PATCH v1 1/2] mtd: spi-nor: add Octal " Jaime Liao @ 2023-07-25 7:16 ` Michael Walle 2023-07-25 9:05 ` liao jaime 0 siblings, 1 reply; 16+ messages in thread From: Michael Walle @ 2023-07-25 7:16 UTC (permalink / raw) To: Jaime Liao Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu, JaimeLiao Hi, > From: JaimeLiao <jaimeliao.tw@gmail.com> You write "We" in your next patch. "We" as in macronix? Then please use your macronix email address for the patches. Please note, you can still send them through your gmail account. > Enable Octal DTR mode with 20 dummy cycles to allow running > at the maximum supported frequency for adding Macronix flash > in Octal DTR mode. Please explain a bit more what you are doing here. The patch itself looks dodgy. You are writing CR2 but maybe thats used for register accesses?! I also can't really tell from the macro names. > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > Co-authored-by: Tudor Ambarus <tudor.ambarus@linaro.org> There seems to be no written process documentation wether this has to be followed by a SoB (unlike Co-developed-by). Dunno. > --- > drivers/mtd/spi-nor/macronix.c | 77 ++++++++++++++++++++++++++++++++++ > 1 file changed, 77 insertions(+) > > diff --git a/drivers/mtd/spi-nor/macronix.c > b/drivers/mtd/spi-nor/macronix.c > index 04888258e891..9010b81e098f 100644 > --- a/drivers/mtd/spi-nor/macronix.c > +++ b/drivers/mtd/spi-nor/macronix.c > @@ -8,6 +8,12 @@ > > #include "core.h" > > +#define SPINOR_OP_RD_CR2 0x71 /* Read configuration register 2 */ > +#define SPINOR_OP_WR_CR2 0x72 /* Write configuration register 2 */ Copied from spansion.c? Why isn't there an _MXIC_ in the name? > +#define SPINOR_REG_MXIC_CR2_MODE 0x00000000 /* For setting octal DTR > mode */ > +#define SPINOR_REG_MXIC_OPI_DTR_EN 0x2 /* Enable Octal DTR */ > +#define SPINOR_REG_MXIC_SPI_EN 0x0 /* Enable SPI */ The names don't make much sense to me. Are you accessing individual registers? If so please use MXIC_REG_<regname> and MXIC_REG_<regname>_<bit/mode/mask/..> > + > static int > mx25l25635_post_bfpt_fixups(struct spi_nor *nor, > const struct sfdp_parameter_header *bfpt_header, > @@ -32,6 +38,76 @@ static const struct spi_nor_fixups mx25l25635_fixups > = { > .post_bfpt = mx25l25635_post_bfpt_fixups, > }; > > +/** > + * spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix > flashes. > + * @nor: pointer to a 'struct spi_nor' > + * @enable: whether to enable Octal DTR or switch back to SPI > + * > + * Return: 0 on success, -errno otherwise. > + */ > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor, bool > enable) > +{ > + struct spi_mem_op op; > + u8 *buf = nor->bouncebuf, i; > + int ret; > + > + /* Set/unset the octal and DTR enable bits. */ > + ret = spi_nor_write_enable(nor); > + if (ret) > + return ret; > + > + if (enable) { > + buf[0] = SPINOR_REG_MXIC_OPI_DTR_EN; > + } else { > + /* > + * The register is 1-byte wide, but 1-byte transactions are not > + * allowed in 8D-8D-8D mode. Since there is no register at the > + * next location, just initialize the value to 0 and let the > + * transaction go on. > + */ > + buf[0] = SPINOR_REG_MXIC_SPI_EN; > + buf[1] = 0x0; > + } > + > + op = (struct spi_mem_op) > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1), > + SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1), > + SPI_MEM_OP_NO_DUMMY, > + SPI_MEM_OP_DATA_OUT(enable ? 1 : 2, buf, 1)); > + > + if (!enable) > + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > + > + ret = spi_mem_exec_op(nor->spimem, &op); > + if (ret) > + return ret; > + > + /* Read flash ID to make sure the switch was successful. */ While cleaning up the flash_info db I come around this and it is copied all over the place. Please work on factoring this (also the other code in micron-st.c and spansion.c) out into a helper. > + op = (struct spi_mem_op) > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1), > + SPI_MEM_OP_ADDR(enable ? 4 : 0, 0, 1), > + SPI_MEM_OP_DUMMY(enable ? 4 : 0, 1), > + SPI_MEM_OP_DATA_IN(SPI_NOR_MAX_ID_LEN, buf, 1)); > + > + if (enable) > + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > + > + ret = spi_mem_exec_op(nor->spimem, &op); > + if (ret) > + return ret; > + > + if (enable) { > + for (i = 0; i < nor->info->id_len; i++) > + if (buf[i * 2] != nor->info->id[i]) > + return -EINVAL; Why is the ID now swapped? Doesn't look right. -michael > + } else { > + if (memcmp(buf, nor->info->id, nor->info->id_len)) > + return -EINVAL; > + } > + > + return 0; > +} > + > static const struct flash_info macronix_nor_parts[] = { > /* Macronix */ > { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1) > @@ -108,6 +184,7 @@ static const struct flash_info macronix_nor_parts[] > = { > static void macronix_nor_default_init(struct spi_nor *nor) > { > nor->params->quad_enable = spi_nor_sr1_bit6_quad_enable; > + nor->params->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable; > } > > static void macronix_nor_late_init(struct spi_nor *nor) ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] mtd: spi-nor: add Octal DTR support for Macronix flash 2023-07-25 7:16 ` Michael Walle @ 2023-07-25 9:05 ` liao jaime 2023-07-25 9:28 ` Michael Walle 0 siblings, 1 reply; 16+ messages in thread From: liao jaime @ 2023-07-25 9:05 UTC (permalink / raw) To: Michael Walle; +Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu Hi Michael > > Hi, > > > From: JaimeLiao <jaimeliao.tw@gmail.com> > > You write "We" in your next patch. "We" as in macronix? Then please > use your macronix email address for the patches. Please note, you > can still send them through your gmail account. Yes I am Macronix engineer and sorry for the company mail issue so that I can't send and reply patch on Macronix mail. > > > Enable Octal DTR mode with 20 dummy cycles to allow running > > at the maximum supported frequency for adding Macronix flash > > in Octal DTR mode. > > Please explain a bit more what you are doing here. The patch itself > looks dodgy. You are writing CR2 but maybe thats used for register > accesses?! I also can't really tell from the macro names. Ok I will correct it to _MXIC_ next version of patch. > > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > Co-authored-by: Tudor Ambarus <tudor.ambarus@linaro.org> > > There seems to be no written process documentation wether this has > to be followed by a SoB (unlike Co-developed-by). Dunno. Maybe it is not "Co-authored-by", it will be correct next version. > > > --- > > drivers/mtd/spi-nor/macronix.c | 77 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 77 insertions(+) > > > > diff --git a/drivers/mtd/spi-nor/macronix.c > > b/drivers/mtd/spi-nor/macronix.c > > index 04888258e891..9010b81e098f 100644 > > --- a/drivers/mtd/spi-nor/macronix.c > > +++ b/drivers/mtd/spi-nor/macronix.c > > @@ -8,6 +8,12 @@ > > > > #include "core.h" > > > > +#define SPINOR_OP_RD_CR2 0x71 /* Read configuration register 2 */ > > +#define SPINOR_OP_WR_CR2 0x72 /* Write configuration register 2 */ > > Copied from spansion.c? Why isn't there an _MXIC_ in the name? It will be correct next version. > > > +#define SPINOR_REG_MXIC_CR2_MODE 0x00000000 /* For setting octal DTR > > mode */ > > +#define SPINOR_REG_MXIC_OPI_DTR_EN 0x2 /* Enable Octal DTR */ > > +#define SPINOR_REG_MXIC_SPI_EN 0x0 /* Enable SPI */ > > The names don't make much sense to me. Are you accessing individual > registers? If so please use MXIC_REG_<regname> and > MXIC_REG_<regname>_<bit/mode/mask/..> > > > + > > static int > > mx25l25635_post_bfpt_fixups(struct spi_nor *nor, > > const struct sfdp_parameter_header *bfpt_header, > > @@ -32,6 +38,76 @@ static const struct spi_nor_fixups mx25l25635_fixups > > = { > > .post_bfpt = mx25l25635_post_bfpt_fixups, > > }; > > > > +/** > > + * spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix > > flashes. > > + * @nor: pointer to a 'struct spi_nor' > > + * @enable: whether to enable Octal DTR or switch back to SPI > > + * > > + * Return: 0 on success, -errno otherwise. > > + */ > > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor, bool > > enable) > > +{ > > + struct spi_mem_op op; > > + u8 *buf = nor->bouncebuf, i; > > + int ret; > > + > > + /* Set/unset the octal and DTR enable bits. */ > > + ret = spi_nor_write_enable(nor); > > + if (ret) > > + return ret; > > + > > + if (enable) { > > + buf[0] = SPINOR_REG_MXIC_OPI_DTR_EN; > > + } else { > > + /* > > + * The register is 1-byte wide, but 1-byte transactions are not > > + * allowed in 8D-8D-8D mode. Since there is no register at the > > + * next location, just initialize the value to 0 and let the > > + * transaction go on. > > + */ > > + buf[0] = SPINOR_REG_MXIC_SPI_EN; > > + buf[1] = 0x0; > > + } > > + > > + op = (struct spi_mem_op) > > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1), > > + SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1), > > + SPI_MEM_OP_NO_DUMMY, > > + SPI_MEM_OP_DATA_OUT(enable ? 1 : 2, buf, 1)); > > + > > + if (!enable) > > + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > > + > > + ret = spi_mem_exec_op(nor->spimem, &op); > > + if (ret) > > + return ret; > > + > > + /* Read flash ID to make sure the switch was successful. */ > > While cleaning up the flash_info db I come around this and it is > copied all over the place. Please work on factoring this (also the > other code in micron-st.c and spansion.c) out into a helper. Let me clearify the data order for read ID on Macronix flashes. Read ID SPI mode : c2-84-3c-c2-84-3c OPI DTR mode : c2-c2-84-84-3c-3c So that I create a specify judement for checking ID via 8D-8D-8D on Macronix flash. > > > + op = (struct spi_mem_op) > > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1), > > + SPI_MEM_OP_ADDR(enable ? 4 : 0, 0, 1), > > + SPI_MEM_OP_DUMMY(enable ? 4 : 0, 1), > > + SPI_MEM_OP_DATA_IN(SPI_NOR_MAX_ID_LEN, buf, 1)); > > + > > + if (enable) > > + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > > + > > + ret = spi_mem_exec_op(nor->spimem, &op); > > + if (ret) > > + return ret; > > + > > + if (enable) { > > + for (i = 0; i < nor->info->id_len; i++) > > + if (buf[i * 2] != nor->info->id[i]) > > + return -EINVAL; > > Why is the ID now swapped? Doesn't look right. Actullay 6 bytes data are c2-c2-84-84-3c-3c which are got by 8D-8D-8D read id on Macronix flash. > > -michael > > > + } else { > > + if (memcmp(buf, nor->info->id, nor->info->id_len)) > > + return -EINVAL; > > + } > > + > > + return 0; > > +} > > + > > static const struct flash_info macronix_nor_parts[] = { > > /* Macronix */ > > { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1) > > @@ -108,6 +184,7 @@ static const struct flash_info macronix_nor_parts[] > > = { > > static void macronix_nor_default_init(struct spi_nor *nor) > > { > > nor->params->quad_enable = spi_nor_sr1_bit6_quad_enable; > > + nor->params->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable; > > } > > > > static void macronix_nor_late_init(struct spi_nor *nor) Thanks your reply Jaime ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] mtd: spi-nor: add Octal DTR support for Macronix flash 2023-07-25 9:05 ` liao jaime @ 2023-07-25 9:28 ` Michael Walle 2023-07-25 9:49 ` liao jaime 0 siblings, 1 reply; 16+ messages in thread From: Michael Walle @ 2023-07-25 9:28 UTC (permalink / raw) To: liao jaime; +Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu Hi, >> You write "We" in your next patch. "We" as in macronix? Then please >> use your macronix email address for the patches. Please note, you >> can still send them through your gmail account. > Yes I am Macronix engineer and sorry for the company mail > issue so that I can't send and reply patch on Macronix mail. Thus I was saying that you should use the macronix mail for the patch author and the SoB and send your mails with your gmail account (git will take care of the difference). >> While cleaning up the flash_info db I come around this and it is >> copied all over the place. Please work on factoring this (also the >> other code in micron-st.c and spansion.c) out into a helper. > Let me clearify the data order for read ID on Macronix flashes. > Read ID > SPI mode : c2-84-3c-c2-84-3c > OPI DTR mode : c2-c2-84-84-3c-3c So you are basically duplicating the id bytes in DTR mode. The same byte is transferred both on the falling and rising edge of a clock cycle. I think this needs further changes to the core. I means that if the core will do a rdid in octal mode, it returns "garbage" for now. How is the data transferred in octal DTR mode? Reading the same data in SPI and octal DTR mode should return the exact same bytes. So one test would be to use the flash in SPI mode, write some data, enable octal DTR mode and read it back and compare it. They must match. > So that I create a specify judement for checking ID via 8D-8D-8D > on Macronix flash. No, please make it a common helper for all flashes. >> > + op = (struct spi_mem_op) >> > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1), >> > + SPI_MEM_OP_ADDR(enable ? 4 : 0, 0, 1), >> > + SPI_MEM_OP_DUMMY(enable ? 4 : 0, 1), >> > + SPI_MEM_OP_DATA_IN(SPI_NOR_MAX_ID_LEN, buf, 1)); >> > + >> > + if (enable) >> > + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); >> > + >> > + ret = spi_mem_exec_op(nor->spimem, &op); >> > + if (ret) >> > + return ret; >> > + >> > + if (enable) { >> > + for (i = 0; i < nor->info->id_len; i++) >> > + if (buf[i * 2] != nor->info->id[i]) >> > + return -EINVAL; >> >> Why is the ID now swapped? Doesn't look right. > Actullay 6 bytes data are c2-c2-84-84-3c-3c which are got by 8D-8D-8D > read id > on Macronix flash. See above. -michael ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 1/2] mtd: spi-nor: add Octal DTR support for Macronix flash 2023-07-25 9:28 ` Michael Walle @ 2023-07-25 9:49 ` liao jaime 0 siblings, 0 replies; 16+ messages in thread From: liao jaime @ 2023-07-25 9:49 UTC (permalink / raw) To: Michael Walle; +Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu Hi Michael > > Hi, > > >> You write "We" in your next patch. "We" as in macronix? Then please > >> use your macronix email address for the patches. Please note, you > >> can still send them through your gmail account. > > Yes I am Macronix engineer and sorry for the company mail > > issue so that I can't send and reply patch on Macronix mail. > > Thus I was saying that you should use the macronix mail for the > patch author and the SoB and send your mails with your gmail > account (git will take care of the difference). Got it, thanks. > > >> While cleaning up the flash_info db I come around this and it is > >> copied all over the place. Please work on factoring this (also the > >> other code in micron-st.c and spansion.c) out into a helper. > > Let me clearify the data order for read ID on Macronix flashes. > > Read ID > > SPI mode : c2-84-3c-c2-84-3c > > OPI DTR mode : c2-c2-84-84-3c-3c > > So you are basically duplicating the id bytes in DTR mode. The same > byte is transferred both on the falling and rising edge of a clock > cycle. I think this needs further changes to the core. I means that > if the core will do a rdid in octal mode, it returns "garbage" for > now. Do you mean a common function for ID comapre in core.c? > > How is the data transferred in octal DTR mode? Reading the same data > in SPI and octal DTR mode should return the exact same bytes. For all flashed in this patch, data reading are all same between SPI mode and octal DTR mode. > > So one test would be to use the flash in SPI mode, write some data, > enable octal DTR mode and read it back and compare it. They must > match. > > > So that I create a specify judement for checking ID via 8D-8D-8D > > on Macronix flash. > > No, please make it a common helper for all flashes. > > >> > + op = (struct spi_mem_op) > >> > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDID, 1), > >> > + SPI_MEM_OP_ADDR(enable ? 4 : 0, 0, 1), > >> > + SPI_MEM_OP_DUMMY(enable ? 4 : 0, 1), > >> > + SPI_MEM_OP_DATA_IN(SPI_NOR_MAX_ID_LEN, buf, 1)); > >> > + > >> > + if (enable) > >> > + spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); > >> > + > >> > + ret = spi_mem_exec_op(nor->spimem, &op); > >> > + if (ret) > >> > + return ret; > >> > + > >> > + if (enable) { > >> > + for (i = 0; i < nor->info->id_len; i++) > >> > + if (buf[i * 2] != nor->info->id[i]) > >> > + return -EINVAL; > >> > >> Why is the ID now swapped? Doesn't look right. > > Actullay 6 bytes data are c2-c2-84-84-3c-3c which are got by 8D-8D-8D > > read id > > on Macronix flash. > > See above. > > -michael Thank you Jaime ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash 2023-07-25 2:23 [PATCH v1 0/2] Add octal DTR support for Macronix flash Jaime Liao 2023-07-25 2:23 ` [PATCH v1 1/2] mtd: spi-nor: add Octal " Jaime Liao @ 2023-07-25 2:23 ` Jaime Liao 2023-07-25 7:40 ` Michael Walle 2023-07-25 8:01 ` [PATCH v1 0/2] Add octal DTR support for Macronix flash Tudor Ambarus 2 siblings, 1 reply; 16+ messages in thread From: Jaime Liao @ 2023-07-25 2:23 UTC (permalink / raw) To: linux-mtd, tudor.ambarus, pratyush, michael, miquel.raynal Cc: leoyu, JaimeLiao From: JaimeLiao <jaimeliao.tw@gmail.com> Adding Macronix Octal flash for Octal DTR support. The octaflash series can be divided into the following types: MX25 series : Serial NOR Flash. MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation. LW/UW series : Support simultaneous Read-while-Write operation in multiple bank architecture. Read-while-write feature which means read data one bank while another bank is programing or erasing. MX25LM : 3.0V Octal I/O -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf MX25UM : 1.8V Octal I/O -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf MX66LM : 3.0V Octal I/O with stacked die -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf MX66UM : 1.8V Octal I/O with stacked die -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf MX25LW : 3.0V Octal I/O with Read-while-Write MX25UW : 1.8V Octal I/O with Read-while-Write MX66LW : 3.0V Octal I/O with Read-while-Write and stack die MX66UW : 1.8V Octal I/O with Read-while-Write and stack die MX25UM51245G : 512Mb flash, with Word mode data output format when Octal DTR read MX25UM51345G : 512Mb flash, with Byte mode data output format when Octal DTR read Macronix Octal flash with two types, "byte mode" and "word mode". Because of word mode flash with byte swap issue when Octal DTR read, adding byte mode flash in this patchset only. About LW/UW series, please contact us freely if you have any questions. For adding Octal NOR Flash IDs, we have validated each Flash on plateform zynq-picozed. As below are the SFDP table dump. zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id c2943c zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer macronix zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname mx66uw2g345gx0 zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx66uw2g345gx0 zynq> hexdump mx66uw2g345gx0 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 0000030 0000 0000 0000 0000 ffff ffff ffff ffff 0000040 20e5 ff8a ffff 7fff ff00 ff00 ff00 ff00 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 0000060 ff00 ff00 7987 0001 1284 e200 04cc 4667 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 0000080 0000 0000 0000 237c 0048 0000 0000 8888 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 0000100 0000 0106 0000 0000 0002 0301 0200 0000 0000110 0000 0106 0000 0000 0000 0672 0200 0000 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 0000130 4514 8098 0643 001f dc21 ffff ffff ffff 0000140 ffff ffff ffff ffff ffff ffff ffff ffff zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id c2843c zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer macronix zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname mx66uw2g345g zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx66uw2g345g zynq> hexdump mx66uw2g345g 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 0000030 0000 0000 0000 0000 ffff ffff ffff ffff 0000040 20e5 ff8a ffff 7fff ff00 ff00 ff00 ff00 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 0000060 ff00 ff00 7987 0001 1284 e200 04cc 4667 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 0000080 0000 0000 0000 237c 0048 0000 0000 8888 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 0000100 0000 0106 0000 0000 0002 0301 0200 0000 0000110 0000 0106 0000 0000 0000 0672 0200 0000 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 0000130 4514 8098 0643 001f dc21 ffff ffff ffff 0000140 ffff ffff ffff ffff ffff ffff ffff ffff zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id c2843a zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer macronix zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname mx25uw51345g zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx25uw51345g zynq> hexdump mx25uw51345g 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 0000030 0000 0000 0000 0000 ffff ffff ffff ffff 0000040 20e5 ff8a ffff 1fff ff00 ff00 ff00 ff00 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 0000060 ff00 ff00 798b 0001 128f e200 04cc 4667 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 0000080 0000 0000 0000 237c 0048 0000 0000 8888 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 0000100 0000 0106 0000 0000 0002 0301 0200 0000 0000110 0000 0106 0000 0000 0000 0672 0200 0000 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 0000130 4514 8098 0643 000f dc21 ffff ffff ffff 0000140 ffff ffff ffff ffff ffff ffff ffff ffff zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id c28339 zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer macronix zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname mx25um25345g zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx25um25345g zynq> hexdump mx25um25345g 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 0000030 0000 0000 0000 0000 ffff ffff ffff ffff 0000040 20e5 ff8a ffff 0fff ff00 ff00 ff00 ff00 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 0000060 ff00 ff00 6987 0001 1282 d200 02cc 3867 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 0000080 0000 0000 0000 237c 0048 0000 0000 8888 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 0000100 0000 0106 0000 0000 0002 0301 0200 0000 0000110 0000 0106 0000 0000 0000 0672 0200 0000 0000120 ee00 69c0 7272 7171 d800 f6f7 0904 0000 0000130 4514 8098 0643 000f dc21 ffff ffff ffff 0000140 ffff ffff ffff ffff ffff ffff ffff ffff zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id c28439 zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer macronix zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname mx25uw25345g zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx25uw25345g zynq> hexdump mx25uw25345g 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 0000030 0000 0000 0000 0000 ffff ffff ffff ffff 0000040 20e5 ff8a ffff 0fff ff00 ff00 ff00 ff00 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 0000060 ff00 ff00 7987 0001 1284 d200 04cc 4667 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 0000080 0000 0000 0000 237c 0048 0000 0000 8888 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 0000100 0000 0106 0000 0000 0002 0301 0200 0000 0000110 0000 0106 0000 0000 0000 0672 0200 0000 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 0000130 4514 8098 0643 000f dc21 ffff ffff ffff 0000140 ffff ffff ffff ffff ffff ffff ffff ffff zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id c28438 zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer macronix zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname mx25uw12345g zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx25uw12345g zynq> hexdump mx25uw12345g 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 0000030 0000 0000 0000 0000 ffff ffff ffff ffff 0000040 20e5 ff8a ffff 07ff ff00 ff00 ff00 ff00 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 0000060 ff00 ff00 798b 0001 128f c900 04cc 4667 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 0000080 0000 0000 0000 237c 0048 0000 0000 8888 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 0000100 0000 0106 0000 0000 0002 0301 0200 0000 0000110 0000 0106 0000 0000 0000 0672 0200 0000 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 0000130 4514 8098 0643 000f dc21 ffff ffff ffff 0000140 ffff ffff ffff ffff ffff ffff ffff ffff zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id c28437 zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer macronix zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname mx25uw6345g zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx25uw6345g zynq> hexdump mx25uw6345g 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 0000030 0000 0000 0000 0000 ffff ffff ffff ffff 0000040 20e5 ff8a ffff 03ff ff00 ff00 ff00 ff00 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 0000060 ff00 ff00 798b 0001 128f c400 04cc 4667 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 0000080 0000 0000 0000 237c 0048 0000 0000 8888 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 0000100 0000 0106 0000 0000 0002 0301 0200 0000 0000110 0000 0106 0000 0000 0000 0672 0200 0000 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 0000130 4514 8098 0643 000f dc21 ffff ffff ffff 0000140 ffff ffff ffff ffff ffff ffff ffff ffff Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> --- drivers/mtd/spi-nor/macronix.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c index 9010b81e098f..657f320e414a 100644 --- a/drivers/mtd/spi-nor/macronix.c +++ b/drivers/mtd/spi-nor/macronix.c @@ -179,6 +179,33 @@ static const struct flash_info macronix_nor_parts[] = { { "mx66u2g45g", INFO(0xc2253c, 0, 64 * 1024, 4096) NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, + { "mx66uw2g345g", INFO(0xc2843c, 0, 64 * 1024, 4096) + FLAGS(SPI_NOR_RWW) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, + { "mx66uw2g345gx0", INFO(0xc2943c, 0, 64 * 1024, 4096) + FLAGS(SPI_NOR_RWW) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, + { "mx25uw51345g", INFO(0xc2843a, 0, 16 * 1024, 4096) + FLAGS(SPI_NOR_RWW) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, + { "mx25um25345g", INFO(0xc28339, 0, 8 * 1024, 4096) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, + { "mx25uw25345g", INFO(0xc28439, 0, 8 * 1024, 4096) + FLAGS(SPI_NOR_RWW) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, + { "mx25uw12345g", INFO(0xc28438, 0, 4 * 1024, 4096) + FLAGS(SPI_NOR_RWW) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, + { "mx25uw6345g", INFO(0xc28437, 0, 2 * 1024, 4096) + FLAGS(SPI_NOR_RWW) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_OCTAL_DTR_PP) + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, }; static void macronix_nor_default_init(struct spi_nor *nor) -- 2.25.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash 2023-07-25 2:23 ` [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash Jaime Liao @ 2023-07-25 7:40 ` Michael Walle 2023-07-25 9:21 ` liao jaime 0 siblings, 1 reply; 16+ messages in thread From: Michael Walle @ 2023-07-25 7:40 UTC (permalink / raw) To: Jaime Liao Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu, JaimeLiao Hi, > From: JaimeLiao <jaimeliao.tw@gmail.com> > > Adding Macronix Octal flash for Octal DTR support. > > The octaflash series can be divided into the following types: > > MX25 series : Serial NOR Flash. > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) > LM/UM series : Up to 250MHz clock frequency with both DTR/STR > operation. > LW/UW series : Support simultaneous Read-while-Write operation in > multiple > bank architecture. Read-while-write feature which means > read > data one bank while another bank is programing or > erasing. > > MX25LM : 3.0V Octal I/O > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf Link: tag at the end please. But dead. Redirected to "moved to a new home", maybe you should improve on stable links :) Esp. because you have the version in it. > MX25UM : 1.8V Octal I/O > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf dead. I've used https://www.mxic.com.tw/Lists/Datasheet/Attachments/8967/MX25UM51245G,%201.8V,%20512Mb,%20v1.5.pdf There "For SFDP register values detail, please contact local Macronix sales channel for Application Note.". Could you please send me (privately if you like) the AppNote for the SFDP table? > MX66LM : 3.0V Octal I/O with stacked die > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf dead > > MX66UM : 1.8V Octal I/O with stacked die > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf dead > > MX25LW : 3.0V Octal I/O with Read-while-Write > MX25UW : 1.8V Octal I/O with Read-while-Write > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die So the stack die information come from SFDP? Can RWW also be read from the SFDP tables? Do you have vendor SFDP tables where this information can come from? > > MX25UM51245G : 512Mb flash, with Word mode data output format when > Octal DTR read > MX25UM51345G : 512Mb flash, with Byte mode data output format when > Octal DTR read > > Macronix Octal flash with two types, "byte mode" and "word mode". > Because of word mode flash with byte swap issue when Octal DTR read, > adding byte mode flash in this patchset only. > > About LW/UW series, please contact us freely if you have any > questions. For adding Octal NOR Flash IDs, we have validated > each Flash on plateform zynq-picozed. Again "us" as in macronix? but then, there is no trace that this commit is comming from macronix. > As below are the SFDP table dump. Thanks! > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id > c2943c > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer > macronix > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname > mx66uw2g345gx0 > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx66uw2g345gx0 > zynq> hexdump mx66uw2g345gx0 > 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 > 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 > 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 > 0000030 0000 0000 0000 0000 ffff ffff ffff ffff > 0000040 20e5 ff8a ffff 7fff ff00 ff00 ff00 ff00 > 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 > 0000060 ff00 ff00 7987 0001 1284 e200 04cc 4667 > 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 > 0000080 0000 0000 0000 237c 0048 0000 0000 8888 > 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff > 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 > 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 > 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 > 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 > 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 > 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 > 0000100 0000 0106 0000 0000 0002 0301 0200 0000 > 0000110 0000 0106 0000 0000 0000 0672 0200 0000 > 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 > 0000130 4514 8098 0643 001f dc21 ffff ffff ffff > 0000140 ffff ffff ffff ffff ffff ffff ffff ffff md5sum is missing and please use either xxd or if not available, "hexdump -C". > --- a/drivers/mtd/spi-nor/macronix.c > +++ b/drivers/mtd/spi-nor/macronix.c > @@ -179,6 +179,33 @@ static const struct flash_info > macronix_nor_parts[] = { > { "mx66u2g45g", INFO(0xc2253c, 0, 64 * 1024, 4096) > NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) > FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, > + { "mx66uw2g345g", INFO(0xc2843c, 0, 64 * 1024, 4096) Please use INFO(0xc2843c, 0, 0, 0) > + FLAGS(SPI_NOR_RWW) Maybe one of your proprietary tables indicate RWW capabilites? > + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ > | SPI_NOR_OCTAL_DTR_PP) No NO_SFDP_FLAGS() for new parts. > + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, You should have a correct "4-Byte Address Instruction Table", therefore you don't need the FIXUPS_FLAGS. -michael ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash 2023-07-25 7:40 ` Michael Walle @ 2023-07-25 9:21 ` liao jaime 2023-07-25 9:39 ` Michael Walle 0 siblings, 1 reply; 16+ messages in thread From: liao jaime @ 2023-07-25 9:21 UTC (permalink / raw) To: Michael Walle; +Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu Hi Michael > > Hi, > > > From: JaimeLiao <jaimeliao.tw@gmail.com> > > > > Adding Macronix Octal flash for Octal DTR support. > > > > The octaflash series can be divided into the following types: > > > > MX25 series : Serial NOR Flash. > > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) > > LM/UM series : Up to 250MHz clock frequency with both DTR/STR > > operation. > > LW/UW series : Support simultaneous Read-while-Write operation in > > multiple > > bank architecture. Read-while-write feature which means > > read > > data one bank while another bank is programing or > > erasing. > > > > MX25LM : 3.0V Octal I/O > > > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > Link: tag at the end please. But dead. Redirected to "moved to a new > home", maybe you > should improve on stable links :) Esp. because you have the version in > it. Sorry, I will update links next version of patch. > > > MX25UM : 1.8V Octal I/O > > > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf > > dead. I've used > > https://www.mxic.com.tw/Lists/Datasheet/Attachments/8967/MX25UM51245G,%201.8V,%20512Mb,%20v1.5.pdf > > There "For SFDP register values detail, please contact local Macronix > sales > channel for Application Note.". Could you please send me (privately if > you > like) the AppNote for the SFDP table? Ok, I will contact with Macronix sales for this information and send to you privately if it is available. > > > MX66LM : 3.0V Octal I/O with stacked die > > > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf > > dead > > > > > MX66UM : 1.8V Octal I/O with stacked die > > > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf > > dead > > > > > MX25LW : 3.0V Octal I/O with Read-while-Write > > MX25UW : 1.8V Octal I/O with Read-while-Write > > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die > > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die > > So the stack die information come from SFDP? Can RWW also be read from > the SFDP tables? Do you have vendor SFDP tables where this information > can come from? For this introduction, it just introduce Macronix EPN naming rules. As I know, rww didn't include JESD216D. > > > > > MX25UM51245G : 512Mb flash, with Word mode data output format when > > Octal DTR read > > MX25UM51345G : 512Mb flash, with Byte mode data output format when > > Octal DTR read > > > > Macronix Octal flash with two types, "byte mode" and "word mode". > > Because of word mode flash with byte swap issue when Octal DTR read, > > adding byte mode flash in this patchset only. > > > > About LW/UW series, please contact us freely if you have any > > questions. For adding Octal NOR Flash IDs, we have validated > > each Flash on plateform zynq-picozed. > > Again "us" as in macronix? but then, there is no trace that this commit > is comming from macronix. It is relate to Macronix mail issue, so we prefer send patches on gmail. A question, how could I mention the commit is comming from Macronix if I still send patch from gmail? > > > As below are the SFDP table dump. > > Thanks! > > > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id > > c2943c > > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer > > macronix > > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname > > mx66uw2g345gx0 > > zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/sfdp > mx66uw2g345gx0 > > zynq> hexdump mx66uw2g345gx0 > > 0000000 4653 5044 0108 fd04 0700 1401 0040 ff00 > > 0000010 0187 1c01 0090 ff00 000a 0801 0100 ff00 > > 0000020 0005 0501 0120 ff00 0084 0201 0134 ff00 > > 0000030 0000 0000 0000 0000 ffff ffff ffff ffff > > 0000040 20e5 ff8a ffff 7fff ff00 ff00 ff00 ff00 > > 0000050 ffee ffff ffff ff00 ffff ff00 200c d810 > > 0000060 ff00 ff00 7987 0001 1284 e200 04cc 4667 > > 0000070 b030 b030 bdf4 5cd5 0000 ff00 1010 2000 > > 0000080 0000 0000 0000 237c 0048 0000 0000 8888 > > 0000090 0000 0000 0000 4000 d10f f3ff d10f f3ff > > 00000a0 0500 9000 0500 b100 2b00 9500 2b00 9600 > > 00000b0 7172 b803 7172 b803 0000 0000 a390 8218 > > 00000c0 c000 9669 0000 0000 0000 0000 7172 9800 > > 00000d0 7172 b800 7172 9900 0000 0000 7172 9800 > > 00000e0 7172 f800 7172 9900 7172 f900 0000 0000 > > 00000f0 0000 0000 1501 d001 7172 d806 0000 5086 > > 0000100 0000 0106 0000 0000 0002 0301 0200 0000 > > 0000110 0000 0106 0000 0000 0000 0672 0200 0000 > > 0000120 ee00 69c0 7272 7171 d800 f6f7 0a00 0000 > > 0000130 4514 8098 0643 001f dc21 ffff ffff ffff > > 0000140 ffff ffff ffff ffff ffff ffff ffff ffff > > md5sum is missing and please use either xxd or if not > available, "hexdump -C". Ok, I will update content of SFDP dump with md5sum and using xxd command. > > > --- a/drivers/mtd/spi-nor/macronix.c > > +++ b/drivers/mtd/spi-nor/macronix.c > > @@ -179,6 +179,33 @@ static const struct flash_info > > macronix_nor_parts[] = { > > { "mx66u2g45g", INFO(0xc2253c, 0, 64 * 1024, 4096) > > NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) > > FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, > > + { "mx66uw2g345g", INFO(0xc2843c, 0, 64 * 1024, 4096) > > Please use INFO(0xc2843c, 0, 0, 0) Sorry I didn't get it. > > > + FLAGS(SPI_NOR_RWW) > > Maybe one of your proprietary tables indicate RWW capabilites? As I know, RWW could be got on datasheet only for now. So that follow the existing rule using FLAGS for it. > > > + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ > > | SPI_NOR_OCTAL_DTR_PP) > > No NO_SFDP_FLAGS() for new parts. > > > + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, > > You should have a correct "4-Byte Address Instruction Table", therefore > you don't need the FIXUPS_FLAGS. 4 bytes opcode flag could be get by parsing bfpt. But I think it would be great if ID table include it as well. Because of some flashes in market may not define SFDP table. > > -michael Thanks Jaime ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash 2023-07-25 9:21 ` liao jaime @ 2023-07-25 9:39 ` Michael Walle 2023-07-25 9:55 ` liao jaime 0 siblings, 1 reply; 16+ messages in thread From: Michael Walle @ 2023-07-25 9:39 UTC (permalink / raw) To: liao jaime; +Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu Hi, >> So the stack die information come from SFDP? Can RWW also be read from >> the SFDP tables? Do you have vendor SFDP tables where this information >> can come from? > For this introduction, it just introduce Macronix EPN naming rules. > As I know, rww didn't include JESD216D. Yes, but you might or might not have proprietary tables in the SFDP, which might inidicate wether that part has RWW or now. Thus I was asking for that document above. >> Again "us" as in macronix? but then, there is no trace that this >> commit >> is comming from macronix. > It is relate to Macronix mail issue, so we prefer send patches on > gmail. > A question, how could I mention the commit is comming from Macronix if > I still send patch from gmail? Yes see my former mail. >> md5sum is missing and please use either xxd or if not >> available, "hexdump -C". > Ok, I will update content of SFDP dump with md5sum and > using xxd command. Thanks! >> > --- a/drivers/mtd/spi-nor/macronix.c >> > +++ b/drivers/mtd/spi-nor/macronix.c >> > @@ -179,6 +179,33 @@ static const struct flash_info >> > macronix_nor_parts[] = { >> > { "mx66u2g45g", INFO(0xc2253c, 0, 64 * 1024, 4096) >> > NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) >> > FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, >> > + { "mx66uw2g345g", INFO(0xc2843c, 0, 64 * 1024, 4096) >> >> Please use INFO(0xc2843c, 0, 0, 0) > Sorry I didn't get it. That should come from the SFDP tables. >> > + FLAGS(SPI_NOR_RWW) >> >> Maybe one of your proprietary tables indicate RWW capabilites? > As I know, RWW could be got on datasheet only for now. > So that follow the existing rule using FLAGS for it. So you didn't test it? Then I'm inclined to say you should drop this flag from this patchset. >> > + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ >> > | SPI_NOR_OCTAL_DTR_PP) >> >> No NO_SFDP_FLAGS() for new parts. >> >> > + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, >> >> You should have a correct "4-Byte Address Instruction Table", >> therefore >> you don't need the FIXUPS_FLAGS. > 4 bytes opcode flag could be get by parsing bfpt. > But I think it would be great if ID table include it as well. > Because of some flashes in market may not define SFDP table. Which ones would that be? Are there any new flashes without SFDP tables? And even if, it should be added if there is an actual board using that flash without SFDP. I'm against just adding flags just because "there might be something out there". Ideally, there shouldn't be any entry at all. -michael ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash 2023-07-25 9:39 ` Michael Walle @ 2023-07-25 9:55 ` liao jaime 0 siblings, 0 replies; 16+ messages in thread From: liao jaime @ 2023-07-25 9:55 UTC (permalink / raw) To: Michael Walle; +Cc: linux-mtd, tudor.ambarus, pratyush, miquel.raynal, leoyu Hi Michael > > Hi, > > >> So the stack die information come from SFDP? Can RWW also be read from > >> the SFDP tables? Do you have vendor SFDP tables where this information > >> can come from? > > For this introduction, it just introduce Macronix EPN naming rules. > > As I know, rww didn't include JESD216D. > > Yes, but you might or might not have proprietary tables in the SFDP, > which > might inidicate wether that part has RWW or now. Thus I was asking for > that > document above. Sorry, I don't have proprietary tables in SFDP. For checking whether RWW feature support, I need to check in datasheet and EPN. > > >> Again "us" as in macronix? but then, there is no trace that this > >> commit > >> is comming from macronix. > > It is relate to Macronix mail issue, so we prefer send patches on > > gmail. > > A question, how could I mention the commit is comming from Macronix if > > I still send patch from gmail? > > Yes see my former mail. Thanks. > > >> md5sum is missing and please use either xxd or if not > >> available, "hexdump -C". > > Ok, I will update content of SFDP dump with md5sum and > > using xxd command. > > Thanks! > > >> > --- a/drivers/mtd/spi-nor/macronix.c > >> > +++ b/drivers/mtd/spi-nor/macronix.c > >> > @@ -179,6 +179,33 @@ static const struct flash_info > >> > macronix_nor_parts[] = { > >> > { "mx66u2g45g", INFO(0xc2253c, 0, 64 * 1024, 4096) > >> > NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) > >> > FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, > >> > + { "mx66uw2g345g", INFO(0xc2843c, 0, 64 * 1024, 4096) > >> > >> Please use INFO(0xc2843c, 0, 0, 0) > > Sorry I didn't get it. > > That should come from the SFDP tables. > > >> > + FLAGS(SPI_NOR_RWW) > >> > >> Maybe one of your proprietary tables indicate RWW capabilites? > > As I know, RWW could be got on datasheet only for now. > > So that follow the existing rule using FLAGS for it. > > So you didn't test it? Then I'm inclined to say you should > drop this flag from this patchset. > > >> > + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ > >> > | SPI_NOR_OCTAL_DTR_PP) > >> > >> No NO_SFDP_FLAGS() for new parts. > >> > >> > + FIXUP_FLAGS(SPI_NOR_4B_OPCODES) }, > >> > >> You should have a correct "4-Byte Address Instruction Table", > >> therefore > >> you don't need the FIXUPS_FLAGS. > > 4 bytes opcode flag could be get by parsing bfpt. > > But I think it would be great if ID table include it as well. > > Because of some flashes in market may not define SFDP table. > > Which ones would that be? Are there any new flashes without SFDP > tables? And even if, it should be added if there is an actual board > using that flash without SFDP. I'm against just adding flags just > because "there might be something out there". Ideally, there shouldn't > be any entry at all. Agree, I hope all features get from SFDP table and as I know new flash all support SFDP. But for RWW, I still need a flag for using. > > -michael Thanks Jaime ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 0/2] Add octal DTR support for Macronix flash 2023-07-25 2:23 [PATCH v1 0/2] Add octal DTR support for Macronix flash Jaime Liao 2023-07-25 2:23 ` [PATCH v1 1/2] mtd: spi-nor: add Octal " Jaime Liao 2023-07-25 2:23 ` [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash Jaime Liao @ 2023-07-25 8:01 ` Tudor Ambarus 2023-07-25 8:28 ` Michael Walle 2 siblings, 1 reply; 16+ messages in thread From: Tudor Ambarus @ 2023-07-25 8:01 UTC (permalink / raw) To: Jaime Liao, linux-mtd, pratyush, michael, miquel.raynal; +Cc: leoyu On 7/25/23 03:23, Jaime Liao wrote: > From: JaimeLiao <jaimeliao.tw@gmail.com> > > This series add method for Macronix Octal DTR Eable/Disable > and add Macronix Octal flash support. Do all these flashes swap the bytes in octal DTR mode? If yes, you should add the infrastructure so that controllers can swap the bytes back, otherwise you'll break bootloaders which work in 1-1-1 mode, and breaking the boot chain is unacceptable. Tudor ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 0/2] Add octal DTR support for Macronix flash 2023-07-25 8:01 ` [PATCH v1 0/2] Add octal DTR support for Macronix flash Tudor Ambarus @ 2023-07-25 8:28 ` Michael Walle 2023-07-25 8:47 ` Tudor Ambarus 0 siblings, 1 reply; 16+ messages in thread From: Michael Walle @ 2023-07-25 8:28 UTC (permalink / raw) To: Tudor Ambarus; +Cc: Jaime Liao, linux-mtd, pratyush, miquel.raynal, leoyu Am 2023-07-25 10:01, schrieb Tudor Ambarus: > On 7/25/23 03:23, Jaime Liao wrote: >> From: JaimeLiao <jaimeliao.tw@gmail.com> >> >> This series add method for Macronix Octal DTR Eable/Disable >> and add Macronix Octal flash support. > > Do all these flashes swap the bytes in octal DTR mode? If yes, > you should add the infrastructure so that controllers can swap > the bytes back, otherwise you'll break bootloaders which work > in 1-1-1 mode, and breaking the boot chain is unacceptable. It might also be the SPI controller. Was the zynq SPI controller used before with octal flashes? -michael ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 0/2] Add octal DTR support for Macronix flash 2023-07-25 8:28 ` Michael Walle @ 2023-07-25 8:47 ` Tudor Ambarus 2023-07-25 9:25 ` liao jaime 0 siblings, 1 reply; 16+ messages in thread From: Tudor Ambarus @ 2023-07-25 8:47 UTC (permalink / raw) To: Michael Walle; +Cc: Jaime Liao, linux-mtd, pratyush, miquel.raynal, leoyu On 7/25/23 09:28, Michael Walle wrote: > Am 2023-07-25 10:01, schrieb Tudor Ambarus: >> On 7/25/23 03:23, Jaime Liao wrote: >>> From: JaimeLiao <jaimeliao.tw@gmail.com> >>> >>> This series add method for Macronix Octal DTR Eable/Disable >>> and add Macronix Octal flash support. >> >> Do all these flashes swap the bytes in octal DTR mode? If yes, >> you should add the infrastructure so that controllers can swap >> the bytes back, otherwise you'll break bootloaders which work >> in 1-1-1 mode, and breaking the boot chain is unacceptable. > > It might also be the SPI controller. Was the zynq SPI controller > used before with octal flashes? > No, it's the macronix flashes that swap the bytes by default. At least the one which I've worked with few years ago. Some controllers can swap the bytes back, but they have to be informed from mtd. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 0/2] Add octal DTR support for Macronix flash 2023-07-25 8:47 ` Tudor Ambarus @ 2023-07-25 9:25 ` liao jaime 2023-07-25 10:50 ` Tudor Ambarus 0 siblings, 1 reply; 16+ messages in thread From: liao jaime @ 2023-07-25 9:25 UTC (permalink / raw) To: Tudor Ambarus; +Cc: Michael Walle, linux-mtd, pratyush, miquel.raynal, leoyu Hi Tudor > > > > On 7/25/23 09:28, Michael Walle wrote: > > Am 2023-07-25 10:01, schrieb Tudor Ambarus: > >> On 7/25/23 03:23, Jaime Liao wrote: > >>> From: JaimeLiao <jaimeliao.tw@gmail.com> > >>> > >>> This series add method for Macronix Octal DTR Eable/Disable > >>> and add Macronix Octal flash support. > >> > >> Do all these flashes swap the bytes in octal DTR mode? If yes, > >> you should add the infrastructure so that controllers can swap > >> the bytes back, otherwise you'll break bootloaders which work > >> in 1-1-1 mode, and breaking the boot chain is unacceptable. No, only parts of flashes. MX25UM51345G : flash without swap bytes in octal dtr mode MX25UM51245G : flash will swap bytes in octal dtr mode So that I hope flashes without swap the bytes can be support. And I will send new patch for mention flashes which swap the bytes in Octal DTR mode. > > > > It might also be the SPI controller. Was the zynq SPI controller > > used before with octal flashes? > > > > No, it's the macronix flashes that swap the bytes by default. At least > the one which I've worked with few years ago. Some controllers can > swap the bytes back, but they have to be informed from mtd. Yes, it should inform mtd. Thanks Jaime ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v1 0/2] Add octal DTR support for Macronix flash 2023-07-25 9:25 ` liao jaime @ 2023-07-25 10:50 ` Tudor Ambarus 0 siblings, 0 replies; 16+ messages in thread From: Tudor Ambarus @ 2023-07-25 10:50 UTC (permalink / raw) To: liao jaime; +Cc: Michael Walle, linux-mtd, pratyush, miquel.raynal, leoyu On 7/25/23 10:25, liao jaime wrote: > Hi Tudor > Hi, >> >> On 7/25/23 09:28, Michael Walle wrote: >>> Am 2023-07-25 10:01, schrieb Tudor Ambarus: >>>> On 7/25/23 03:23, Jaime Liao wrote: >>>>> From: JaimeLiao <jaimeliao.tw@gmail.com> >>>>> >>>>> This series add method for Macronix Octal DTR Eable/Disable >>>>> and add Macronix Octal flash support. >>>> >>>> Do all these flashes swap the bytes in octal DTR mode? If yes, >>>> you should add the infrastructure so that controllers can swap >>>> the bytes back, otherwise you'll break bootloaders which work >>>> in 1-1-1 mode, and breaking the boot chain is unacceptable. > No, only parts of flashes. > MX25UM51345G : flash without swap bytes in octal dtr mode > MX25UM51245G : flash will swap bytes in octal dtr mode > So that I hope flashes without swap the bytes can be support. Flashes that don't swap bytes by default are ok with the current support that exists in spimem. So please start with these first. > And I will send new patch for mention flashes which swap the bytes > in Octal DTR mode. The flashes that swap bytes by default won't be accepted until we figure out how to sync the configuration between the flash and the SPI controller. > >>> >>> It might also be the SPI controller. Was the zynq SPI controller >>> used before with octal flashes? >>> >> >> No, it's the macronix flashes that swap the bytes by default. At least >> the one which I've worked with few years ago. Some controllers can >> swap the bytes back, but they have to be informed from mtd. > Yes, it should inform mtd. > mtd shall inform the SPI controller and agree on the configuration. Maybe some bootloaders can use octal DTR and the swap is not needed at the controller level, as some bootloaders may handle swapped data. So it should be a configuration choice and a configuration agreement between mtd and spi. Cheers, ta ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-07-25 10:50 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-07-25 2:23 [PATCH v1 0/2] Add octal DTR support for Macronix flash Jaime Liao 2023-07-25 2:23 ` [PATCH v1 1/2] mtd: spi-nor: add Octal " Jaime Liao 2023-07-25 7:16 ` Michael Walle 2023-07-25 9:05 ` liao jaime 2023-07-25 9:28 ` Michael Walle 2023-07-25 9:49 ` liao jaime 2023-07-25 2:23 ` [PATCH v1 2/2] mtd: spi-nor: add support for Macronix Octal flash Jaime Liao 2023-07-25 7:40 ` Michael Walle 2023-07-25 9:21 ` liao jaime 2023-07-25 9:39 ` Michael Walle 2023-07-25 9:55 ` liao jaime 2023-07-25 8:01 ` [PATCH v1 0/2] Add octal DTR support for Macronix flash Tudor Ambarus 2023-07-25 8:28 ` Michael Walle 2023-07-25 8:47 ` Tudor Ambarus 2023-07-25 9:25 ` liao jaime 2023-07-25 10:50 ` Tudor Ambarus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox