On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng <bmeng...@gmail.com> wrote: > Hi Jagan, > > On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng <bmeng...@gmail.com> wrote: >> Hi Jagan, >> >> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng <bmeng...@gmail.com> 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 >>> => >>> >> >> Looks like you messed up the ICH SPI driver. Something went wrong with >> your patch series. ICH SPI controller is a special one (only supports >> slow read) especially when it comes to deal with an SST flash which is >> even odd (only supports byte program). I feel this ICH SPI controller >> is quite vulnerable to SPI changes as it breaks many times. Maybe >> Jagan you can purchase one Crown Bay board for the SPI flash testing >> (a joke!) >> >> logs below: >> >> => sf read 100000 100000 100 >> device 0 offset 0x100000, size 0x100 >> SF: 256 bytes @ 0x100000 Read: OK >> => crc fff00000 100 >> crc32 for fff00000 ... fff000ff ==> ac8e7061 >> => crc 100000 100 >> crc32 for 00100000 ... 001000ff ==> b44fdefc >> >> See? the contents of 'sf read' to address 0x100000 does not match the >> original one in SPI flash (0xfff00000) >> >> Anyway, I will continue debugging this. >> > > Root cause identified. Patch available @ > http://patchwork.ozlabs.org/patch/584500/.
This should be http://patchwork.ozlabs.org/patch/584517/ I doubt storing all SPI modes into a single spi->mode is a good idea. Previously they are separate variables. > Please squash mine into an > appropriate place in your series. > > Given the logic detection is completely wrong, I doubt how you tested > this whole series. What boards/flashes have you tested this on? > Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot