On Thu, Feb 18, 2016 at 4:21 AM, Tom Rini trini@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 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 =>
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