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.
Regards, Bin