[U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
Bin Meng
bmeng.cn at gmail.com
Thu Feb 18 08:22:10 CET 2016
On Thu, Feb 18, 2016 at 3:13 PM, Jagan Teki <jteki at openedev.com> wrote:
> Hi Bin,
>
> On 18 February 2016 at 10:54, Bin Meng <bmeng.cn at gmail.com> wrote:
>> 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?
>
> Yes the patch[1] where I missed the mode detection, over looked with
> respect to previous one. thanks for identifying this. And the boards I
> tested uses default read and write opcode that's the reason I
> succeeded. Will squash your change on this.
>
> [1] https://patchwork.ozlabs.org/patch/582615/
>
Along with the patch http://patchwork.ozlabs.org/patch/584517/, on the
spi-nor branch of u-boot-spi repo
For the whole series, tested on Intel Crown Bay, Intel Galileo and
Intel Bayley Bay.
Tested-by: Bin Meng <bmeng.cn at gmail.com>
Regards,
Bin
More information about the U-Boot
mailing list