Re: [PATCH v8 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash
Hi Jagan > > On Fri, Jul 15, 2022 at 2:47 PM liao jaime wrote: > > > > Hi Jagan > > > > > > On Mon, Jul 4, 2022 at 11:43 AM JaimeLiao wrote: > > > > > > > > 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. > > > > > > > > > > Can you resend this patch on top of u-boot-spi/master > > This patchset is created in the newest version of U-boot(2022.07-rc5). > > Yes. u-boot-spi/master has moved something further. please send only > this patch on top of it. Ok I will prepare for it. Should I re-send this patch for new version v9 or keep on v8? > > Jagan.
Re: [PATCH v8 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash
Hi Jagan > > On Mon, Jul 4, 2022 at 11:43 AM JaimeLiao wrote: > > > > 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. > > > > Can you resend this patch on top of u-boot-spi/master This patchset is created in the newest version of U-boot(2022.07-rc5). > > Jagan.
Re: [PATCH v8 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
Hi Jagan
>
> On Mon, Jul 4, 2022 at 11:42 AM JaimeLiao wrote:
> >
> > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> > 8D-8D-8D
> > in the begging of probe.
> >
> > Command extension type is not standardized across flash vendors in DTR mode.
> >
> > For suiting different vendor flash devices, adding a flag to seperate types
> > for
> > soft reset on boot.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/Kconfig| 7 +++
> > drivers/mtd/spi/spi-nor-core.c | 7 ++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > index f350c7e5dc..5bb1baa019 100644
> > --- a/drivers/mtd/spi/Kconfig
> > +++ b/drivers/mtd/spi/Kconfig
> > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> > can support a type of operation in a much more refined way compared
> > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> >
> > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
> > + bool "Command extension type is INVERT for Software Reset on boot"
> > + default n
> > + help
> > +Because of SFDP information can not be get before boot.
> > +So define command extension type is INVERT when Software Reset on
> > boot only.
> > +
> > config SPI_FLASH_SOFT_RESET
> > bool "Software Reset support for SPI NOR flashes"
> > help
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index 5d319e4c0f..50460feaf8 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3697,7 +3697,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> > enum spi_nor_cmd_ext ext;
> >
> > ext = nor->cmd_ext_type;
> > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
>
> Better check those parts whose extension is not standard instead of CONFIG.
spi_nor_soft_reset will be execute before read ID and read SFDP so
that I think we are hard
to get information from flash device.
>
> Jagan.
Thanks
Jaime
Re: [PATCH] mtd: spi-nor: Parse SFDP Command Sequence to change to Octal DDR(8D-8D-8D) mode
Hi Tudor > > On 3/15/22 10:45, liao jaime wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > Hi > > > >> Hi, > >> > >> On 3/10/22 08:59, JaimeLiao wrote: > >>> +static int spi_nor_generall_octal_dtr_enable(struct spi_nor *nor) > >> > >> Is there a disable method too? If not, can we deduce it? > > Because of difference with flash vendors, I think it is hard to deduce the > > method "spi_nor_generall_octal_dtr_disable". > >> > > I've quickly skimmed through the code it seems that once octal is enabled > and you reset the board, the flash remains in octal mode if it doesn't > have a dedicated hardware reset line and the octal bit is non volatile. > This is bad because there might be ROMs that don't know 8d-8d-8d mode and > you'll break the boot sequence for them. spi_nor_soft_reset will execute at spi_nor_scan and spi_nor_remove. After spi_nor_soft_reset, flash will back to 1-1-1 mode. I think we don't need disable method for backing 1-1-1 mode. Thanks Jaime
Re: [PATCH] mtd: spi-nor: Parse SFDP Command Sequence to change to Octal DDR(8D-8D-8D) mode
Hi > Hi, > > On 3/10/22 08:59, JaimeLiao wrote: > > +static int spi_nor_generall_octal_dtr_enable(struct spi_nor *nor) > > Is there a disable method too? If not, can we deduce it? Because of difference with flash vendors, I think it is hard to deduce the method "spi_nor_generall_octal_dtr_disable". > > Cheers, > ta Thanks Jaime
Re: [PATCH v6 3/4] mtd: spi-nor-core: Add support for Macronix Octal flash
Hi Pratyush
>
> On 03/01/22 10:47AM, tudor.amba...@microchip.com wrote:
> > On 12/29/21 7:56 AM, JaimeLiao wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > the content is safe
> > >
> > > 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
> > >
> > > 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.
> > >
> > > Signed-off-by: JaimeLiao
> > > ---
> > > drivers/mtd/spi/spi-nor-ids.c | 22 +-
> > > 1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > > index cb3a08872d..5c13ea3a78 100644
> > > --- a/drivers/mtd/spi/spi-nor-ids.c
> > > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = {
> > > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
> > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32,
> > > SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) },
> > > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) },
> > > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx66lm1g45g",0xc2853b, 0, 32 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx66um2g45g",0xc2803c, 0, 64 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx66um1g45g",0xc2803b, 0, 32 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx66uw1g45g",0xc2813b, 0, 32 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K |
> > > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > > + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K |
Re: [PATCH v6 1/4] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Tudor
>
> Hi,
>
> On 12/29/21 7:56 AM, JaimeLiao wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
> > Macronix flash in Octal DTR mode.
> >
> > Enable Octal DTR mode with 20 dummy cycles to allow running at the
> > maximum supported frequency.
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 83 ++
> > include/linux/mtd/spi-nor.h| 12 -
> > 2 files changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index d5d905fa5a..0a6550984b 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = {
> > };
> > #endif /* CONFIG_SPI_FLASH_MT35XU */
> >
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > +/**
> > + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> > Configuration Register 2.
> > + * @nor: pointer to a 'struct spi_nor'
> > + *
> > + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
> > + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like
> > OPI memories.
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
>
> This method should be called just for the flashes that do not define the
> JESD216 "Command Sequences to Change to Octal DDR (8D-8D-8D) mode" table.
> Or where SFDP is skipped intentionally.
I think Octal DTR enable method have been defined by manufacturers.
It would be better if the method could be parce from SFDP.
But I prefer to follow the existing rules for adding the flashes which
have been output but not be support in uboot.
>
> > +{
> > + struct spi_mem_op op;
> > + int ret;
> > + u8 buf;
> > +
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_DC_20;
> > + 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_DC, 1),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_DATA_OUT(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret)
> > + return ret;
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + nor->read_dummy = MXIC_MAX_DC;
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> > + 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(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret) {
> > + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> > + return ret;
> > + }
> > + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> > +
> > + return 0;
> > +}
> > +
> > +static void macronix_octal_default_init(struct spi_nor *nor)
>
> I think we should get rid of the default_init() hook, it messes how
> the params are initialized, there's a spaghetti right now, it's very hard to
> determine who initializes which params solely by reading the code. I would
> advise to follow linux and use a late_init() hook where explicit octal dtr
> enable method is required.
Sure it is a good idea.
I hope U-boot could have more similar architecture with Linux kernel.
>
>
> > +{
> > + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
> > +}
> > +
> > +static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor,
> > +struct spi_nor_flash_parameter
> > *params)
> > +{
> > + /*
> > +* Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
> > +* SPI_NOR_OCTAL_DTR_READ flag exists.
> > +*/
> > + if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
> > + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
>
> This confirms the spaghetti theory. This is not SFDP related, why do you use
> the post_sfdp hook?
Because of SPI_NOR_OCTAL_DTR_PP is not existing in U-boot.
I will take other suitable method to enable it next patch.
>
> > +}
> > +
> > +static struct spi_nor_fixups macronix_octal_fixups = {
> > + .default_init = macronix_octal_default_init,
> > + .post_sfdp = macronix_octal_post_sfdp_fixup,
> > +};
>
Re: [PATCH v6 1/4] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Miquel
>
> Hi Jaime,
>
> You made a typo on Jagan's address, you might need to resend.
Yes your are right, I have re-send the cover letter to Jagan.
>
> The title does not look correct, maybe you miss a word after Octal. And
> is it something Macronix specific? I believe this is generic and you
> can drop "Macronix" (the second occurrence) from the title.
Ok got it.
>
> jaimeliao...@gmail.com wrote on Wed, 29 Dec 2021 13:56:17 +0800:
>
> > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
>
> When pointing to an upstream commit I think even in U-Boot the style
> should be something like:
> <12-digit hash> ("title of the commit")
> which at least allows to know which commit we are talking about.
OK.
>
> > Macronix flash in Octal DTR mode.
>
> This first part of the commit log should be moved below.
>
> >
> > Enable Octal DTR mode with 20 dummy cycles to allow running at the
> > maximum supported frequency.
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 83 ++
> > include/linux/mtd/spi-nor.h| 12 -
> > 2 files changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index d5d905fa5a..0a6550984b 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = {
> > };
> > #endif /* CONFIG_SPI_FLASH_MT35XU */
> >
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > +/**
> > + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> > Configuration Register 2.
>
> This is very specific to Macronix I believe? Please just use a generic
> description here.
Yes I will modify this part next patch.
>
> > + * @nor: pointer to a 'struct spi_nor'
> > + *
> > + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
> > + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like
> > OPI memories.
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
> > +{
> > + struct spi_mem_op op;
> > + int ret;
> > + u8 buf;
> > +
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_DC_20;
> > + 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_DC, 1),
> > +SPI_MEM_OP_NO_DUMMY,
> > +SPI_MEM_OP_DATA_OUT(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret)
> > + return ret;
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + nor->read_dummy = MXIC_MAX_DC;
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> > + 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(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret) {
> > + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> > + return ret;
> > + }
> > + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> > +
> > + return 0;
> > +}
> > +
> > +static void macronix_octal_default_init(struct spi_nor *nor)
> > +{
> > + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
> > +}
> > +
> > +static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor,
> > + struct spi_nor_flash_parameter
> > *params)
> > +{
> > + /*
> > + * Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
> > + * SPI_NOR_OCTAL_DTR_READ flag exists.
> > + */
> > + if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
> > + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
> > +}
> > +
> > +static struct spi_nor_fixups macronix_octal_fixups = {
> > + .default_init = macronix_octal_default_init,
> > + .post_sfdp = macronix_octal_post_sfdp_fixup,
> > +};
> > +#endif /* CONFIG_SPI_FLASH_MACRONIX */
> > +
> > /** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
> > * @nor: pointer to a 'struct spi_nor'
> > *
> > @@ -3655,6 +3734,10 @@ void spi_nor_set_fixups(struct spi_nor *nor)
> > if (!strcmp(nor->info->name, "mt35xu512aba"))
> > nor->fixups = &mt35xu512aba_fixups;
> > #endif
> > +
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > + nor->fixups = ¯onix_octal_fixups;
> > +#endif /*
Re: [PATCH v5 3/3] mtd: spi-nor-core: Add support for Macronix Octal flash
Hi Tudor
>
> On 11/18/21 12:13 PM, JaimeLiao wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > 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
> >
> > 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.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-ids.c | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > index cb3a08872d..5c13ea3a78 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = {
> > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32,
> > SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) },
> > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) },
> > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66lm1g45g",0xc2853b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
>
> which one of all these flashes (including the ones from below) support
> SFDP and which not? Which can discover the octal dtr method by parsing
> SFDP and which not? Depending on these those flash_info flags may change.
I agree that we need a method for octal dtr support on flash which
didn't include SFDP
but the patch of method is separate with Octal DTR patch.
> Why do you need SPI_NOR_4B_OPCODES, can't this support be discovered
> when parsing SFDP? How about SECT_4K?
>
> I know for sure there are variants of mx66lm1g45g that do not support
> SFDP, and flavors that do support SFDP. How you'll differentiate between
> the two flavors of the same flash?
>
> I chose to SKIP SFDP parsing for mx66lm1g45g as there's no infrastructure
> to handle its case, neither in linux, nor u-boot.
> Here's what I proposed for now:
> https://lore.kernel.org/all/20211103234950.202289-3-tudor.amba...@microchip.com/
>
>
> Cheers,
> ta
>
> > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um2g45g",0xc2803c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um1g45g",0xc2803b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw1g45g",0xc2813b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51345g"
Re: [PATCH v5 1/3] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Tudor
>
> On 11/26/21 7:28 AM, liao jaime wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Hi Tudor
>
> Hi,
>
> >
> >>
> >> On 11/18/21 12:13 PM, JaimeLiao wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> >>> the content is safe
> >>>
> >>
> >> Hi, Jaime,
> >>
> >>> Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
> >>> Macronix flash in Octal DTR mode.
> >>>
> >>> Enable Octal DTR mode with 20 dummy cycles to allow running at the
> >>> maximum supported frequency.
> >>>
> >>> -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> >>>
> >>
> >> I have submitted a similar patch at
> >> https://lore.kernel.org/all/20211103162454.179191-2-tudor.amba...@microchip.com/T/#me9b6e48c33fd545a9c0b5a5136778651ea64171a
> >>
> >> but I think yours has precedence, you're already at v5.
> >>
> >>> Signed-off-by: JaimeLiao
> >>> ---
> >>> drivers/mtd/spi/spi-nor-core.c | 83 ++
> >>> include/linux/mtd/spi-nor.h| 12 -
> >>> 2 files changed, 93 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/mtd/spi/spi-nor-core.c
> >>> b/drivers/mtd/spi/spi-nor-core.c
> >>> index d5d905fa5a..0a6550984b 100644
> >>> --- a/drivers/mtd/spi/spi-nor-core.c
> >>> +++ b/drivers/mtd/spi/spi-nor-core.c
> >>> @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups =
> >>> {
> >>> };
> >>> #endif /* CONFIG_SPI_FLASH_MT35XU */
> >>>
> >>> +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> >>> +/**
> >>> + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> >>> Configuration Register 2.
> >>> + * @nor: pointer to a 'struct spi_nor'
> >>> + *
> >>> + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
> >>> + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like
> >>> OPI memories.
> >>> + *
> >>> + * Return: 0 on success, -errno otherwise.
> >>> + */
> >>> +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
> >>> +{
> >>> + struct spi_mem_op op;
> >>> + int ret;
> >>> + u8 buf;
> >>> +
> >>> + ret = write_enable(nor);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + buf = SPINOR_REG_MXIC_DC_20;
> >>> + 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_DC, 1),
> >>> + SPI_MEM_OP_NO_DUMMY,
> >>> + SPI_MEM_OP_DATA_OUT(1, &buf, 1));
> >>> +
> >>> + ret = spi_mem_exec_op(nor->spi, &op);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + ret = spi_nor_wait_till_ready(nor);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + nor->read_dummy = MXIC_MAX_DC;
> >>> + ret = write_enable(nor);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> >>> + 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(1, &buf, 1));
> >>> +
> >>> + ret = spi_mem_exec_op(nor->spi, &op);
> >>> + if (ret) {
> >>> + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> >>> + return ret;
> >>> + }
> >>> + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> &g
Re: [PATCH v5 2/3] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
Hi Tudor
>
> On 11/18/21 12:13 PM, JaimeLiao wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> > 8D-8D-8D
> > in the begging of probe.
> >
> > Command extension type is not standardized across flash vendors in DTR mode.
> >
> > For suiting different vendor flash devices, adding a flag to seperate types
> > for
> > soft reset on boot.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/Kconfig| 7 +++
> > drivers/mtd/spi/spi-nor-core.c | 7 ++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > index 1b2ef37e92..9b7d195770 100644
> > --- a/drivers/mtd/spi/Kconfig
> > +++ b/drivers/mtd/spi/Kconfig
> > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> > can support a type of operation in a much more refined way compared
> > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> >
> > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
>
> There will be many combinations of reset types and cmd_ext types, better to
> introduce
> a way to select the reset type and then to select the cmd_ext type so that we
> avoid
> introducing so many configs/dt props.
>
> I think Pratyush is working to fix this, would you sync with him?
Sure, this configuration is according Pratyush suggestion.
> Check the discussion at
> https://lore.kernel.org/all/20211103234950.202289-4-tudor.amba...@microchip.com/
>
> Cheers,
> ta
>
> > + bool "Command extension type is INVERT for Software Reset on boot"
> > + default n
> > + help
> > +Because of SFDP information can not be get before boot.
> > +So define command extension type is INVERT when Software Reset on
> > boot only.
> > +
> > config SPI_FLASH_SOFT_RESET
> > bool "Software Reset support for SPI NOR flashes"
> > default n
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index 0a6550984b..2b6947cefc 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> > enum spi_nor_cmd_ext ext;
> >
> > ext = nor->cmd_ext_type;
> > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */
> > + }
> >
> > op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN,
> > 0),
> > SPI_MEM_OP_NO_DUMMY,
> > --
> > 2.17.1
> >
>
Re: [PATCH v5 1/3] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Tudor
>
> On 11/18/21 12:13 PM, JaimeLiao wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
>
> Hi, Jaime,
>
> > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
> > Macronix flash in Octal DTR mode.
> >
> > Enable Octal DTR mode with 20 dummy cycles to allow running at the
> > maximum supported frequency.
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> >
>
> I have submitted a similar patch at
> https://lore.kernel.org/all/20211103162454.179191-2-tudor.amba...@microchip.com/T/#me9b6e48c33fd545a9c0b5a5136778651ea64171a
>
> but I think yours has precedence, you're already at v5.
>
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 83 ++
> > include/linux/mtd/spi-nor.h| 12 -
> > 2 files changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index d5d905fa5a..0a6550984b 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = {
> > };
> > #endif /* CONFIG_SPI_FLASH_MT35XU */
> >
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > +/**
> > + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> > Configuration Register 2.
> > + * @nor: pointer to a 'struct spi_nor'
> > + *
> > + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
> > + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like
> > OPI memories.
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
> > +{
> > + struct spi_mem_op op;
> > + int ret;
> > + u8 buf;
> > +
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_DC_20;
> > + 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_DC, 1),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_DATA_OUT(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret)
> > + return ret;
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + nor->read_dummy = MXIC_MAX_DC;
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> > + 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(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret) {
> > + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> > + return ret;
> > + }
> > + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> > +
> > + return 0;
> > +}
> > +
> > +static void macronix_octal_default_init(struct spi_nor *nor)
> > +{
> > + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
> > +}
>
> Can't we determine the octal dtr method by parsing SFDP?
>
It is a good idea for getting flash parameters by checking SFDP.
Your patchwork is on-going to solve the ID collision issues in Linux kernel.
I think U-boot should follow the method after ID collision patchwork
finish in Linux kenel.
So that octal dtr method follow the configuration for now.
Thanks
Jaime
> Cheers,
> ta
>
> > +
> > +static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor,
> > +struct spi_nor_flash_parameter
> > *params)
> > +{
> > + /*
> > +* Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
> > +* SPI_NOR_OCTAL_DTR_READ flag exists.
> > +*/
> > + if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
> > + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
> > +}
> > +
> > +static struct spi_nor_fixups macronix_octal_fixups = {
> > + .default_init = macronix_octal_default_init,
> > + .post_sfdp = macronix_octal_post_sfdp_fixup,
> > +};
> > +#endif /* CONFIG_SPI_FLASH_MACRONIX */
> > +
> > /** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
> > * @nor: pointer to a 'struct spi_nor'
> > *
> > @@ -3655,6 +3734,10 @@ void spi_nor_set_fixups(struct spi_nor *nor)
> > if (!strcmp(nor->info->name, "mt35xu512aba"))
> > nor->fixups = &mt35xu512aba_fixups;
> > #endif
> > +
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > + nor->fixups = ¯onix_octa
Re: [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Jagan > > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao wrote: > > > > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding > > Macronix flash in Octal DTR mode. > > > > Enable Octal DTR mode with 20 dummy cycles to allow running at the > > maximum supported frequency. > > > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > > > Signed-off-by: JaimeLiao > > --- > > drivers/mtd/spi/Kconfig| 7 +++ > > drivers/mtd/spi/spi-nor-core.c | 83 ++ > > include/linux/mtd/spi-nor.h| 13 +- > > 3 files changed, 101 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > > index 1b2ef37e92..67599b32c9 100644 > > --- a/drivers/mtd/spi/Kconfig > > +++ b/drivers/mtd/spi/Kconfig > > @@ -162,6 +162,13 @@ config SPI_FLASH_MACRONIX > > help > > Add support for various Macronix SPI flash chips (MX25Lxxx) > > > > +config SPI_FLASH_MACRONIX_OCTAL > > What if we use exiting SPI_FLASH_MACRONIX for it? does it increasing > size much? if not go for exiting macro. I want to seperate SPI_FLASH_MACRONIX and SPI_FLASH_MACRONIX_OCTAL for enabling Macronix octal support. Refer to your suggestions, checking SPI_FLASH_MACRONIX and other configuration which means octal enable is better. But I didn't found the existing configuration means "octal enable". It would be great if you can recommend the suitable configuration set for nor->fixups hooks macronix_octal_fixups. I will have v5 patchwork with the configuration checking. Thanks Jaime
Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
>
> On 25/10/21 12:30PM, Jagan Teki wrote:
> > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao wrote:
> > >
> > > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> > > 8D-8D-8D
> > > in the begging of probe.
> > >
> > > Command extension type is not standardized across flash vendors in DTR
> > > mode.
> > >
> > > For suiting different vendor flash devices, adding a flag to seperate
> > > types for
> > > soft reset on boot.
> > >
> > > Signed-off-by: JaimeLiao
> > > ---
> > > drivers/mtd/spi/Kconfig| 7 +++
> > > drivers/mtd/spi/spi-nor-core.c | 7 ++-
> > > 2 files changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > > index 67599b32c9..8304d6c973 100644
> > > --- a/drivers/mtd/spi/Kconfig
> > > +++ b/drivers/mtd/spi/Kconfig
> > > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> > > can support a type of operation in a much more refined way
> > > compared
> > > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> > >
> > > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
> > > + bool "Command extension type is INVERT for Software Reset on boot"
> > > + default n
> > > + help
> > > +Because of SFDP information can not be get before boot.
> > > +So define command extension type is INVERT when Software Reset
> > > on boot only.
> > > +
> > > config SPI_FLASH_SOFT_RESET
> > > bool "Software Reset support for SPI NOR flashes"
> > > default n
> > > diff --git a/drivers/mtd/spi/spi-nor-core.c
> > > b/drivers/mtd/spi/spi-nor-core.c
> > > index fdaca0a0d3..87a7de7d60 100644
> > > --- a/drivers/mtd/spi/spi-nor-core.c
> > > +++ b/drivers/mtd/spi/spi-nor-core.c
> > > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> > > enum spi_nor_cmd_ext ext;
> > >
> > > ext = nor->cmd_ext_type;
> > > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> > > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> > > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> > > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */
> >
> > I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try
> > it that way instead of new macro?
>
> The problem is that for OSPI boot mode the ROM can often leave the flash
> in 8D-8D-8D mode. So when U-Boot first starts executing the flash is
> already in 8D-8D-8D mode and there is no easy and reliable way to detect
> this mode. So we must blindly perform a soft reset before probing the
> flash and reading SFDP so that it is reset back to a usable state.
>
> This is why we can't detect the extension via BFPT since the flash is in
> an unknown state. This is not the case when resetting before booting the
> OS since at that point we have fully probed the flash. So I think this
> config must only be used for the reset at boot time. For later resets we
> should indeed use the extension provided by BFPT.
>
> This is a kinda hacky but I can't come up with a better alternative.
>
> Jamie,
>
> Below diff is what I have been suggesting you in my earlier replies.
> Note that this is just a quick and dirty implementation, I have not
> tested this at all. That is up to you to do. Please also test soft reset
> _after_ the probe is finished so we know that it works correctly when
> using data from BFPT as well.
>
> -- 8< --
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 4388a08a90..b0f22e0ce5 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3616,10 +3616,6 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> {
> struct spi_mem_op op;
> int ret;
> - enum spi_nor_cmd_ext ext;
> -
> - ext = nor->cmd_ext_type;
> - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
>
> op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN,
> 0),
> SPI_MEM_OP_NO_DUMMY,
> @@ -3629,7 +3625,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> ret = spi_mem_exec_op(nor->spi, &op);
> if (ret) {
> dev_warn(nor->dev, "Software reset enable failed: %d\n", ret);
> - goto out;
> + return ret;
> }
>
> op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 0),
> @@ -3640,7 +3636,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> ret = spi_mem_exec_op(nor->spi, &op);
> if (ret) {
> dev_warn(nor->dev, "Software reset failed: %d\n", ret);
> - goto out;
> + return ret;
> }
>
> /*
> @@ -3650,9 +3646,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> */
> udelay(SPI_NOR_SRST_SLEEP_LEN);
>
> -out:
> - nor->cmd_ext_type = ext;
> - return ret;
> +
Re: [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash
>
> On 18/10/21 02:24PM, JaimeLiao wrote:
> > 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
> >
> > 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.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-ids.c | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > index cb3a08872d..5c13ea3a78 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = {
> > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ
> > | SPI_NOR_4B_OPCODES | SECT_4K) },
> > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) },
> > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
>
> Why are you changing the name of this flash?
>
> Other than this, the patch looks good to me.
MX66UW2G345G is similar to MX66UW2G345GX0 and MX66UW2G345G's device ID
is 0xc2843c actually.
So that I correct it and add MX66UW2G345GX0 in IDs table.
>
> > + { INFO("mx66lm1g45g",0xc2853b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um2g45g",0xc2803c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um1g45g",0xc2803b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw1g45g",0xc2813b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw12a45g", 0xc28938, 0, 4 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_RE
Re: [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible
> > On 18/10/21 02:24PM, JaimeLiao wrote: > > Following linux kernel to check address width and 4byte flag to enable > > 4byte opcode setting. > > > > Signed-off-by: JaimeLiao > > --- > > drivers/mtd/spi/spi-nor-core.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > > index 87a7de7d60..7d6671ade2 100644 > > --- a/drivers/mtd/spi/spi-nor-core.c > > +++ b/drivers/mtd/spi/spi-nor-core.c > > @@ -3902,6 +3902,10 @@ int spi_nor_scan(struct spi_nor *nor) > > return -EINVAL; > > } > > > > + /* Set 4byte opcodes when possible. */ > > + if (nor->addr_width == 4 && info->flags & SPI_NOR_4B_OPCODES) > > + spi_nor_set_4byte_opcodes(nor, info); > > + > > I still don't think this is the right thing to do. You should rework the > previous check for SPI_NOR_4B_OPCODES to fit whatever your flash needs > instead of adding it again. You are right, 3 byte command can be accepted after SPINOR_OP_EN4B. I will remove this part in patch next revision. > > > /* Send all the required SPI flash commands to initialize device */ > > ret = spi_nor_init(nor); > > if (ret) > > -- > > 2.17.1 > > > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc.
Re: [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash
MX66UW2G345G is similar to MX66UW2G345GX0 and MX66UW2G345G's device ID is
0xc2843c actually.
So that I correct it and add MX66UW2G345GX0 in IDs table.
Pratyush Yadav 於 2021年10月26日 週二 上午3:45寫道：
> On 18/10/21 02:24PM, JaimeLiao wrote:
> > 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
> >
> > 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.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-ids.c | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c
> b/drivers/mtd/spi/spi-nor-ids.c
> > index cb3a08872d..5c13ea3a78 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = {
> > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32,
> SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) },
> > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) },
> > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
>
> Why are you changing the name of this flash?
>
> Other than this, the patch looks good to me.
>
> > + { INFO("mx66lm1g45g",0xc2853b, 0, 32 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um2g45g",0xc2803c, 0, 64 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um1g45g",0xc2803b, 0, 32 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw1g45g",0xc2813b, 0, 32 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw12a45g", 0xc28938, 0, 4 * 1024, 4096, SECT_4K |
> SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES)
Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
For validating soft_reset after probe, I have test it on my side.
It is working with command extension type which got from BFPT.
Pratyush Yadav 於 2021年10月26日 週二 上午3:42寫道：
> On 25/10/21 12:30PM, Jagan Teki wrote:
> > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao
> wrote:
> > >
> > > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> 8D-8D-8D
> > > in the begging of probe.
> > >
> > > Command extension type is not standardized across flash vendors in DTR
> mode.
> > >
> > > For suiting different vendor flash devices, adding a flag to seperate
> types for
> > > soft reset on boot.
> > >
> > > Signed-off-by: JaimeLiao
> > > ---
> > > drivers/mtd/spi/Kconfig| 7 +++
> > > drivers/mtd/spi/spi-nor-core.c | 7 ++-
> > > 2 files changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > > index 67599b32c9..8304d6c973 100644
> > > --- a/drivers/mtd/spi/Kconfig
> > > +++ b/drivers/mtd/spi/Kconfig
> > > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> > > can support a type of operation in a much more refined way
> compared
> > > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> > >
> > > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
> > > + bool "Command extension type is INVERT for Software Reset on
> boot"
> > > + default n
> > > + help
> > > +Because of SFDP information can not be get before boot.
> > > +So define command extension type is INVERT when Software
> Reset on boot only.
> > > +
> > > config SPI_FLASH_SOFT_RESET
> > > bool "Software Reset support for SPI NOR flashes"
> > > default n
> > > diff --git a/drivers/mtd/spi/spi-nor-core.c
> b/drivers/mtd/spi/spi-nor-core.c
> > > index fdaca0a0d3..87a7de7d60 100644
> > > --- a/drivers/mtd/spi/spi-nor-core.c
> > > +++ b/drivers/mtd/spi/spi-nor-core.c
> > > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor
> *nor)
> > > enum spi_nor_cmd_ext ext;
> > >
> > > ext = nor->cmd_ext_type;
> > > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> > > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> > > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> > > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */
> >
> > I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try
> > it that way instead of new macro?
>
> The problem is that for OSPI boot mode the ROM can often leave the flash
> in 8D-8D-8D mode. So when U-Boot first starts executing the flash is
> already in 8D-8D-8D mode and there is no easy and reliable way to detect
> this mode. So we must blindly perform a soft reset before probing the
> flash and reading SFDP so that it is reset back to a usable state.
>
> This is why we can't detect the extension via BFPT since the flash is in
> an unknown state. This is not the case when resetting before booting the
> OS since at that point we have fully probed the flash. So I think this
> config must only be used for the reset at boot time. For later resets we
> should indeed use the extension provided by BFPT.
>
> This is a kinda hacky but I can't come up with a better alternative.
>
> Jamie,
>
> Below diff is what I have been suggesting you in my earlier replies.
> Note that this is just a quick and dirty implementation, I have not
> tested this at all. That is up to you to do. Please also test soft reset
> _after_ the probe is finished so we know that it works correctly when
> using data from BFPT as well.
>
> -- 8< --
> diff --git a/drivers/mtd/spi/spi-nor-core.c
> b/drivers/mtd/spi/spi-nor-core.c
> index 4388a08a90..b0f22e0ce5 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3616,10 +3616,6 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> {
> struct spi_mem_op op;
> int ret;
> - enum spi_nor_cmd_ext ext;
> -
> - ext = nor->cmd_ext_type;
> - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
>
> op = (struct
> spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0),
> SPI_MEM_OP_NO_DUMMY,
> @@ -3629,7 +3625,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> ret = spi_mem_exec_op(nor->spi, &op);
> if (ret) {
> dev_warn(nor->dev, "Software reset enable failed: %d\n",
> ret);
> - goto out;
> + return ret;
> }
>
> op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST,
> 0),
> @@ -3640,7 +3636,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> ret = spi_mem_exec_op(nor->spi, &op);
> if (ret) {
> dev_warn(nor->dev, "Software reset failed: %d\n", ret);
> - goto out;
> + return ret;
> }
>
> /*
> @@ -3650,9 +3646,7 @@ static int spi_nor_soft_reset(s
Re: [PATCH v3 3/4] mtd: spi-nor-core: set 4byte opcode when possible
>if (spi_nor_protocol_is_dtr(nor->read_proto)) {
> /* Always use 4-byte addresses in DTR mode. */
>nor->addr_width = 4;
because of nor->addr_width have been set to 4 when protocol is dtr
>} else if (nor->addr_width) {
>/* already configured from SFDP */
>} else if (info->addr_width) {
>nor->addr_width = info->addr_width;
>} else {
>nor->addr_width = 3;
>}
>
>if (nor->addr_width == 3 && mtd->size > SZ_16M) {
>#ifndef CONFIG_SPI_FLASH_BAR
>/* enable 4-byte addressing if the device exceeds 16MiB */
>nor->addr_width = 4;
>if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
>info->flags & SPI_NOR_4B_OPCODES)
>spi_nor_set_4byte_opcodes(nor, info);
nor->addr_width is equal 4 when protocol is dtr
so we need a judgement to do spi_nor_set_4byte_opcodes(nor, info)
>#else
>/* Configure the BAR - discover bank cmds and read current bank */
>nor->addr_width = 3;
>ret = read_bar(nor, info);
>if (ret < 0)
>return ret;
>#endif
>}
Pratyush Yadav 於 2021年9月25日 週六 上午2:29寫道：
> On 13/09/21 01:42PM, JaimeLiao wrote:
> > Following linux kernel to check address width and 4byte flag to enable
> > 4byte opcode setting.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c
> b/drivers/mtd/spi/spi-nor-core.c
> > index 4bcd58d839..81c61d87bc 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3902,6 +3902,10 @@ int spi_nor_scan(struct spi_nor *nor)
> > return -EINVAL;
> > }
> >
> > + /* Set 4byte opcodes when possible. */
> > + if (nor->addr_width == 4 && info->flags & SPI_NOR_4B_OPCODES)
> > + spi_nor_set_4byte_opcodes(nor, info);
>
> This is already done a few lines above. Why do you need to do it again?
>
> > +
> > /* Send all the required SPI flash commands to initialize device */
> > ret = spi_nor_init(nor);
> > if (ret)
> > --
> > 2.17.1
> >
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
>
Re: [PATCH v2 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
Hi Pratyush
Thanks for your reply, I want to create "CONFIG_SPI_EXT_INVERT"
to separate extension types.
Changed as below, do you have any suggestion?
ext = nor->cmd_ext_type;
if (!nor->cmd_ext_type) {
nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
#ifdef CONFIG_SPI_NOR_EXT_INVERT
nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
#endif
}
Pratyush Yadav 於 2021年8月30日 週一 下午7:30寫道：
> Hi,
>
> On 20/08/21 02:58PM, JaimeLiao wrote:
> > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> 8D-8D-8D
> > in the begging of probe.
> >
> > Command extension type is not standardized across flash vendors in DTR
> mode.
> >
> > For suiting different vendor flash devices, having second times
> Softreset with
> > different types is clumsy but useful in the begging of probe.
>
> Yes, it is indeed clumsy, and I am not convinced this is the right way
> to go.
>
> Firstly, you issue the reset twice. This is obviously not ideal and you
> have to hope the command with incorrect extension is ignored, and not
> interpreted as something different. But more importantly, you also do
> the same when called via spi_nor_remove(). At that point you have parsed
> SFDP and know the flash we are dealing with so you should already know
> which extension to use.
>
> So here is my suggestion: create a separate function, something like
> spi_nor_early_soft_reset(). In that function check a config variable to
> decide which extension to use and temporarily set nor->cmd_ext_type to
> that. Then in spi_nor_soft_reset() just use nor->cmd_ext_type, no need
> to hard code the extension. This way you will certainly use the correct
> extension at remove and will have a more accurate guess at probe time.
>
> I admit this isn't the cleanest solution, but this is the best I can
> come up with right now.
>
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c
> b/drivers/mtd/spi/spi-nor-core.c
> > index 351ca9c3a8..707eb9c1d2 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3692,6 +3692,36 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> >*/
> > udelay(SPI_NOR_SRST_SLEEP_LEN);
> >
> > + /* Manufacturers with different command extension type. For
> suitting
> > + * different flash devices, using command extension type is equal
> "INVERT"
> > + * when second time Software Reset.
> > + */
> > +
> > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> > + op = (struct
> spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_NO_ADDR,
> > + SPI_MEM_OP_NO_DATA);
> > + spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret) {
> > + dev_warn(nor->dev, "Software reset enable failed: %d\n",
> ret);
> > + goto out;
> > + }
> > +
> > + op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST,
> 0),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_NO_ADDR,
> > + SPI_MEM_OP_NO_DATA);
> > + spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret) {
> > + dev_warn(nor->dev, "Software reset failed: %d\n", ret);
> > + goto out;
> > + }
> > +
> > + udelay(SPI_NOR_SRST_SLEEP_LEN);
> > +
> > out:
> > nor->cmd_ext_type = ext;
> > return ret;
> > --
> > 2.17.1
> >
>
> --
> Regards,
> Pratyush Yadav
> Texas Instruments Inc.
>
Re: [PATCH 1/4] mtd: spi-nor: macronix: add support for Macronix octaflash
Hi Pratyush
Thanks for your reply and I have send v2 patch , please
help to review.
I prefer to have v3 patch for replacing SPI_FLASH_MACRONIX with
SPI_FLASH_MACRONIX_OCTAL.
It would be great if you could help to review v2 and then I will
add the modifications in v3.
Thanks
Jaime
Pratyush Yadav 於 2021年8月14日 週六 上午2:06寫道：
> On 13/08/21 03:25PM, JaimeLiao wrote:
> > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
> > Macronix flash in Octal DTR mode.
> > Enable Octal DTR mode with 20 dummy cycles to allow running at the
> > maximum supported frequency.
>
> Please include a link to the flash datasheet so the reviewers can
> properly review your patch.
>
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 75 ++
> > include/linux/mtd/spi-nor.h| 13 +-
> > 2 files changed, 86 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c
> b/drivers/mtd/spi/spi-nor-core.c
> > index d5d905fa5a..6b195b1fd3 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3489,6 +3489,77 @@ static struct spi_nor_fixups mt35xu512aba_fixups
> = {
> > };
> > #endif /* CONFIG_SPI_FLASH_MT35XU */
> >
> > +#ifdef CONFIG_SPI_FLASH_MACRONIX
> > +/**
> > + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> Configuration Register 2.
> > + * @nor: pointer to a 'struct spi_nor'
> > + *
> > + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
>
> Nitpick: Why the blank line here?
> > + *
> > + * bit 2 of Configuration Register 2 is the DOPI bit for Macronix like
> OPI memories.
>
> Nitpick: Capitalize the 'b'.
>
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
> > +{
> > + struct spi_mem_op op;
> > + int ret;
> > + u8 buf;
> > +
> > + write_enable(nor);
>
> Need to check the return code here.
>
> > +
> > + buf = SPINOR_REG_MXIC_DC_20;
> > + 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_DC, 1),
> > +SPI_MEM_OP_NO_DUMMY,
> > +SPI_MEM_OP_DATA_OUT(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret)
> > + return ret;
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + nor->read_dummy = MXIC_MAX_DC;
> > + write_enable(nor);
> > +
> > + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> > + 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(1, &buf, 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, &op);
> > + if (ret) {
> > + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> > + return ret;
> > + }
> > + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> > +
> > + return 0;
> > +}
> > +
> > +static void macronix_default_init(struct spi_nor *nor)
> > +{
> > + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
> > +}
> > +
> > +static void macronix_post_sfdp_fixup(struct spi_nor *nor,
> > + struct spi_nor_flash_parameter
> *params)
> > +{
> > + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
>
> This does not seem right. You would mark every Macronix flash Octal DTR
> capable which is clearly not true.
>
> > +}
> > +
> > +static struct spi_nor_fixups macronix_fixups = {
> > + .default_init = macronix_default_init,
> > + .post_sfdp = macronix_post_sfdp_fixup,
> > +};
> > +#endif /* CONFIG_SPI_FLASH_MACRONIX */
> > +
> > /** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
> > * @nor: pointer to a 'struct spi_nor'
> > *
> > @@ -3655,6 +3726,10 @@ void spi_nor_set_fixups(struct spi_nor *nor)
> > if (!strcmp(nor->info->name, "mt35xu512aba"))
> > nor->fixups = &mt35xu512aba_fixups;
> > #endif
> > +
> > +#ifdef CONFIG_SPI_FLASH_MACRONIX
> > + nor->fixups = ¯onix_fixups;
> > +#endif
> > }
> >
> > int spi_nor_scan(struct spi_nor *nor)
> > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> > index 7ddc4ba2bf..2ad579f66d 100644
> > --- a/include/linux/mtd/spi-nor.h
> > +++ b/include/linux/mtd/spi-nor.h
> > @@ -116,8 +116,17 @@
> > #define XSR_RDY BIT(7) /* Ready */
> >
> > /* Used for Macronix and Winbond flashes. */
> > -#define SPINOR_OP_EN4B 0xb7/* Enter 4-byte mode */
> > -#define SPINOR_OP_EX4B 0xe9/* Exit 4-byte mode */
> > +#define SPINOR_OP_EN4B 0xb7/* Enter
> 4-byte mode */
> > +#define SPINOR_OP_EX4B
