On Thu, Feb 18, 2016 at 4:21 AM, Tom Rini <tr...@konsulko.com> wrote: > 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 :) >
Last time I checked QEMU and looks it does not support SPI yet on x86. I can have another check. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
