* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
@ 2016-02-14 20:46 Jagan Teki
2016-02-16 19:47 ` Jagan Teki
` (3 more replies)
0 siblings, 4 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-14 20:46 UTC (permalink / raw)
To: u-boot
Compared to previous patch series this series adds spi-nor
core with spi-nor controller drivers are of "mtd uclass"
This is whole series for all spi-nor related changes, and while
series tested on spansion spi-nor chip.
Know issue:
- arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
Why this framework:
Some of the SPI device drivers at drivers/spi not a real
spi controllers, Unlike normal/generic SPI controllers they
operates only with SPI-NOR flash devices. these were technically
termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
The problem with these were resides at drivers/spi is entire
SPI layer becomes SPI-NOR flash oriented which is absolutely
a wrong indication where SPI layer getting effected more with
flash operations - So this SPI-NOR core will resolve this issue
by separating all SPI-NOR flash operations from spi layer and
creats a generic layer called SPI-NOR core which can be used to
interact SPI-NOR to SPI driver interface layer and the SPI-NOR
controller driver. The idea is taken from Linux spi-nor framework.
Before SPI-NOR:
-----------------------
cmd/sf.c
-----------------------
spi_flash.c
-----------------------
sf_probe.c
-----------------------
spi-uclass
-----------------------
spi drivers
-----------------------
SPI NOR chip
-----------------------
After SPI-NOR:
------------------------------
cmd/sf.c
------------------------------
spi-nor.c
-------------------------------
m25p80.c spi nor drivers
-------------------------------
spi-uclass SPI NOR chip
-------------------------------
spi drivers
-------------------------------
SPI NOR chip
-------------------------------
SPI-NOR with MTD:
------------------------------
cmd/sf.c
------------------------------
MTD core
------------------------------
spi-nor.c
-------------------------------
m25p80.c spi nor drivers
-------------------------------
spi-uclass SPI NOR chip
-------------------------------
spi drivers
-------------------------------
SPI NOR chip
-------------------------------
drivers/mtd/spi-nor/spi-nor.c: spi-nor core
drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
which is an interface layer b/w spi-nor core drivers/spi
drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
Changes for v6:
- Fixed git bisectable issues, with buildman.
- Fixed spi-nor compilation issues
- newly designed changes.
Changes for v5:
- newly designed changes
Testing:
$ git clone git://git.denx.de/u-boot-spi.git
$ cd u-boot-spi
$ git checkout -b spi-nor origin/spi-nor
Jagan Teki (76):
mtd: Add m25p80 driver
mtd: Add Kconfig entry for MTD_M25P80
mtd: Add SPI-NOR core support
doc: device-tree-bindings: jedec,spi-nor
mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
mtd: spi-nor: Add MTD support
mtd: spi-nor: Add spi_nor support in m25p80
mtd: spi-nor: Add dm spi-nor probing
mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
mtd: spi-nor: m25p80: Add spi_nor support for non-dm
sf: Rename erase_size to erasesize
sf: Use erasesize instead of sector_size
sf: Use uint64_t for flash->size
spi_flash: Use mtd_info operation for SPI-NOR
spi_flash: Use spi_flash_t instead of struct spi_flash
mtd: spi-nor: Move spi_read_then_write to spi layer
spi: Rename spi_read_then_write to spi_write_then_read
mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
mtd: spi-nor: Copy spl files from drivers/mtd/spi
mtd: spi-nor: spl: Follow ascending order of include headers
mtd: spi-nor: fsl_espi_spl: Use mtd_info
mtd: spi-nor: spi_spl_load: Use mtd_info
mtd: spi-nor: Add flash vendor Kconfig entries
arm: zynq: Kconfig: Select MTD uclass
arm: zynq: Kconfig: Drop DM_SPI_FLASH
defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
mtd: spi-nor: Copy sf_dataflash
mtd: dataflash: Remove unneeded spi data
mtd: dataflash: Move flash id detection into jedec_probe
mtd: dataflash: Fix add_dataflash return logic
mtd: dataflash: Add UCLASS_MTD support
mtd: dataflash: Use spi_write_then_read
mtd: dataflash: Drop sf_internal.h
mtd: dataflash: Minor cleanups
mtd: Rename sf_dataflash.c to mtd_dataflash.c
mtd: spi-nor: Add Kconfig entry for mtd_dataflash
mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
defconfig: ls1021aqds_qspi: Enable SPI-NOR
defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
mtd: spi-nor: Copy sandbox
mtd: spi-nor: sandbox: Use spi-nor header
mtd: spi-nor: Add SPI_NOR_SANBOX
sandbox: kconfig: Drop DM_SPI_FLASH
sandbox: kconfig: Select MTD uclass
defconfigs: sandbox: Enable SPI-NOR
mtd: sandbox: Use CONFIG_MTD_SPI_NOR
defconfigs: sandbox: Enable SPI_NOR_SANDBOX
spi_flash: Use spi_flash_t
mtd: spi-nor: Add CONFIG_SPI_NOR_MISC
config: Enable SPI-NOR framework
spi-nor: Use CONFIG_MTD_SPI_NOR
configs: Use CONFIG_MTD_SPI_NOR
configs: Use CONFIG_SPI_NOR_BAR
configs: spi-nor: Add new flash vendor configs
configs: Use CONFIG_SPI_NOR_MISC
spi: Drop mode_rx
spi: Drop SPI_RX_FAST
configs: Enable MTD uclass in missing configs
configs: Drop CONFIG_SPI_FLASH_MTD
uclass: Replace UCLASS_SPI_FLASH with UCLASS_MTD
uclass: Drop UCLASS_SPI_FLASH
configs: Use CONFIG_SPL_SPI_NOR_SUPPORT
configs: Enable CONFIG_SPL_MTD_SUPPORT
sf: Drop entire spi-flash framework
MAINTAINERS: Add myself as SPI NOR maintainer
configs: CONFIG_MTD_SPI_NOR_USE_4K_SECTORS
MAINTAINERS | 11 +-
Makefile | 2 +-
arch/Kconfig | 4 +-
arch/arm/Kconfig | 10 +-
arch/arm/mach-rockchip/Kconfig | 2 +-
arch/arm/mach-rockchip/rk3288-board-spl.c | 2 +-
arch/arm/mach-tegra/Kconfig | 2 +-
arch/x86/lib/mrccache.c | 3 +-
board/Arcturus/ucp1020/cmd_arc.c | 2 +-
board/Synology/common/cmd_syno.c | 2 +-
board/buffalo/lsxl/lsxl.c | 2 +-
board/congatec/cgtqmx6eval/cgtqmx6eval.c | 2 +-
board/davinci/da8xxevm/da850evm.c | 4 +-
board/davinci/ea20/ea20.c | 2 +-
board/renesas/sh7752evb/sh7752evb.c | 4 +-
board/renesas/sh7753evb/sh7753evb.c | 4 +-
board/renesas/sh7757lcr/sh7757lcr.c | 6 +-
board/siemens/taurus/taurus.c | 2 +-
cmd/sf.c | 38 +-
common/env_sf.c | 6 +-
common/splash_source.c | 4 +-
configs/B4420QDS_NAND_defconfig | 5 +-
configs/B4420QDS_SPIFLASH_defconfig | 5 +-
configs/B4420QDS_defconfig | 5 +-
configs/B4860QDS_NAND_defconfig | 5 +-
configs/B4860QDS_SECURE_BOOT_defconfig | 5 +-
configs/B4860QDS_SPIFLASH_defconfig | 5 +-
configs/B4860QDS_SRIO_PCIE_BOOT_defconfig | 5 +-
configs/B4860QDS_defconfig | 5 +-
configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 5 +-
configs/BSC9131RDB_NAND_defconfig | 5 +-
configs/BSC9131RDB_SPIFLASH_SYSCLK100_defconfig | 5 +-
configs/BSC9131RDB_SPIFLASH_defconfig | 5 +-
configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 5 +-
configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 5 +-
configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 5 +-
configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 5 +-
configs/BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig | 5 +-
configs/BSC9132QDS_NOR_DDRCLK100_defconfig | 5 +-
configs/BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig | 5 +-
configs/BSC9132QDS_NOR_DDRCLK133_defconfig | 5 +-
.../BSC9132QDS_SDCARD_DDRCLK100_SECURE_defconfig | 5 +-
configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig | 5 +-
.../BSC9132QDS_SDCARD_DDRCLK133_SECURE_defconfig | 5 +-
configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig | 5 +-
.../BSC9132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 5 +-
configs/BSC9132QDS_SPIFLASH_DDRCLK100_defconfig | 5 +-
.../BSC9132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 5 +-
configs/BSC9132QDS_SPIFLASH_DDRCLK133_defconfig | 5 +-
configs/C29XPCIE_NAND_defconfig | 7 +-
configs/C29XPCIE_NOR_SECBOOT_defconfig | 7 +-
configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig | 7 +-
configs/C29XPCIE_SPIFLASH_defconfig | 7 +-
configs/C29XPCIE_defconfig | 7 +-
configs/M52277EVB_defconfig | 5 +-
configs/M52277EVB_stmicro_defconfig | 5 +-
configs/M54418TWR_defconfig | 5 +-
configs/M54418TWR_nand_mii_defconfig | 5 +-
configs/M54418TWR_nand_rmii_defconfig | 5 +-
configs/M54418TWR_nand_rmii_lowfreq_defconfig | 5 +-
configs/M54418TWR_serial_mii_defconfig | 5 +-
configs/M54418TWR_serial_rmii_defconfig | 5 +-
configs/M54451EVB_defconfig | 5 +-
configs/M54451EVB_stmicro_defconfig | 5 +-
configs/M54455EVB_a66_defconfig | 5 +-
configs/M54455EVB_defconfig | 5 +-
configs/M54455EVB_i66_defconfig | 5 +-
configs/M54455EVB_intel_defconfig | 5 +-
configs/M54455EVB_stm33_defconfig | 5 +-
configs/MPC8536DS_36BIT_defconfig | 5 +-
configs/MPC8536DS_SDCARD_defconfig | 5 +-
configs/MPC8536DS_SPIFLASH_defconfig | 5 +-
configs/MPC8536DS_defconfig | 5 +-
configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PA_36BIT_NAND_defconfig | 5 +-
configs/P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PA_36BIT_NOR_defconfig | 5 +-
configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 5 +-
.../P1010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 5 +-
configs/P1010RDB-PA_NAND_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PA_NAND_defconfig | 5 +-
configs/P1010RDB-PA_NOR_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PA_NOR_defconfig | 5 +-
configs/P1010RDB-PA_SDCARD_defconfig | 5 +-
configs/P1010RDB-PA_SPIFLASH_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PA_SPIFLASH_defconfig | 5 +-
configs/P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PB_36BIT_NAND_defconfig | 5 +-
configs/P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PB_36BIT_NOR_defconfig | 5 +-
configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 5 +-
.../P1010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 5 +-
configs/P1010RDB-PB_NAND_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PB_NAND_defconfig | 5 +-
configs/P1010RDB-PB_NOR_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PB_NOR_defconfig | 5 +-
configs/P1010RDB-PB_SDCARD_defconfig | 5 +-
configs/P1010RDB-PB_SPIFLASH_SECBOOT_defconfig | 5 +-
configs/P1010RDB-PB_SPIFLASH_defconfig | 5 +-
configs/P1020RDB-PC_36BIT_NAND_defconfig | 5 +-
configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 5 +-
configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 5 +-
configs/P1020RDB-PC_36BIT_defconfig | 5 +-
configs/P1020RDB-PC_NAND_defconfig | 5 +-
configs/P1020RDB-PC_SDCARD_defconfig | 5 +-
configs/P1020RDB-PC_SPIFLASH_defconfig | 5 +-
configs/P1020RDB-PC_defconfig | 5 +-
configs/P1020RDB-PD_NAND_defconfig | 5 +-
configs/P1020RDB-PD_SDCARD_defconfig | 5 +-
configs/P1020RDB-PD_SPIFLASH_defconfig | 5 +-
configs/P1020RDB-PD_defconfig | 5 +-
configs/P1021RDB-PC_36BIT_NAND_defconfig | 5 +-
configs/P1021RDB-PC_36BIT_SDCARD_defconfig | 5 +-
configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig | 5 +-
configs/P1021RDB-PC_36BIT_defconfig | 5 +-
configs/P1021RDB-PC_NAND_defconfig | 5 +-
configs/P1021RDB-PC_SDCARD_defconfig | 5 +-
configs/P1021RDB-PC_SPIFLASH_defconfig | 5 +-
configs/P1021RDB-PC_defconfig | 5 +-
configs/P1022DS_36BIT_NAND_defconfig | 5 +-
configs/P1022DS_36BIT_SDCARD_defconfig | 5 +-
configs/P1022DS_36BIT_SPIFLASH_defconfig | 5 +-
configs/P1022DS_36BIT_defconfig | 5 +-
configs/P1022DS_NAND_defconfig | 5 +-
configs/P1022DS_SDCARD_defconfig | 5 +-
configs/P1022DS_SPIFLASH_defconfig | 5 +-
configs/P1022DS_defconfig | 5 +-
configs/P1024RDB_36BIT_defconfig | 5 +-
configs/P1024RDB_NAND_defconfig | 5 +-
configs/P1024RDB_SDCARD_defconfig | 5 +-
configs/P1024RDB_SPIFLASH_defconfig | 5 +-
configs/P1024RDB_defconfig | 5 +-
configs/P1025RDB_36BIT_defconfig | 5 +-
configs/P1025RDB_NAND_defconfig | 5 +-
configs/P1025RDB_SDCARD_defconfig | 5 +-
configs/P1025RDB_SPIFLASH_defconfig | 5 +-
configs/P1025RDB_defconfig | 5 +-
configs/P2020RDB-PC_36BIT_NAND_defconfig | 5 +-
configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 5 +-
configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 5 +-
configs/P2020RDB-PC_36BIT_defconfig | 5 +-
configs/P2020RDB-PC_NAND_defconfig | 5 +-
configs/P2020RDB-PC_SDCARD_defconfig | 5 +-
configs/P2020RDB-PC_SPIFLASH_defconfig | 5 +-
configs/P2020RDB-PC_defconfig | 5 +-
configs/P2041RDB_NAND_defconfig | 5 +-
configs/P2041RDB_SDCARD_defconfig | 5 +-
configs/P2041RDB_SECURE_BOOT_defconfig | 5 +-
configs/P2041RDB_SPIFLASH_defconfig | 5 +-
configs/P2041RDB_SRIO_PCIE_BOOT_defconfig | 5 +-
configs/P2041RDB_defconfig | 5 +-
configs/P3041DS_NAND_SECURE_BOOT_defconfig | 5 +-
configs/P3041DS_NAND_defconfig | 5 +-
configs/P3041DS_SDCARD_defconfig | 5 +-
configs/P3041DS_SECURE_BOOT_defconfig | 5 +-
configs/P3041DS_SPIFLASH_defconfig | 5 +-
configs/P3041DS_SRIO_PCIE_BOOT_defconfig | 5 +-
configs/P3041DS_defconfig | 5 +-
configs/P4080DS_SDCARD_defconfig | 5 +-
configs/P4080DS_SECURE_BOOT_defconfig | 5 +-
configs/P4080DS_SPIFLASH_defconfig | 5 +-
configs/P4080DS_SRIO_PCIE_BOOT_defconfig | 5 +-
configs/P4080DS_defconfig | 5 +-
configs/P5020DS_NAND_SECURE_BOOT_defconfig | 5 +-
configs/P5020DS_NAND_defconfig | 5 +-
configs/P5020DS_SDCARD_defconfig | 5 +-
configs/P5020DS_SECURE_BOOT_defconfig | 5 +-
configs/P5020DS_SPIFLASH_defconfig | 5 +-
configs/P5020DS_SRIO_PCIE_BOOT_defconfig | 5 +-
configs/P5020DS_defconfig | 5 +-
configs/P5040DS_NAND_SECURE_BOOT_defconfig | 5 +-
configs/P5040DS_NAND_defconfig | 5 +-
configs/P5040DS_SDCARD_defconfig | 5 +-
configs/P5040DS_SECURE_BOOT_defconfig | 5 +-
configs/P5040DS_SPIFLASH_defconfig | 5 +-
configs/P5040DS_defconfig | 5 +-
configs/T1023RDB_NAND_defconfig | 5 +-
configs/T1023RDB_SDCARD_defconfig | 5 +-
configs/T1023RDB_SECURE_BOOT_defconfig | 5 +-
configs/T1023RDB_SPIFLASH_defconfig | 5 +-
configs/T1023RDB_defconfig | 5 +-
configs/T1024QDS_DDR4_SECURE_BOOT_defconfig | 9 +-
configs/T1024QDS_DDR4_defconfig | 9 +-
configs/T1024QDS_NAND_defconfig | 9 +-
configs/T1024QDS_SDCARD_defconfig | 9 +-
configs/T1024QDS_SECURE_BOOT_defconfig | 9 +-
configs/T1024QDS_SPIFLASH_defconfig | 9 +-
configs/T1024QDS_defconfig | 9 +-
configs/T1024RDB_NAND_defconfig | 5 +-
configs/T1024RDB_SDCARD_defconfig | 5 +-
configs/T1024RDB_SECURE_BOOT_defconfig | 5 +-
configs/T1024RDB_SPIFLASH_defconfig | 5 +-
configs/T1024RDB_defconfig | 5 +-
configs/T1040D4RDB_NAND_defconfig | 5 +-
configs/T1040D4RDB_SDCARD_defconfig | 5 +-
configs/T1040D4RDB_SECURE_BOOT_defconfig | 5 +-
configs/T1040D4RDB_SPIFLASH_defconfig | 5 +-
configs/T1040D4RDB_defconfig | 5 +-
configs/T1040QDS_DDR4_defconfig | 9 +-
configs/T1040QDS_SECURE_BOOT_defconfig | 9 +-
configs/T1040QDS_defconfig | 9 +-
configs/T1040RDB_NAND_defconfig | 5 +-
configs/T1040RDB_SDCARD_defconfig | 5 +-
configs/T1040RDB_SECURE_BOOT_defconfig | 5 +-
configs/T1040RDB_SPIFLASH_defconfig | 5 +-
configs/T1040RDB_defconfig | 5 +-
configs/T1042D4RDB_NAND_defconfig | 5 +-
configs/T1042D4RDB_SDCARD_defconfig | 5 +-
configs/T1042D4RDB_SECURE_BOOT_defconfig | 5 +-
configs/T1042D4RDB_SPIFLASH_defconfig | 5 +-
configs/T1042D4RDB_defconfig | 5 +-
configs/T1042RDB_PI_NAND_defconfig | 5 +-
configs/T1042RDB_PI_SDCARD_defconfig | 5 +-
configs/T1042RDB_PI_SPIFLASH_defconfig | 5 +-
configs/T1042RDB_PI_defconfig | 5 +-
configs/T1042RDB_SECURE_BOOT_defconfig | 5 +-
configs/T1042RDB_defconfig | 5 +-
configs/T2080QDS_NAND_defconfig | 9 +-
configs/T2080QDS_SDCARD_defconfig | 9 +-
configs/T2080QDS_SECURE_BOOT_defconfig | 9 +-
configs/T2080QDS_SPIFLASH_defconfig | 9 +-
configs/T2080QDS_SRIO_PCIE_BOOT_defconfig | 9 +-
configs/T2080QDS_defconfig | 9 +-
configs/T2080RDB_NAND_defconfig | 5 +-
configs/T2080RDB_SDCARD_defconfig | 5 +-
configs/T2080RDB_SECURE_BOOT_defconfig | 5 +-
configs/T2080RDB_SPIFLASH_defconfig | 5 +-
configs/T2080RDB_SRIO_PCIE_BOOT_defconfig | 5 +-
configs/T2080RDB_defconfig | 5 +-
configs/T2081QDS_NAND_defconfig | 9 +-
configs/T2081QDS_SDCARD_defconfig | 9 +-
configs/T2081QDS_SPIFLASH_defconfig | 9 +-
configs/T2081QDS_SRIO_PCIE_BOOT_defconfig | 9 +-
configs/T2081QDS_defconfig | 9 +-
configs/T4160QDS_NAND_defconfig | 5 +-
configs/T4160QDS_SDCARD_defconfig | 5 +-
configs/T4160QDS_SECURE_BOOT_defconfig | 5 +-
configs/T4160QDS_defconfig | 5 +-
configs/T4160RDB_defconfig | 5 +-
configs/T4240QDS_NAND_defconfig | 5 +-
configs/T4240QDS_SDCARD_defconfig | 5 +-
configs/T4240QDS_SECURE_BOOT_defconfig | 5 +-
configs/T4240QDS_SRIO_PCIE_BOOT_defconfig | 5 +-
configs/T4240QDS_defconfig | 5 +-
configs/T4240RDB_SDCARD_defconfig | 5 +-
configs/T4240RDB_defconfig | 5 +-
configs/UCP1020_SPIFLASH_defconfig | 9 +-
configs/UCP1020_defconfig | 9 +-
configs/alt_defconfig | 7 +-
configs/am335x_boneblack_defconfig | 5 +-
configs/am335x_boneblack_vboot_defconfig | 5 +-
configs/am335x_evm_defconfig | 5 +-
configs/am335x_evm_nor_defconfig | 5 +-
configs/am335x_evm_norboot_defconfig | 5 +-
configs/am335x_evm_spiboot_defconfig | 5 +-
configs/am335x_evm_usbspl_defconfig | 5 +-
configs/am335x_gp_evm_defconfig | 5 +-
configs/am437x_gp_evm_defconfig | 5 +-
configs/am437x_sk_evm_defconfig | 9 +-
configs/am43xx_evm_defconfig | 7 +-
configs/am43xx_evm_ethboot_defconfig | 5 +-
configs/am43xx_evm_qspiboot_defconfig | 5 +-
configs/am43xx_evm_usbhost_boot_defconfig | 5 +-
configs/am57xx_evm_defconfig | 5 +-
configs/aristainetos2_defconfig | 5 +-
configs/aristainetos2b_defconfig | 5 +-
configs/aristainetos_defconfig | 5 +-
configs/at91sam9n12ek_mmc_defconfig | 5 +-
configs/at91sam9n12ek_nandflash_defconfig | 5 +-
configs/at91sam9n12ek_spiflash_defconfig | 5 +-
configs/at91sam9x5ek_dataflash_defconfig | 5 +-
configs/at91sam9x5ek_mmc_defconfig | 5 +-
configs/at91sam9x5ek_nandflash_defconfig | 5 +-
configs/at91sam9x5ek_spiflash_defconfig | 5 +-
configs/atngw100_defconfig | 5 +-
configs/atngw100mkii_defconfig | 5 +-
configs/axm_defconfig | 5 +-
configs/bayleybay_defconfig | 9 +-
configs/beaver_defconfig | 5 +-
configs/bf518f-ezbrd_defconfig | 7 +-
configs/bf525-ucr2_defconfig | 5 +-
configs/bf526-ezbrd_defconfig | 5 +-
configs/bf527-ad7160-eval_defconfig | 5 +-
configs/bf527-ezkit-v2_defconfig | 5 +-
configs/bf527-ezkit_defconfig | 5 +-
configs/bf527-sdp_defconfig | 16 +-
configs/bf537-minotaur_defconfig | 5 +-
configs/bf537-pnav_defconfig | 5 +-
configs/bf537-srv1_defconfig | 5 +-
configs/bf537-stamp_defconfig | 16 +-
configs/bf548-ezkit_defconfig | 5 +-
configs/bf561-acvilon_defconfig | 5 +-
configs/bf609-ezkit_defconfig | 16 +-
configs/bg0900_defconfig | 7 +-
configs/birdland_bav335a_defconfig | 5 +-
configs/birdland_bav335b_defconfig | 5 +-
configs/blackstamp_defconfig | 5 +-
configs/blackvme_defconfig | 5 +-
configs/br4_defconfig | 5 +-
configs/cardhu_defconfig | 5 +-
configs/chromebook_link_defconfig | 9 +-
configs/chromebox_panther_defconfig | 9 +-
configs/clearfog_defconfig | 3 +-
configs/cm_fx6_defconfig | 17 +-
.../controlcenterd_36BIT_SDCARD_DEVELOP_defconfig | 5 +-
configs/controlcenterd_36BIT_SDCARD_defconfig | 5 +-
configs/coreboot-x86_defconfig | 9 +-
configs/crownbay_defconfig | 11 +-
configs/d2net_v2_defconfig | 5 +-
configs/da850_am18xxevm_defconfig | 7 +-
configs/da850evm_defconfig | 7 +-
configs/da850evm_direct_nor_defconfig | 7 +-
configs/dalmore_defconfig | 5 +-
configs/db-88f6820-gp_defconfig | 7 +-
configs/db-mv784mp-gp_defconfig | 7 +-
configs/dra72_evm_defconfig | 9 +-
configs/dra74_evm_defconfig | 9 +-
configs/dra7xx_evm_defconfig | 7 +-
configs/dra7xx_evm_qspiboot_defconfig | 5 +-
configs/dra7xx_evm_uart3_defconfig | 5 +-
configs/draco_defconfig | 5 +-
configs/dreamplug_defconfig | 5 +-
configs/ds414_defconfig | 7 +-
configs/e2220-1170_defconfig | 5 +-
configs/ea20_defconfig | 5 +-
configs/ethernut5_defconfig | 5 +-
configs/galileo_defconfig | 9 +-
configs/gose_defconfig | 7 +-
configs/gplugd_defconfig | 7 +-
configs/inetspace_v2_defconfig | 5 +-
configs/ip04_defconfig | 7 +-
configs/jetson-tk1_defconfig | 5 +-
configs/k2e_evm_defconfig | 5 +-
configs/k2g_evm_defconfig | 5 +-
configs/k2hk_evm_defconfig | 5 +-
configs/k2l_evm_defconfig | 5 +-
configs/km_kirkwood_128m16_defconfig | 5 +-
configs/km_kirkwood_defconfig | 5 +-
configs/km_kirkwood_pci_defconfig | 5 +-
configs/kmcoge4_defconfig | 7 +-
configs/kmcoge5un_defconfig | 5 +-
configs/kmlion1_defconfig | 7 +-
configs/kmnusa_defconfig | 5 +-
configs/kmsugp1_defconfig | 5 +-
configs/kmsuv31_defconfig | 5 +-
configs/koelsch_defconfig | 7 +-
configs/lager_defconfig | 7 +-
configs/ls1021aqds_qspi_defconfig | 7 +-
configs/ls1021atwr_qspi_defconfig | 8 +-
configs/ls1021atwr_sdcard_qspi_defconfig | 7 +-
configs/ls1043aqds_defconfig | 3 +-
configs/ls1043aqds_lpuart_defconfig | 3 +-
configs/ls1043aqds_nand_defconfig | 3 +-
configs/ls1043aqds_nor_ddr3_defconfig | 3 +-
configs/ls1043aqds_qspi_defconfig | 3 +-
configs/ls1043aqds_sdcard_ifc_defconfig | 3 +-
configs/ls1043aqds_sdcard_qspi_defconfig | 3 +-
configs/ls1043ardb_SECURE_BOOT_defconfig | 3 +-
configs/ls1043ardb_defconfig | 3 +-
configs/ls1043ardb_nand_defconfig | 3 +-
configs/ls1043ardb_sdcard_defconfig | 3 +-
configs/ls2080aqds_defconfig | 2 +-
configs/ls2080ardb_defconfig | 2 +-
configs/ls2085aqds_defconfig | 2 +-
configs/ls2085ardb_defconfig | 2 +-
configs/lschlv2_defconfig | 5 +-
configs/lsxhl_defconfig | 5 +-
configs/m28evk_defconfig | 5 +-
configs/marsboard_defconfig | 5 +-
configs/maxbcm_defconfig | 11 +-
configs/mgcoge3un_defconfig | 5 +-
configs/minnowmax_defconfig | 11 +-
configs/mx28evk_auart_console_defconfig | 5 +-
configs/mx28evk_defconfig | 5 +-
configs/mx28evk_nand_defconfig | 5 +-
configs/mx28evk_spi_defconfig | 5 +-
configs/mx6dlsabreauto_defconfig | 5 +-
configs/mx6dlsabresd_defconfig | 5 +-
configs/mx6qpsabreauto_defconfig | 5 +-
configs/mx6qsabreauto_defconfig | 5 +-
configs/mx6qsabrelite_defconfig | 5 +-
configs/mx6qsabresd_defconfig | 5 +-
configs/mx6sabresd_spl_defconfig | 5 +-
configs/mx6slevk_defconfig | 5 +-
configs/mx6slevk_spinor_defconfig | 5 +-
configs/mx6slevk_spl_defconfig | 5 +-
configs/mx6sxsabreauto_defconfig | 7 +-
configs/mx6sxsabresd_defconfig | 5 +-
configs/mx6sxsabresd_spl_defconfig | 3 +-
configs/net2big_v2_defconfig | 5 +-
configs/netspace_lite_v2_defconfig | 5 +-
configs/netspace_max_v2_defconfig | 5 +-
configs/netspace_mini_v2_defconfig | 5 +-
configs/netspace_v2_defconfig | 5 +-
configs/nitrogen6dl2g_defconfig | 5 +-
configs/nitrogen6dl_defconfig | 5 +-
configs/nitrogen6q2g_defconfig | 5 +-
configs/nitrogen6q_defconfig | 5 +-
configs/nitrogen6s1g_defconfig | 5 +-
configs/nitrogen6s_defconfig | 5 +-
configs/nyan-big_defconfig | 5 +-
configs/omapl138_lcdk_defconfig | 7 +-
configs/ot1200_defconfig | 11 +-
configs/ot1200_spl_defconfig | 11 +-
configs/p2371-0000_defconfig | 5 +-
configs/p2371-2180_defconfig | 5 +-
configs/p2571_defconfig | 5 +-
configs/pcm051_rev1_defconfig | 5 +-
configs/pcm051_rev3_defconfig | 5 +-
configs/peach-pi_defconfig | 7 +-
configs/peach-pit_defconfig | 7 +-
configs/porter_defconfig | 7 +-
configs/portl2_defconfig | 5 +-
configs/pr1_defconfig | 5 +-
configs/pxm2_defconfig | 5 +-
configs/qemu-x86_defconfig | 9 +-
configs/rastaban_defconfig | 5 +-
configs/riotboard_defconfig | 5 +-
configs/rut_defconfig | 5 +-
configs/sama5d2_xplained_mmc_defconfig | 3 +-
configs/sama5d2_xplained_spiflash_defconfig | 3 +-
configs/sama5d3xek_mmc_defconfig | 5 +-
configs/sama5d3xek_nandflash_defconfig | 5 +-
configs/sama5d3xek_spiflash_defconfig | 5 +-
configs/sama5d4_xplained_mmc_defconfig | 5 +-
configs/sama5d4_xplained_nandflash_defconfig | 5 +-
configs/sama5d4_xplained_spiflash_defconfig | 5 +-
configs/sama5d4ek_mmc_defconfig | 5 +-
configs/sama5d4ek_nandflash_defconfig | 5 +-
configs/sama5d4ek_spiflash_defconfig | 5 +-
configs/sandbox_defconfig | 19 +-
configs/sh7752evb_defconfig | 7 +-
configs/sh7753evb_defconfig | 7 +-
configs/sh7757lcr_defconfig | 5 +-
configs/silk_defconfig | 7 +-
configs/smdk5250_defconfig | 7 +-
configs/smdk5420_defconfig | 7 +-
configs/snow_defconfig | 7 +-
configs/socfpga_arria5_defconfig | 9 +-
configs/socfpga_cyclone5_defconfig | 9 +-
configs/socfpga_sockit_defconfig | 9 +-
configs/socfpga_socrates_defconfig | 7 +-
configs/socfpga_sr1500_defconfig | 5 +-
configs/spring_defconfig | 7 +-
configs/stout_defconfig | 7 +-
configs/stv0991_defconfig | 4 +-
configs/taurus_defconfig | 5 +-
configs/tec-ng_defconfig | 5 +-
configs/theadorable_debug_defconfig | 7 +-
configs/theadorable_defconfig | 7 +-
configs/thuban_defconfig | 5 +-
configs/tqma6q_mba6_mmc_defconfig | 5 +-
configs/tqma6q_mba6_spi_defconfig | 5 +-
configs/tqma6s_mba6_mmc_defconfig | 5 +-
configs/tqma6s_mba6_spi_defconfig | 5 +-
configs/trimslice_defconfig | 5 +-
configs/tseries_spi_defconfig | 5 +-
configs/venice2_defconfig | 5 +-
configs/vf610twr_defconfig | 3 +-
configs/vf610twr_nand_defconfig | 3 +-
configs/zynq_microzed_defconfig | 9 +-
configs/zynq_zc702_defconfig | 11 +-
configs/zynq_zc706_defconfig | 11 +-
configs/zynq_zc770_xm010_defconfig | 13 +-
configs/zynq_zc770_xm013_defconfig | 5 +-
configs/zynq_zed_defconfig | 11 +-
configs/zynq_zybo_defconfig | 5 +-
doc/SPI/README.ti_qspi_dra_test | 2 +-
doc/device-tree-bindings/mtd/jedec,spi-nor.txt | 78 ++
doc/mtd/spi-nor.txt | 81 ++
drivers/Makefile | 2 +-
drivers/dfu/dfu_sf.c | 12 +-
drivers/mtd/Kconfig | 2 +-
drivers/mtd/spi-nor/Kconfig | 125 +++
drivers/mtd/spi-nor/Makefile | 20 +
drivers/mtd/{spi => spi-nor}/fsl_espi_spl.c | 6 +-
drivers/mtd/spi-nor/m25p80.c | 332 ++++++
.../sf_dataflash.c => spi-nor/mtd_dataflash.c} | 429 ++++---
drivers/mtd/{spi => spi-nor}/sandbox.c | 51 +-
drivers/mtd/spi-nor/spi-nor-ids.c | 283 +++++
drivers/mtd/spi-nor/spi-nor-probe.c | 52 +
drivers/mtd/spi-nor/spi-nor.c | 1141 +++++++++++++++++++
drivers/mtd/{spi => spi-nor}/spi_spl_load.c | 7 +-
drivers/mtd/spi/Kconfig | 131 ---
drivers/mtd/spi/Makefile | 18 -
drivers/mtd/spi/sf-uclass.c | 103 --
drivers/mtd/spi/sf.c | 58 -
drivers/mtd/spi/sf_internal.h | 243 ----
drivers/mtd/spi/sf_mtd.c | 104 --
drivers/mtd/spi/sf_params.c | 146 ---
drivers/mtd/spi/sf_probe.c | 181 ---
drivers/mtd/spi/spi_flash.c | 1185 --------------------
drivers/net/fm/fm.c | 2 +-
drivers/net/phy/cortina.c | 2 +-
drivers/spi/fsl_qspi.c | 18 +-
drivers/spi/ich.c | 6 +-
drivers/spi/spi-uclass.c | 35 +-
drivers/spi/spi.c | 24 +
drivers/spi/ti_qspi.c | 6 +-
examples/standalone/Makefile | 2 +-
include/configs/MPC8536DS.h | 2 +-
include/configs/P1010RDB.h | 3 +-
include/configs/P1022DS.h | 3 +-
include/configs/T102xQDS.h | 5 +-
include/configs/T102xRDB.h | 5 +-
include/configs/T104xRDB.h | 5 +-
include/configs/T208xQDS.h | 7 +-
include/configs/T208xRDB.h | 7 +-
include/configs/UCP1020.h | 4 +-
include/configs/am335x_evm.h | 3 +-
include/configs/am43xx_evm.h | 2 +-
include/configs/aristainetos-common.h | 1 -
include/configs/at91sam9n12ek.h | 3 +-
include/configs/at91sam9x5ek.h | 3 +-
include/configs/bav335x.h | 3 +-
include/configs/bfin_adi_common.h | 2 +-
include/configs/cgtqmx6eval.h | 10 +-
include/configs/chromebook_jerry.h | 5 +-
include/configs/clearfog.h | 5 +-
include/configs/cm_fx6.h | 3 +-
include/configs/cm_t43.h | 9 +-
include/configs/da850evm.h | 6 +-
include/configs/db-88f6820-gp.h | 3 +-
include/configs/db-mv784mp-gp.h | 3 +-
include/configs/dra7xx_evm.h | 5 +-
include/configs/dreamplug.h | 2 +-
include/configs/ds414.h | 3 +-
include/configs/exynos5-common.h | 2 +-
include/configs/gw_ventana.h | 13 +-
include/configs/km/kmp204x-common.h | 2 +-
include/configs/ls1021aqds.h | 2 -
include/configs/ls1021atwr.h | 1 -
include/configs/ls1043a_common.h | 8 +-
include/configs/ls1043aqds.h | 2 +-
include/configs/ls2080aqds.h | 3 +-
include/configs/ls2080ardb.h | 5 +-
include/configs/lsxl.h | 2 +-
include/configs/maxbcm.h | 3 +-
include/configs/mx6ul_14x14_evk.h | 7 +-
include/configs/mx7dsabresd.h | 7 +-
include/configs/omapl138_lcdk.h | 3 +-
include/configs/ot1200.h | 3 +-
include/configs/p1_p2_rdb_pc.h | 5 +-
include/configs/pcm051.h | 3 +-
include/configs/pcm052.h | 3 +-
include/configs/rk3036_common.h | 4 +-
include/configs/rk3288_common.h | 2 +-
include/configs/sama5d2_xplained.h | 5 +-
include/configs/sama5d3xek.h | 3 +-
include/configs/sama5d4_xplained.h | 3 +-
include/configs/sama5d4ek.h | 3 +-
include/configs/siemens-am33x-common.h | 3 +-
include/configs/socfpga_common.h | 8 +-
include/configs/taurus.h | 3 +-
include/configs/tegra-common-usb-gadget.h | 2 +-
include/configs/theadorable.h | 3 +-
include/configs/ti_armv7_keystone2.h | 3 +-
include/configs/tseries.h | 3 +-
include/configs/zynq-common.h | 6 +-
include/dm/uclass-id.h | 1 -
include/linux/err.h | 5 +
include/linux/mtd/spi-nor.h | 253 +++++
include/spi.h | 33 +-
include/spi_flash.h | 233 +---
566 files changed, 4437 insertions(+), 3863 deletions(-)
create mode 100644 doc/device-tree-bindings/mtd/jedec,spi-nor.txt
create mode 100644 doc/mtd/spi-nor.txt
create mode 100644 drivers/mtd/spi-nor/Kconfig
create mode 100644 drivers/mtd/spi-nor/Makefile
rename drivers/mtd/{spi => spi-nor}/fsl_espi_spl.c (97%)
create mode 100644 drivers/mtd/spi-nor/m25p80.c
rename drivers/mtd/{spi/sf_dataflash.c => spi-nor/mtd_dataflash.c} (61%)
rename drivers/mtd/{spi => spi-nor}/sandbox.c (95%)
create mode 100644 drivers/mtd/spi-nor/spi-nor-ids.c
create mode 100644 drivers/mtd/spi-nor/spi-nor-probe.c
create mode 100644 drivers/mtd/spi-nor/spi-nor.c
rename drivers/mtd/{spi => spi-nor}/spi_spl_load.c (94%)
delete mode 100644 drivers/mtd/spi/Kconfig
delete mode 100644 drivers/mtd/spi/Makefile
delete mode 100644 drivers/mtd/spi/sf-uclass.c
delete mode 100644 drivers/mtd/spi/sf.c
delete mode 100644 drivers/mtd/spi/sf_internal.h
delete mode 100644 drivers/mtd/spi/sf_mtd.c
delete mode 100644 drivers/mtd/spi/sf_params.c
delete mode 100644 drivers/mtd/spi/sf_probe.c
delete mode 100644 drivers/mtd/spi/spi_flash.c
create mode 100644 include/linux/mtd/spi-nor.h
--
1.9.1
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-14 20:46 [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support Jagan Teki
@ 2016-02-16 19:47 ` Jagan Teki
2016-02-17 5:22 ` Bin Meng
2016-02-17 19:00 ` Simon Glass
` (2 subsequent siblings)
3 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-16 19:47 UTC (permalink / raw)
To: u-boot
On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
> Compared to previous patch series this series adds spi-nor
> core with spi-nor controller drivers are of "mtd uclass"
>
> This is whole series for all spi-nor related changes, and while
> series tested on spansion spi-nor chip.
>
> Know issue:
> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>
> Why this framework:
>
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>
> The problem with these were resides at drivers/spi is entire
> SPI layer becomes SPI-NOR flash oriented which is absolutely
> a wrong indication where SPI layer getting effected more with
> flash operations - So this SPI-NOR core will resolve this issue
> by separating all SPI-NOR flash operations from spi layer and
> creats a generic layer called SPI-NOR core which can be used to
> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> controller driver. The idea is taken from Linux spi-nor framework.
>
> Before SPI-NOR:
>
> -----------------------
> cmd/sf.c
> -----------------------
> spi_flash.c
> -----------------------
> sf_probe.c
> -----------------------
> spi-uclass
> -----------------------
> spi drivers
> -----------------------
> SPI NOR chip
> -----------------------
>
> After SPI-NOR:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> SPI-NOR with MTD:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> MTD core
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> which is an interface layer b/w spi-nor core drivers/spi
> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
Tested both DM and non-DM models
Tested-by: Jagan Teki <jteki@openedev.com>
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-16 19:47 ` Jagan Teki
@ 2016-02-17 5:22 ` Bin Meng
2016-02-17 5:27 ` Bin Meng
2016-02-17 7:37 ` Jagan Teki
0 siblings, 2 replies; 47+ messages in thread
From: Bin Meng @ 2016-02-17 5:22 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> -----------------------
>> cmd/sf.c
>> -----------------------
>> spi_flash.c
>> -----------------------
>> sf_probe.c
>> -----------------------
>> spi-uclass
>> -----------------------
>> spi drivers
>> -----------------------
>> SPI NOR chip
>> -----------------------
>>
>> After SPI-NOR:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> SPI-NOR with MTD:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> MTD core
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>
> Tested both DM and non-DM models
>
> Tested-by: Jagan Teki <jteki@openedev.com>
My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
the SPI flash correctly, however after "reset" U-Boot still shows: ***
Warning - bad CRC, using default environment
spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
KiB, total 2 MiB
*** Warning - bad CRC, using default environment
Anything wrong?
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 5:22 ` Bin Meng
@ 2016-02-17 5:27 ` Bin Meng
2016-02-17 5:34 ` Jagan Teki
2016-02-17 8:54 ` Jagan Teki
2016-02-17 7:37 ` Jagan Teki
1 sibling, 2 replies; 47+ messages in thread
From: Bin Meng @ 2016-02-17 5:27 UTC (permalink / raw)
To: u-boot
On Wed, Feb 17, 2016 at 1:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> -----------------------
>>> cmd/sf.c
>>> -----------------------
>>> spi_flash.c
>>> -----------------------
>>> sf_probe.c
>>> -----------------------
>>> spi-uclass
>>> -----------------------
>>> spi drivers
>>> -----------------------
>>> SPI NOR chip
>>> -----------------------
>>>
>>> After SPI-NOR:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> SPI-NOR with MTD:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> MTD core
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Tested both DM and non-DM models
>>
>> Tested-by: Jagan Teki <jteki@openedev.com>
>
> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
> the SPI flash correctly, however after "reset" U-Boot still shows: ***
> Warning - bad CRC, using default environment
>
> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
> KiB, total 2 MiB
> *** Warning - bad CRC, using default environment
>
> Anything wrong?
>
Another testing on Intel Galileo shows that: it does NOT build for galileo.
arch/x86/lib/built-in.o: In function `mrccache_update':
arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm'
arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'
Did you run buildman for your whole series?
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 5:27 ` Bin Meng
@ 2016-02-17 5:34 ` Jagan Teki
2016-02-17 8:54 ` Jagan Teki
1 sibling, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 5:34 UTC (permalink / raw)
To: u-boot
On 17 February 2016 at 10:57, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Wed, Feb 17, 2016 at 1:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>> Compared to previous patch series this series adds spi-nor
>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>
>>>> This is whole series for all spi-nor related changes, and while
>>>> series tested on spansion spi-nor chip.
>>>>
>>>> Know issue:
>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>
>>>> Why this framework:
>>>>
>>>> Some of the SPI device drivers at drivers/spi not a real
>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>> operates only with SPI-NOR flash devices. these were technically
>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>
>>>> The problem with these were resides at drivers/spi is entire
>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>> a wrong indication where SPI layer getting effected more with
>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>> by separating all SPI-NOR flash operations from spi layer and
>>>> creats a generic layer called SPI-NOR core which can be used to
>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>
>>>> Before SPI-NOR:
>>>>
>>>> -----------------------
>>>> cmd/sf.c
>>>> -----------------------
>>>> spi_flash.c
>>>> -----------------------
>>>> sf_probe.c
>>>> -----------------------
>>>> spi-uclass
>>>> -----------------------
>>>> spi drivers
>>>> -----------------------
>>>> SPI NOR chip
>>>> -----------------------
>>>>
>>>> After SPI-NOR:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> SPI-NOR with MTD:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> MTD core
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Tested both DM and non-DM models
>>>
>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>
>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>> Warning - bad CRC, using default environment
>>
>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>> KiB, total 2 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Anything wrong?
>>
>
> Another testing on Intel Galileo shows that: it does NOT build for galileo.
>
> arch/x86/lib/built-in.o: In function `mrccache_update':
> arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm'
> arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'
>
> Did you run buildman for your whole series?
Yes this is the known issues, I mentioned on the cover letter. we need
to fix this one.
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 5:22 ` Bin Meng
2016-02-17 5:27 ` Bin Meng
@ 2016-02-17 7:37 ` Jagan Teki
2016-02-17 7:38 ` Jagan Teki
1 sibling, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 7:37 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> -----------------------
>>> cmd/sf.c
>>> -----------------------
>>> spi_flash.c
>>> -----------------------
>>> sf_probe.c
>>> -----------------------
>>> spi-uclass
>>> -----------------------
>>> spi drivers
>>> -----------------------
>>> SPI NOR chip
>>> -----------------------
>>>
>>> After SPI-NOR:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> SPI-NOR with MTD:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> MTD core
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Tested both DM and non-DM models
>>
>> Tested-by: Jagan Teki <jteki@openedev.com>
>
> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
> the SPI flash correctly, however after "reset" U-Boot still shows: ***
> Warning - bad CRC, using default environment
>
> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
> KiB, total 2 MiB
> *** Warning - bad CRC, using default environment
>
> Anything wrong?
I'm not getting the warning
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 7:37 ` Jagan Teki
@ 2016-02-17 7:38 ` Jagan Teki
2016-02-17 9:10 ` Bin Meng
0 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 7:38 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
> Hi Bin,
>
> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>> Compared to previous patch series this series adds spi-nor
>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>
>>>> This is whole series for all spi-nor related changes, and while
>>>> series tested on spansion spi-nor chip.
>>>>
>>>> Know issue:
>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>
>>>> Why this framework:
>>>>
>>>> Some of the SPI device drivers at drivers/spi not a real
>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>> operates only with SPI-NOR flash devices. these were technically
>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>
>>>> The problem with these were resides at drivers/spi is entire
>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>> a wrong indication where SPI layer getting effected more with
>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>> by separating all SPI-NOR flash operations from spi layer and
>>>> creats a generic layer called SPI-NOR core which can be used to
>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>
>>>> Before SPI-NOR:
>>>>
>>>> -----------------------
>>>> cmd/sf.c
>>>> -----------------------
>>>> spi_flash.c
>>>> -----------------------
>>>> sf_probe.c
>>>> -----------------------
>>>> spi-uclass
>>>> -----------------------
>>>> spi drivers
>>>> -----------------------
>>>> SPI NOR chip
>>>> -----------------------
>>>>
>>>> After SPI-NOR:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> SPI-NOR with MTD:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> MTD core
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Tested both DM and non-DM models
>>>
>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>
>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>> Warning - bad CRC, using default environment
>>
>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>> KiB, total 2 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Anything wrong?
>
>
I'm not getting the warning, after saveenv.
DRAM: ECC disabled 1 GiB
MMC:
spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
KiB, total 16 MiB
In: serial at e0001000
Out: serial at e0001000
Err: serial at e0001000
Model: Zynq MicroZED Board
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 5:27 ` Bin Meng
2016-02-17 5:34 ` Jagan Teki
@ 2016-02-17 8:54 ` Jagan Teki
2016-02-17 8:56 ` Bin Meng
1 sibling, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 8:54 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 17 February 2016 at 10:57, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Wed, Feb 17, 2016 at 1:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>> Compared to previous patch series this series adds spi-nor
>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>
>>>> This is whole series for all spi-nor related changes, and while
>>>> series tested on spansion spi-nor chip.
>>>>
>>>> Know issue:
>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>
>>>> Why this framework:
>>>>
>>>> Some of the SPI device drivers at drivers/spi not a real
>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>> operates only with SPI-NOR flash devices. these were technically
>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>
>>>> The problem with these were resides at drivers/spi is entire
>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>> a wrong indication where SPI layer getting effected more with
>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>> by separating all SPI-NOR flash operations from spi layer and
>>>> creats a generic layer called SPI-NOR core which can be used to
>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>
>>>> Before SPI-NOR:
>>>>
>>>> -----------------------
>>>> cmd/sf.c
>>>> -----------------------
>>>> spi_flash.c
>>>> -----------------------
>>>> sf_probe.c
>>>> -----------------------
>>>> spi-uclass
>>>> -----------------------
>>>> spi drivers
>>>> -----------------------
>>>> SPI NOR chip
>>>> -----------------------
>>>>
>>>> After SPI-NOR:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> SPI-NOR with MTD:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> MTD core
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Tested both DM and non-DM models
>>>
>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>
>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>> Warning - bad CRC, using default environment
>>
>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>> KiB, total 2 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Anything wrong?
>>
>
> Another testing on Intel Galileo shows that: it does NOT build for galileo.
>
> arch/x86/lib/built-in.o: In function `mrccache_update':
> arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm'
> arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'
>
> Did you run buildman for your whole series?
Can you try the u-boot-spi/spi-nor tree again, I have fixed with the patch.
BTW - I couldn't get any build error with buildman without the fix
[1], am I missing anything?
[1] http://paste.ubuntu.com/15099249/
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 8:54 ` Jagan Teki
@ 2016-02-17 8:56 ` Bin Meng
0 siblings, 0 replies; 47+ messages in thread
From: Bin Meng @ 2016-02-17 8:56 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On Wed, Feb 17, 2016 at 4:54 PM, Jagan Teki <jteki@openedev.com> wrote:
> Hi Bin,
>
> On 17 February 2016 at 10:57, Bin Meng <bmeng.cn@gmail.com> wrote:
>> On Wed, Feb 17, 2016 at 1:22 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>>> Compared to previous patch series this series adds spi-nor
>>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>>
>>>>> This is whole series for all spi-nor related changes, and while
>>>>> series tested on spansion spi-nor chip.
>>>>>
>>>>> Know issue:
>>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>>
>>>>> Why this framework:
>>>>>
>>>>> Some of the SPI device drivers at drivers/spi not a real
>>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>>> operates only with SPI-NOR flash devices. these were technically
>>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>>
>>>>> The problem with these were resides at drivers/spi is entire
>>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>>> a wrong indication where SPI layer getting effected more with
>>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>>> by separating all SPI-NOR flash operations from spi layer and
>>>>> creats a generic layer called SPI-NOR core which can be used to
>>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>>
>>>>> Before SPI-NOR:
>>>>>
>>>>> -----------------------
>>>>> cmd/sf.c
>>>>> -----------------------
>>>>> spi_flash.c
>>>>> -----------------------
>>>>> sf_probe.c
>>>>> -----------------------
>>>>> spi-uclass
>>>>> -----------------------
>>>>> spi drivers
>>>>> -----------------------
>>>>> SPI NOR chip
>>>>> -----------------------
>>>>>
>>>>> After SPI-NOR:
>>>>>
>>>>> ------------------------------
>>>>> cmd/sf.c
>>>>> ------------------------------
>>>>> spi-nor.c
>>>>> -------------------------------
>>>>> m25p80.c spi nor drivers
>>>>> -------------------------------
>>>>> spi-uclass SPI NOR chip
>>>>> -------------------------------
>>>>> spi drivers
>>>>> -------------------------------
>>>>> SPI NOR chip
>>>>> -------------------------------
>>>>>
>>>>> SPI-NOR with MTD:
>>>>>
>>>>> ------------------------------
>>>>> cmd/sf.c
>>>>> ------------------------------
>>>>> MTD core
>>>>> ------------------------------
>>>>> spi-nor.c
>>>>> -------------------------------
>>>>> m25p80.c spi nor drivers
>>>>> -------------------------------
>>>>> spi-uclass SPI NOR chip
>>>>> -------------------------------
>>>>> spi drivers
>>>>> -------------------------------
>>>>> SPI NOR chip
>>>>> -------------------------------
>>>>>
>>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>
>>>> Tested both DM and non-DM models
>>>>
>>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>>
>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>> Warning - bad CRC, using default environment
>>>
>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>> KiB, total 2 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Anything wrong?
>>>
>>
>> Another testing on Intel Galileo shows that: it does NOT build for galileo.
>>
>> arch/x86/lib/built-in.o: In function `mrccache_update':
>> arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm'
>> arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'
>>
>> Did you run buildman for your whole series?
>
> Can you try the u-boot-spi/spi-nor tree again, I have fixed with the patch.
>
> BTW - I couldn't get any build error with buildman without the fix
> [1], am I missing anything?
>
> [1] http://paste.ubuntu.com/15099249/
It looks you invoked buildman with "-n". Please remove that and ask
buildman to work :)
>
> thanks!
> --
> Jagan.
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 7:38 ` Jagan Teki
@ 2016-02-17 9:10 ` Bin Meng
2016-02-17 20:21 ` Tom Rini
2016-02-18 4:05 ` Bin Meng
0 siblings, 2 replies; 47+ messages in thread
From: Bin Meng @ 2016-02-17 9:10 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
> Hi Bin,
>
> On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
>> Hi Bin,
>>
>> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>>> Compared to previous patch series this series adds spi-nor
>>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>>
>>>>> This is whole series for all spi-nor related changes, and while
>>>>> series tested on spansion spi-nor chip.
>>>>>
>>>>> Know issue:
>>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>>
>>>>> Why this framework:
>>>>>
>>>>> Some of the SPI device drivers at drivers/spi not a real
>>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>>> operates only with SPI-NOR flash devices. these were technically
>>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>>
>>>>> The problem with these were resides at drivers/spi is entire
>>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>>> a wrong indication where SPI layer getting effected more with
>>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>>> by separating all SPI-NOR flash operations from spi layer and
>>>>> creats a generic layer called SPI-NOR core which can be used to
>>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>>
>>>>> Before SPI-NOR:
>>>>>
>>>>> -----------------------
>>>>> cmd/sf.c
>>>>> -----------------------
>>>>> spi_flash.c
>>>>> -----------------------
>>>>> sf_probe.c
>>>>> -----------------------
>>>>> spi-uclass
>>>>> -----------------------
>>>>> spi drivers
>>>>> -----------------------
>>>>> SPI NOR chip
>>>>> -----------------------
>>>>>
>>>>> After SPI-NOR:
>>>>>
>>>>> ------------------------------
>>>>> cmd/sf.c
>>>>> ------------------------------
>>>>> spi-nor.c
>>>>> -------------------------------
>>>>> m25p80.c spi nor drivers
>>>>> -------------------------------
>>>>> spi-uclass SPI NOR chip
>>>>> -------------------------------
>>>>> spi drivers
>>>>> -------------------------------
>>>>> SPI NOR chip
>>>>> -------------------------------
>>>>>
>>>>> SPI-NOR with MTD:
>>>>>
>>>>> ------------------------------
>>>>> cmd/sf.c
>>>>> ------------------------------
>>>>> MTD core
>>>>> ------------------------------
>>>>> spi-nor.c
>>>>> -------------------------------
>>>>> m25p80.c spi nor drivers
>>>>> -------------------------------
>>>>> spi-uclass SPI NOR chip
>>>>> -------------------------------
>>>>> spi drivers
>>>>> -------------------------------
>>>>> SPI NOR chip
>>>>> -------------------------------
>>>>>
>>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>
>>>> Tested both DM and non-DM models
>>>>
>>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>>
>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>> Warning - bad CRC, using default environment
>>>
>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>> KiB, total 2 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Anything wrong?
>>
>>
>
> I'm not getting the warning, after saveenv.
>
> DRAM: ECC disabled 1 GiB
> MMC:
> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
> KiB, total 16 MiB
> In: serial at e0001000
> Out: serial at e0001000
> Err: serial at e0001000
> Model: Zynq MicroZED Board
>
Tested on another x86 board, still see the 'bad CRC' warning, log below:
U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
CPU: x86, vendor Intel, device 590h
DRAM: 256 MiB
MMC: Quark SDHCI: 0
spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment
Model: Intel Galileo
Net:
Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
eth0: eth_designware#0
Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
, eth1: eth_designware#1
Hit any key to stop autoboot: 0
=> saveenv
Saving Environment to SPI Flash...
Erasing SPI flash...Writing to SPI flash...done
=> reset
resetting ...
U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
CPU: x86, vendor Intel, device 590h
DRAM: 256 MiB
MMC: Quark SDHCI: 0
spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment
Model: Intel Galileo
Net:
Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
eth0: eth_designware#0
Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
, eth1: eth_designware#1
Hit any key to stop autoboot: 0
=>
> thanks!
> --
> Jagan.
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-14 20:46 [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support Jagan Teki
2016-02-16 19:47 ` Jagan Teki
@ 2016-02-17 19:00 ` Simon Glass
2016-02-17 19:14 ` Jagan Teki
` (2 more replies)
2016-02-18 9:18 ` Jagan Teki
2016-02-22 18:17 ` Jagan Teki
3 siblings, 3 replies; 47+ messages in thread
From: Simon Glass @ 2016-02-17 19:00 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On 14 February 2016 at 13:46, Jagan Teki <jteki@openedev.com> wrote:
> Compared to previous patch series this series adds spi-nor
> core with spi-nor controller drivers are of "mtd uclass"
>
> This is whole series for all spi-nor related changes, and while
> series tested on spansion spi-nor chip.
>
> Know issue:
> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>
> Why this framework:
>
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>
> The problem with these were resides at drivers/spi is entire
> SPI layer becomes SPI-NOR flash oriented which is absolutely
> a wrong indication where SPI layer getting effected more with
> flash operations - So this SPI-NOR core will resolve this issue
> by separating all SPI-NOR flash operations from spi layer and
> creats a generic layer called SPI-NOR core which can be used to
> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> controller driver. The idea is taken from Linux spi-nor framework.
>
> Before SPI-NOR:
>
> -----------------------
> cmd/sf.c
> -----------------------
> spi_flash.c
> -----------------------
> sf_probe.c
> -----------------------
> spi-uclass
> -----------------------
> spi drivers
> -----------------------
> SPI NOR chip
> -----------------------
>
> After SPI-NOR:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> SPI-NOR with MTD:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> MTD core
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> which is an interface layer b/w spi-nor core drivers/spi
> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>
> Changes for v6:
> - Fixed git bisectable issues, with buildman.
> - Fixed spi-nor compilation issues
> - newly designed changes.
>
> Changes for v5:
> - newly designed changes
>
> Testing:
> $ git clone git://git.denx.de/u-boot-spi.git
> $ cd u-boot-spi
> $ git checkout -b spi-nor origin/spi-nor
I see quite a large rodata increase at this commit. Is it necessary?
67: configs: Use CONFIG_SPI_NOR_MISC
arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0
text +384.0
There are also bisectability problems (build errors for some commits)
- e.g. chromebook_jerry.
Regards,
Simon
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 19:00 ` Simon Glass
@ 2016-02-17 19:14 ` Jagan Teki
2016-02-17 19:23 ` Jagan Teki
2016-02-17 20:08 ` Jagan Teki
2016-02-22 8:57 ` Jagan Teki
2 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 19:14 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 18 February 2016 at 00:30, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On 14 February 2016 at 13:46, Jagan Teki <jteki@openedev.com> wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> -----------------------
>> cmd/sf.c
>> -----------------------
>> spi_flash.c
>> -----------------------
>> sf_probe.c
>> -----------------------
>> spi-uclass
>> -----------------------
>> spi drivers
>> -----------------------
>> SPI NOR chip
>> -----------------------
>>
>> After SPI-NOR:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> SPI-NOR with MTD:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> MTD core
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>
> I see quite a large rodata increase at this commit. Is it necessary?
If ie the case then we need to revert the vendor configs w/o add them
into CONFIG_SPI_NOR_MISC.
>
> 67: configs: Use CONFIG_SPI_NOR_MISC
> arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0
> text +384.0
>
> There are also bisectability problems (build errors for some commits)
> - e.g. chromebook_jerry.
Did you pick u-boot-spi/spi-nor?
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 19:14 ` Jagan Teki
@ 2016-02-17 19:23 ` Jagan Teki
0 siblings, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 19:23 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 18 February 2016 at 00:44, Jagan Teki <jteki@openedev.com> wrote:
> Hi Simon,
>
> On 18 February 2016 at 00:30, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On 14 February 2016 at 13:46, Jagan Teki <jteki@openedev.com> wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> -----------------------
>>> cmd/sf.c
>>> -----------------------
>>> spi_flash.c
>>> -----------------------
>>> sf_probe.c
>>> -----------------------
>>> spi-uclass
>>> -----------------------
>>> spi drivers
>>> -----------------------
>>> SPI NOR chip
>>> -----------------------
>>>
>>> After SPI-NOR:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> SPI-NOR with MTD:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> MTD core
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Changes for v6:
>>> - Fixed git bisectable issues, with buildman.
>>> - Fixed spi-nor compilation issues
>>> - newly designed changes.
>>>
>>> Changes for v5:
>>> - newly designed changes
>>>
>>> Testing:
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b spi-nor origin/spi-nor
>>
>> I see quite a large rodata increase at this commit. Is it necessary?
>
> If ie the case then we need to revert the vendor configs w/o add them
> into CONFIG_SPI_NOR_MISC.
>
>>
>> 67: configs: Use CONFIG_SPI_NOR_MISC
>> arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0
>> text +384.0
I couldn't find rodata section for this commit[1] am I missing anything?
[1] http://paste.ubuntu.com/15101966/
>>
>> There are also bisectability problems (build errors for some commits)
>> - e.g. chromebook_jerry.
>
> Did you pick u-boot-spi/spi-nor?
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 19:00 ` Simon Glass
2016-02-17 19:14 ` Jagan Teki
@ 2016-02-17 20:08 ` Jagan Teki
2016-02-17 20:46 ` Jagan Teki
2016-02-22 8:57 ` Jagan Teki
2 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 20:08 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 18 February 2016 at 00:30, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On 14 February 2016 at 13:46, Jagan Teki <jteki@openedev.com> wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> -----------------------
>> cmd/sf.c
>> -----------------------
>> spi_flash.c
>> -----------------------
>> sf_probe.c
>> -----------------------
>> spi-uclass
>> -----------------------
>> spi drivers
>> -----------------------
>> SPI NOR chip
>> -----------------------
>>
>> After SPI-NOR:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> SPI-NOR with MTD:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> MTD core
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>
> I see quite a large rodata increase at this commit. Is it necessary?
>
> 67: configs: Use CONFIG_SPI_NOR_MISC
> arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0
> text +384.0
>
> There are also bisectability problems (build errors for some commits)
> - e.g. chromebook_jerry.
Yes, this I missed defining SPI_NOR config will update that.
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 9:10 ` Bin Meng
@ 2016-02-17 20:21 ` Tom Rini
2016-02-18 3:38 ` Bin Meng
2016-02-18 4:05 ` Bin Meng
1 sibling, 1 reply; 47+ messages in thread
From: Tom Rini @ 2016-02-17 20:21 UTC (permalink / raw)
To: u-boot
On Wed, Feb 17, 2016 at 05:10:33PM +0800, Bin Meng wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
> > Hi Bin,
> >
> > On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
> >> Hi Bin,
> >>
> >> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>> Hi Jagan,
> >>>
> >>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
> >>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
> >>>>> Compared to previous patch series this series adds spi-nor
> >>>>> core with spi-nor controller drivers are of "mtd uclass"
> >>>>>
> >>>>> This is whole series for all spi-nor related changes, and while
> >>>>> series tested on spansion spi-nor chip.
> >>>>>
> >>>>> Know issue:
> >>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
> >>>>>
> >>>>> Why this framework:
> >>>>>
> >>>>> Some of the SPI device drivers at drivers/spi not a real
> >>>>> spi controllers, Unlike normal/generic SPI controllers they
> >>>>> operates only with SPI-NOR flash devices. these were technically
> >>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
> >>>>>
> >>>>> The problem with these were resides at drivers/spi is entire
> >>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
> >>>>> a wrong indication where SPI layer getting effected more with
> >>>>> flash operations - So this SPI-NOR core will resolve this issue
> >>>>> by separating all SPI-NOR flash operations from spi layer and
> >>>>> creats a generic layer called SPI-NOR core which can be used to
> >>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> >>>>> controller driver. The idea is taken from Linux spi-nor framework.
> >>>>>
> >>>>> Before SPI-NOR:
> >>>>>
> >>>>> -----------------------
> >>>>> cmd/sf.c
> >>>>> -----------------------
> >>>>> spi_flash.c
> >>>>> -----------------------
> >>>>> sf_probe.c
> >>>>> -----------------------
> >>>>> spi-uclass
> >>>>> -----------------------
> >>>>> spi drivers
> >>>>> -----------------------
> >>>>> SPI NOR chip
> >>>>> -----------------------
> >>>>>
> >>>>> After SPI-NOR:
> >>>>>
> >>>>> ------------------------------
> >>>>> cmd/sf.c
> >>>>> ------------------------------
> >>>>> spi-nor.c
> >>>>> -------------------------------
> >>>>> m25p80.c spi nor drivers
> >>>>> -------------------------------
> >>>>> spi-uclass SPI NOR chip
> >>>>> -------------------------------
> >>>>> spi drivers
> >>>>> -------------------------------
> >>>>> SPI NOR chip
> >>>>> -------------------------------
> >>>>>
> >>>>> SPI-NOR with MTD:
> >>>>>
> >>>>> ------------------------------
> >>>>> cmd/sf.c
> >>>>> ------------------------------
> >>>>> MTD core
> >>>>> ------------------------------
> >>>>> spi-nor.c
> >>>>> -------------------------------
> >>>>> m25p80.c spi nor drivers
> >>>>> -------------------------------
> >>>>> spi-uclass SPI NOR chip
> >>>>> -------------------------------
> >>>>> spi drivers
> >>>>> -------------------------------
> >>>>> SPI NOR chip
> >>>>> -------------------------------
> >>>>>
> >>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> >>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> >>>>> which is an interface layer b/w spi-nor core drivers/spi
> >>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
> >>>>
> >>>> Tested both DM and non-DM models
> >>>>
> >>>> Tested-by: Jagan Teki <jteki@openedev.com>
> >>>
> >>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
> >>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
> >>> Warning - bad CRC, using default environment
> >>>
> >>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
> >>> KiB, total 2 MiB
> >>> *** Warning - bad CRC, using default environment
> >>>
> >>> Anything wrong?
> >>
> >>
> >
> > I'm not getting the warning, after saveenv.
> >
> > DRAM: ECC disabled 1 GiB
> > MMC:
> > spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
> > KiB, total 16 MiB
> > In: serial at e0001000
> > Out: serial at e0001000
> > Err: serial at e0001000
> > Model: Zynq MicroZED Board
> >
>
> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>
> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>
> CPU: x86, vendor Intel, device 590h
> DRAM: 256 MiB
> MMC: Quark SDHCI: 0
> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> *** Warning - bad CRC, using default environment
>
> Model: Intel Galileo
> Net:
> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
> eth0: eth_designware#0
> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
> , eth1: eth_designware#1
> Hit any key to stop autoboot: 0
> => saveenv
> Saving Environment to SPI Flash...
> Erasing SPI flash...Writing to SPI flash...done
> => reset
> resetting ...
>
>
> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>
> CPU: x86, vendor Intel, device 590h
> DRAM: 256 MiB
> MMC: Quark SDHCI: 0
> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> *** Warning - bad CRC, using default environment
>
> Model: Intel Galileo
> Net:
> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
> eth0: eth_designware#0
> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
> , eth1: eth_designware#1
> Hit any key to stop autoboot: 0
> =>
A thought, can we replicate this on qemu-x86? That should be a platform
everyone can try :)
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160217/ae1d70b0/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 20:08 ` Jagan Teki
@ 2016-02-17 20:46 ` Jagan Teki
0 siblings, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-17 20:46 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 18 February 2016 at 01:38, Jagan Teki <jteki@openedev.com> wrote:
> Hi Simon,
>
> On 18 February 2016 at 00:30, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On 14 February 2016 at 13:46, Jagan Teki <jteki@openedev.com> wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> -----------------------
>>> cmd/sf.c
>>> -----------------------
>>> spi_flash.c
>>> -----------------------
>>> sf_probe.c
>>> -----------------------
>>> spi-uclass
>>> -----------------------
>>> spi drivers
>>> -----------------------
>>> SPI NOR chip
>>> -----------------------
>>>
>>> After SPI-NOR:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> SPI-NOR with MTD:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> MTD core
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Changes for v6:
>>> - Fixed git bisectable issues, with buildman.
>>> - Fixed spi-nor compilation issues
>>> - newly designed changes.
>>>
>>> Changes for v5:
>>> - newly designed changes
>>>
>>> Testing:
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b spi-nor origin/spi-nor
>>
>> I see quite a large rodata increase at this commit. Is it necessary?
>>
>> 67: configs: Use CONFIG_SPI_NOR_MISC
>> arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0
>> text +384.0
>>
>> There are also bisectability problems (build errors for some commits)
>> - e.g. chromebook_jerry.
>
> Yes, this I missed defining SPI_NOR config will update that.
u-boot-spi/spi-nor updated, let me know if you find any build issues.
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 20:21 ` Tom Rini
@ 2016-02-18 3:38 ` Bin Meng
0 siblings, 0 replies; 47+ messages in thread
From: Bin Meng @ 2016-02-18 3:38 UTC (permalink / raw)
To: u-boot
On Thu, Feb 18, 2016 at 4:21 AM, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Feb 17, 2016 at 05:10:33PM +0800, Bin Meng wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
>> > Hi Bin,
>> >
>> > On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
>> >> Hi Bin,
>> >>
>> >> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>> Hi Jagan,
>> >>>
>> >>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>> >>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>> >>>>> Compared to previous patch series this series adds spi-nor
>> >>>>> core with spi-nor controller drivers are of "mtd uclass"
>> >>>>>
>> >>>>> This is whole series for all spi-nor related changes, and while
>> >>>>> series tested on spansion spi-nor chip.
>> >>>>>
>> >>>>> Know issue:
>> >>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>> >>>>>
>> >>>>> Why this framework:
>> >>>>>
>> >>>>> Some of the SPI device drivers at drivers/spi not a real
>> >>>>> spi controllers, Unlike normal/generic SPI controllers they
>> >>>>> operates only with SPI-NOR flash devices. these were technically
>> >>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>> >>>>>
>> >>>>> The problem with these were resides at drivers/spi is entire
>> >>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> >>>>> a wrong indication where SPI layer getting effected more with
>> >>>>> flash operations - So this SPI-NOR core will resolve this issue
>> >>>>> by separating all SPI-NOR flash operations from spi layer and
>> >>>>> creats a generic layer called SPI-NOR core which can be used to
>> >>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> >>>>> controller driver. The idea is taken from Linux spi-nor framework.
>> >>>>>
>> >>>>> Before SPI-NOR:
>> >>>>>
>> >>>>> -----------------------
>> >>>>> cmd/sf.c
>> >>>>> -----------------------
>> >>>>> spi_flash.c
>> >>>>> -----------------------
>> >>>>> sf_probe.c
>> >>>>> -----------------------
>> >>>>> spi-uclass
>> >>>>> -----------------------
>> >>>>> spi drivers
>> >>>>> -----------------------
>> >>>>> SPI NOR chip
>> >>>>> -----------------------
>> >>>>>
>> >>>>> After SPI-NOR:
>> >>>>>
>> >>>>> ------------------------------
>> >>>>> cmd/sf.c
>> >>>>> ------------------------------
>> >>>>> spi-nor.c
>> >>>>> -------------------------------
>> >>>>> m25p80.c spi nor drivers
>> >>>>> -------------------------------
>> >>>>> spi-uclass SPI NOR chip
>> >>>>> -------------------------------
>> >>>>> spi drivers
>> >>>>> -------------------------------
>> >>>>> SPI NOR chip
>> >>>>> -------------------------------
>> >>>>>
>> >>>>> SPI-NOR with MTD:
>> >>>>>
>> >>>>> ------------------------------
>> >>>>> cmd/sf.c
>> >>>>> ------------------------------
>> >>>>> MTD core
>> >>>>> ------------------------------
>> >>>>> spi-nor.c
>> >>>>> -------------------------------
>> >>>>> m25p80.c spi nor drivers
>> >>>>> -------------------------------
>> >>>>> spi-uclass SPI NOR chip
>> >>>>> -------------------------------
>> >>>>> spi drivers
>> >>>>> -------------------------------
>> >>>>> SPI NOR chip
>> >>>>> -------------------------------
>> >>>>>
>> >>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> >>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> >>>>> which is an interface layer b/w spi-nor core drivers/spi
>> >>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>> >>>>
>> >>>> Tested both DM and non-DM models
>> >>>>
>> >>>> Tested-by: Jagan Teki <jteki@openedev.com>
>> >>>
>> >>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>> >>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>> >>> Warning - bad CRC, using default environment
>> >>>
>> >>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>> >>> KiB, total 2 MiB
>> >>> *** Warning - bad CRC, using default environment
>> >>>
>> >>> Anything wrong?
>> >>
>> >>
>> >
>> > I'm not getting the warning, after saveenv.
>> >
>> > DRAM: ECC disabled 1 GiB
>> > MMC:
>> > spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>> > KiB, total 16 MiB
>> > In: serial at e0001000
>> > Out: serial at e0001000
>> > Err: serial at e0001000
>> > Model: Zynq MicroZED Board
>> >
>>
>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>
>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>
>> CPU: x86, vendor Intel, device 590h
>> DRAM: 256 MiB
>> MMC: Quark SDHCI: 0
>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Model: Intel Galileo
>> Net:
>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>> eth0: eth_designware#0
>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>> , eth1: eth_designware#1
>> Hit any key to stop autoboot: 0
>> => saveenv
>> Saving Environment to SPI Flash...
>> Erasing SPI flash...Writing to SPI flash...done
>> => reset
>> resetting ...
>>
>>
>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>
>> CPU: x86, vendor Intel, device 590h
>> DRAM: 256 MiB
>> MMC: Quark SDHCI: 0
>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Model: Intel Galileo
>> Net:
>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>> eth0: eth_designware#0
>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>> , eth1: eth_designware#1
>> Hit any key to stop autoboot: 0
>> =>
>
> A thought, can we replicate this on qemu-x86? That should be a platform
> everyone can try :)
>
Last time I checked QEMU and looks it does not support SPI yet on x86.
I can have another check.
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 9:10 ` Bin Meng
2016-02-17 20:21 ` Tom Rini
@ 2016-02-18 4:05 ` Bin Meng
2016-02-18 5:13 ` Bin Meng
1 sibling, 1 reply; 47+ messages in thread
From: Bin Meng @ 2016-02-18 4:05 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
>> Hi Bin,
>>
>> On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
>>> Hi Bin,
>>>
>>> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>>>> Compared to previous patch series this series adds spi-nor
>>>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>>>
>>>>>> This is whole series for all spi-nor related changes, and while
>>>>>> series tested on spansion spi-nor chip.
>>>>>>
>>>>>> Know issue:
>>>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>>>
>>>>>> Why this framework:
>>>>>>
>>>>>> Some of the SPI device drivers at drivers/spi not a real
>>>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>>>> operates only with SPI-NOR flash devices. these were technically
>>>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>>>
>>>>>> The problem with these were resides at drivers/spi is entire
>>>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>>>> a wrong indication where SPI layer getting effected more with
>>>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>>>> by separating all SPI-NOR flash operations from spi layer and
>>>>>> creats a generic layer called SPI-NOR core which can be used to
>>>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>>>
>>>>>> Before SPI-NOR:
>>>>>>
>>>>>> -----------------------
>>>>>> cmd/sf.c
>>>>>> -----------------------
>>>>>> spi_flash.c
>>>>>> -----------------------
>>>>>> sf_probe.c
>>>>>> -----------------------
>>>>>> spi-uclass
>>>>>> -----------------------
>>>>>> spi drivers
>>>>>> -----------------------
>>>>>> SPI NOR chip
>>>>>> -----------------------
>>>>>>
>>>>>> After SPI-NOR:
>>>>>>
>>>>>> ------------------------------
>>>>>> cmd/sf.c
>>>>>> ------------------------------
>>>>>> spi-nor.c
>>>>>> -------------------------------
>>>>>> m25p80.c spi nor drivers
>>>>>> -------------------------------
>>>>>> spi-uclass SPI NOR chip
>>>>>> -------------------------------
>>>>>> spi drivers
>>>>>> -------------------------------
>>>>>> SPI NOR chip
>>>>>> -------------------------------
>>>>>>
>>>>>> SPI-NOR with MTD:
>>>>>>
>>>>>> ------------------------------
>>>>>> cmd/sf.c
>>>>>> ------------------------------
>>>>>> MTD core
>>>>>> ------------------------------
>>>>>> spi-nor.c
>>>>>> -------------------------------
>>>>>> m25p80.c spi nor drivers
>>>>>> -------------------------------
>>>>>> spi-uclass SPI NOR chip
>>>>>> -------------------------------
>>>>>> spi drivers
>>>>>> -------------------------------
>>>>>> SPI NOR chip
>>>>>> -------------------------------
>>>>>>
>>>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>>
>>>>> Tested both DM and non-DM models
>>>>>
>>>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>>>
>>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>>> Warning - bad CRC, using default environment
>>>>
>>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>>> KiB, total 2 MiB
>>>> *** Warning - bad CRC, using default environment
>>>>
>>>> Anything wrong?
>>>
>>>
>>
>> I'm not getting the warning, after saveenv.
>>
>> DRAM: ECC disabled 1 GiB
>> MMC:
>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>> KiB, total 16 MiB
>> In: serial at e0001000
>> Out: serial at e0001000
>> Err: serial at e0001000
>> Model: Zynq MicroZED Board
>>
>
> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>
> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>
> CPU: x86, vendor Intel, device 590h
> DRAM: 256 MiB
> MMC: Quark SDHCI: 0
> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> *** Warning - bad CRC, using default environment
>
> Model: Intel Galileo
> Net:
> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
> eth0: eth_designware#0
> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
> , eth1: eth_designware#1
> Hit any key to stop autoboot: 0
> => saveenv
> Saving Environment to SPI Flash...
> Erasing SPI flash...Writing to SPI flash...done
> => reset
> resetting ...
>
>
> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>
> CPU: x86, vendor Intel, device 590h
> DRAM: 256 MiB
> MMC: Quark SDHCI: 0
> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
> *** Warning - bad CRC, using default environment
>
> Model: Intel Galileo
> Net:
> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
> eth0: eth_designware#0
> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
> , eth1: eth_designware#1
> Hit any key to stop autoboot: 0
> =>
>
Looks like you messed up the ICH SPI driver. Something went wrong with
your patch series. ICH SPI controller is a special one (only supports
slow read) especially when it comes to deal with an SST flash which is
even odd (only supports byte program). I feel this ICH SPI controller
is quite vulnerable to SPI changes as it breaks many times. Maybe
Jagan you can purchase one Crown Bay board for the SPI flash testing
(a joke!)
logs below:
=> sf read 100000 100000 100
device 0 offset 0x100000, size 0x100
SF: 256 bytes @ 0x100000 Read: OK
=> crc fff00000 100
crc32 for fff00000 ... fff000ff ==> ac8e7061
=> crc 100000 100
crc32 for 00100000 ... 001000ff ==> b44fdefc
See? the contents of 'sf read' to address 0x100000 does not match the
original one in SPI flash (0xfff00000)
Anyway, I will continue debugging this.
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-18 4:05 ` Bin Meng
@ 2016-02-18 5:13 ` Bin Meng
2016-02-18 5:24 ` Bin Meng
0 siblings, 1 reply; 47+ messages in thread
From: Bin Meng @ 2016-02-18 5:13 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
>>> Hi Bin,
>>>
>>> On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>> Compared to previous patch series this series adds spi-nor
>>>>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>>>>
>>>>>>> This is whole series for all spi-nor related changes, and while
>>>>>>> series tested on spansion spi-nor chip.
>>>>>>>
>>>>>>> Know issue:
>>>>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>>>>
>>>>>>> Why this framework:
>>>>>>>
>>>>>>> Some of the SPI device drivers at drivers/spi not a real
>>>>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>>>>> operates only with SPI-NOR flash devices. these were technically
>>>>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>>>>
>>>>>>> The problem with these were resides at drivers/spi is entire
>>>>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>>>>> a wrong indication where SPI layer getting effected more with
>>>>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>>>>> by separating all SPI-NOR flash operations from spi layer and
>>>>>>> creats a generic layer called SPI-NOR core which can be used to
>>>>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>>>>
>>>>>>> Before SPI-NOR:
>>>>>>>
>>>>>>> -----------------------
>>>>>>> cmd/sf.c
>>>>>>> -----------------------
>>>>>>> spi_flash.c
>>>>>>> -----------------------
>>>>>>> sf_probe.c
>>>>>>> -----------------------
>>>>>>> spi-uclass
>>>>>>> -----------------------
>>>>>>> spi drivers
>>>>>>> -----------------------
>>>>>>> SPI NOR chip
>>>>>>> -----------------------
>>>>>>>
>>>>>>> After SPI-NOR:
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> cmd/sf.c
>>>>>>> ------------------------------
>>>>>>> spi-nor.c
>>>>>>> -------------------------------
>>>>>>> m25p80.c spi nor drivers
>>>>>>> -------------------------------
>>>>>>> spi-uclass SPI NOR chip
>>>>>>> -------------------------------
>>>>>>> spi drivers
>>>>>>> -------------------------------
>>>>>>> SPI NOR chip
>>>>>>> -------------------------------
>>>>>>>
>>>>>>> SPI-NOR with MTD:
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> cmd/sf.c
>>>>>>> ------------------------------
>>>>>>> MTD core
>>>>>>> ------------------------------
>>>>>>> spi-nor.c
>>>>>>> -------------------------------
>>>>>>> m25p80.c spi nor drivers
>>>>>>> -------------------------------
>>>>>>> spi-uclass SPI NOR chip
>>>>>>> -------------------------------
>>>>>>> spi drivers
>>>>>>> -------------------------------
>>>>>>> SPI NOR chip
>>>>>>> -------------------------------
>>>>>>>
>>>>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>>>
>>>>>> Tested both DM and non-DM models
>>>>>>
>>>>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>>>>
>>>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>>>> Warning - bad CRC, using default environment
>>>>>
>>>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>>>> KiB, total 2 MiB
>>>>> *** Warning - bad CRC, using default environment
>>>>>
>>>>> Anything wrong?
>>>>
>>>>
>>>
>>> I'm not getting the warning, after saveenv.
>>>
>>> DRAM: ECC disabled 1 GiB
>>> MMC:
>>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>>> KiB, total 16 MiB
>>> In: serial at e0001000
>>> Out: serial at e0001000
>>> Err: serial at e0001000
>>> Model: Zynq MicroZED Board
>>>
>>
>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>
>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>
>> CPU: x86, vendor Intel, device 590h
>> DRAM: 256 MiB
>> MMC: Quark SDHCI: 0
>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Model: Intel Galileo
>> Net:
>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>> eth0: eth_designware#0
>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>> , eth1: eth_designware#1
>> Hit any key to stop autoboot: 0
>> => saveenv
>> Saving Environment to SPI Flash...
>> Erasing SPI flash...Writing to SPI flash...done
>> => reset
>> resetting ...
>>
>>
>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>
>> CPU: x86, vendor Intel, device 590h
>> DRAM: 256 MiB
>> MMC: Quark SDHCI: 0
>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Model: Intel Galileo
>> Net:
>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>> eth0: eth_designware#0
>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>> , eth1: eth_designware#1
>> Hit any key to stop autoboot: 0
>> =>
>>
>
> Looks like you messed up the ICH SPI driver. Something went wrong with
> your patch series. ICH SPI controller is a special one (only supports
> slow read) especially when it comes to deal with an SST flash which is
> even odd (only supports byte program). I feel this ICH SPI controller
> is quite vulnerable to SPI changes as it breaks many times. Maybe
> Jagan you can purchase one Crown Bay board for the SPI flash testing
> (a joke!)
>
> logs below:
>
> => sf read 100000 100000 100
> device 0 offset 0x100000, size 0x100
> SF: 256 bytes @ 0x100000 Read: OK
> => crc fff00000 100
> crc32 for fff00000 ... fff000ff ==> ac8e7061
> => crc 100000 100
> crc32 for 00100000 ... 001000ff ==> b44fdefc
>
> See? the contents of 'sf read' to address 0x100000 does not match the
> original one in SPI flash (0xfff00000)
>
> Anyway, I will continue debugging this.
>
Root cause identified. Patch available @
http://patchwork.ozlabs.org/patch/584500/. Please squash mine into an
appropriate place in your series.
Given the logic detection is completely wrong, I doubt how you tested
this whole series. What boards/flashes have you tested this on?
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-18 5:13 ` Bin Meng
@ 2016-02-18 5:24 ` Bin Meng
2016-02-18 7:13 ` Jagan Teki
0 siblings, 1 reply; 47+ messages in thread
From: Bin Meng @ 2016-02-18 5:24 UTC (permalink / raw)
To: u-boot
On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Jagan,
>
> On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>>> Compared to previous patch series this series adds spi-nor
>>>>>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>>>>>
>>>>>>>> This is whole series for all spi-nor related changes, and while
>>>>>>>> series tested on spansion spi-nor chip.
>>>>>>>>
>>>>>>>> Know issue:
>>>>>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>>>>>
>>>>>>>> Why this framework:
>>>>>>>>
>>>>>>>> Some of the SPI device drivers at drivers/spi not a real
>>>>>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>>>>>> operates only with SPI-NOR flash devices. these were technically
>>>>>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>>>>>
>>>>>>>> The problem with these were resides at drivers/spi is entire
>>>>>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>>>>>> a wrong indication where SPI layer getting effected more with
>>>>>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>>>>>> by separating all SPI-NOR flash operations from spi layer and
>>>>>>>> creats a generic layer called SPI-NOR core which can be used to
>>>>>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>>>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>>>>>
>>>>>>>> Before SPI-NOR:
>>>>>>>>
>>>>>>>> -----------------------
>>>>>>>> cmd/sf.c
>>>>>>>> -----------------------
>>>>>>>> spi_flash.c
>>>>>>>> -----------------------
>>>>>>>> sf_probe.c
>>>>>>>> -----------------------
>>>>>>>> spi-uclass
>>>>>>>> -----------------------
>>>>>>>> spi drivers
>>>>>>>> -----------------------
>>>>>>>> SPI NOR chip
>>>>>>>> -----------------------
>>>>>>>>
>>>>>>>> After SPI-NOR:
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>> cmd/sf.c
>>>>>>>> ------------------------------
>>>>>>>> spi-nor.c
>>>>>>>> -------------------------------
>>>>>>>> m25p80.c spi nor drivers
>>>>>>>> -------------------------------
>>>>>>>> spi-uclass SPI NOR chip
>>>>>>>> -------------------------------
>>>>>>>> spi drivers
>>>>>>>> -------------------------------
>>>>>>>> SPI NOR chip
>>>>>>>> -------------------------------
>>>>>>>>
>>>>>>>> SPI-NOR with MTD:
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>> cmd/sf.c
>>>>>>>> ------------------------------
>>>>>>>> MTD core
>>>>>>>> ------------------------------
>>>>>>>> spi-nor.c
>>>>>>>> -------------------------------
>>>>>>>> m25p80.c spi nor drivers
>>>>>>>> -------------------------------
>>>>>>>> spi-uclass SPI NOR chip
>>>>>>>> -------------------------------
>>>>>>>> spi drivers
>>>>>>>> -------------------------------
>>>>>>>> SPI NOR chip
>>>>>>>> -------------------------------
>>>>>>>>
>>>>>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>>>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>>>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>>>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>>>>
>>>>>>> Tested both DM and non-DM models
>>>>>>>
>>>>>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>>>>>
>>>>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>>>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>>>>> Warning - bad CRC, using default environment
>>>>>>
>>>>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>>>>> KiB, total 2 MiB
>>>>>> *** Warning - bad CRC, using default environment
>>>>>>
>>>>>> Anything wrong?
>>>>>
>>>>>
>>>>
>>>> I'm not getting the warning, after saveenv.
>>>>
>>>> DRAM: ECC disabled 1 GiB
>>>> MMC:
>>>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>>>> KiB, total 16 MiB
>>>> In: serial at e0001000
>>>> Out: serial at e0001000
>>>> Err: serial at e0001000
>>>> Model: Zynq MicroZED Board
>>>>
>>>
>>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>>
>>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>>
>>> CPU: x86, vendor Intel, device 590h
>>> DRAM: 256 MiB
>>> MMC: Quark SDHCI: 0
>>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Model: Intel Galileo
>>> Net:
>>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>>> eth0: eth_designware#0
>>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>>> , eth1: eth_designware#1
>>> Hit any key to stop autoboot: 0
>>> => saveenv
>>> Saving Environment to SPI Flash...
>>> Erasing SPI flash...Writing to SPI flash...done
>>> => reset
>>> resetting ...
>>>
>>>
>>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>>
>>> CPU: x86, vendor Intel, device 590h
>>> DRAM: 256 MiB
>>> MMC: Quark SDHCI: 0
>>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Model: Intel Galileo
>>> Net:
>>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>>> eth0: eth_designware#0
>>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>>> , eth1: eth_designware#1
>>> Hit any key to stop autoboot: 0
>>> =>
>>>
>>
>> Looks like you messed up the ICH SPI driver. Something went wrong with
>> your patch series. ICH SPI controller is a special one (only supports
>> slow read) especially when it comes to deal with an SST flash which is
>> even odd (only supports byte program). I feel this ICH SPI controller
>> is quite vulnerable to SPI changes as it breaks many times. Maybe
>> Jagan you can purchase one Crown Bay board for the SPI flash testing
>> (a joke!)
>>
>> logs below:
>>
>> => sf read 100000 100000 100
>> device 0 offset 0x100000, size 0x100
>> SF: 256 bytes @ 0x100000 Read: OK
>> => crc fff00000 100
>> crc32 for fff00000 ... fff000ff ==> ac8e7061
>> => crc 100000 100
>> crc32 for 00100000 ... 001000ff ==> b44fdefc
>>
>> See? the contents of 'sf read' to address 0x100000 does not match the
>> original one in SPI flash (0xfff00000)
>>
>> Anyway, I will continue debugging this.
>>
>
> Root cause identified. Patch available @
> http://patchwork.ozlabs.org/patch/584500/.
This should be http://patchwork.ozlabs.org/patch/584517/
I doubt storing all SPI modes into a single spi->mode is a good idea.
Previously they are separate variables.
> Please squash mine into an
> appropriate place in your series.
>
> Given the logic detection is completely wrong, I doubt how you tested
> this whole series. What boards/flashes have you tested this on?
>
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-18 5:24 ` Bin Meng
@ 2016-02-18 7:13 ` Jagan Teki
2016-02-18 7:22 ` Bin Meng
0 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-18 7:13 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 18 February 2016 at 10:54, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>>>> Compared to previous patch series this series adds spi-nor
>>>>>>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>>>>>>
>>>>>>>>> This is whole series for all spi-nor related changes, and while
>>>>>>>>> series tested on spansion spi-nor chip.
>>>>>>>>>
>>>>>>>>> Know issue:
>>>>>>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>>>>>>
>>>>>>>>> Why this framework:
>>>>>>>>>
>>>>>>>>> Some of the SPI device drivers at drivers/spi not a real
>>>>>>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>>>>>>> operates only with SPI-NOR flash devices. these were technically
>>>>>>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>>>>>>
>>>>>>>>> The problem with these were resides at drivers/spi is entire
>>>>>>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>>>>>>> a wrong indication where SPI layer getting effected more with
>>>>>>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>>>>>>> by separating all SPI-NOR flash operations from spi layer and
>>>>>>>>> creats a generic layer called SPI-NOR core which can be used to
>>>>>>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>>>>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>>>>>>
>>>>>>>>> Before SPI-NOR:
>>>>>>>>>
>>>>>>>>> -----------------------
>>>>>>>>> cmd/sf.c
>>>>>>>>> -----------------------
>>>>>>>>> spi_flash.c
>>>>>>>>> -----------------------
>>>>>>>>> sf_probe.c
>>>>>>>>> -----------------------
>>>>>>>>> spi-uclass
>>>>>>>>> -----------------------
>>>>>>>>> spi drivers
>>>>>>>>> -----------------------
>>>>>>>>> SPI NOR chip
>>>>>>>>> -----------------------
>>>>>>>>>
>>>>>>>>> After SPI-NOR:
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>> cmd/sf.c
>>>>>>>>> ------------------------------
>>>>>>>>> spi-nor.c
>>>>>>>>> -------------------------------
>>>>>>>>> m25p80.c spi nor drivers
>>>>>>>>> -------------------------------
>>>>>>>>> spi-uclass SPI NOR chip
>>>>>>>>> -------------------------------
>>>>>>>>> spi drivers
>>>>>>>>> -------------------------------
>>>>>>>>> SPI NOR chip
>>>>>>>>> -------------------------------
>>>>>>>>>
>>>>>>>>> SPI-NOR with MTD:
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>> cmd/sf.c
>>>>>>>>> ------------------------------
>>>>>>>>> MTD core
>>>>>>>>> ------------------------------
>>>>>>>>> spi-nor.c
>>>>>>>>> -------------------------------
>>>>>>>>> m25p80.c spi nor drivers
>>>>>>>>> -------------------------------
>>>>>>>>> spi-uclass SPI NOR chip
>>>>>>>>> -------------------------------
>>>>>>>>> spi drivers
>>>>>>>>> -------------------------------
>>>>>>>>> SPI NOR chip
>>>>>>>>> -------------------------------
>>>>>>>>>
>>>>>>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>>>>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>>>>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>>>>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>>>>>
>>>>>>>> Tested both DM and non-DM models
>>>>>>>>
>>>>>>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>>>>>>
>>>>>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>>>>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>>>>>> Warning - bad CRC, using default environment
>>>>>>>
>>>>>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>>>>>> KiB, total 2 MiB
>>>>>>> *** Warning - bad CRC, using default environment
>>>>>>>
>>>>>>> Anything wrong?
>>>>>>
>>>>>>
>>>>>
>>>>> I'm not getting the warning, after saveenv.
>>>>>
>>>>> DRAM: ECC disabled 1 GiB
>>>>> MMC:
>>>>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>>>>> KiB, total 16 MiB
>>>>> In: serial at e0001000
>>>>> Out: serial at e0001000
>>>>> Err: serial at e0001000
>>>>> Model: Zynq MicroZED Board
>>>>>
>>>>
>>>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>>>
>>>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>>>
>>>> CPU: x86, vendor Intel, device 590h
>>>> DRAM: 256 MiB
>>>> MMC: Quark SDHCI: 0
>>>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>>>> *** Warning - bad CRC, using default environment
>>>>
>>>> Model: Intel Galileo
>>>> Net:
>>>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>>>> eth0: eth_designware#0
>>>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>>>> , eth1: eth_designware#1
>>>> Hit any key to stop autoboot: 0
>>>> => saveenv
>>>> Saving Environment to SPI Flash...
>>>> Erasing SPI flash...Writing to SPI flash...done
>>>> => reset
>>>> resetting ...
>>>>
>>>>
>>>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>>>
>>>> CPU: x86, vendor Intel, device 590h
>>>> DRAM: 256 MiB
>>>> MMC: Quark SDHCI: 0
>>>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>>>> *** Warning - bad CRC, using default environment
>>>>
>>>> Model: Intel Galileo
>>>> Net:
>>>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>>>> eth0: eth_designware#0
>>>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>>>> , eth1: eth_designware#1
>>>> Hit any key to stop autoboot: 0
>>>> =>
>>>>
>>>
>>> Looks like you messed up the ICH SPI driver. Something went wrong with
>>> your patch series. ICH SPI controller is a special one (only supports
>>> slow read) especially when it comes to deal with an SST flash which is
>>> even odd (only supports byte program). I feel this ICH SPI controller
>>> is quite vulnerable to SPI changes as it breaks many times. Maybe
>>> Jagan you can purchase one Crown Bay board for the SPI flash testing
>>> (a joke!)
>>>
>>> logs below:
>>>
>>> => sf read 100000 100000 100
>>> device 0 offset 0x100000, size 0x100
>>> SF: 256 bytes @ 0x100000 Read: OK
>>> => crc fff00000 100
>>> crc32 for fff00000 ... fff000ff ==> ac8e7061
>>> => crc 100000 100
>>> crc32 for 00100000 ... 001000ff ==> b44fdefc
>>>
>>> See? the contents of 'sf read' to address 0x100000 does not match the
>>> original one in SPI flash (0xfff00000)
>>>
>>> Anyway, I will continue debugging this.
>>>
>>
>> Root cause identified. Patch available @
>> http://patchwork.ozlabs.org/patch/584500/.
>
> This should be http://patchwork.ozlabs.org/patch/584517/
>
> I doubt storing all SPI modes into a single spi->mode is a good idea.
> Previously they are separate variables.
>
>> Please squash mine into an
>> appropriate place in your series.
>>
>> Given the logic detection is completely wrong, I doubt how you tested
>> this whole series. What boards/flashes have you tested this on?
Yes the patch[1] where I missed the mode detection, over looked with
respect to previous one. thanks for identifying this. And the boards I
tested uses default read and write opcode that's the reason I
succeeded. Will squash your change on this.
[1] https://patchwork.ozlabs.org/patch/582615/
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-18 7:13 ` Jagan Teki
@ 2016-02-18 7:22 ` Bin Meng
0 siblings, 0 replies; 47+ messages in thread
From: Bin Meng @ 2016-02-18 7:22 UTC (permalink / raw)
To: u-boot
On Thu, Feb 18, 2016 at 3:13 PM, Jagan Teki <jteki@openedev.com> wrote:
> Hi Bin,
>
> On 18 February 2016 at 10:54, Bin Meng <bmeng.cn@gmail.com> wrote:
>> On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki@openedev.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 17 February 2016 at 13:07, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>>>>>>>> Compared to previous patch series this series adds spi-nor
>>>>>>>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>>>>>>>
>>>>>>>>>> This is whole series for all spi-nor related changes, and while
>>>>>>>>>> series tested on spansion spi-nor chip.
>>>>>>>>>>
>>>>>>>>>> Know issue:
>>>>>>>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>>>>>>>
>>>>>>>>>> Why this framework:
>>>>>>>>>>
>>>>>>>>>> Some of the SPI device drivers at drivers/spi not a real
>>>>>>>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>>>>>>>> operates only with SPI-NOR flash devices. these were technically
>>>>>>>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>>>>>>>
>>>>>>>>>> The problem with these were resides at drivers/spi is entire
>>>>>>>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>>>>>>>> a wrong indication where SPI layer getting effected more with
>>>>>>>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>>>>>>>> by separating all SPI-NOR flash operations from spi layer and
>>>>>>>>>> creats a generic layer called SPI-NOR core which can be used to
>>>>>>>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>>>>>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>>>>>>>
>>>>>>>>>> Before SPI-NOR:
>>>>>>>>>>
>>>>>>>>>> -----------------------
>>>>>>>>>> cmd/sf.c
>>>>>>>>>> -----------------------
>>>>>>>>>> spi_flash.c
>>>>>>>>>> -----------------------
>>>>>>>>>> sf_probe.c
>>>>>>>>>> -----------------------
>>>>>>>>>> spi-uclass
>>>>>>>>>> -----------------------
>>>>>>>>>> spi drivers
>>>>>>>>>> -----------------------
>>>>>>>>>> SPI NOR chip
>>>>>>>>>> -----------------------
>>>>>>>>>>
>>>>>>>>>> After SPI-NOR:
>>>>>>>>>>
>>>>>>>>>> ------------------------------
>>>>>>>>>> cmd/sf.c
>>>>>>>>>> ------------------------------
>>>>>>>>>> spi-nor.c
>>>>>>>>>> -------------------------------
>>>>>>>>>> m25p80.c spi nor drivers
>>>>>>>>>> -------------------------------
>>>>>>>>>> spi-uclass SPI NOR chip
>>>>>>>>>> -------------------------------
>>>>>>>>>> spi drivers
>>>>>>>>>> -------------------------------
>>>>>>>>>> SPI NOR chip
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> SPI-NOR with MTD:
>>>>>>>>>>
>>>>>>>>>> ------------------------------
>>>>>>>>>> cmd/sf.c
>>>>>>>>>> ------------------------------
>>>>>>>>>> MTD core
>>>>>>>>>> ------------------------------
>>>>>>>>>> spi-nor.c
>>>>>>>>>> -------------------------------
>>>>>>>>>> m25p80.c spi nor drivers
>>>>>>>>>> -------------------------------
>>>>>>>>>> spi-uclass SPI NOR chip
>>>>>>>>>> -------------------------------
>>>>>>>>>> spi drivers
>>>>>>>>>> -------------------------------
>>>>>>>>>> SPI NOR chip
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>>>>>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>>>>>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>>>>>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>>>>>>
>>>>>>>>> Tested both DM and non-DM models
>>>>>>>>>
>>>>>>>>> Tested-by: Jagan Teki <jteki@openedev.com>
>>>>>>>>
>>>>>>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>>>>>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>>>>>>> Warning - bad CRC, using default environment
>>>>>>>>
>>>>>>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>>>>>>> KiB, total 2 MiB
>>>>>>>> *** Warning - bad CRC, using default environment
>>>>>>>>
>>>>>>>> Anything wrong?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I'm not getting the warning, after saveenv.
>>>>>>
>>>>>> DRAM: ECC disabled 1 GiB
>>>>>> MMC:
>>>>>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>>>>>> KiB, total 16 MiB
>>>>>> In: serial at e0001000
>>>>>> Out: serial at e0001000
>>>>>> Err: serial at e0001000
>>>>>> Model: Zynq MicroZED Board
>>>>>>
>>>>>
>>>>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>>>>
>>>>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>>>>
>>>>> CPU: x86, vendor Intel, device 590h
>>>>> DRAM: 256 MiB
>>>>> MMC: Quark SDHCI: 0
>>>>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>>>>> *** Warning - bad CRC, using default environment
>>>>>
>>>>> Model: Intel Galileo
>>>>> Net:
>>>>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>>>>> eth0: eth_designware#0
>>>>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>>>>> , eth1: eth_designware#1
>>>>> Hit any key to stop autoboot: 0
>>>>> => saveenv
>>>>> Saving Environment to SPI Flash...
>>>>> Erasing SPI flash...Writing to SPI flash...done
>>>>> => reset
>>>>> resetting ...
>>>>>
>>>>>
>>>>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>>>>
>>>>> CPU: x86, vendor Intel, device 590h
>>>>> DRAM: 256 MiB
>>>>> MMC: Quark SDHCI: 0
>>>>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
>>>>> *** Warning - bad CRC, using default environment
>>>>>
>>>>> Model: Intel Galileo
>>>>> Net:
>>>>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>>>>> eth0: eth_designware#0
>>>>> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
>>>>> , eth1: eth_designware#1
>>>>> Hit any key to stop autoboot: 0
>>>>> =>
>>>>>
>>>>
>>>> Looks like you messed up the ICH SPI driver. Something went wrong with
>>>> your patch series. ICH SPI controller is a special one (only supports
>>>> slow read) especially when it comes to deal with an SST flash which is
>>>> even odd (only supports byte program). I feel this ICH SPI controller
>>>> is quite vulnerable to SPI changes as it breaks many times. Maybe
>>>> Jagan you can purchase one Crown Bay board for the SPI flash testing
>>>> (a joke!)
>>>>
>>>> logs below:
>>>>
>>>> => sf read 100000 100000 100
>>>> device 0 offset 0x100000, size 0x100
>>>> SF: 256 bytes @ 0x100000 Read: OK
>>>> => crc fff00000 100
>>>> crc32 for fff00000 ... fff000ff ==> ac8e7061
>>>> => crc 100000 100
>>>> crc32 for 00100000 ... 001000ff ==> b44fdefc
>>>>
>>>> See? the contents of 'sf read' to address 0x100000 does not match the
>>>> original one in SPI flash (0xfff00000)
>>>>
>>>> Anyway, I will continue debugging this.
>>>>
>>>
>>> Root cause identified. Patch available @
>>> http://patchwork.ozlabs.org/patch/584500/.
>>
>> This should be http://patchwork.ozlabs.org/patch/584517/
>>
>> I doubt storing all SPI modes into a single spi->mode is a good idea.
>> Previously they are separate variables.
>>
>>> Please squash mine into an
>>> appropriate place in your series.
>>>
>>> Given the logic detection is completely wrong, I doubt how you tested
>>> this whole series. What boards/flashes have you tested this on?
>
> Yes the patch[1] where I missed the mode detection, over looked with
> respect to previous one. thanks for identifying this. And the boards I
> tested uses default read and write opcode that's the reason I
> succeeded. Will squash your change on this.
>
> [1] https://patchwork.ozlabs.org/patch/582615/
>
Along with the patch http://patchwork.ozlabs.org/patch/584517/, on the
spi-nor branch of u-boot-spi repo
For the whole series, tested on Intel Crown Bay, Intel Galileo and
Intel Bayley Bay.
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Regards,
Bin
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-14 20:46 [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support Jagan Teki
2016-02-16 19:47 ` Jagan Teki
2016-02-17 19:00 ` Simon Glass
@ 2016-02-18 9:18 ` Jagan Teki
2016-02-22 18:17 ` Jagan Teki
3 siblings, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-18 9:18 UTC (permalink / raw)
To: u-boot
Hi Stefan/Siva/Mugunthan/Vikas/Others
On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
> Compared to previous patch series this series adds spi-nor
> core with spi-nor controller drivers are of "mtd uclass"
>
> This is whole series for all spi-nor related changes, and while
> series tested on spansion spi-nor chip.
>
> Know issue:
> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>
> Why this framework:
>
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>
> The problem with these were resides at drivers/spi is entire
> SPI layer becomes SPI-NOR flash oriented which is absolutely
> a wrong indication where SPI layer getting effected more with
> flash operations - So this SPI-NOR core will resolve this issue
> by separating all SPI-NOR flash operations from spi layer and
> creats a generic layer called SPI-NOR core which can be used to
> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> controller driver. The idea is taken from Linux spi-nor framework.
>
> Before SPI-NOR:
>
> -----------------------
> cmd/sf.c
> -----------------------
> spi_flash.c
> -----------------------
> sf_probe.c
> -----------------------
> spi-uclass
> -----------------------
> spi drivers
> -----------------------
> SPI NOR chip
> -----------------------
>
> After SPI-NOR:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> SPI-NOR with MTD:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> MTD core
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> which is an interface layer b/w spi-nor core drivers/spi
> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>
> Changes for v6:
> - Fixed git bisectable issues, with buildman.
> - Fixed spi-nor compilation issues
> - newly designed changes.
>
> Changes for v5:
> - newly designed changes
>
> Testing:
> $ git clone git://git.denx.de/u-boot-spi.git
> $ cd u-boot-spi
> $ git checkout -b spi-nor origin/spi-nor
Please test this series?
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-17 19:00 ` Simon Glass
2016-02-17 19:14 ` Jagan Teki
2016-02-17 20:08 ` Jagan Teki
@ 2016-02-22 8:57 ` Jagan Teki
2016-02-22 13:51 ` Tom Rini
2 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-22 8:57 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 18 February 2016 at 00:30, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On 14 February 2016 at 13:46, Jagan Teki <jteki@openedev.com> wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> -----------------------
>> cmd/sf.c
>> -----------------------
>> spi_flash.c
>> -----------------------
>> sf_probe.c
>> -----------------------
>> spi-uclass
>> -----------------------
>> spi drivers
>> -----------------------
>> SPI NOR chip
>> -----------------------
>>
>> After SPI-NOR:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> SPI-NOR with MTD:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> MTD core
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>
> I see quite a large rodata increase at this commit. Is it necessary?
>
> 67: configs: Use CONFIG_SPI_NOR_MISC
> arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0
> text +384.0
>
> There are also bisectability problems (build errors for some commits)
> - e.g. chromebook_jerry.
No bisectable issues now, made buildman test.
And here is image size test:
http://paste.ubuntu.com/15169227/
Size of entire series (step 0)
http://paste.ubuntu.com/15169235/
Let me know for any issues, I'm planning to send the whole series
again for final review.
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-22 8:57 ` Jagan Teki
@ 2016-02-22 13:51 ` Tom Rini
0 siblings, 0 replies; 47+ messages in thread
From: Tom Rini @ 2016-02-22 13:51 UTC (permalink / raw)
To: u-boot
On Mon, Feb 22, 2016 at 02:27:34PM +0530, Jagan Teki wrote:
> Hi Simon,
>
> On 18 February 2016 at 00:30, Simon Glass <sjg@chromium.org> wrote:
> > Hi Jagan,
> >
> > On 14 February 2016 at 13:46, Jagan Teki <jteki@openedev.com> wrote:
> >> Compared to previous patch series this series adds spi-nor
> >> core with spi-nor controller drivers are of "mtd uclass"
> >>
> >> This is whole series for all spi-nor related changes, and while
> >> series tested on spansion spi-nor chip.
> >>
> >> Know issue:
> >> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
> >>
> >> Why this framework:
> >>
> >> Some of the SPI device drivers at drivers/spi not a real
> >> spi controllers, Unlike normal/generic SPI controllers they
> >> operates only with SPI-NOR flash devices. these were technically
> >> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
> >>
> >> The problem with these were resides at drivers/spi is entire
> >> SPI layer becomes SPI-NOR flash oriented which is absolutely
> >> a wrong indication where SPI layer getting effected more with
> >> flash operations - So this SPI-NOR core will resolve this issue
> >> by separating all SPI-NOR flash operations from spi layer and
> >> creats a generic layer called SPI-NOR core which can be used to
> >> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> >> controller driver. The idea is taken from Linux spi-nor framework.
> >>
> >> Before SPI-NOR:
> >>
> >> -----------------------
> >> cmd/sf.c
> >> -----------------------
> >> spi_flash.c
> >> -----------------------
> >> sf_probe.c
> >> -----------------------
> >> spi-uclass
> >> -----------------------
> >> spi drivers
> >> -----------------------
> >> SPI NOR chip
> >> -----------------------
> >>
> >> After SPI-NOR:
> >>
> >> ------------------------------
> >> cmd/sf.c
> >> ------------------------------
> >> spi-nor.c
> >> -------------------------------
> >> m25p80.c spi nor drivers
> >> -------------------------------
> >> spi-uclass SPI NOR chip
> >> -------------------------------
> >> spi drivers
> >> -------------------------------
> >> SPI NOR chip
> >> -------------------------------
> >>
> >> SPI-NOR with MTD:
> >>
> >> ------------------------------
> >> cmd/sf.c
> >> ------------------------------
> >> MTD core
> >> ------------------------------
> >> spi-nor.c
> >> -------------------------------
> >> m25p80.c spi nor drivers
> >> -------------------------------
> >> spi-uclass SPI NOR chip
> >> -------------------------------
> >> spi drivers
> >> -------------------------------
> >> SPI NOR chip
> >> -------------------------------
> >>
> >> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> >> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> >> which is an interface layer b/w spi-nor core drivers/spi
> >> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
> >>
> >> Changes for v6:
> >> - Fixed git bisectable issues, with buildman.
> >> - Fixed spi-nor compilation issues
> >> - newly designed changes.
> >>
> >> Changes for v5:
> >> - newly designed changes
> >>
> >> Testing:
> >> $ git clone git://git.denx.de/u-boot-spi.git
> >> $ cd u-boot-spi
> >> $ git checkout -b spi-nor origin/spi-nor
> >
> > I see quite a large rodata increase at this commit. Is it necessary?
> >
> > 67: configs: Use CONFIG_SPI_NOR_MISC
> > arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0
> > text +384.0
> >
> > There are also bisectability problems (build errors for some commits)
> > - e.g. chromebook_jerry.
>
> No bisectable issues now, made buildman test.
>
> And here is image size test:
> http://paste.ubuntu.com/15169227/
>
> Size of entire series (step 0)
> http://paste.ubuntu.com/15169235/
Looks good, thanks.
> Let me know for any issues, I'm planning to send the whole series
> again for final review.
Please note that we're ~22 days from release, so this is too late for
v2016.03 but we can get it in right after release, if everyone is happy
otherwise.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160222/9a73f085/attachment.sig>
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-14 20:46 [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support Jagan Teki
` (2 preceding siblings ...)
2016-02-18 9:18 ` Jagan Teki
@ 2016-02-22 18:17 ` Jagan Teki
2016-02-22 18:41 ` york sun
` (2 more replies)
3 siblings, 3 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-22 18:17 UTC (permalink / raw)
To: u-boot
Hi York,
On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
> Compared to previous patch series this series adds spi-nor
> core with spi-nor controller drivers are of "mtd uclass"
>
> This is whole series for all spi-nor related changes, and while
> series tested on spansion spi-nor chip.
>
> Know issue:
> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>
> Why this framework:
>
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>
> The problem with these were resides at drivers/spi is entire
> SPI layer becomes SPI-NOR flash oriented which is absolutely
> a wrong indication where SPI layer getting effected more with
> flash operations - So this SPI-NOR core will resolve this issue
> by separating all SPI-NOR flash operations from spi layer and
> creats a generic layer called SPI-NOR core which can be used to
> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> controller driver. The idea is taken from Linux spi-nor framework.
>
> Before SPI-NOR:
>
> -----------------------
> cmd/sf.c
> -----------------------
> spi_flash.c
> -----------------------
> sf_probe.c
> -----------------------
> spi-uclass
> -----------------------
> spi drivers
> -----------------------
> SPI NOR chip
> -----------------------
>
> After SPI-NOR:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> SPI-NOR with MTD:
>
> ------------------------------
> cmd/sf.c
> ------------------------------
> MTD core
> ------------------------------
> spi-nor.c
> -------------------------------
> m25p80.c spi nor drivers
> -------------------------------
> spi-uclass SPI NOR chip
> -------------------------------
> spi drivers
> -------------------------------
> SPI NOR chip
> -------------------------------
>
> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> which is an interface layer b/w spi-nor core drivers/spi
> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>
> Changes for v6:
> - Fixed git bisectable issues, with buildman.
> - Fixed spi-nor compilation issues
> - newly designed changes.
>
> Changes for v5:
> - newly designed changes
>
> Testing:
> $ git clone git://git.denx.de/u-boot-spi.git
> $ cd u-boot-spi
> $ git checkout -b spi-nor origin/spi-nor
>
> Jagan Teki (76):
> mtd: Add m25p80 driver
> mtd: Add Kconfig entry for MTD_M25P80
> mtd: Add SPI-NOR core support
> doc: device-tree-bindings: jedec,spi-nor
> mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
> mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
> mtd: spi-nor: Add MTD support
> mtd: spi-nor: Add spi_nor support in m25p80
> mtd: spi-nor: Add dm spi-nor probing
> mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
> mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
> mtd: spi-nor: m25p80: Add spi_nor support for non-dm
> sf: Rename erase_size to erasesize
> sf: Use erasesize instead of sector_size
> sf: Use uint64_t for flash->size
> spi_flash: Use mtd_info operation for SPI-NOR
> spi_flash: Use spi_flash_t instead of struct spi_flash
> mtd: spi-nor: Move spi_read_then_write to spi layer
> spi: Rename spi_read_then_write to spi_write_then_read
> mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
> mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
> mtd: spi-nor: Copy spl files from drivers/mtd/spi
> mtd: spi-nor: spl: Follow ascending order of include headers
> mtd: spi-nor: fsl_espi_spl: Use mtd_info
> mtd: spi-nor: spi_spl_load: Use mtd_info
> mtd: spi-nor: Add flash vendor Kconfig entries
> arm: zynq: Kconfig: Select MTD uclass
> arm: zynq: Kconfig: Drop DM_SPI_FLASH
> defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
> defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
> defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
> spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
> configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
> configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
> mtd: spi-nor: Copy sf_dataflash
> mtd: dataflash: Remove unneeded spi data
> mtd: dataflash: Move flash id detection into jedec_probe
> mtd: dataflash: Fix add_dataflash return logic
> mtd: dataflash: Add UCLASS_MTD support
> mtd: dataflash: Use spi_write_then_read
> mtd: dataflash: Drop sf_internal.h
> mtd: dataflash: Minor cleanups
> mtd: Rename sf_dataflash.c to mtd_dataflash.c
> mtd: spi-nor: Add Kconfig entry for mtd_dataflash
> mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
> mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
> configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
> defconfig: ls1021aqds_qspi: Enable SPI-NOR
> defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-22 18:17 ` Jagan Teki
@ 2016-02-22 18:41 ` york sun
2016-02-22 18:52 ` Fabio Estevam
2016-02-26 20:44 ` york sun
2 siblings, 0 replies; 47+ messages in thread
From: york sun @ 2016-02-22 18:41 UTC (permalink / raw)
To: u-boot
On 02/22/2016 10:18 AM, Jagan Teki wrote:
> Hi York,
>
> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> -----------------------
>> cmd/sf.c
>> -----------------------
>> spi_flash.c
>> -----------------------
>> sf_probe.c
>> -----------------------
>> spi-uclass
>> -----------------------
>> spi drivers
>> -----------------------
>> SPI NOR chip
>> -----------------------
>>
>> After SPI-NOR:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> SPI-NOR with MTD:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> MTD core
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>>
>> Jagan Teki (76):
>> mtd: Add m25p80 driver
>> mtd: Add Kconfig entry for MTD_M25P80
>> mtd: Add SPI-NOR core support
>> doc: device-tree-bindings: jedec,spi-nor
>> mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>> mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>> mtd: spi-nor: Add MTD support
>> mtd: spi-nor: Add spi_nor support in m25p80
>> mtd: spi-nor: Add dm spi-nor probing
>> mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>> mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>> mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>> sf: Rename erase_size to erasesize
>> sf: Use erasesize instead of sector_size
>> sf: Use uint64_t for flash->size
>> spi_flash: Use mtd_info operation for SPI-NOR
>> spi_flash: Use spi_flash_t instead of struct spi_flash
>> mtd: spi-nor: Move spi_read_then_write to spi layer
>> spi: Rename spi_read_then_write to spi_write_then_read
>> mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>> mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>> mtd: spi-nor: Copy spl files from drivers/mtd/spi
>> mtd: spi-nor: spl: Follow ascending order of include headers
>> mtd: spi-nor: fsl_espi_spl: Use mtd_info
>> mtd: spi-nor: spi_spl_load: Use mtd_info
>> mtd: spi-nor: Add flash vendor Kconfig entries
>> arm: zynq: Kconfig: Select MTD uclass
>> arm: zynq: Kconfig: Drop DM_SPI_FLASH
>> defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>> defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>> defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>> spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>> configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>> configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>> mtd: spi-nor: Copy sf_dataflash
>> mtd: dataflash: Remove unneeded spi data
>> mtd: dataflash: Move flash id detection into jedec_probe
>> mtd: dataflash: Fix add_dataflash return logic
>> mtd: dataflash: Add UCLASS_MTD support
>> mtd: dataflash: Use spi_write_then_read
>> mtd: dataflash: Drop sf_internal.h
>> mtd: dataflash: Minor cleanups
>> mtd: Rename sf_dataflash.c to mtd_dataflash.c
>> mtd: spi-nor: Add Kconfig entry for mtd_dataflash
>> mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
>> mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
>> configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
>> defconfig: ls1021aqds_qspi: Enable SPI-NOR
>> defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
>
> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
I am trying to get there. I have a lot on my plate now. This may take a while.
York
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-22 18:17 ` Jagan Teki
2016-02-22 18:41 ` york sun
@ 2016-02-22 18:52 ` Fabio Estevam
2016-02-23 13:03 ` Jagan Teki
2016-02-26 20:44 ` york sun
2 siblings, 1 reply; 47+ messages in thread
From: Fabio Estevam @ 2016-02-22 18:52 UTC (permalink / raw)
To: u-boot
On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki <jteki@openedev.com> wrote:
> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
Does not even build for me (mx6qsabresd_defconfig) :
CC drivers/misc/mxc_ocotp.o
drivers/dfu/dfu_sf.c: In function ?dfu_read_medium_sf?:
drivers/dfu/dfu_sf.c:23:2: warning: passing argument 1 of
?spi_flash_read? from incompatible pointer type [enabled by default]
In file included from include/dfu.h:17:0,
from drivers/dfu/dfu_sf.c:11:
include/spi_flash.h:33:19: note: expected ?struct spi_flash_t *? but
argument is of type ?struct spi_flash *?
drivers/dfu/dfu_sf.c: In function ?find_sector?:
drivers/dfu/dfu_sf.c:28:50: error: dereferencing pointer to incomplete type
drivers/dfu/dfu_sf.c:29:19: error: dereferencing pointer to incomplete type
drivers/dfu/dfu_sf.c: In function ?dfu_write_medium_sf?:
drivers/dfu/dfu_sf.c:39:26: error: dereferencing pointer to incomplete type
drivers/dfu/dfu_sf.c:39:10: warning: passing argument 1 of
?spi_flash_erase? from incompatible pointer type [enabled by default]
In file included from include/dfu.h:17:0,
from drivers/dfu/dfu_sf.c:11:
include/spi_flash.h:45:19: note: expected ?struct spi_flash_t *? but
argument is of type ?struct spi_flash *?
drivers/dfu/dfu_sf.c:44:10: warning: passing argument 1 of
?spi_flash_write? from incompatible pointer type [enabled by default]
In file included from include/dfu.h:17:0,
from drivers/dfu/dfu_sf.c:11:
include/spi_flash.h:39:19: note: expected ?struct spi_flash_t *? but
argument is of type ?struct spi_flash *?
drivers/dfu/dfu_sf.c: In function ?dfu_free_entity_sf?:
drivers/dfu/dfu_sf.c:63:2: warning: passing argument 1 of
?spi_flash_free? from incompatible pointer type [enabled by default]
In file included from include/dfu.h:17:0,
from drivers/dfu/dfu_sf.c:11:
include/spi_flash.h:87:6: note: expected ?struct spi_flash_t *? but
argument is of type ?struct spi_flash *?
drivers/dfu/dfu_sf.c: In function ?dfu_fill_entity_sf?:
drivers/dfu/dfu_sf.c:120:19: warning: assignment from incompatible
pointer type [enabled by default]
drivers/dfu/dfu_sf.c:126:38: error: dereferencing pointer to incomplete type
drivers/dfu/dfu_sf.c:136:3: warning: passing argument 1 of
?spi_flash_free? from incompatible pointer type [enabled by default]
In file included from include/dfu.h:17:0,
from drivers/dfu/dfu_sf.c:11:
include/spi_flash.h:87:6: note: expected ?struct spi_flash_t *? but
argument is of type ?struct spi_flash *?
make[2]: *** [drivers/dfu/dfu_sf.o] Error 1
make[1]: *** [drivers/dfu] Error 2
make[1]: *** Waiting for unfinished jobs....
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-22 18:52 ` Fabio Estevam
@ 2016-02-23 13:03 ` Jagan Teki
2016-02-23 20:46 ` Fabio Estevam
0 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-23 13:03 UTC (permalink / raw)
To: u-boot
Hi Fabio,
On 23 February 2016 at 00:22, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki <jteki@openedev.com> wrote:
>
>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>
> Does not even build for me (mx6qsabresd_defconfig) :
Please try again, I think I missed some changes. mean while I ran
buildman again will update that one as well.
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-23 13:03 ` Jagan Teki
@ 2016-02-23 20:46 ` Fabio Estevam
2016-02-29 12:27 ` Jagan Teki
0 siblings, 1 reply; 47+ messages in thread
From: Fabio Estevam @ 2016-02-23 20:46 UTC (permalink / raw)
To: u-boot
On Tue, Feb 23, 2016 at 10:03 AM, Jagan Teki <jteki@openedev.com> wrote:
> Hi Fabio,
>
> On 23 February 2016 at 00:22, Fabio Estevam <festevam@gmail.com> wrote:
>> On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki <jteki@openedev.com> wrote:
>>
>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>
>> Does not even build for me (mx6qsabresd_defconfig) :
>
> Please try again, I think I missed some changes. mean while I ran
> buildman again will update that one as well.
Now it builds and basic sf commands work fine.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-22 18:17 ` Jagan Teki
2016-02-22 18:41 ` york sun
2016-02-22 18:52 ` Fabio Estevam
@ 2016-02-26 20:44 ` york sun
2016-02-26 23:04 ` Simon Glass
2016-02-29 12:26 ` Jagan Teki
2 siblings, 2 replies; 47+ messages in thread
From: york sun @ 2016-02-26 20:44 UTC (permalink / raw)
To: u-boot
On 02/22/2016 10:18 AM, Jagan Teki wrote:
> Hi York,
>
> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> -----------------------
>> cmd/sf.c
>> -----------------------
>> spi_flash.c
>> -----------------------
>> sf_probe.c
>> -----------------------
>> spi-uclass
>> -----------------------
>> spi drivers
>> -----------------------
>> SPI NOR chip
>> -----------------------
>>
>> After SPI-NOR:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> SPI-NOR with MTD:
>>
>> ------------------------------
>> cmd/sf.c
>> ------------------------------
>> MTD core
>> ------------------------------
>> spi-nor.c
>> -------------------------------
>> m25p80.c spi nor drivers
>> -------------------------------
>> spi-uclass SPI NOR chip
>> -------------------------------
>> spi drivers
>> -------------------------------
>> SPI NOR chip
>> -------------------------------
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>>
>> Jagan Teki (76):
>> mtd: Add m25p80 driver
>> mtd: Add Kconfig entry for MTD_M25P80
>> mtd: Add SPI-NOR core support
>> doc: device-tree-bindings: jedec,spi-nor
>> mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>> mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>> mtd: spi-nor: Add MTD support
>> mtd: spi-nor: Add spi_nor support in m25p80
>> mtd: spi-nor: Add dm spi-nor probing
>> mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>> mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>> mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>> sf: Rename erase_size to erasesize
>> sf: Use erasesize instead of sector_size
>> sf: Use uint64_t for flash->size
>> spi_flash: Use mtd_info operation for SPI-NOR
>> spi_flash: Use spi_flash_t instead of struct spi_flash
>> mtd: spi-nor: Move spi_read_then_write to spi layer
>> spi: Rename spi_read_then_write to spi_write_then_read
>> mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>> mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>> mtd: spi-nor: Copy spl files from drivers/mtd/spi
>> mtd: spi-nor: spl: Follow ascending order of include headers
>> mtd: spi-nor: fsl_espi_spl: Use mtd_info
>> mtd: spi-nor: spi_spl_load: Use mtd_info
>> mtd: spi-nor: Add flash vendor Kconfig entries
>> arm: zynq: Kconfig: Select MTD uclass
>> arm: zynq: Kconfig: Drop DM_SPI_FLASH
>> defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>> defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>> defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>> spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>> configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>> configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>> mtd: spi-nor: Copy sf_dataflash
>> mtd: dataflash: Remove unneeded spi data
>> mtd: dataflash: Move flash id detection into jedec_probe
>> mtd: dataflash: Fix add_dataflash return logic
>> mtd: dataflash: Add UCLASS_MTD support
>> mtd: dataflash: Use spi_write_then_read
>> mtd: dataflash: Drop sf_internal.h
>> mtd: dataflash: Minor cleanups
>> mtd: Rename sf_dataflash.c to mtd_dataflash.c
>> mtd: spi-nor: Add Kconfig entry for mtd_dataflash
>> mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
>> mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
>> configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
>> defconfig: ls1021aqds_qspi: Enable SPI-NOR
>> defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
>
> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>
Jagan,
I am getting there. Will test sf probe/read/write and probably boot on selected
platforms. Is there any specific platform/test in your mind?
York
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-26 20:44 ` york sun
@ 2016-02-26 23:04 ` Simon Glass
2016-02-29 12:38 ` Jagan Teki
2016-02-29 12:26 ` Jagan Teki
1 sibling, 1 reply; 47+ messages in thread
From: Simon Glass @ 2016-02-26 23:04 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On 26 February 2016 at 13:44, york sun <york.sun@nxp.com> wrote:
> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>> Hi York,
>>
>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> -----------------------
>>> cmd/sf.c
>>> -----------------------
>>> spi_flash.c
>>> -----------------------
>>> sf_probe.c
>>> -----------------------
>>> spi-uclass
>>> -----------------------
>>> spi drivers
>>> -----------------------
>>> SPI NOR chip
>>> -----------------------
>>>
>>> After SPI-NOR:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> SPI-NOR with MTD:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> MTD core
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Changes for v6:
>>> - Fixed git bisectable issues, with buildman.
>>> - Fixed spi-nor compilation issues
>>> - newly designed changes.
>>>
>>> Changes for v5:
>>> - newly designed changes
>>>
>>> Testing:
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b spi-nor origin/spi-nor
>>>
>>> Jagan Teki (76):
>>> mtd: Add m25p80 driver
>>> mtd: Add Kconfig entry for MTD_M25P80
>>> mtd: Add SPI-NOR core support
>>> doc: device-tree-bindings: jedec,spi-nor
>>> mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>>> mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>>> mtd: spi-nor: Add MTD support
>>> mtd: spi-nor: Add spi_nor support in m25p80
>>> mtd: spi-nor: Add dm spi-nor probing
>>> mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>>> mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>>> mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>>> sf: Rename erase_size to erasesize
>>> sf: Use erasesize instead of sector_size
>>> sf: Use uint64_t for flash->size
>>> spi_flash: Use mtd_info operation for SPI-NOR
>>> spi_flash: Use spi_flash_t instead of struct spi_flash
>>> mtd: spi-nor: Move spi_read_then_write to spi layer
>>> spi: Rename spi_read_then_write to spi_write_then_read
>>> mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>>> mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>>> mtd: spi-nor: Copy spl files from drivers/mtd/spi
>>> mtd: spi-nor: spl: Follow ascending order of include headers
>>> mtd: spi-nor: fsl_espi_spl: Use mtd_info
>>> mtd: spi-nor: spi_spl_load: Use mtd_info
>>> mtd: spi-nor: Add flash vendor Kconfig entries
>>> arm: zynq: Kconfig: Select MTD uclass
>>> arm: zynq: Kconfig: Drop DM_SPI_FLASH
>>> defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>>> defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>>> defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>>> spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>>> configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>>> configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>>> mtd: spi-nor: Copy sf_dataflash
>>> mtd: dataflash: Remove unneeded spi data
>>> mtd: dataflash: Move flash id detection into jedec_probe
>>> mtd: dataflash: Fix add_dataflash return logic
>>> mtd: dataflash: Add UCLASS_MTD support
>>> mtd: dataflash: Use spi_write_then_read
>>> mtd: dataflash: Drop sf_internal.h
>>> mtd: dataflash: Minor cleanups
>>> mtd: Rename sf_dataflash.c to mtd_dataflash.c
>>> mtd: spi-nor: Add Kconfig entry for mtd_dataflash
>>> mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
>>> mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
>>> configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
>>> defconfig: ls1021aqds_qspi: Enable SPI-NOR
>>> defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
>>
>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>
> Jagan,
>
> I am getting there. Will test sf probe/read/write and probably boot on selected
> platforms. Is there any specific platform/test in your mind?
Can you check test failures also? I re-enabled the SPI tests (see
u-boot-dm/master) and applied this series but get build warnings and a
test failure.
Also I see that the MTD uclass has replaced SPI flash. But the MTD
uclass does not have any operations...it does not seem to fit
correctly with driver model.
Regards,
Simon
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-26 20:44 ` york sun
2016-02-26 23:04 ` Simon Glass
@ 2016-02-29 12:26 ` Jagan Teki
2016-03-03 20:33 ` york sun
1 sibling, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-29 12:26 UTC (permalink / raw)
To: u-boot
Hi York,
On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>> Hi York,
>>
>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> -----------------------
>>> cmd/sf.c
>>> -----------------------
>>> spi_flash.c
>>> -----------------------
>>> sf_probe.c
>>> -----------------------
>>> spi-uclass
>>> -----------------------
>>> spi drivers
>>> -----------------------
>>> SPI NOR chip
>>> -----------------------
>>>
>>> After SPI-NOR:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> SPI-NOR with MTD:
>>>
>>> ------------------------------
>>> cmd/sf.c
>>> ------------------------------
>>> MTD core
>>> ------------------------------
>>> spi-nor.c
>>> -------------------------------
>>> m25p80.c spi nor drivers
>>> -------------------------------
>>> spi-uclass SPI NOR chip
>>> -------------------------------
>>> spi drivers
>>> -------------------------------
>>> SPI NOR chip
>>> -------------------------------
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Changes for v6:
>>> - Fixed git bisectable issues, with buildman.
>>> - Fixed spi-nor compilation issues
>>> - newly designed changes.
>>>
>>> Changes for v5:
>>> - newly designed changes
>>>
>>> Testing:
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b spi-nor origin/spi-nor
>>>
>>> Jagan Teki (76):
>>> mtd: Add m25p80 driver
>>> mtd: Add Kconfig entry for MTD_M25P80
>>> mtd: Add SPI-NOR core support
>>> doc: device-tree-bindings: jedec,spi-nor
>>> mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>>> mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>>> mtd: spi-nor: Add MTD support
>>> mtd: spi-nor: Add spi_nor support in m25p80
>>> mtd: spi-nor: Add dm spi-nor probing
>>> mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>>> mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>>> mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>>> sf: Rename erase_size to erasesize
>>> sf: Use erasesize instead of sector_size
>>> sf: Use uint64_t for flash->size
>>> spi_flash: Use mtd_info operation for SPI-NOR
>>> spi_flash: Use spi_flash_t instead of struct spi_flash
>>> mtd: spi-nor: Move spi_read_then_write to spi layer
>>> spi: Rename spi_read_then_write to spi_write_then_read
>>> mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>>> mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>>> mtd: spi-nor: Copy spl files from drivers/mtd/spi
>>> mtd: spi-nor: spl: Follow ascending order of include headers
>>> mtd: spi-nor: fsl_espi_spl: Use mtd_info
>>> mtd: spi-nor: spi_spl_load: Use mtd_info
>>> mtd: spi-nor: Add flash vendor Kconfig entries
>>> arm: zynq: Kconfig: Select MTD uclass
>>> arm: zynq: Kconfig: Drop DM_SPI_FLASH
>>> defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>>> defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>>> defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>>> spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>>> configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>>> configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>>> mtd: spi-nor: Copy sf_dataflash
>>> mtd: dataflash: Remove unneeded spi data
>>> mtd: dataflash: Move flash id detection into jedec_probe
>>> mtd: dataflash: Fix add_dataflash return logic
>>> mtd: dataflash: Add UCLASS_MTD support
>>> mtd: dataflash: Use spi_write_then_read
>>> mtd: dataflash: Drop sf_internal.h
>>> mtd: dataflash: Minor cleanups
>>> mtd: Rename sf_dataflash.c to mtd_dataflash.c
>>> mtd: spi-nor: Add Kconfig entry for mtd_dataflash
>>> mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
>>> mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
>>> configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
>>> defconfig: ls1021aqds_qspi: Enable SPI-NOR
>>> defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
>>
>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>
> Jagan,
>
> I am getting there. Will test sf probe/read/write and probably boot on selected
> platforms. Is there any specific platform/test in your mind?
Yes, these tests OK. and if possible please verify 'sf protect' as well.
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-23 20:46 ` Fabio Estevam
@ 2016-02-29 12:27 ` Jagan Teki
2016-02-29 12:34 ` Fabio Estevam
0 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-02-29 12:27 UTC (permalink / raw)
To: u-boot
Hi Fabio,
On 24 February 2016 at 02:16, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 10:03 AM, Jagan Teki <jteki@openedev.com> wrote:
>> Hi Fabio,
>>
>> On 23 February 2016 at 00:22, Fabio Estevam <festevam@gmail.com> wrote:
>>> On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki <jteki@openedev.com> wrote:
>>>
>>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>>
>>> Does not even build for me (mx6qsabresd_defconfig) :
>>
>> Please try again, I think I missed some changes. mean while I ran
>> buildman again will update that one as well.
>
> Now it builds and basic sf commands work fine.
Please verify 'sf protect' as well if you haven't tested.
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-29 12:27 ` Jagan Teki
@ 2016-02-29 12:34 ` Fabio Estevam
2016-02-29 12:39 ` Jagan Teki
0 siblings, 1 reply; 47+ messages in thread
From: Fabio Estevam @ 2016-02-29 12:34 UTC (permalink / raw)
To: u-boot
On Mon, Feb 29, 2016 at 9:27 AM, Jagan Teki <jteki@openedev.com> wrote:
> Please verify 'sf protect' as well if you haven't tested.
I tested it last week and it worked fine.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-26 23:04 ` Simon Glass
@ 2016-02-29 12:38 ` Jagan Teki
0 siblings, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-29 12:38 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 27 February 2016 at 04:34, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On 26 February 2016 at 13:44, york sun <york.sun@nxp.com> wrote:
>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>>> Hi York,
>>>
>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>> Compared to previous patch series this series adds spi-nor
>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>
>>>> This is whole series for all spi-nor related changes, and while
>>>> series tested on spansion spi-nor chip.
>>>>
>>>> Know issue:
>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>
>>>> Why this framework:
>>>>
>>>> Some of the SPI device drivers at drivers/spi not a real
>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>> operates only with SPI-NOR flash devices. these were technically
>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>
>>>> The problem with these were resides at drivers/spi is entire
>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>> a wrong indication where SPI layer getting effected more with
>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>> by separating all SPI-NOR flash operations from spi layer and
>>>> creats a generic layer called SPI-NOR core which can be used to
>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>
>>>> Before SPI-NOR:
>>>>
>>>> -----------------------
>>>> cmd/sf.c
>>>> -----------------------
>>>> spi_flash.c
>>>> -----------------------
>>>> sf_probe.c
>>>> -----------------------
>>>> spi-uclass
>>>> -----------------------
>>>> spi drivers
>>>> -----------------------
>>>> SPI NOR chip
>>>> -----------------------
>>>>
>>>> After SPI-NOR:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> SPI-NOR with MTD:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> MTD core
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>
>>>> Changes for v6:
>>>> - Fixed git bisectable issues, with buildman.
>>>> - Fixed spi-nor compilation issues
>>>> - newly designed changes.
>>>>
>>>> Changes for v5:
>>>> - newly designed changes
>>>>
>>>> Testing:
>>>> $ git clone git://git.denx.de/u-boot-spi.git
>>>> $ cd u-boot-spi
>>>> $ git checkout -b spi-nor origin/spi-nor
>>>>
>>>> Jagan Teki (76):
>>>> mtd: Add m25p80 driver
>>>> mtd: Add Kconfig entry for MTD_M25P80
>>>> mtd: Add SPI-NOR core support
>>>> doc: device-tree-bindings: jedec,spi-nor
>>>> mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>>>> mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>>>> mtd: spi-nor: Add MTD support
>>>> mtd: spi-nor: Add spi_nor support in m25p80
>>>> mtd: spi-nor: Add dm spi-nor probing
>>>> mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>>>> mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>>>> mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>>>> sf: Rename erase_size to erasesize
>>>> sf: Use erasesize instead of sector_size
>>>> sf: Use uint64_t for flash->size
>>>> spi_flash: Use mtd_info operation for SPI-NOR
>>>> spi_flash: Use spi_flash_t instead of struct spi_flash
>>>> mtd: spi-nor: Move spi_read_then_write to spi layer
>>>> spi: Rename spi_read_then_write to spi_write_then_read
>>>> mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>>>> mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>>>> mtd: spi-nor: Copy spl files from drivers/mtd/spi
>>>> mtd: spi-nor: spl: Follow ascending order of include headers
>>>> mtd: spi-nor: fsl_espi_spl: Use mtd_info
>>>> mtd: spi-nor: spi_spl_load: Use mtd_info
>>>> mtd: spi-nor: Add flash vendor Kconfig entries
>>>> arm: zynq: Kconfig: Select MTD uclass
>>>> arm: zynq: Kconfig: Drop DM_SPI_FLASH
>>>> defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>>>> defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>>>> defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>>>> spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>>>> configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>>>> configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>>>> mtd: spi-nor: Copy sf_dataflash
>>>> mtd: dataflash: Remove unneeded spi data
>>>> mtd: dataflash: Move flash id detection into jedec_probe
>>>> mtd: dataflash: Fix add_dataflash return logic
>>>> mtd: dataflash: Add UCLASS_MTD support
>>>> mtd: dataflash: Use spi_write_then_read
>>>> mtd: dataflash: Drop sf_internal.h
>>>> mtd: dataflash: Minor cleanups
>>>> mtd: Rename sf_dataflash.c to mtd_dataflash.c
>>>> mtd: spi-nor: Add Kconfig entry for mtd_dataflash
>>>> mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
>>>> mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
>>>> configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
>>>> defconfig: ls1021aqds_qspi: Enable SPI-NOR
>>>> defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
>>>
>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>>
>> Jagan,
>>
>> I am getting there. Will test sf probe/read/write and probably boot on selected
>> platforms. Is there any specific platform/test in your mind?
>
> Can you check test failures also? I re-enabled the SPI tests (see
> u-boot-dm/master) and applied this series but get build warnings and a
> test failure.
Yes I will add those fixes as well.
>
> Also I see that the MTD uclass has replaced SPI flash. But the MTD
> uclass does not have any operations...it does not seem to fit
> correctly with driver model.
True, we need to add these as well. Since MTD is common for most of
the flash's, we need to discuss for proper additions.
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-29 12:34 ` Fabio Estevam
@ 2016-02-29 12:39 ` Jagan Teki
0 siblings, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-02-29 12:39 UTC (permalink / raw)
To: u-boot
On 29 February 2016 at 18:04, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Feb 29, 2016 at 9:27 AM, Jagan Teki <jteki@openedev.com> wrote:
>
>> Please verify 'sf protect' as well if you haven't tested.
>
> I tested it last week and it worked fine.
OK, thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-02-29 12:26 ` Jagan Teki
@ 2016-03-03 20:33 ` york sun
2016-03-07 16:45 ` york sun
0 siblings, 1 reply; 47+ messages in thread
From: york sun @ 2016-03-03 20:33 UTC (permalink / raw)
To: u-boot
On 02/29/2016 04:26 AM, Jagan Teki wrote:
> Hi York,
>
> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>>> Hi York,
>>>
>>> On 15 February 2016 at 02:16, Jagan Teki <jteki@openedev.com> wrote:
>>>> Compared to previous patch series this series adds spi-nor
>>>> core with spi-nor controller drivers are of "mtd uclass"
>>>>
>>>> This is whole series for all spi-nor related changes, and while
>>>> series tested on spansion spi-nor chip.
>>>>
>>>> Know issue:
>>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>>
>>>> Why this framework:
>>>>
>>>> Some of the SPI device drivers at drivers/spi not a real
>>>> spi controllers, Unlike normal/generic SPI controllers they
>>>> operates only with SPI-NOR flash devices. these were technically
>>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>>
>>>> The problem with these were resides at drivers/spi is entire
>>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>>> a wrong indication where SPI layer getting effected more with
>>>> flash operations - So this SPI-NOR core will resolve this issue
>>>> by separating all SPI-NOR flash operations from spi layer and
>>>> creats a generic layer called SPI-NOR core which can be used to
>>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>>
>>>> Before SPI-NOR:
>>>>
>>>> -----------------------
>>>> cmd/sf.c
>>>> -----------------------
>>>> spi_flash.c
>>>> -----------------------
>>>> sf_probe.c
>>>> -----------------------
>>>> spi-uclass
>>>> -----------------------
>>>> spi drivers
>>>> -----------------------
>>>> SPI NOR chip
>>>> -----------------------
>>>>
>>>> After SPI-NOR:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> SPI-NOR with MTD:
>>>>
>>>> ------------------------------
>>>> cmd/sf.c
>>>> ------------------------------
>>>> MTD core
>>>> ------------------------------
>>>> spi-nor.c
>>>> -------------------------------
>>>> m25p80.c spi nor drivers
>>>> -------------------------------
>>>> spi-uclass SPI NOR chip
>>>> -------------------------------
>>>> spi drivers
>>>> -------------------------------
>>>> SPI NOR chip
>>>> -------------------------------
>>>>
>>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>>> which is an interface layer b/w spi-nor core drivers/spi
>>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>>
>>>> Changes for v6:
>>>> - Fixed git bisectable issues, with buildman.
>>>> - Fixed spi-nor compilation issues
>>>> - newly designed changes.
>>>>
>>>> Changes for v5:
>>>> - newly designed changes
>>>>
>>>> Testing:
>>>> $ git clone git://git.denx.de/u-boot-spi.git
>>>> $ cd u-boot-spi
>>>> $ git checkout -b spi-nor origin/spi-nor
>>>>
>>>> Jagan Teki (76):
>>>> mtd: Add m25p80 driver
>>>> mtd: Add Kconfig entry for MTD_M25P80
>>>> mtd: Add SPI-NOR core support
>>>> doc: device-tree-bindings: jedec,spi-nor
>>>> mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>>>> mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>>>> mtd: spi-nor: Add MTD support
>>>> mtd: spi-nor: Add spi_nor support in m25p80
>>>> mtd: spi-nor: Add dm spi-nor probing
>>>> mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>>>> mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>>>> mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>>>> sf: Rename erase_size to erasesize
>>>> sf: Use erasesize instead of sector_size
>>>> sf: Use uint64_t for flash->size
>>>> spi_flash: Use mtd_info operation for SPI-NOR
>>>> spi_flash: Use spi_flash_t instead of struct spi_flash
>>>> mtd: spi-nor: Move spi_read_then_write to spi layer
>>>> spi: Rename spi_read_then_write to spi_write_then_read
>>>> mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>>>> mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>>>> mtd: spi-nor: Copy spl files from drivers/mtd/spi
>>>> mtd: spi-nor: spl: Follow ascending order of include headers
>>>> mtd: spi-nor: fsl_espi_spl: Use mtd_info
>>>> mtd: spi-nor: spi_spl_load: Use mtd_info
>>>> mtd: spi-nor: Add flash vendor Kconfig entries
>>>> arm: zynq: Kconfig: Select MTD uclass
>>>> arm: zynq: Kconfig: Drop DM_SPI_FLASH
>>>> defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>>>> defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>>>> defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>>>> spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>>>> configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>>>> configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>>>> mtd: spi-nor: Copy sf_dataflash
>>>> mtd: dataflash: Remove unneeded spi data
>>>> mtd: dataflash: Move flash id detection into jedec_probe
>>>> mtd: dataflash: Fix add_dataflash return logic
>>>> mtd: dataflash: Add UCLASS_MTD support
>>>> mtd: dataflash: Use spi_write_then_read
>>>> mtd: dataflash: Drop sf_internal.h
>>>> mtd: dataflash: Minor cleanups
>>>> mtd: Rename sf_dataflash.c to mtd_dataflash.c
>>>> mtd: spi-nor: Add Kconfig entry for mtd_dataflash
>>>> mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY
>>>> mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY
>>>> configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH
>>>> defconfig: ls1021aqds_qspi: Enable SPI-NOR
>>>> defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH
>>>
>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>>
>> Jagan,
>>
>> I am getting there. Will test sf probe/read/write and probably boot on selected
>> platforms. Is there any specific platform/test in your mind?
>
> Yes, these tests OK. and if possible please verify 'sf protect' as well.
>
Jagan,
Sorry for the delay. I am having issue with both ls1021aqds and ls1043aqds. Need
to work with internal team to sort it out.
My understanding the tests you need are for spi-nor, in my case, fsl-qspi,
right? This is not for fsl-dspi or fsl-espi driver. I only have ls1021aqds and
ls1043aqds with such support.
York
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-03 20:33 ` york sun
@ 2016-03-07 16:45 ` york sun
2016-03-09 3:17 ` Huan Wang
2016-03-09 8:07 ` Qianyu Gong
0 siblings, 2 replies; 47+ messages in thread
From: york sun @ 2016-03-07 16:45 UTC (permalink / raw)
To: u-boot
On 03/03/2016 01:06 PM, york sun wrote:
> On 02/29/2016 04:26 AM, Jagan Teki wrote:
>> Hi York,
>>
>> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
>>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
<snip>
>>>>
>>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>>>
>>> Jagan,
>>>
>>> I am getting there. Will test sf probe/read/write and probably boot on selected
>>> platforms. Is there any specific platform/test in your mind?
>>
>> Yes, these tests OK. and if possible please verify 'sf protect' as well.
>>
>
> Jagan,
>
> Sorry for the delay. I am having issue with both ls1021aqds and ls1043aqds. Need
> to work with internal team to sort it out.
>
> My understanding the tests you need are for spi-nor, in my case, fsl-qspi,
> right? This is not for fsl-dspi or fsl-espi driver. I only have ls1021aqds and
> ls1043aqds with such support.
>
Jagan,
Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some
issues. They will post their findings (and possible fix) to this thread.
York
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-07 16:45 ` york sun
@ 2016-03-09 3:17 ` Huan Wang
2016-03-09 8:07 ` Qianyu Gong
1 sibling, 0 replies; 47+ messages in thread
From: Huan Wang @ 2016-03-09 3:17 UTC (permalink / raw)
To: u-boot
Hi, Jagan,
> On 03/03/2016 01:06 PM, york sun wrote:
> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
> >> Hi York,
> >>
> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>
> <snip>
>
> >>>>
> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
> >>>>
> >>> Jagan,
> >>>
> >>> I am getting there. Will test sf probe/read/write and probably boot
> >>> on selected platforms. Is there any specific platform/test in your
> mind?
> >>
> >> Yes, these tests OK. and if possible please verify 'sf protect' as
> well.
> >>
> >
> > Jagan,
> >
> > Sorry for the delay. I am having issue with both ls1021aqds and
> > ls1043aqds. Need to work with internal team to sort it out.
> >
> > My understanding the tests you need are for spi-nor, in my case,
> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only
> > have ls1021aqds and ls1043aqds with such support.
> >
>
> Jagan,
>
> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were
> some issues. They will post their findings (and possible fix) to this
> thread.
>
[Alison Wang] I verified QSPI boot on LS1021AQDS and LS1021ATWR boards based
on u-boot-spi/spi-nor branch. As we also support QSPI in SD boot, some modifications
are needed for ls1021aqds_sdcard_qspi_defconfig and ls1021atwr_sdcard_qspi_defconfig.
I submitted a set for the modifications, please help to review.
http://patchwork.ozlabs.org/patch/594819/
http://patchwork.ozlabs.org/patch/594820/
BTW, I have a concern about so much debugging information. Could we print them only when debugging?
drivers/mtd/spi-nor/m25p80.c:
printf("m25p80: 0x%p => cmd = { 0x%02x 0x%02x%02x%02x } chunk_len = %zu\n",
buf, flash->command[0], flash->command[1], flash->command[2],
flash->command[3], len);
=> run upqspiboot
Speed: 1000, full duplex
Using eTSEC3 device
TFTP from server 10.192.208.233; our IP address is 10.193.20.116
Filename 'wh/ls1/u-boot-qspiboot-swap.bin'.
Load address: 0x82000000
Loading: ###################################
1.5 MiB/s
done
Bytes transferred = 508532 (7c274 hex)
m25p80: erase d8 1 0 0 (10000)
m25p80: erase d8 2 0 0 (20000)
m25p80: erase d8 3 0 0 (30000)
m25p80: erase d8 4 0 0 (40000)
m25p80: erase d8 5 0 0 (50000)
m25p80: erase d8 6 0 0 (60000)
m25p80: erase d8 7 0 0 (70000)
m25p80: erase d8 8 0 0 (80000)
m25p80: erase d8 9 0 0 (90000)
SF: 589824 bytes @ 0x10000 Erased: OK
device 0 offset 0x10000, size 0x80000
m25p80: 0x82000000 => cmd = { 0x02 0x010000 } chunk_len = 64
m25p80: 0x82000040 => cmd = { 0x02 0x010040 } chunk_len = 64
m25p80: 0x82000080 => cmd = { 0x02 0x010080 } chunk_len = 64
m25p80: 0x820000c0 => cmd = { 0x02 0x0100c0 } chunk_len = 64
m25p80: 0x82000100 => cmd = { 0x02 0x010100 } chunk_len = 64
m25p80: 0x82000140 => cmd = { 0x02 0x010140 } chunk_len = 64
m25p80: 0x82000180 => cmd = { 0x02 0x010180 } chunk_len = 64
m25p80: 0x820001c0 => cmd = { 0x02 0x0101c0 } chunk_len = 64
m25p80: 0x82000200 => cmd = { 0x02 0x010200 } chunk_len = 64
m25p80: 0x82000240 => cmd = { 0x02 0x010240 } chunk_len = 64
m25p80: 0x82000280 => cmd = { 0x02 0x010280 } chunk_len = 64
m25p80: 0x820002c0 => cmd = { 0x02 0x0102c0 } chunk_len = 64
m25p80: 0x82000300 => cmd = { 0x02 0x010300 } chunk_len = 64
m25p80: 0x82000340 => cmd = { 0x02 0x010340 } chunk_len = 64
m25p80: 0x82000380 => cmd = { 0x02 0x010380 } chunk_len = 64
m25p80: 0x820003c0 => cmd = { 0x02 0x0103c0 } chunk_len = 64
.... (So much..)
Best Regards,
Alison Wang
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-07 16:45 ` york sun
2016-03-09 3:17 ` Huan Wang
@ 2016-03-09 8:07 ` Qianyu Gong
2016-03-15 11:18 ` Jagan Teki
1 sibling, 1 reply; 47+ messages in thread
From: Qianyu Gong @ 2016-03-09 8:07 UTC (permalink / raw)
To: u-boot
Hi Jagan,
> -----Original Message-----
> From: york sun
> Sent: Tuesday, March 08, 2016 12:46 AM
> To: Jagan Teki <jteki@openedev.com>; Huan Wang <alison.wang@nxp.com>;
> Qianyu Gong <qianyu.gong@nxp.com>
> Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <sivadur@xilinx.com>;
> Stefan Roese <sr@denx.de>; Michal Simek <michal.simek@xilinx.com>; Tom Rini
> <trini@konsulko.com>
> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>
> On 03/03/2016 01:06 PM, york sun wrote:
> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
> >> Hi York,
> >>
> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>
> <snip>
>
> >>>>
> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
> >>>>
> >>> Jagan,
> >>>
> >>> I am getting there. Will test sf probe/read/write and probably boot
> >>> on selected platforms. Is there any specific platform/test in your mind?
> >>
> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
> >>
> >
> > Jagan,
> >
> > Sorry for the delay. I am having issue with both ls1021aqds and
> > ls1043aqds. Need to work with internal team to sort it out.
> >
> > My understanding the tests you need are for spi-nor, in my case,
> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only
> > have ls1021aqds and ls1043aqds with such support.
> >
>
> Jagan,
>
> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some
> issues. They will post their findings (and possible fix) to this thread.
>
> York
I tested on LS1043AQDS board based on your spi-nor branch. The 'spi_flash_probe'
failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is not defined
for the board but it could be selected if CONFIG_MTD && CONFIG_DM_SPI, correct?
So after I moved CONFIG_MTD to the defconfig file, the probing could work now.
And there is another small effect on our Fman driver. It would like to read ucode blob
from the QSPI flash. As the 'spi_flash_read' interface is changed, I've modified the address
value to an offset value in flash.
Here are my patches:
http://patchwork.ozlabs.org/patch/594872/
http://patchwork.ozlabs.org/patch/594873/
http://patchwork.ozlabs.org/patch/594874/
Regards,
Qianyu
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-09 8:07 ` Qianyu Gong
@ 2016-03-15 11:18 ` Jagan Teki
2016-03-15 11:20 ` Jagan Teki
` (2 more replies)
0 siblings, 3 replies; 47+ messages in thread
From: Jagan Teki @ 2016-03-15 11:18 UTC (permalink / raw)
To: u-boot
On 9 March 2016 at 13:37, Qianyu Gong <qianyu.gong@nxp.com> wrote:
> Hi Jagan,
>
>> -----Original Message-----
>> From: york sun
>> Sent: Tuesday, March 08, 2016 12:46 AM
>> To: Jagan Teki <jteki@openedev.com>; Huan Wang <alison.wang@nxp.com>;
>> Qianyu Gong <qianyu.gong@nxp.com>
>> Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <sivadur@xilinx.com>;
>> Stefan Roese <sr@denx.de>; Michal Simek <michal.simek@xilinx.com>; Tom Rini
>> <trini@konsulko.com>
>> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>>
>> On 03/03/2016 01:06 PM, york sun wrote:
>> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
>> >> Hi York,
>> >>
>> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
>> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>>
>> <snip>
>>
>> >>>>
>> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>> >>>>
>> >>> Jagan,
>> >>>
>> >>> I am getting there. Will test sf probe/read/write and probably boot
>> >>> on selected platforms. Is there any specific platform/test in your mind?
>> >>
>> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
>> >>
>> >
>> > Jagan,
>> >
>> > Sorry for the delay. I am having issue with both ls1021aqds and
>> > ls1043aqds. Need to work with internal team to sort it out.
>> >
>> > My understanding the tests you need are for spi-nor, in my case,
>> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only
>> > have ls1021aqds and ls1043aqds with such support.
>> >
>>
>> Jagan,
>>
>> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some
>> issues. They will post their findings (and possible fix) to this thread.
>>
>> York
>
> I tested on LS1043AQDS board based on your spi-nor branch. The 'spi_flash_probe'
> failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is not defined
> for the board but it could be selected if CONFIG_MTD && CONFIG_DM_SPI, correct?
>
> So after I moved CONFIG_MTD to the defconfig file, the probing could work now.
>
> And there is another small effect on our Fman driver. It would like to read ucode blob
> from the QSPI flash. As the 'spi_flash_read' interface is changed, I've modified the address
> value to an offset value in flash.
Qianyu,
> Here are my patches:
> http://patchwork.ozlabs.org/patch/594872/
> http://patchwork.ozlabs.org/patch/594873/
> http://patchwork.ozlabs.org/patch/594874/
I have applied 3rd patch on my test branch, and remaining two will go
in another time like once spi-nor got merged.
Qianyu/Alison Wang,
Please test this[1] branch for your new changes and let me know for any issues.
[1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor-next
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-15 11:18 ` Jagan Teki
@ 2016-03-15 11:20 ` Jagan Teki
2016-03-16 3:44 ` Qianyu Gong
2016-03-17 1:07 ` Huan Wang
2 siblings, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-03-15 11:20 UTC (permalink / raw)
To: u-boot
Hi Mugunthan,
On 15 March 2016 at 16:48, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On 9 March 2016 at 13:37, Qianyu Gong <qianyu.gong@nxp.com> wrote:
>> Hi Jagan,
>>
>>> -----Original Message-----
>>> From: york sun
>>> Sent: Tuesday, March 08, 2016 12:46 AM
>>> To: Jagan Teki <jteki@openedev.com>; Huan Wang <alison.wang@nxp.com>;
>>> Qianyu Gong <qianyu.gong@nxp.com>
>>> Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <sivadur@xilinx.com>;
>>> Stefan Roese <sr@denx.de>; Michal Simek <michal.simek@xilinx.com>; Tom Rini
>>> <trini@konsulko.com>
>>> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>>>
>>> On 03/03/2016 01:06 PM, york sun wrote:
>>> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
>>> >> Hi York,
>>> >>
>>> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
>>> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>>>
>>> <snip>
>>>
>>> >>>>
>>> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>> >>>>
>>> >>> Jagan,
>>> >>>
>>> >>> I am getting there. Will test sf probe/read/write and probably boot
>>> >>> on selected platforms. Is there any specific platform/test in your mind?
>>> >>
>>> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
>>> >>
>>> >
>>> > Jagan,
>>> >
>>> > Sorry for the delay. I am having issue with both ls1021aqds and
>>> > ls1043aqds. Need to work with internal team to sort it out.
>>> >
>>> > My understanding the tests you need are for spi-nor, in my case,
>>> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only
>>> > have ls1021aqds and ls1043aqds with such support.
>>> >
>>>
>>> Jagan,
>>>
>>> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some
>>> issues. They will post their findings (and possible fix) to this thread.
>>>
>>> York
>>
>> I tested on LS1043AQDS board based on your spi-nor branch. The 'spi_flash_probe'
>> failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is not defined
>> for the board but it could be selected if CONFIG_MTD && CONFIG_DM_SPI, correct?
>>
>> So after I moved CONFIG_MTD to the defconfig file, the probing could work now.
>>
>> And there is another small effect on our Fman driver. It would like to read ucode blob
>> from the QSPI flash. As the 'spi_flash_read' interface is changed, I've modified the address
>> value to an offset value in flash.
>
> Qianyu,
>
>> Here are my patches:
>> http://patchwork.ozlabs.org/patch/594872/
>> http://patchwork.ozlabs.org/patch/594873/
>> http://patchwork.ozlabs.org/patch/594874/
>
> I have applied 3rd patch on my test branch, and remaining two will go
> in another time like once spi-nor got merged.
>
> Qianyu/Alison Wang,
>
> Please test this[1] branch for your new changes and let me know for any issues.
>
Please test this [1] branch on your hardware, dra72/74 look some build
issues, please fix accordingly.
[1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor-next
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-15 11:18 ` Jagan Teki
2016-03-15 11:20 ` Jagan Teki
@ 2016-03-16 3:44 ` Qianyu Gong
2016-03-16 14:20 ` Jagan Teki
2016-03-17 1:07 ` Huan Wang
2 siblings, 1 reply; 47+ messages in thread
From: Qianyu Gong @ 2016-03-16 3:44 UTC (permalink / raw)
To: u-boot
> -----Original Message-----
> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
> Sent: Tuesday, March 15, 2016 7:18 PM
> To: Qianyu Gong <qianyu.gong@nxp.com>; Huan Wang <alison.wang@nxp.com>
> Cc: york sun <york.sun@nxp.com>; Tom Rini <trini@konsulko.com>; Siva Durga
> Prasad Paladugu <sivadur@xilinx.com>; Michal Simek <michal.simek@xilinx.com>;
> u-boot at lists.denx.de; Stefan Roese <sr@denx.de>; Mingkai Hu
> <mingkai.hu@nxp.com>
> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>
> On 9 March 2016 at 13:37, Qianyu Gong <qianyu.gong@nxp.com> wrote:
> > Hi Jagan,
> >
> >> -----Original Message-----
> >> From: york sun
> >> Sent: Tuesday, March 08, 2016 12:46 AM
> >> To: Jagan Teki <jteki@openedev.com>; Huan Wang <alison.wang@nxp.com>;
> >> Qianyu Gong <qianyu.gong@nxp.com>
> >> Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu
> >> <sivadur@xilinx.com>; Stefan Roese <sr@denx.de>; Michal Simek
> >> <michal.simek@xilinx.com>; Tom Rini <trini@konsulko.com>
> >> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
> >>
> >> On 03/03/2016 01:06 PM, york sun wrote:
> >> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
> >> >> Hi York,
> >> >>
> >> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
> >> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
> >>
> >> <snip>
> >>
> >> >>>>
> >> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
> >> >>>>
> >> >>> Jagan,
> >> >>>
> >> >>> I am getting there. Will test sf probe/read/write and probably
> >> >>> boot on selected platforms. Is there any specific platform/test in your mind?
> >> >>
> >> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
> >> >>
> >> >
> >> > Jagan,
> >> >
> >> > Sorry for the delay. I am having issue with both ls1021aqds and
> >> > ls1043aqds. Need to work with internal team to sort it out.
> >> >
> >> > My understanding the tests you need are for spi-nor, in my case,
> >> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I
> >> > only have ls1021aqds and ls1043aqds with such support.
> >> >
> >>
> >> Jagan,
> >>
> >> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There
> >> were some issues. They will post their findings (and possible fix) to this thread.
> >>
> >> York
> >
> > I tested on LS1043AQDS board based on your spi-nor branch. The
> 'spi_flash_probe'
> > failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is
> > not defined for the board but it could be selected if CONFIG_MTD &&
> CONFIG_DM_SPI, correct?
> >
> > So after I moved CONFIG_MTD to the defconfig file, the probing could work now.
> >
> > And there is another small effect on our Fman driver. It would like to
> > read ucode blob from the QSPI flash. As the 'spi_flash_read' interface
> > is changed, I've modified the address value to an offset value in flash.
>
> Qianyu,
>
> > Here are my patches:
> > http://patchwork.ozlabs.org/patch/594872/
> > http://patchwork.ozlabs.org/patch/594873/
> > http://patchwork.ozlabs.org/patch/594874/
>
> I have applied 3rd patch on my test branch, and remaining two will go in another
> time like once spi-nor got merged.
>
> Qianyu/Alison Wang,
>
> Please test this[1] branch for your new changes and let me know for any issues.
>
> [1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor-
> next
>
> --
> Jagan.
Hi Jagan,
Both DSPI and QSPI work well on LS1043ARDB/LS1043AQDS board.
Thanks!
Regards,
Qianyu
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-16 3:44 ` Qianyu Gong
@ 2016-03-16 14:20 ` Jagan Teki
2016-03-21 9:20 ` Jagan Teki
0 siblings, 1 reply; 47+ messages in thread
From: Jagan Teki @ 2016-03-16 14:20 UTC (permalink / raw)
To: u-boot
On 16 March 2016 at 09:14, Qianyu Gong <qianyu.gong@nxp.com> wrote:
>
>> -----Original Message-----
>> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>> Sent: Tuesday, March 15, 2016 7:18 PM
>> To: Qianyu Gong <qianyu.gong@nxp.com>; Huan Wang <alison.wang@nxp.com>
>> Cc: york sun <york.sun@nxp.com>; Tom Rini <trini@konsulko.com>; Siva Durga
>> Prasad Paladugu <sivadur@xilinx.com>; Michal Simek <michal.simek@xilinx.com>;
>> u-boot at lists.denx.de; Stefan Roese <sr@denx.de>; Mingkai Hu
>> <mingkai.hu@nxp.com>
>> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>>
>> On 9 March 2016 at 13:37, Qianyu Gong <qianyu.gong@nxp.com> wrote:
>> > Hi Jagan,
>> >
>> >> -----Original Message-----
>> >> From: york sun
>> >> Sent: Tuesday, March 08, 2016 12:46 AM
>> >> To: Jagan Teki <jteki@openedev.com>; Huan Wang <alison.wang@nxp.com>;
>> >> Qianyu Gong <qianyu.gong@nxp.com>
>> >> Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu
>> >> <sivadur@xilinx.com>; Stefan Roese <sr@denx.de>; Michal Simek
>> >> <michal.simek@xilinx.com>; Tom Rini <trini@konsulko.com>
>> >> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>> >>
>> >> On 03/03/2016 01:06 PM, york sun wrote:
>> >> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
>> >> >> Hi York,
>> >> >>
>> >> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
>> >> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>> >>
>> >> <snip>
>> >>
>> >> >>>>
>> >> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>> >> >>>>
>> >> >>> Jagan,
>> >> >>>
>> >> >>> I am getting there. Will test sf probe/read/write and probably
>> >> >>> boot on selected platforms. Is there any specific platform/test in your mind?
>> >> >>
>> >> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
>> >> >>
>> >> >
>> >> > Jagan,
>> >> >
>> >> > Sorry for the delay. I am having issue with both ls1021aqds and
>> >> > ls1043aqds. Need to work with internal team to sort it out.
>> >> >
>> >> > My understanding the tests you need are for spi-nor, in my case,
>> >> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I
>> >> > only have ls1021aqds and ls1043aqds with such support.
>> >> >
>> >>
>> >> Jagan,
>> >>
>> >> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There
>> >> were some issues. They will post their findings (and possible fix) to this thread.
>> >>
>> >> York
>> >
>> > I tested on LS1043AQDS board based on your spi-nor branch. The
>> 'spi_flash_probe'
>> > failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is
>> > not defined for the board but it could be selected if CONFIG_MTD &&
>> CONFIG_DM_SPI, correct?
>> >
>> > So after I moved CONFIG_MTD to the defconfig file, the probing could work now.
>> >
>> > And there is another small effect on our Fman driver. It would like to
>> > read ucode blob from the QSPI flash. As the 'spi_flash_read' interface
>> > is changed, I've modified the address value to an offset value in flash.
>>
>> Qianyu,
>>
>> > Here are my patches:
>> > http://patchwork.ozlabs.org/patch/594872/
>> > http://patchwork.ozlabs.org/patch/594873/
>> > http://patchwork.ozlabs.org/patch/594874/
>>
>> I have applied 3rd patch on my test branch, and remaining two will go in another
>> time like once spi-nor got merged.
>>
>> Qianyu/Alison Wang,
>>
>> Please test this[1] branch for your new changes and let me know for any issues.
>>
>> [1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor-
>> next
>>
>> --
>> Jagan.
>
> Hi Jagan,
>
> Both DSPI and QSPI work well on LS1043ARDB/LS1043AQDS board.
> Thanks!
thanks!
Mugunthan/Alison Wang,
Please use u-boot-spi/spi-nor-test for your testing.
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-15 11:18 ` Jagan Teki
2016-03-15 11:20 ` Jagan Teki
2016-03-16 3:44 ` Qianyu Gong
@ 2016-03-17 1:07 ` Huan Wang
2 siblings, 0 replies; 47+ messages in thread
From: Huan Wang @ 2016-03-17 1:07 UTC (permalink / raw)
To: u-boot
Hi, Jagan,
> On 9 March 2016 at 13:37, Qianyu Gong <qianyu.gong@nxp.com> wrote:
> > Hi Jagan,
> >
> >> -----Original Message-----
> >> From: york sun
> >> Sent: Tuesday, March 08, 2016 12:46 AM
> >> To: Jagan Teki <jteki@openedev.com>; Huan Wang <alison.wang@nxp.com>;
> >> Qianyu Gong <qianyu.gong@nxp.com>
> >> Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu
> >> <sivadur@xilinx.com>; Stefan Roese <sr@denx.de>; Michal Simek
> >> <michal.simek@xilinx.com>; Tom Rini <trini@konsulko.com>
> >> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
> >>
> >> On 03/03/2016 01:06 PM, york sun wrote:
> >> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
> >> >> Hi York,
> >> >>
> >> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
> >> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
> >>
> >> <snip>
> >>
> >> >>>>
> >> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
> >> >>>>
> >> >>> Jagan,
> >> >>>
> >> >>> I am getting there. Will test sf probe/read/write and probably
> >> >>> boot on selected platforms. Is there any specific platform/test
> in your mind?
> >> >>
> >> >> Yes, these tests OK. and if possible please verify 'sf protect' as
> well.
> >> >>
> >> >
> >> > Jagan,
> >> >
> >> > Sorry for the delay. I am having issue with both ls1021aqds and
> >> > ls1043aqds. Need to work with internal team to sort it out.
> >> >
> >> > My understanding the tests you need are for spi-nor, in my case,
> >> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I
> >> > only have ls1021aqds and ls1043aqds with such support.
> >> >
> >>
> >> Jagan,
> >>
> >> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There
> >> were some issues. They will post their findings (and possible fix) to
> this thread.
> >>
> >> York
> >
> > I tested on LS1043AQDS board based on your spi-nor branch. The
> 'spi_flash_probe'
> > failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is
> > not defined for the board but it could be selected if CONFIG_MTD &&
> CONFIG_DM_SPI, correct?
> >
> > So after I moved CONFIG_MTD to the defconfig file, the probing could
> work now.
> >
> > And there is another small effect on our Fman driver. It would like to
> > read ucode blob from the QSPI flash. As the 'spi_flash_read' interface
> > is changed, I've modified the address value to an offset value in
> flash.
>
> Qianyu,
>
> > Here are my patches:
> > http://patchwork.ozlabs.org/patch/594872/
> > http://patchwork.ozlabs.org/patch/594873/
> > http://patchwork.ozlabs.org/patch/594874/
>
> I have applied 3rd patch on my test branch, and remaining two will go in
> another time like once spi-nor got merged.
>
> Qianyu/Alison Wang,
>
> Please test this[1] branch for your new changes and let me know for any
> issues.
>
> [1] http://git.denx.de/?p=u-boot/u-boot-
> spi.git;a=shortlog;h=refs/heads/spi-nor-next
>
>
[Alison Wang] No problem on LS1021AQDS and LS1021ATWR.
Thanks.
Best Regards,
Alison Wang
^ permalink raw reply [flat|nested] 47+ messages in thread
* [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
2016-03-16 14:20 ` Jagan Teki
@ 2016-03-21 9:20 ` Jagan Teki
0 siblings, 0 replies; 47+ messages in thread
From: Jagan Teki @ 2016-03-21 9:20 UTC (permalink / raw)
To: u-boot
Hi Mugunthan,
On 16 March 2016 at 19:50, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On 16 March 2016 at 09:14, Qianyu Gong <qianyu.gong@nxp.com> wrote:
>>
>>> -----Original Message-----
>>> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>>> Sent: Tuesday, March 15, 2016 7:18 PM
>>> To: Qianyu Gong <qianyu.gong@nxp.com>; Huan Wang <alison.wang@nxp.com>
>>> Cc: york sun <york.sun@nxp.com>; Tom Rini <trini@konsulko.com>; Siva Durga
>>> Prasad Paladugu <sivadur@xilinx.com>; Michal Simek <michal.simek@xilinx.com>;
>>> u-boot at lists.denx.de; Stefan Roese <sr@denx.de>; Mingkai Hu
>>> <mingkai.hu@nxp.com>
>>> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>>>
>>> On 9 March 2016 at 13:37, Qianyu Gong <qianyu.gong@nxp.com> wrote:
>>> > Hi Jagan,
>>> >
>>> >> -----Original Message-----
>>> >> From: york sun
>>> >> Sent: Tuesday, March 08, 2016 12:46 AM
>>> >> To: Jagan Teki <jteki@openedev.com>; Huan Wang <alison.wang@nxp.com>;
>>> >> Qianyu Gong <qianyu.gong@nxp.com>
>>> >> Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu
>>> >> <sivadur@xilinx.com>; Stefan Roese <sr@denx.de>; Michal Simek
>>> >> <michal.simek@xilinx.com>; Tom Rini <trini@konsulko.com>
>>> >> Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
>>> >>
>>> >> On 03/03/2016 01:06 PM, york sun wrote:
>>> >> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
>>> >> >> Hi York,
>>> >> >>
>>> >> >> On 27 February 2016 at 02:14, york sun <york.sun@nxp.com> wrote:
>>> >> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>>> >>
>>> >> <snip>
>>> >>
>>> >> >>>>
>>> >> >>>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
>>> >> >>>>
>>> >> >>> Jagan,
>>> >> >>>
>>> >> >>> I am getting there. Will test sf probe/read/write and probably
>>> >> >>> boot on selected platforms. Is there any specific platform/test in your mind?
>>> >> >>
>>> >> >> Yes, these tests OK. and if possible please verify 'sf protect' as well.
>>> >> >>
>>> >> >
>>> >> > Jagan,
>>> >> >
>>> >> > Sorry for the delay. I am having issue with both ls1021aqds and
>>> >> > ls1043aqds. Need to work with internal team to sort it out.
>>> >> >
>>> >> > My understanding the tests you need are for spi-nor, in my case,
>>> >> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I
>>> >> > only have ls1021aqds and ls1043aqds with such support.
>>> >> >
>>> >>
>>> >> Jagan,
>>> >>
>>> >> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There
>>> >> were some issues. They will post their findings (and possible fix) to this thread.
>>> >>
>>> >> York
>>> >
>>> > I tested on LS1043AQDS board based on your spi-nor branch. The
>>> 'spi_flash_probe'
>>> > failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is
>>> > not defined for the board but it could be selected if CONFIG_MTD &&
>>> CONFIG_DM_SPI, correct?
>>> >
>>> > So after I moved CONFIG_MTD to the defconfig file, the probing could work now.
>>> >
>>> > And there is another small effect on our Fman driver. It would like to
>>> > read ucode blob from the QSPI flash. As the 'spi_flash_read' interface
>>> > is changed, I've modified the address value to an offset value in flash.
>>>
>>> Qianyu,
>>>
>>> > Here are my patches:
>>> > http://patchwork.ozlabs.org/patch/594872/
>>> > http://patchwork.ozlabs.org/patch/594873/
>>> > http://patchwork.ozlabs.org/patch/594874/
>>>
>>> I have applied 3rd patch on my test branch, and remaining two will go in another
>>> time like once spi-nor got merged.
>>>
>>> Qianyu/Alison Wang,
>>>
>>> Please test this[1] branch for your new changes and let me know for any issues.
>>>
>>> [1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor-
>>> next
>>>
>>> --
>>> Jagan.
>>
>> Hi Jagan,
>>
>> Both DSPI and QSPI work well on LS1043ARDB/LS1043AQDS board.
>> Thanks!
>
> thanks!
>
> Mugunthan/Alison Wang,
>
> Please use u-boot-spi/spi-nor-test for your testing.
Please test this?
thanks!
--
Jagan.
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2016-03-21 9:20 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-14 20:46 [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support Jagan Teki
2016-02-16 19:47 ` Jagan Teki
2016-02-17 5:22 ` Bin Meng
2016-02-17 5:27 ` Bin Meng
2016-02-17 5:34 ` Jagan Teki
2016-02-17 8:54 ` Jagan Teki
2016-02-17 8:56 ` Bin Meng
2016-02-17 7:37 ` Jagan Teki
2016-02-17 7:38 ` Jagan Teki
2016-02-17 9:10 ` Bin Meng
2016-02-17 20:21 ` Tom Rini
2016-02-18 3:38 ` Bin Meng
2016-02-18 4:05 ` Bin Meng
2016-02-18 5:13 ` Bin Meng
2016-02-18 5:24 ` Bin Meng
2016-02-18 7:13 ` Jagan Teki
2016-02-18 7:22 ` Bin Meng
2016-02-17 19:00 ` Simon Glass
2016-02-17 19:14 ` Jagan Teki
2016-02-17 19:23 ` Jagan Teki
2016-02-17 20:08 ` Jagan Teki
2016-02-17 20:46 ` Jagan Teki
2016-02-22 8:57 ` Jagan Teki
2016-02-22 13:51 ` Tom Rini
2016-02-18 9:18 ` Jagan Teki
2016-02-22 18:17 ` Jagan Teki
2016-02-22 18:41 ` york sun
2016-02-22 18:52 ` Fabio Estevam
2016-02-23 13:03 ` Jagan Teki
2016-02-23 20:46 ` Fabio Estevam
2016-02-29 12:27 ` Jagan Teki
2016-02-29 12:34 ` Fabio Estevam
2016-02-29 12:39 ` Jagan Teki
2016-02-26 20:44 ` york sun
2016-02-26 23:04 ` Simon Glass
2016-02-29 12:38 ` Jagan Teki
2016-02-29 12:26 ` Jagan Teki
2016-03-03 20:33 ` york sun
2016-03-07 16:45 ` york sun
2016-03-09 3:17 ` Huan Wang
2016-03-09 8:07 ` Qianyu Gong
2016-03-15 11:18 ` Jagan Teki
2016-03-15 11:20 ` Jagan Teki
2016-03-16 3:44 ` Qianyu Gong
2016-03-16 14:20 ` Jagan Teki
2016-03-21 9:20 ` Jagan Teki
2016-03-17 1:07 ` Huan Wang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.