Re: [U-Boot] [PATCH v10 00/27] dm: Generic MTD Subsystem, with SPI-NOR interface

28 Dec 2017


      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: wd@denx.de