On Thu, Feb 18, 2016 at 3:13 PM, Jagan Teki jteki@openedev.com wrote:
Hi Bin,
On 18 February 2016 at 10:54, Bin Meng bmeng.cn@gmail.com wrote:
On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Jagan,
On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki jteki@openedev.com wrote:
Hi Bin,
On 17 February 2016 at 13:07, Jagan Teki jteki@openedev.com wrote: > Hi Bin, > > On 17 February 2016 at 10:52, Bin Meng bmeng.cn@gmail.com wrote: >> Hi Jagan, >> >> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki jteki@openedev.com wrote: >>> On 15 February 2016 at 02:16, Jagan Teki jteki@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@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?
Yes the patch[1] where I missed the mode detection, over looked with respect to previous one. thanks for identifying this. And the boards I tested uses default read and write opcode that's the reason I succeeded. Will squash your change on this.
Along with the patch http://patchwork.ozlabs.org/patch/584517/, on the spi-nor branch of u-boot-spi repo
For the whole series, tested on Intel Crown Bay, Intel Galileo and Intel Bayley Bay. Tested-by: Bin Meng bmeng.cn@gmail.com
Regards, Bin