[U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Tom Rini]

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 at openedev.com> wrote:
> > Hi Bin,
> >
> > On 17 February 2016 at 13:07, Jagan Teki <jteki at openedev.com> wrote:
> >> Hi Bin,
> >>
> >> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn at gmail.com> wrote:
> >>> Hi Jagan,
> >>>
> >>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki at openedev.com> wrote:
> >>>> On 15 February 2016 at 02:16, Jagan Teki <jteki at 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 at 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>