[U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
Bin Meng
bmeng.cn at gmail.com
Thu Feb 18 06:13:16 CET 2016
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/. 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