On 17 February 2016 at 10:57, Bin Meng <bmeng...@gmail.com> wrote: > On Wed, Feb 17, 2016 at 1:22 PM, 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? >> > > 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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
