On Fri, Sep 20, 2024 at 09:34:54AM +0200, Michal Simek wrote:
On 9/20/24 00:05, Tom Rini wrote:
On Wed, Sep 18, 2024 at 01:18:10PM +0200, Michal Simek wrote:
Hi Tom,
On 9/5/24 05:21, Venkatesh Yadav Abbarapu wrote:
This series adds support for Xilinx qspi parallel and stacked memeories.
In parallel mode, the current implementation assumes that a maximum of two flashes are connected. The QSPI controller splits the data evenly between both the flashes so, both the flashes that are connected in parallel mode should be identical. During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in nor->flags.
In stacked mode the current implementation assumes that a maximum of two flashes are connected and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical.
Spi-nor will pass on the appropriate flash select flag to low level driver, and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as each write operation results in writing both the flashes. For doubling the address space each operation is performed at addr/2 flash offset, where addr is the address specified by the user.
Similarly for read and erase operations it will read from both flashes, so size and offset are divided by 2 and send to flash.
Changes in v2:
- Fixed the compilation issues.
Changes in v3:
- Fixed the CI issues.
Changes in v4:
- Removed the dio,dummy_bytes variables from zynq_qspi driver.
- Fix the compilation issue by including the DM_SPI config.
Changes in v5:
- Fixed the issue reported by buildman.
Changes in v6:
- Fixed the issues reported while running the sandbox test cases.
Changes in v7:
- Fixed the issues reported while running these da850evm_defconfig, imx28_xea_defconfig configs.
- Fixed the issue when DM_SPI config is disabled.
- Fixed the issue while running the sandbox_noinst_defconfig with spl ./spl/u-boot-spl -d arch/sandbox/dts/test.dtb jedec_spi_nor spi.bin@0: has no valid 'reg' property (-12) jedec_spi_nor spi.bin@1: has no valid 'reg' property (-12) ### ERROR ### Please RESET the board ### Changes in v8:
- Fixed the compilation issue with imx28_xea_defconfig.
- Fixed the SPL size issue with the axm and taurus defconfigs.
- Rebased the patches on top of next branch.
Changes in v9:
- Updated the commit log why SPL_FIT is being enabled.
Changes in v10:
- Added the new config SPI_ADVANCE to fix the issue while enabling imx28_xea_defconfig.
Changes in v11:
- Removed the unused variable, corrected the type of variable and replaced memcpy with memmove.
Changes in v12:
- Fixed the compilation issue with mx6sabresd defconfig, as the binary size got exceeded.
Changes in v13:
- Fixed the compilation issue for imx28 by making bisectable.
- Disable the config SPI_ADVANCE by default.
- Rearranged the patch series order.
Ashok Reddy Soma (2): mtd: spi-nor: Add parallel memories support for read_sr and read_fsr mtd: spi-nor: Add parallel and stacked memories support in read_bar and write_bar
Venkatesh Yadav Abbarapu (6): config: mx6sabresd: Default don't enable the flash lock mtd: spi-nor: Add parallel and stacked memories support spi: spi-uclass: Read chipselect and restrict capabilities config: xilinx: Enable the SPI_ADVANCE config option spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver spi: zynq_qspi: Add parallel memories support in QSPI driver
configs/mx6sabresd_defconfig | 1 + configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynq_virt_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + drivers/mtd/spi/sandbox.c | 2 +- drivers/mtd/spi/spi-nor-core.c | 400 ++++++++++++++++++++--- drivers/spi/Kconfig | 6 + drivers/spi/altera_spi.c | 4 +- drivers/spi/atcspi200_spi.c | 2 +- drivers/spi/ath79_spi.c | 2 +- drivers/spi/atmel_spi.c | 6 +- drivers/spi/bcm63xx_hsspi.c | 42 +-- drivers/spi/bcm63xx_spi.c | 6 +- drivers/spi/bcmbca_hsspi.c | 34 +- drivers/spi/cf_spi.c | 6 +- drivers/spi/davinci_spi.c | 8 +- drivers/spi/fsl_dspi.c | 18 +- drivers/spi/fsl_espi.c | 4 +- drivers/spi/fsl_qspi.c | 4 +- drivers/spi/gxp_spi.c | 2 +- drivers/spi/mpc8xx_spi.c | 4 +- drivers/spi/mpc8xxx_spi.c | 10 +- drivers/spi/mscc_bb_spi.c | 4 +- drivers/spi/mxc_spi.c | 6 +- drivers/spi/npcm_fiu_spi.c | 14 +- drivers/spi/nxp_fspi.c | 2 +- drivers/spi/octeon_spi.c | 2 +- drivers/spi/omap3_spi.c | 4 +- drivers/spi/pic32_spi.c | 2 +- drivers/spi/rk_spi.c | 4 +- drivers/spi/rockchip_sfc.c | 2 +- drivers/spi/spi-aspeed-smc.c | 28 +- drivers/spi/spi-mxic.c | 6 +- drivers/spi/spi-qup.c | 4 +- drivers/spi/spi-sifive.c | 6 +- drivers/spi/spi-sn-f-ospi.c | 2 +- drivers/spi/spi-sunxi.c | 6 +- drivers/spi/spi-synquacer.c | 4 +- drivers/spi/spi-uclass.c | 34 +- drivers/spi/stm32_qspi.c | 2 +- drivers/spi/stm32_spi.c | 4 +- drivers/spi/ti_qspi.c | 14 +- drivers/spi/xilinx_spi.c | 6 +- drivers/spi/zynq_qspi.c | 121 ++++++- drivers/spi/zynq_spi.c | 6 +- drivers/spi/zynqmp_gqspi.c | 141 +++++++- include/linux/mtd/spi-nor.h | 12 + include/spi.h | 23 +- lib/acpi/acpi_device.c | 2 +- 50 files changed, 795 insertions(+), 231 deletions(-)
Acked-by: Michal Simek michal.simek@amd.com
Any comment about this series? It is around for a while. I pushed it to CI sometime ago and nothing has been reported. FYI: https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/22232
Tom: If there is any other comment can you please merge this to next to get more testing on other HW?
Fair point, and sorry for the delay on my own feedback here. The problem I see right now, and iot2050 is the platform in front of me in my logs, is that SPL is growing by 1344 bytes from this. Full U-Boot is as well, but that's a little more tolerable, if we can't avoid it. But we need to try and avoid that in SPL.
I played with it and pretty much some save can be saved if we use some ifs and one trick. I c&p it below. Especially the last one is something to discuss if it is acceptable solution. The aim is to get conditions to if (0) and get rid of that code by compiler itself.
This is fine, yeah.
And in connection to platform you mentioned. I tried to enable LTO and it looks like is saving a lot of space on this platform. Isn't it something to consider too?
I wasn't clear, sorry. That was just the only platform in my terminal with the build log that showed huge numbers of platforms growing in U-Boot, and growing in SPL, from this series.