[U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Bin Meng]

Hi Jagan,

On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki <jteki at openedev.com> wrote:
>> Hi Bin,
>>
>> On 17 February 2016 at 13:07, Jagan Teki <jteki at openedev.com> wrote:
>>> Hi Bin,
>>>
>>> On 17 February 2016 at 10:52, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki <jteki at openedev.com> wrote:
>>>>> On 15 February 2016 at 02:16, Jagan Teki <jteki at 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 at 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 at e0001000
>> Out:   serial at e0001000
>> Err:   serial at 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