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

Bin Meng bmeng.cn at gmail.com
Thu Feb 18 06:24:38 CET 2016 

On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Jagan,
>
> On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
>> 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.
>>
>
> 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

More information about the U-Boot mailing list