[PATCH v3 0/4] mtd: spi: spi-nor: rk3399: rock-pi-4: u-boot/next Support SPI NOR Flash in Rock Pi 4 (XTX xt25f32b)
The Radxa Rock Pi 4 board is sold from revision 1.4 with a soldered 4Mb SPI NOR Flash. This series allows to use it from U-Boot and boot from it.
This series applies to u-boot/master.
Changes since v2:
- rebased on master
- droped 5th path, and enabled CONFIG_SPL_DM_SEQ_ALIAS instead to have the flash on spi1 both on SPL and U-Boot proper.
Changes since v1:
- Changed bus number to 1 in SPL to match U-Boot proper (before it was bus 0 in SPL and bus 1 in U-Boot).
- Generalization. v1 did a first soft_reset in 8_8_8_DTR but that wouldn't work since Pratyush Yadav fixed supports_op() in commit 5752d6ae8daacbd ("spi: spi-mem: add spi_mem_dtr_supports_op()"). So now we try a few protocols until 1_1_1 is supported by controller and device. Might work for more systems.
Radxa Rock Pi 4B from version 1.4 on carries a 4MiB XTX Technology Inc 25F32B SPI NOR Flash. (previous versions had pads where users could solder different chips).
Add its parameters to spi-nor-ids.c so U-Boot can discover it and (after further changes) we can boot from SPI.
Note that the Flash is declared to be dual and quad capable because the datasheet [4] says so but I couldn't try it because in Rock Pi 4 it is not wired for QuadSPI, and rk3399 does not seem to support dual SPI either (or I couldn't find any register to configure spi1tx and spi1rx as bidirectional).
But the same Flash part could be used as in quad or dual model in some other board.
Likewise locks are in the datasheet but untested.
The part has been added to downstream U-Boot [1] and linux [2] [3]:
Changed from v2:
- no change
Changed from v1:
- no change
Link: [1] https://github.com/armbian/build/commit/c41cb4c454570127ad3238f6b901fbf3aa77... Link: [2] https://github.com/radxa/kernel/blob/release-4.4-rockpi4/drivers/mtd/spi-nor... Link: [3] https://github.com/radxa/kernel/commit/8216f17965de7bc7ced7092aab0e2bfe16838... Link: [4] https://www.xtxtech.com/download/?AId=157
Signed-off-by: Xavier Drudis Ferran xdrudis@tinet.cat
Cc: Jagan Teki jagan@amarulasolutions.com Cc: Vignesh R vigneshr@ti.com
--- drivers/mtd/spi/spi-nor-ids.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c index 4fe8b0d92c..b09df00bab 100644 --- a/drivers/mtd/spi/spi-nor-ids.c +++ b/drivers/mtd/spi/spi-nor-ids.c @@ -452,6 +452,9 @@ const struct flash_info spi_nor_ids[] = { #ifdef CONFIG_SPI_FLASH_XTX /* XTX Technology (Shenzhen) Limited */ { INFO("xt25f128b", 0x0b4018, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { INFO("xt25f32b", 0x0b4016, 0, 64 * 1024, 64, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ + | SPI_NOR_HAS_LOCK | SPI_NOR_HAS_SST26LOCK) }, #endif { }, };
Configure Rock Pi 4 to boot from SPI NOR Flash.
Based on flash chip, board documentation and tests, this is the fastest I could use it.
This seems to be the minimum necessary configuration for Rock Pi 4 to be able to boot from SPI NOR Flash.
With the next patch, it works to sf probe 1:0, sf read, sf erase, sf write, sf read and then boot linux and flashrom can write to it. Sometimes flashrom seems to fail to write when at U-Boot stage there was no sf read or write, not sure why. Might work better after a little while off power.
Note: It seems to work with or without CONFIG_SPL_SPI_FLASH_TINY If I disable it, and enable CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT I have to increase CONFIG_SPL_MAX_SIZE (I set it to 0x2e800) because the SPL grew over 1200 bytes bigger. It might work better, or just be chance, but it boots from SPI 0.3s slower. So I leave this out of this patch.
Changed since v2:
- added CONFIG_SPL_DM_SEQ_ALIAS to keep spi1 numeration consistent between SPL and U-Boot
Changed since v1:
- include CONFIG_SF_DEFAULT_BUS=1 now that numeration will be unified between U-Boot and SPL (at patch 5/5)
Cc: Simon Glass sjg@chromium.org Cc: Philipp Tomsich philipp.tomsich@vrull.eu Cc: Kever Yang kever.yang@rock-chips.com
Signed-off-by: Xavier Drudis Ferran xdrudis@tinet.cat --- arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 18 ++++++++++++++++++ configs/rock-pi-4-rk3399_defconfig | 22 ++++++++++++++++++++++ 2 files changed, 40 insertions(+)
diff --git a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi index c17e769f64..4c2fe8f6bc 100644 --- a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi @@ -15,3 +15,21 @@ &vdd_log { regulator-init-microvolt = <950000>; }; + +&spi1 { + status = "okay"; + spi-max-frequency = <40000000>; + spi-activate-delay = <12000>; /* 12 ms */ + + norflash: flash@0 { + compatible = "rockchip,spidev", "jedec,spi-nor"; + reg = <0>; + + spi-max-frequency = <40000000>; + spi-cpha; + spi-cpol; + + status = "okay"; + u-boot,dm-pre-reloc; + }; +}; diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index cf2e9fbde3..d5fadcb64f 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -10,6 +10,8 @@ CONFIG_ROCKCHIP_RK3399=y CONFIG_TARGET_EVB_RK3399=y CONFIG_DEBUG_UART_BASE=0xFF1A0000 CONFIG_DEBUG_UART_CLOCK=24000000 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y @@ -28,6 +30,10 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_STACK=0x400000 CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000 +CONFIG_SPL_MTD_SUPPORT=y +CONFIG_SPL_SPI_FLASH_MTD=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0xb0000 CONFIG_TPL=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y @@ -40,6 +46,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y @@ -48,21 +55,36 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ROCKCHIP=y +CONFIG_MTD=y +CONFIG_DM_MTD=y +CONFIG_SF_DEFAULT_BUS=1 +CONFIG_SF_DEFAULT_MODE=0x3 +CONFIG_SF_DEFAULT_SPEED=40000000 +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_XTX=y +CONFIG_SPI_FLASH_MTD=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_NVME_PCI=y CONFIG_PCI=y +CONFIG_SPL_PHY=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y +CONFIG_SPL_REGULATOR_PWM=y +CONFIG_DM_REGULATOR_GPIO=y CONFIG_REGULATOR_RK8XX=y CONFIG_PWM_ROCKCHIP=y CONFIG_RAM_RK3399_LPDDR4=y CONFIG_DM_RESET=y CONFIG_BAUDRATE=1500000 CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_ROCKCHIP_SPI=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y
On 2022/7/20 23:41, Xavier Drudis Ferran wrote:
Configure Rock Pi 4 to boot from SPI NOR Flash.
Based on flash chip, board documentation and tests, this is the fastest I could use it.
This seems to be the minimum necessary configuration for Rock Pi 4 to be able to boot from SPI NOR Flash.
With the next patch, it works to sf probe 1:0, sf read, sf erase, sf write, sf read and then boot linux and flashrom can write to it. Sometimes flashrom seems to fail to write when at U-Boot stage there was no sf read or write, not sure why. Might work better after a little while off power.
Note: It seems to work with or without CONFIG_SPL_SPI_FLASH_TINY If I disable it, and enable CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT I have to increase CONFIG_SPL_MAX_SIZE (I set it to 0x2e800) because the SPL grew over 1200 bytes bigger. It might work better, or just be chance, but it boots from SPI 0.3s slower. So I leave this out of this patch.
Changed since v2:
- added CONFIG_SPL_DM_SEQ_ALIAS to keep spi1 numeration consistent between SPL and U-BootChanged since v1:
- include CONFIG_SF_DEFAULT_BUS=1 now that numeration will be unified between U-Boot and SPL (at patch 5/5)Cc: Simon Glass sjg@chromium.org Cc: Philipp Tomsich philipp.tomsich@vrull.eu Cc: Kever Yang kever.yang@rock-chips.com
Signed-off-by: Xavier Drudis Ferran xdrudis@tinet.cat
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 18 ++++++++++++++++++ configs/rock-pi-4-rk3399_defconfig | 22 ++++++++++++++++++++++ 2 files changed, 40 insertions(+)
diff --git a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi index c17e769f64..4c2fe8f6bc 100644 --- a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi @@ -15,3 +15,21 @@ &vdd_log { regulator-init-microvolt = <950000>; };
+&spi1 {
- status = "okay";
- spi-max-frequency = <40000000>;
- spi-activate-delay = <12000>; /* 12 ms */
- norflash: flash@0 {
compatible = "rockchip,spidev", "jedec,spi-nor";reg = <0>;spi-max-frequency = <40000000>;spi-cpha;spi-cpol;status = "okay";u-boot,dm-pre-reloc;- };
+}; diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index cf2e9fbde3..d5fadcb64f 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -10,6 +10,8 @@ CONFIG_ROCKCHIP_RK3399=y CONFIG_TARGET_EVB_RK3399=y CONFIG_DEBUG_UART_BASE=0xFF1A0000 CONFIG_DEBUG_UART_CLOCK=24000000 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y @@ -28,6 +30,10 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_STACK=0x400000 CONFIG_SPL_STACK_R=y CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000 +CONFIG_SPL_MTD_SUPPORT=y +CONFIG_SPL_SPI_FLASH_MTD=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0xb0000 CONFIG_TPL=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y @@ -40,6 +46,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y @@ -48,21 +55,36 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ROCKCHIP=y +CONFIG_MTD=y +CONFIG_DM_MTD=y +CONFIG_SF_DEFAULT_BUS=1 +CONFIG_SF_DEFAULT_MODE=0x3 +CONFIG_SF_DEFAULT_SPEED=40000000 +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_XTX=y +CONFIG_SPI_FLASH_MTD=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_NVME_PCI=y CONFIG_PCI=y +CONFIG_SPL_PHY=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y +CONFIG_SPL_REGULATOR_PWM=y +CONFIG_DM_REGULATOR_GPIO=y CONFIG_REGULATOR_RK8XX=y CONFIG_PWM_ROCKCHIP=y CONFIG_RAM_RK3399_LPDDR4=y CONFIG_DM_RESET=y CONFIG_BAUDRATE=1500000 CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_ROCKCHIP_SPI=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y
XTX25F32B does not use octal mode and accepts soft reset, despite its SFDP tables. Soft reset at U-Boot exit seems to be required to write to /dev/mtd0 from flashrom in linux. Soft reset at U-Boot start seems to help booting from SPI (at least with the dts properties I'm using).
The first soft reset is done before the flash id is read and the fixups can be called, and v1 of this patch would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. This was since commit 5752d6ae8daa ("spi: spi-mem: add spi_mem_dtr_supports_op()") by Pratyush Yadav.
So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there.
Changed since v2:
- none (rebase)
Changed since v1:
- Generalization. First soft reset with SNOR_PROTO_8_8_8_DTR stopped working since the improvement by Pratyush Yadav. Instead of trying 8_8_8_DTR always at first reset, and force 1_1_1 once XTX25F32B is detected (so, for last reset) do a generic loop for any chip trying protocols until one is supported and starting by the 8_8_8_DTR protocol (the one previously used). This leverages the fixed supports_op() to take into account controller and device.
fixups can be called, and it would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there.
Signed-off-by: Xavier Drudis Ferran xdrudis@tinet.cat
Cc: Jagan Teki jagan@amarulasolutions.com Cc: Vignesh R vigneshr@ti.com
--- drivers/mtd/spi/spi-nor-core.c | 98 ++++++++++++++++++++++++++++++---- include/linux/mtd/spi-nor.h | 5 ++ 2 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index 8a226a7af5..17f0cb51fb 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3575,6 +3575,18 @@ static struct spi_nor_fixups mt35xu512aba_fixups = { }; #endif /* CONFIG_SPI_FLASH_MT35XU */
+#ifdef CONFIG_SPI_FLASH_XTX +static void xtx25f32b_post_sfdp_fixup(struct spi_nor *nor, + struct spi_nor_flash_parameter *params) +{ + nor->flags |= SNOR_F_SOFT_RESET; +} + +static struct spi_nor_fixups xtx25f32b_fixups = { + .post_sfdp = xtx25f32b_post_sfdp_fixup, +}; +#endif + #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) /** * spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix flashes. @@ -3733,6 +3745,53 @@ static int spi_nor_init(struct spi_nor *nor) }
#ifdef CONFIG_SPI_FLASH_SOFT_RESET +/** + * spi_nor_soft_reset_setup_op() - Initial setup of op for soft + * reset. Initializes nor->reset_proto iff needed. + * + * @nor: the spi_nor structure nor->reset_proto will be used or if + * null, it'll be assigned the used protocol, from a few + * protocols that get tried for device and controller + * support. + * + * @opcode operation code for soft reset (or soft reset enable, + * we currently assume they work the same in all systems) + * + * @op: pointer to operation struct to set up for reset or reset + * enable. + */ +static void spi_nor_soft_reset_setup_op(struct spi_nor *nor, u16 opcode, struct spi_mem_op *op) +{ + enum spi_nor_protocol reset_proto; + /** + * admitedly arbitrary list, to be improved if there's + * new knowledge of what works in different systems + */ + enum spi_nor_protocol reset_proto_candidates[] = { + SNOR_PROTO_8_8_8_DTR, SNOR_PROTO_1_1_1_DTR, SNOR_PROTO_8_8_8, + SNOR_PROTO_4_4_4, SNOR_PROTO_2_2_2, SNOR_PROTO_1_1_1 + }; + + if (nor->reset_proto) { + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), + SPI_MEM_OP_NO_DUMMY, + SPI_MEM_OP_NO_ADDR, + SPI_MEM_OP_NO_DATA); + spi_nor_setup_op(nor, op, nor->reset_proto); + } else { + for (int i = 0; i < ARRAY_SIZE(reset_proto_candidates) && !nor->reset_proto ; i++) { + reset_proto = reset_proto_candidates[i]; + *op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0), + SPI_MEM_OP_NO_DUMMY, + SPI_MEM_OP_NO_ADDR, + SPI_MEM_OP_NO_DATA); + spi_nor_setup_op(nor, op, reset_proto); + if (spi_mem_supports_op(nor->spi, op)) + nor->reset_proto = reset_proto; + } + } +} + /** * spi_nor_soft_reset() - perform the JEDEC Software Reset sequence * @nor: the spi_nor structure @@ -3756,11 +3815,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) #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, - SPI_MEM_OP_NO_ADDR, - SPI_MEM_OP_NO_DATA); - spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR); + spi_nor_soft_reset_setup_op(nor, SPINOR_OP_SRSTEN, &op); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset enable failed: %d\n", ret); @@ -3771,7 +3826,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) 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); + spi_nor_setup_op(nor, &op, nor->reset_proto); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset failed: %d\n", ret); @@ -3789,18 +3844,34 @@ out: nor->cmd_ext_type = ext; return ret; } -#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ + +static bool flash_supports_proto(const struct flash_info *flash, enum spi_nor_protocol proto) +{ + switch (spi_nor_get_protocol_data_nbits(proto)) { + case 8: + return flash->flags & (spi_nor_protocol_is_dtr(proto) + ? SPI_NOR_OCTAL_DTR_READ + : SPI_NOR_OCTAL_READ); + case 4: return flash->flags & SPI_NOR_QUAD_READ; + case 2: return flash->flags & SPI_NOR_DUAL_READ; + default: + return 1; + } +}
int spi_nor_remove(struct spi_nor *nor) { -#ifdef CONFIG_SPI_FLASH_SOFT_RESET - if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ && + if (flash_supports_proto(nor->info, nor->reset_proto) && nor->flags & SNOR_F_SOFT_RESET) return spi_nor_soft_reset(nor); -#endif - return 0; } +#else /* !CONFIG_SPI_FLASH_SOFT_RESET */ +int spi_nor_remove(struct spi_nor *nor) +{ + return 0; +} +#endif /* CONFIG_SPI_FLASH_SOFT_RESET */
void spi_nor_set_fixups(struct spi_nor *nor) { @@ -3835,6 +3906,11 @@ void spi_nor_set_fixups(struct spi_nor *nor) #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) nor->fixups = ¯onix_octal_fixups; #endif /* SPI_FLASH_MACRONIX */ + +#ifdef CONFIG_SPI_FLASH_XTX + if (!strcmp(nor->info->name, "xt25f32b")) + nor->fixups = &xtx25f32b_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 2595bad9df..4fc81e7b8d 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -501,6 +501,8 @@ struct spi_flash { * @read_proto: the SPI protocol for read operations * @write_proto: the SPI protocol for write operations * @reg_proto the SPI protocol for read_reg/write_reg/erase operations + * @reset_proto: The SPI protocol for soft reset to return to state expected + * by OS before running the OS (at remove time) or at sf probe * @cmd_buf: used by the write_reg * @cmd_ext_type: the command opcode extension for DTR mode. * @fixups: flash-specific fixup hooks. @@ -546,6 +548,9 @@ struct spi_nor { enum spi_nor_protocol read_proto; enum spi_nor_protocol write_proto; enum spi_nor_protocol reg_proto; +#ifdef CONFIG_SPI_FLASH_SOFT_RESET + enum spi_nor_protocol reset_proto; +#endif bool sst_write_second; u32 flags; u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE];
On 20/07/22 05:42PM, Xavier Drudis Ferran wrote:
XTX25F32B does not use octal mode and accepts soft reset, despite its SFDP tables. Soft reset at U-Boot exit seems to be required to write to /dev/mtd0 from flashrom in linux. Soft reset at U-Boot start seems to help booting from SPI (at least with the dts properties I'm using).
The first soft reset is done before the flash id is read and the fixups can be called, and v1 of this patch would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. This was since commit 5752d6ae8daa ("spi: spi-mem: add spi_mem_dtr_supports_op()") by Pratyush Yadav.
So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there.
Changed since v2:
- none (rebase)
Changed since v1:
- Generalization. First soft reset with SNOR_PROTO_8_8_8_DTR stopped working since the improvement by Pratyush Yadav. Instead of trying 8_8_8_DTR always at first reset, and force 1_1_1 once XTX25F32B is detected (so, for last reset) do a generic loop for any chip trying protocols until one is supported and starting by the 8_8_8_DTR protocol (the one previously used). This leverages the fixed supports_op() to take into account controller and device.
Please don't put the changelog in the commit message. Put it below the 3 dashed lines below.
fixups can be called, and it would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there.
Signed-off-by: Xavier Drudis Ferran xdrudis@tinet.cat
Cc: Jagan Teki jagan@amarulasolutions.com Cc: Vignesh R vigneshr@ti.com
drivers/mtd/spi/spi-nor-core.c | 98 ++++++++++++++++++++++++++++++---- include/linux/mtd/spi-nor.h | 5 ++ 2 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index 8a226a7af5..17f0cb51fb 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3575,6 +3575,18 @@ static struct spi_nor_fixups mt35xu512aba_fixups = { }; #endif /* CONFIG_SPI_FLASH_MT35XU */
+#ifdef CONFIG_SPI_FLASH_XTX +static void xtx25f32b_post_sfdp_fixup(struct spi_nor *nor,
struct spi_nor_flash_parameter *params)+{
- nor->flags |= SNOR_F_SOFT_RESET;
+}
+static struct spi_nor_fixups xtx25f32b_fixups = {
- .post_sfdp = xtx25f32b_post_sfdp_fixup,
+}; +#endif
#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) /**
- spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix flashes.
@@ -3733,6 +3745,53 @@ static int spi_nor_init(struct spi_nor *nor) }
#ifdef CONFIG_SPI_FLASH_SOFT_RESET +/**
- spi_nor_soft_reset_setup_op() - Initial setup of op for soft
- reset. Initializes nor->reset_proto iff needed.
- @nor: the spi_nor structure nor->reset_proto will be used or if
null, it'll be assigned the used protocol, from a few
protocols that get tried for device and controller
support.
- @opcode operation code for soft reset (or soft reset enable,
we currently assume they work the same in all systems)
- @op: pointer to operation struct to set up for reset or reset
enable.- */
+static void spi_nor_soft_reset_setup_op(struct spi_nor *nor, u16 opcode, struct spi_mem_op *op) +{
- enum spi_nor_protocol reset_proto;
- /**
* admitedly arbitrary list, to be improved if there's* new knowledge of what works in different systems*/- enum spi_nor_protocol reset_proto_candidates[] = {
SNOR_PROTO_8_8_8_DTR, SNOR_PROTO_1_1_1_DTR, SNOR_PROTO_8_8_8,SNOR_PROTO_4_4_4, SNOR_PROTO_2_2_2, SNOR_PROTO_1_1_1- };
- if (nor->reset_proto) {
*op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0),SPI_MEM_OP_NO_DUMMY,SPI_MEM_OP_NO_ADDR,SPI_MEM_OP_NO_DATA);spi_nor_setup_op(nor, op, nor->reset_proto);- } else {
for (int i = 0; i < ARRAY_SIZE(reset_proto_candidates) && !nor->reset_proto ; i++) {reset_proto = reset_proto_candidates[i];*op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0),SPI_MEM_OP_NO_DUMMY,SPI_MEM_OP_NO_ADDR,SPI_MEM_OP_NO_DATA);spi_nor_setup_op(nor, op, reset_proto);if (spi_mem_supports_op(nor->spi, op))
This only tells if the _controller_ supports the op. There is no way to find out if the flash supports the op without reading SFDP, which would need you to either reset the flash or know which mode it is in. So this patch is all wrong.
The only way to find out what the flash supports is to read its ID or SFDP.
nor->reset_proto = reset_proto;}- }
+}
/**
- spi_nor_soft_reset() - perform the JEDEC Software Reset sequence
- @nor: the spi_nor structure
@@ -3756,11 +3815,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) #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,SPI_MEM_OP_NO_ADDR,SPI_MEM_OP_NO_DATA);- spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
- spi_nor_soft_reset_setup_op(nor, SPINOR_OP_SRSTEN, &op); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset enable failed: %d\n", ret);
@@ -3771,7 +3826,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) 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);
- spi_nor_setup_op(nor, &op, nor->reset_proto); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset failed: %d\n", ret);
@@ -3789,18 +3844,34 @@ out: nor->cmd_ext_type = ext; return ret; } -#endif /* CONFIG_SPI_FLASH_SOFT_RESET */
+static bool flash_supports_proto(const struct flash_info *flash, enum spi_nor_protocol proto) +{
- switch (spi_nor_get_protocol_data_nbits(proto)) {
- case 8:
return flash->flags & (spi_nor_protocol_is_dtr(proto)? SPI_NOR_OCTAL_DTR_READ: SPI_NOR_OCTAL_READ);- case 4: return flash->flags & SPI_NOR_QUAD_READ;
- case 2: return flash->flags & SPI_NOR_DUAL_READ;
- default:
return 1;- }
+}
int spi_nor_remove(struct spi_nor *nor) { -#ifdef CONFIG_SPI_FLASH_SOFT_RESET
- if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ &&
- if (flash_supports_proto(nor->info, nor->reset_proto) && nor->flags & SNOR_F_SOFT_RESET) return spi_nor_soft_reset(nor);
-#endif
- return 0;
} +#else /* !CONFIG_SPI_FLASH_SOFT_RESET */ +int spi_nor_remove(struct spi_nor *nor) +{
- return 0;
+} +#endif /* CONFIG_SPI_FLASH_SOFT_RESET */
void spi_nor_set_fixups(struct spi_nor *nor) { @@ -3835,6 +3906,11 @@ void spi_nor_set_fixups(struct spi_nor *nor) #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) nor->fixups = ¯onix_octal_fixups; #endif /* SPI_FLASH_MACRONIX */
+#ifdef CONFIG_SPI_FLASH_XTX
- if (!strcmp(nor->info->name, "xt25f32b"))
nor->fixups = &xtx25f32b_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 2595bad9df..4fc81e7b8d 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -501,6 +501,8 @@ struct spi_flash {
- @read_proto: the SPI protocol for read operations
- @write_proto: the SPI protocol for write operations
- @reg_proto the SPI protocol for read_reg/write_reg/erase operations
- @reset_proto: The SPI protocol for soft reset to return to state expected
by OS before running the OS (at remove time) or at sf probe- @cmd_buf: used by the write_reg
- @cmd_ext_type: the command opcode extension for DTR mode.
- @fixups: flash-specific fixup hooks.
@@ -546,6 +548,9 @@ struct spi_nor { enum spi_nor_protocol read_proto; enum spi_nor_protocol write_proto; enum spi_nor_protocol reg_proto; +#ifdef CONFIG_SPI_FLASH_SOFT_RESET
- enum spi_nor_protocol reset_proto;
+#endif bool sst_write_second; u32 flags; u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE]; -- 2.20.1
Thank you for your time looking at the patch.
El Tue, Jul 26, 2022 at 12:43:06PM +0530, Pratyush Yadav deia:
Please don't put the changelog in the commit message. Put it below the 3 dashed lines below.
Sorry. Will try to remember it next time. Not sure there's a next version of this patch, though.
This only tells if the _controller_ supports the op. There is no way to find out if the flash supports the op without reading SFDP, which would need you to either reset the flash or know which mode it is in.
Correct. But you can't always read the SFDP if you get the flash in some wrong state and try to reset it through a mode that the controller doesn't support.
So this patch is all wrong.
Then I won't send a 4th version unless someone else thinks it's worth it and I have more time for it.
The only way to find out what the flash supports is to read its ID or SFDP.
Chicken and egg ? The soft_reset is done before reading SFDP. It was done always in octal mode before my patch ("always" means whenever CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT was enabled). My patch tries to do it in a mode that the controller supports.
In my experiments this helps being able to program /dev/mtd0 from linux with flashrom. If that is working in mainstream U-Boot on a Rock Pi 4B version 1.4 or later (with XTX flash) for the rest of people, then I must be testing wrong, what do I know?
Thanks. Have a nice day.
On 26/07/22 10:27AM, Xavier Drudis Ferran wrote:
Thank you for your time looking at the patch.
El Tue, Jul 26, 2022 at 12:43:06PM +0530, Pratyush Yadav deia:
Please don't put the changelog in the commit message. Put it below the 3 dashed lines below.
Sorry. Will try to remember it next time. Not sure there's a next version of this patch, though.
This only tells if the _controller_ supports the op. There is no way to find out if the flash supports the op without reading SFDP, which would need you to either reset the flash or know which mode it is in.
Correct. But you can't always read the SFDP if you get the flash in some wrong state and try to reset it through a mode that the controller doesn't support.
So this patch is all wrong.
Then I won't send a 4th version unless someone else thinks it's worth it and I have more time for it.
The only way to find out what the flash supports is to read its ID or SFDP.
Chicken and egg ? The soft_reset is done before reading SFDP. It was done always in octal mode before my patch ("always" means whenever CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT was enabled). My patch tries to do it in a mode that the controller supports.
Yes, this is indeed a chicken and egg problem of sorts. The octal mode soft reset I added is a hack that gets _some_ flashes working but not all. I see 3 possible ways to solve this:
1. Encode soft reset type in device tree. Read DT to issue the correct type of reset. But if a flash supports multiple stateful modes like 4D-4D-4D and 8D-8D-8D, this might not work so well. 2. Do a hardware reset. This needs the RESET# line to be connected on the board and some way to toggle it. Does not work for boards that do not have this. 3. Discover the mode the flash is in. The SFDP spec (JESD216D-01) does recommend a way to do this in section "4.5 Command Modes". This can let us find out which type of soft reset command the flash takes by reading SFDP. Of course, this needs the flash to implement the read SFDP command in all modes, which is not mandatory as per spec (at least as per xSPI spec (JESD251), which documents 8D-8D-8D flashes).
There is no one size fits all solution that I can see, so I think we need to do all 3 to get full coverage of all cases. But start with the one that fixes your use case and is easiest for you. I would guess that is point 2.
And all this does not even fix the problem of flashes that do not support 1S-1S-1S mode at all. There are some flashes out there that simply only support 8D-8D-8D mode. For those flashes, a reset would still put them in 8D-8D-8D mode. To support those you need to discover the flash mode and then initialize the flash in that mode itself, without resetting.
I would recommending working with the Linux SPI NOR subsystem first. That has more eyes looking at it so it would be easier to come up with a good solution. Then you can backport it to U-Boot.
In my experiments this helps being able to program /dev/mtd0 from linux with flashrom. If that is working in mainstream U-Boot on a Rock Pi 4B version 1.4 or later (with XTX flash) for the rest of people, then I must be testing wrong, what do I know?
Thanks. Have a nice day.
El Tue, Jul 26, 2022 at 02:39:09PM +0530, Pratyush Yadav deia:
Yes, this is indeed a chicken and egg problem of sorts. The octal mode soft reset I added is a hack that gets _some_ flashes working but not all. I see 3 possible ways to solve this:
But it was a hack that solved a problem. We still have hunger, war and disease, but we have some more flashes working. That's some good, isn't it?
- Encode soft reset type in device tree. Read DT to issue the correct type of reset. But if a flash supports multiple stateful modes like 4D-4D-4D and 8D-8D-8D, this might not work so well.
So must flash chips always be listed in dts ? Can some boards have a socket and users plug different flashes to it ? Might it then not work so well also ? My idea was try what you can with the controller you have because you know more what controller you have than what flash you have (until you can ask your flash who it is and what it looks like). This is only active when a nondefault kconfig is enabled, anyway.
- Do a hardware reset. This needs the RESET# line to be connected on the board and some way to toggle it. Does not work for boards that do not have this.
ACK. Unfortunately not in my case[1].
- Discover the mode the flash is in. The SFDP spec (JESD216D-01) does recommend a way to do this in section "4.5 Command Modes". This can let us find out which type of soft reset command the flash takes by reading SFDP. Of course, this needs the flash to implement the read SFDP command in all modes, which is not mandatory as per spec (at least as per xSPI spec (JESD251), which documents 8D-8D-8D flashes).
I think my XTX supports the soft reset according to the manual (commands 66 and 99), but the SFDP info does not include info about soft reset. I might misremember though.
There is no one size fits all solution that I can see, so I think we need to do all 3 to get full coverage of all cases. But start with the one that fixes your use case and is easiest for you. I would guess that is point 2.
My XT25F32B-S has no hardware reset pin. The manual[2] says so in a sentence, in page 49 (out of context) and the pinout is :
- Chip Select Input (CS#) - Data Output(SO) or I/O 1 (IO1) - Write Protect Input (WP#), or I/O2 (IO2) - Ground (VSS) - Data Input (SI), or I/O 0 (IO0) - Serial Clock Input (SCLK) - Hold Input (HOLD#) - Power Supply (VCC)
And of course the board does not have a line for the nonexistent pin, so no, the closest to hardware reset would be board poweroff. SI, SO, CS and SCLK are connected to a 40 pin connector though, so I can ground them or pull them up or something. But no use.
And all this does not even fix the problem of flashes that do not support 1S-1S-1S mode at all. There are some flashes out there that simply only support 8D-8D-8D mode. For those flashes, a reset would still put them in 8D-8D-8D mode. To support those you need to discover the flash mode and then initialize the flash in that mode itself, without resetting.
Well, maybe we can limit ourselves to solve solvable problems... That should keep us busy for a while...
I would recommending working with the Linux SPI NOR subsystem first. That has more eyes looking at it so it would be easier to come up with a good solution. Then you can backport it to U-Boot.
Thanks for the advice. Makes sense I guess. I'll see if I have the time and motivation.
[1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4b_plus_v16_sch_20200628.... [2] https://www.xtxtech.com/download/?AId=157
Hi Jagan,
This patchset goes into my todo list, but I'm not very good at SPI module, how do you think about this patchset?
I will happy to merge this if there is no regression for other SPI NOR device.
Thanks,
- Kever
On 2022/7/20 23:42, Xavier Drudis Ferran wrote:
XTX25F32B does not use octal mode and accepts soft reset, despite its SFDP tables. Soft reset at U-Boot exit seems to be required to write to /dev/mtd0 from flashrom in linux. Soft reset at U-Boot start seems to help booting from SPI (at least with the dts properties I'm using).
The first soft reset is done before the flash id is read and the fixups can be called, and v1 of this patch would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. This was since commit 5752d6ae8daa ("spi: spi-mem: add spi_mem_dtr_supports_op()") by Pratyush Yadav.
So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there.
Changed since v2:
- none (rebase)Changed since v1:
- Generalization. First soft reset with SNOR_PROTO_8_8_8_DTR stopped working since the improvement by Pratyush Yadav. Instead of trying 8_8_8_DTR always at first reset, and force 1_1_1 once XTX25F32B is detected (so, for last reset) do a generic loop for any chip trying protocols until one is supported and starting by the 8_8_8_DTR protocol (the one previously used). This leverages the fixed supports_op() to take into account controller and device.fixups can be called, and it would now fail in Rock Pi 4 because of unsupported operation if tried with SNOR_PROTO_8_8_8_DTR. So try a few modes until SNOR_PROTO_1_1_1 works and then remember the reset_proto. This tries to be useful for other boards, but I still don't know any other that needs it and what would work there.
Signed-off-by: Xavier Drudis Ferran xdrudis@tinet.cat
Cc: Jagan Teki jagan@amarulasolutions.com Cc: Vignesh R vigneshr@ti.com
drivers/mtd/spi/spi-nor-core.c | 98 ++++++++++++++++++++++++++++++---- include/linux/mtd/spi-nor.h | 5 ++ 2 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index 8a226a7af5..17f0cb51fb 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3575,6 +3575,18 @@ static struct spi_nor_fixups mt35xu512aba_fixups = { }; #endif /* CONFIG_SPI_FLASH_MT35XU */
+#ifdef CONFIG_SPI_FLASH_XTX +static void xtx25f32b_post_sfdp_fixup(struct spi_nor *nor,
struct spi_nor_flash_parameter *params)+{
- nor->flags |= SNOR_F_SOFT_RESET;
+}
+static struct spi_nor_fixups xtx25f32b_fixups = {
- .post_sfdp = xtx25f32b_post_sfdp_fixup,
+}; +#endif
- #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) /**
- spi_nor_macronix_octal_dtr_enable() - Enable octal DTR on Macronix flashes.
@@ -3733,6 +3745,53 @@ static int spi_nor_init(struct spi_nor *nor) }
#ifdef CONFIG_SPI_FLASH_SOFT_RESET +/**
- spi_nor_soft_reset_setup_op() - Initial setup of op for soft
- reset. Initializes nor->reset_proto iff needed.
- @nor: the spi_nor structure nor->reset_proto will be used or if
null, it'll be assigned the used protocol, from a few
protocols that get tried for device and controller
support.
- @opcode operation code for soft reset (or soft reset enable,
we currently assume they work the same in all systems)
- @op: pointer to operation struct to set up for reset or reset
enable.- */
+static void spi_nor_soft_reset_setup_op(struct spi_nor *nor, u16 opcode, struct spi_mem_op *op) +{
- enum spi_nor_protocol reset_proto;
- /**
* admitedly arbitrary list, to be improved if there's* new knowledge of what works in different systems*/- enum spi_nor_protocol reset_proto_candidates[] = {
SNOR_PROTO_8_8_8_DTR, SNOR_PROTO_1_1_1_DTR, SNOR_PROTO_8_8_8,SNOR_PROTO_4_4_4, SNOR_PROTO_2_2_2, SNOR_PROTO_1_1_1- };
- if (nor->reset_proto) {
*op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0),SPI_MEM_OP_NO_DUMMY,SPI_MEM_OP_NO_ADDR,SPI_MEM_OP_NO_DATA);spi_nor_setup_op(nor, op, nor->reset_proto);- } else {
for (int i = 0; i < ARRAY_SIZE(reset_proto_candidates) && !nor->reset_proto ; i++) {reset_proto = reset_proto_candidates[i];*op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0),SPI_MEM_OP_NO_DUMMY,SPI_MEM_OP_NO_ADDR,SPI_MEM_OP_NO_DATA);spi_nor_setup_op(nor, op, reset_proto);if (spi_mem_supports_op(nor->spi, op))nor->reset_proto = reset_proto;}- }
+}
- /**
- spi_nor_soft_reset() - perform the JEDEC Software Reset sequence
- @nor: the spi_nor structure
@@ -3756,11 +3815,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) #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,SPI_MEM_OP_NO_ADDR,SPI_MEM_OP_NO_DATA);- spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
- spi_nor_soft_reset_setup_op(nor, SPINOR_OP_SRSTEN, &op); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset enable failed: %d\n", ret);
@@ -3771,7 +3826,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) 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);
- spi_nor_setup_op(nor, &op, nor->reset_proto); ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset failed: %d\n", ret);
@@ -3789,18 +3844,34 @@ out: nor->cmd_ext_type = ext; return ret; } -#endif /* CONFIG_SPI_FLASH_SOFT_RESET */
+static bool flash_supports_proto(const struct flash_info *flash, enum spi_nor_protocol proto) +{
- switch (spi_nor_get_protocol_data_nbits(proto)) {
- case 8:
return flash->flags & (spi_nor_protocol_is_dtr(proto)? SPI_NOR_OCTAL_DTR_READ: SPI_NOR_OCTAL_READ);- case 4: return flash->flags & SPI_NOR_QUAD_READ;
- case 2: return flash->flags & SPI_NOR_DUAL_READ;
- default:
return 1;- }
+}
int spi_nor_remove(struct spi_nor *nor) { -#ifdef CONFIG_SPI_FLASH_SOFT_RESET
- if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ &&
- if (flash_supports_proto(nor->info, nor->reset_proto) && nor->flags & SNOR_F_SOFT_RESET) return spi_nor_soft_reset(nor);
-#endif
- return 0; }
+#else /* !CONFIG_SPI_FLASH_SOFT_RESET */ +int spi_nor_remove(struct spi_nor *nor) +{
- return 0;
+} +#endif /* CONFIG_SPI_FLASH_SOFT_RESET */
void spi_nor_set_fixups(struct spi_nor *nor) { @@ -3835,6 +3906,11 @@ void spi_nor_set_fixups(struct spi_nor *nor) #if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX) nor->fixups = ¯onix_octal_fixups; #endif /* SPI_FLASH_MACRONIX */
+#ifdef CONFIG_SPI_FLASH_XTX
- if (!strcmp(nor->info->name, "xt25f32b"))
nor->fixups = &xtx25f32b_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 2595bad9df..4fc81e7b8d 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -501,6 +501,8 @@ struct spi_flash {
- @read_proto: the SPI protocol for read operations
- @write_proto: the SPI protocol for write operations
- @reg_proto the SPI protocol for read_reg/write_reg/erase operations
- @reset_proto: The SPI protocol for soft reset to return to state expected
by OS before running the OS (at remove time) or at sf probe- @cmd_buf: used by the write_reg
- @cmd_ext_type: the command opcode extension for DTR mode.
- @fixups: flash-specific fixup hooks.
@@ -546,6 +548,9 @@ struct spi_nor { enum spi_nor_protocol read_proto; enum spi_nor_protocol write_proto; enum spi_nor_protocol reg_proto; +#ifdef CONFIG_SPI_FLASH_SOFT_RESET
- enum spi_nor_protocol reset_proto;
+#endif bool sst_write_second; u32 flags; u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE];
Trying to boot my Rock Pi 4B from its XTX SPI NOR Flash failed when my custom compiled TF-A had a load address of 0.
The same TF-A booted correctly from MMC.
Add a local variable to spi_mem_exec_op() to determine operation direction, instead of testing rx_buf or tx_buf for null value, so that a buffer at RAM address 0 is accepted.
This commit also cuts short a debug dump of the image loaded to show only the first 0x1000 and the last 0x100 bytes, and not swamping the serial log. When adding the #define DEBUG to the .c file one can change these limits at the same time if they don't fit.
Changed since v2:
- no changes
Changed since v1:
- no changes
Signed-off-by: Xavier Drudis Ferran xdrudis@tinet.cat
Cc: Jagan Teki jagan@amarulasolutions.com
--- drivers/spi/spi-mem.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index 9c1ede1b61..4dc90addb3 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -21,6 +21,8 @@ #include <spi.h> #include <spi-mem.h> #include <dm/device_compat.h> +#define DEBUG_DUMP_START_LENGTH 0x1000 +#define DEBUG_DUMP_END_LENGTH 0x100 #endif
#ifndef __UBOOT__ @@ -373,12 +375,21 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op) if (msg.actual_length != totalxferlen) return -EIO; #else + enum spi_mem_data_dir dir = SPI_MEM_NO_DATA;
if (op->data.nbytes) { - if (op->data.dir == SPI_MEM_DATA_IN) + dir = op->data.dir; + if (dir == SPI_MEM_DATA_IN) { rx_buf = op->data.buf.in; - else + } else { tx_buf = op->data.buf.out; + /** + * keep old behaviour, to assume SPI_MEM_DATA_OUT + * if ever data.nbytes!=0 but data.dir==SPI_MEM_NO_DATA + * (hopefully never) + */ + dir = SPI_MEM_DATA_OUT; + } }
op_len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes; @@ -410,7 +421,7 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op) /* 1st transfer: opcode + address + dummy cycles */ flag = SPI_XFER_BEGIN; /* Make sure to set END bit if no tx or rx data messages follow */ - if (!tx_buf && !rx_buf) + if (dir == SPI_MEM_NO_DATA) flag |= SPI_XFER_END;
ret = spi_xfer(slave, op_len * 8, op_buf, NULL, flag); @@ -418,7 +429,7 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op) return ret;
/* 2nd transfer: rx or tx data path */ - if (tx_buf || rx_buf) { + if (dir != SPI_MEM_NO_DATA) { ret = spi_xfer(slave, op->data.nbytes * 8, tx_buf, rx_buf, SPI_XFER_END); if (ret) @@ -430,10 +441,17 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op) for (i = 0; i < pos; i++) debug("%02x ", op_buf[i]); debug("| [%dB %s] ", - tx_buf || rx_buf ? op->data.nbytes : 0, - tx_buf || rx_buf ? (tx_buf ? "out" : "in") : "-"); - for (i = 0; i < op->data.nbytes; i++) - debug("%02x ", tx_buf ? tx_buf[i] : rx_buf[i]); + op->data.nbytes, + dir == SPI_MEM_DATA_IN ? "in" : (dir == SPI_MEM_DATA_OUT ? "out" : "-")); + for (i = 0; i < op->data.nbytes && i < DEBUG_DUMP_START_LENGTH ; i++) + debug("%02x ", dir == SPI_MEM_DATA_OUT ? tx_buf[i] : rx_buf[i]); + if (op->data.nbytes > DEBUG_DUMP_END_LENGTH && op->data.nbytes > DEBUG_DUMP_START_LENGTH && + i < op->data.nbytes - DEBUG_DUMP_END_LENGTH) { + debug(" ... "); + i = op->data.nbytes - DEBUG_DUMP_END_LENGTH; + } + for (; i < op->data.nbytes ; i++) + debug("%02x ", dir == SPI_MEM_DATA_OUT ? tx_buf[i] : rx_buf[i]); debug("[ret %d]\n", ret);
if (ret < 0)
participants (3)
-
Kever Yang -
Pratyush Yadav -
Xavier Drudis Ferran