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 <jt...@openedev.com> wrote: > > Hi Bin, > > > > On 17 February 2016 at 13:07, Jagan Teki <jt...@openedev.com> wrote: > >> Hi Bin, > >> > >> On 17 February 2016 at 10:52, Bin Meng <bmeng...@gmail.com> wrote: > >>> Hi Jagan, > >>> > >>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jt...@openedev.com> wrote: > >>>> On 15 February 2016 at 02:16, Jagan Teki <jt...@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 <jt...@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@e0001000 > > Out: serial@e0001000 > > Err: serial@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot