Hi Jagan, > Compared to previous series’s [1], [2], [3] and [4] this patch set > redefined most of the implementation suitable to fit into existing > driver-model. > > MTD is generic subsystem for underlying flash devices like nand, > parallel nor, spinor, dataflash etc. So to drive this theory with > driver model(with an example of block layer) mtd is common device > interaction for most of memory technology flashes like nand, > parallel nor, spinor, dataflash etc, these are treated as interface > types wrt u-boot driver model. > > Once the respective interface driver bind happen, the uclass driver > will pass an 'interface type' to mtd layer to create device for it, > for example once spinor ULASS_SPI_NOR driver bind happen, > the uclass driver of spinor will pass MTD_IF_TYPE_SPI_NOR > interface type to create mtd device for spinor devices. > > SPI-NOR: > ======= > 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.
I must admit that I'm a bit confused....
If you don't mind I would like to ask for clarification of a few things:
>
> =======================================
> cmd/spinor.c
^^^^^ - this would be a new set of commands to comply
with DM?
What about "sf" command which we use now to get access
to SPI-NOR memory? A lot of boards already use "sf"
command... which may be tricky to replace.
> =======================================
> mtd-uclass.c
^^^^^ - here we will have a generic MTD layer (as it is
in Linux)
> =======================================
> spi-nor-uclass.c
> =======================================
> spi-nor.c
^^^^^^ - why do we need to have spi-nor.c ? Cannot we
have its functionality in the spi-nor-uclass.c ?
(I'm just curious)
> =======================================
> m25p80.c zynq_qspinor.c
^^^^^ - this is the ^^^^^^^^ - [*]
"generic" spi-nor
driver used in Linux.
I suppose that it will
be reused here?
> =======================================
> spi-uclass.c
^^^^^^^ - why do we
need this uclass?
> =======================================
> zynq_qspi.c
^^^^^ - This is probably
the low-level driver for
zynq QSPI IP block - why
do we have zynq_qspinor.c file above [*]?
What is the difference/need of such division?
> =======================================
> #####SPI NOR chip######
> =======================================
>
> Changes for v10:
> - Update Simon's R-B tag
> - Add mtd dm test case
> - implemented entire code wrt MTD, with interface type
>
> code size:
> ==========
> before:
> $ arm-linux-gnueabi-size u-boot
> text data bss dec
> hex filename 473712 15152 222568
> 711432 adb08 u-boot $ du -hs u-boot-dtb.img
> 488K u-boot-dtb.img
>
> after:
> $ arm-linux-gnueabi-size u-boot
> text data bss dec
> hex filename 470124 14352 222584
> 707060 ac9f4 u-boot $ du -hs u-boot-dtb.img
> 484K u-boot-dtb.img
>
> approximately 4KiB but DM_SPI_FLASH still there which
> can be removed once support added in SPL
>
> test log:
> ========
> Zynq> spinor
> spinor - SPI-NOR Sub-system
>
> Usage:
> spinor list - show list of spinor devices
> spinor info - show current spinor device info
> spinor dev [devnum] - show or set current spinor device
> spinor erase offset len - erase 'len' bytes from 'offset'
> spinor write addr to len - write 'len' bytes to 'to' from
^^^^^^^^^^^^^^^^ I would love to see support for "mtdparts="
It would facilitate handling SPI-NOR "partitions" like
u-boot/SPI/envs/ etc.
I also suppose that "sf probe" (or any its replacement with spinor)
would be not necessary to call before using other SPI-NOR related
commands?
Maybe the biggest request - would it be possible to
add ./doc/README.spi-nor entry with good explanation of this?
> 'addr' spinor read addr from len - read 'len' bytes from 'from'
> to 'addr' spinor protect lock/unlock sector len - protect/unprotect
> 'len' bytes starting at address 'sector'
> Zynq> spinor list
> flash@0: 0
> spi-nor@e000d000: 1
> Zynq> spinor dev 0
> switch to dev #0, OK
> spinor0 is current device
> Zynq> spinor info
> bus: flash@0: 0
> device: s25fl128s_64k
> page size: 256 B
> erase size: 64 KiB
> size: 16 MiB
> Zynq> spinor erase 0xE00000 0x100000
> SPI-NOR: 1048576 bytes @ 0xe00000 Erased: OK
> Zynq> mw.b 0x100 0xcc 0x100000
> Zynq> spinor write 0x100 0xE00000 0x100000
> device 0 offset 0xe00000, size 0x100000
> SPI-NOR: 1048576 bytes @ 0xe00000 Written: OK
> Zynq> spinor read 0x3000000 0xE00000 0x100000
> device 0 offset 0xe00000, size 0x100000
> SPI-NOR: 1048576 bytes @ 0xe00000 Read: OK
> Zynq> cmp.b 0x3000000 0x100 0x100000
> Total of 1048576 byte(s) were the same
> Zynq> spinor dev 1
> switch to dev #1, OK
> spinor1 is current device
> Zynq> spinor info
> bus: spi-nor@e000d000: 1
> device: s25fl128s_64k
> page size: 256 B
> erase size: 64 KiB
> size: 16 MiB
> Zynq> spinor erase 0xE00000 0x100000
> SPI-NOR: 1048576 bytes @ 0xe00000 Erased: OK
> Zynq> mw.b 0x100 0xbb 0x100000
> Zynq> spinor write 0x100 0xE00000 0x100000
> device 0 offset 0xe00000, size 0x100000
> SPI-NOR: 1048576 bytes @ 0xe00000 Written: OK
> Zynq> spinor read 0x3000000 0xE00000 0x100000
> device 0 offset 0xe00000, size 0x100000
> SPI-NOR: 1048576 bytes @ 0xe00000 Read: OK
> Zynq> cmp.b 0x3000000 0x100 0x100000
> Total of 1048576 byte(s) were the same
>
> WIP:
> ===
> - to support non-dm code
> - to support spinor SPL
>
> Repo:
> ====
> $ git clone git://git.denx.de/u-boot-spi.git
> $ cd u-boot-spi
> $ git checkout -b mtd-spinor-working origin/mtd-spinor-working
>
> [1] https://lists.denx.de/pipermail/u-boot/2016-October/271459.html
> [2] http://lists.denx.de/pipermail/u-boot/2016-March/249286.html
> [3] http://lists.denx.de/pipermail/u-boot/2016-February/245418.html
> [4] [PATCH RFC v8 00/16] SPI-NOR/MTD addition
>
> Jagan Teki (27):
> mtd: Add mtd core ops
> mtd: add mtd device create operations
> mtd: add SPI-NOR core support
> mtd: spi-nor: sync/modify sst write operations
> mtd: spi-nor: sync/modify lock operations
> mtd: spi-nor: Kconfig: Add MTD_SPI_NOR entry
> mtd: spi-nor: Kconfig: Add MTD_SPI_NOR_USE_4K_SECTORS
> mtd: spi-nor: Kconfig: Add SPI_NOR_MISC entry
> mtd: spi-nor: Kconfig: Add SPI_NOR_MACRONIX entry
> mtd: spi-nor: Kconfig: Add SPI_NOR_SPANSION entry
> mtd: spi-nor: Kconfig: Add SPI_NOR_STMICRO entry
> mtd: spi-nor: Kconfig: Add SPI_NOR_SST entry
> mtd: spi-nor: Kconfig: Add SPI_NOR_WINBOND entry
> mtd-uclass: use platdata_auto_alloc
> spi: Add spi_write_then_read
> mtd: spi-nor: Add m25p80 driver
> mtd: spi-nor: Kconfig: Add MTD_M25P80 entry
> mtd: spi-nor: Add zynq qspinor driver
> mtd: spi-nor: zynq_qspi: Kconfig: Add MTD_ZYNQ
> mtd: spi-nor: Add 4-byte addresswidth support
> cmd: add spinor cmd support
> cmd: spinor: sync/update protect command
> board_r: initialize spi_nor
> env: add spi-nor environment
> arm: dts: zynq: Add zynq-qspinor node
> dm: zynq: microzed: enable MTD/SPI-NOR framework
> test: dm: add tests for mtd devices
>
> Makefile | 1 +
> arch/arm/dts/zynq-7000.dtsi | 12 +
> arch/arm/dts/zynq-microzed.dts | 12 +-
> cmd/Kconfig | 5 +
> cmd/Makefile | 1 +
> cmd/nvedit.c | 1 +
> cmd/spinor.c | 326 ++++++++++++
> common/board_r.c | 13 +
> configs/sandbox_defconfig | 8 +-
> configs/zynq_microzed_defconfig | 17 +-
> drivers/mtd/Kconfig | 2 +
> drivers/mtd/Makefile | 7 +-
> drivers/mtd/mtd-uclass.c | 203 +++++++-
> drivers/mtd/spi-nor/Kconfig | 89 ++++
> drivers/mtd/spi-nor/Makefile | 15 +
> drivers/mtd/spi-nor/m25p80.c | 251 ++++++++++
> drivers/mtd/spi-nor/spi-nor-ids.c | 184 +++++++
> drivers/mtd/spi-nor/spi-nor-uclass.c | 160 ++++++
> drivers/mtd/spi-nor/spi-nor.c | 940
> +++++++++++++++++++++++++++++++++++
> drivers/mtd/spi-nor/zynq_qspinor.c | 622 +++++++++++++++++++++++
> drivers/spi/spi-uclass.c | 24 +
> env/Kconfig | 27 +
> env/Makefile | 1 +
> env/env.c | 2 +
> env/spinor.c | 113 +++++
> include/dm/uclass-id.h | 1 +
> include/environment.h | 1 +
> include/linux/mtd/mtd.h | 14 +
> include/linux/mtd/spi-nor.h | 223 +++++++++
> include/mtd.h | 176 +++++++
> include/spi.h | 20 +
> test/dm/Makefile | 1 +
> test/dm/mtd.c | 33 ++ 33 files changed, 3493
> insertions(+), 12 deletions(-) create mode 100644 cmd/spinor.c
> create mode 100644 drivers/mtd/spi-nor/Kconfig
> create mode 100644 drivers/mtd/spi-nor/Makefile
> create mode 100644 drivers/mtd/spi-nor/m25p80.c
> create mode 100644 drivers/mtd/spi-nor/spi-nor-ids.c
> create mode 100644 drivers/mtd/spi-nor/spi-nor-uclass.c
> create mode 100644 drivers/mtd/spi-nor/spi-nor.c
> create mode 100644 drivers/mtd/spi-nor/zynq_qspinor.c
> create mode 100644 env/spinor.c
> create mode 100644 include/linux/mtd/spi-nor.h
> create mode 100644 test/dm/mtd.c
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgpp1QKlrFRDM.pgp
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
