On Wed, Feb 17, 2016 at 1:22 PM, 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?

Another testing on Intel Galileo shows that: it does NOT build for galileo.

arch/x86/lib/built-in.o: In function `mrccache_update': arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm' arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'

Did you run buildman for your whole series?

Regards, Bin

Hi Bin,

On 17 February 2016 at 10:57, Bin Meng bmeng.cn@gmail.com wrote:

On Wed, Feb 17, 2016 at 1:22 PM, 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?

Another testing on Intel Galileo shows that: it does NOT build for galileo.

arch/x86/lib/built-in.o: In function `mrccache_update': arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm' arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'

Did you run buildman for your whole series?

Can you try the u-boot-spi/spi-nor tree again, I have fixed with the patch.

BTW - I couldn't get any build error with buildman without the fix [1], am I missing anything?

[1] http://paste.ubuntu.com/15099249/

thanks!

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

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 =>

thanks!

Jagan.

Regards, Bin

On Thu, Feb 18, 2016 at 4:21 AM, Tom Rini trini@konsulko.com wrote:

On Wed, Feb 17, 2016 at 05:10:33PM +0800, Bin Meng 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 =>

A thought, can we replicate this on qemu-x86? That should be a platform everyone can try :)

Last time I checked QEMU and looks it does not support SPI yet on x86. I can have another check.

Regards, Bin

Hi Jagan,

On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng bmeng.cn@gmail.com wrote:

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.

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

Hi Bin,

On 18 February 2016 at 10:54, Bin Meng bmeng.cn@gmail.com wrote:

On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng bmeng.cn@gmail.com wrote:

...

Hi Jagan,

On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng bmeng.cn@gmail.com wrote:

...

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.

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/

thanks!

Hi Simon,

On 18 February 2016 at 00:44, Jagan Teki jteki@openedev.com wrote:

Hi Simon,

On 18 February 2016 at 00:30, Simon Glass sjg@chromium.org wrote:

...

Hi Jagan,

On 14 February 2016 at 13:46, 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)

Changes for v6:

• Fixed git bisectable issues, with buildman.
• Fixed spi-nor compilation issues
• newly designed changes.

Changes for v5:

• newly designed changes

Testing: $ git clone git://git.denx.de/u-boot-spi.git $ cd u-boot-spi $ git checkout -b spi-nor origin/spi-nor

I see quite a large rodata increase at this commit. Is it necessary?

If ie the case then we need to revert the vendor configs w/o add them into CONFIG_SPI_NOR_MISC.

...

67: configs: Use CONFIG_SPI_NOR_MISC arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0 text +384.0

I couldn't find rodata section for this commit[1] am I missing anything?

[1] http://paste.ubuntu.com/15101966/

...

There are also bisectability problems (build errors for some commits)

• e.g. chromebook_jerry.

Did you pick u-boot-spi/spi-nor?

thanks!

Hi Simon,

On 18 February 2016 at 01:38, Jagan Teki jteki@openedev.com wrote:

Hi Simon,

On 18 February 2016 at 00:30, Simon Glass sjg@chromium.org wrote:

...

Hi Jagan,

On 14 February 2016 at 13:46, 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)

Changes for v6:

• Fixed git bisectable issues, with buildman.
• Fixed spi-nor compilation issues
• newly designed changes.

Changes for v5:

• newly designed changes

Testing: $ git clone git://git.denx.de/u-boot-spi.git $ cd u-boot-spi $ git checkout -b spi-nor origin/spi-nor

I see quite a large rodata increase at this commit. Is it necessary?

67: configs: Use CONFIG_SPI_NOR_MISC arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0 text +384.0

There are also bisectability problems (build errors for some commits)

• e.g. chromebook_jerry.

Yes, this I missed defining SPI_NOR config will update that.

u-boot-spi/spi-nor updated, let me know if you find any build issues.

On Mon, Feb 22, 2016 at 02:27:34PM +0530, Jagan Teki wrote:

Hi Simon,

On 18 February 2016 at 00:30, Simon Glass sjg@chromium.org wrote:

...

Hi Jagan,

On 14 February 2016 at 13:46, 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)

Changes for v6:

• Fixed git bisectable issues, with buildman.
• Fixed spi-nor compilation issues
• newly designed changes.

Changes for v5:

• newly designed changes

Testing: $ git clone git://git.denx.de/u-boot-spi.git $ cd u-boot-spi $ git checkout -b spi-nor origin/spi-nor

I see quite a large rodata increase at this commit. Is it necessary?

67: configs: Use CONFIG_SPI_NOR_MISC arm: (for 1/1 boards) all +2434.0 bss +56.0 rodata +1994.0 text +384.0

There are also bisectability problems (build errors for some commits)

• e.g. chromebook_jerry.

No bisectable issues now, made buildman test.

And here is image size test: http://paste.ubuntu.com/15169227/

Size of entire series (step 0) http://paste.ubuntu.com/15169235/

Looks good, thanks.

Let me know for any issues, I'm planning to send the whole series again for final review.

Please note that we're ~22 days from release, so this is too late for v2016.03 but we can get it in right after release, if everyone is happy otherwise.

On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki jteki@openedev.com wrote:

Can you pls- test the dataflash changes? use u-boot-spi/spi-nor

Does not even build for me (mx6qsabresd_defconfig) :

CC drivers/misc/mxc_ocotp.o drivers/dfu/dfu_sf.c: In function ‘dfu_read_medium_sf’: drivers/dfu/dfu_sf.c:23:2: warning: passing argument 1 of ‘spi_flash_read’ from incompatible pointer type [enabled by default] In file included from include/dfu.h:17:0, from drivers/dfu/dfu_sf.c:11: include/spi_flash.h:33:19: note: expected ‘struct spi_flash_t *’ but argument is of type ‘struct spi_flash *’ drivers/dfu/dfu_sf.c: In function ‘find_sector’: drivers/dfu/dfu_sf.c:28:50: error: dereferencing pointer to incomplete type drivers/dfu/dfu_sf.c:29:19: error: dereferencing pointer to incomplete type drivers/dfu/dfu_sf.c: In function ‘dfu_write_medium_sf’: drivers/dfu/dfu_sf.c:39:26: error: dereferencing pointer to incomplete type drivers/dfu/dfu_sf.c:39:10: warning: passing argument 1 of ‘spi_flash_erase’ from incompatible pointer type [enabled by default] In file included from include/dfu.h:17:0, from drivers/dfu/dfu_sf.c:11: include/spi_flash.h:45:19: note: expected ‘struct spi_flash_t *’ but argument is of type ‘struct spi_flash *’ drivers/dfu/dfu_sf.c:44:10: warning: passing argument 1 of ‘spi_flash_write’ from incompatible pointer type [enabled by default] In file included from include/dfu.h:17:0, from drivers/dfu/dfu_sf.c:11: include/spi_flash.h:39:19: note: expected ‘struct spi_flash_t *’ but argument is of type ‘struct spi_flash *’ drivers/dfu/dfu_sf.c: In function ‘dfu_free_entity_sf’: drivers/dfu/dfu_sf.c:63:2: warning: passing argument 1 of ‘spi_flash_free’ from incompatible pointer type [enabled by default] In file included from include/dfu.h:17:0, from drivers/dfu/dfu_sf.c:11: include/spi_flash.h:87:6: note: expected ‘struct spi_flash_t *’ but argument is of type ‘struct spi_flash *’ drivers/dfu/dfu_sf.c: In function ‘dfu_fill_entity_sf’: drivers/dfu/dfu_sf.c:120:19: warning: assignment from incompatible pointer type [enabled by default] drivers/dfu/dfu_sf.c:126:38: error: dereferencing pointer to incomplete type drivers/dfu/dfu_sf.c:136:3: warning: passing argument 1 of ‘spi_flash_free’ from incompatible pointer type [enabled by default] In file included from include/dfu.h:17:0, from drivers/dfu/dfu_sf.c:11: include/spi_flash.h:87:6: note: expected ‘struct spi_flash_t *’ but argument is of type ‘struct spi_flash *’ make[2]: *** [drivers/dfu/dfu_sf.o] Error 1 make[1]: *** [drivers/dfu] Error 2 make[1]: *** Waiting for unfinished jobs....

On Tue, Feb 23, 2016 at 10:03 AM, Jagan Teki jteki@openedev.com wrote:

Hi Fabio,

On 23 February 2016 at 00:22, Fabio Estevam festevam@gmail.com wrote:

...

On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki jteki@openedev.com wrote:

...

Can you pls- test the dataflash changes? use u-boot-spi/spi-nor

Does not even build for me (mx6qsabresd_defconfig) :

Please try again, I think I missed some changes. mean while I ran buildman again will update that one as well.

Now it builds and basic sf commands work fine.

On Mon, Feb 29, 2016 at 9:27 AM, Jagan Teki jteki@openedev.com wrote:

Please verify 'sf protect' as well if you haven't tested.

I tested it last week and it worked fine.

On 02/22/2016 10:18 AM, Jagan Teki wrote:

Hi York,

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)

Changes for v6:

• Fixed git bisectable issues, with buildman.
• Fixed spi-nor compilation issues
• newly designed changes.

Changes for v5:

• newly designed changes

Testing: $ git clone git://git.denx.de/u-boot-spi.git $ cd u-boot-spi $ git checkout -b spi-nor origin/spi-nor

Jagan Teki (76): mtd: Add m25p80 driver mtd: Add Kconfig entry for MTD_M25P80 mtd: Add SPI-NOR core support doc: device-tree-bindings: jedec,spi-nor mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS mtd: spi-nor: Add MTD support mtd: spi-nor: Add spi_nor support in m25p80 mtd: spi-nor: Add dm spi-nor probing mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor mtd: spi-nor: m25p80: Add spi_nor support for non-dm sf: Rename erase_size to erasesize sf: Use erasesize instead of sector_size sf: Use uint64_t for flash->size spi_flash: Use mtd_info operation for SPI-NOR spi_flash: Use spi_flash_t instead of struct spi_flash mtd: spi-nor: Move spi_read_then_write to spi layer spi: Rename spi_read_then_write to spi_write_then_read mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR mtd: spi-nor: Copy spl files from drivers/mtd/spi mtd: spi-nor: spl: Follow ascending order of include headers mtd: spi-nor: fsl_espi_spl: Use mtd_info mtd: spi-nor: spi_spl_load: Use mtd_info mtd: spi-nor: Add flash vendor Kconfig entries arm: zynq: Kconfig: Select MTD uclass arm: zynq: Kconfig: Drop DM_SPI_FLASH defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80 defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR spl: Add CONFIG_SPL_SPI_NOR_SUPPORT configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT configs: zynq: Use CONFIG_SPL_MTD_SUPPORT mtd: spi-nor: Copy sf_dataflash mtd: dataflash: Remove unneeded spi data mtd: dataflash: Move flash id detection into jedec_probe mtd: dataflash: Fix add_dataflash return logic mtd: dataflash: Add UCLASS_MTD support mtd: dataflash: Use spi_write_then_read mtd: dataflash: Drop sf_internal.h mtd: dataflash: Minor cleanups mtd: Rename sf_dataflash.c to mtd_dataflash.c mtd: spi-nor: Add Kconfig entry for mtd_dataflash mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH defconfig: ls1021aqds_qspi: Enable SPI-NOR defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH

Can you pls- test the dataflash changes? use u-boot-spi/spi-nor

Jagan,

I am getting there. Will test sf probe/read/write and probably boot on selected platforms. Is there any specific platform/test in your mind?

York

Hi Simon,

On 27 February 2016 at 04:34, Simon Glass sjg@chromium.org wrote:

Hi Jagan,

On 26 February 2016 at 13:44, york sun york.sun@nxp.com wrote:

...

On 02/22/2016 10:18 AM, Jagan Teki wrote:

...

Hi York,

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)

Changes for v6:

• Fixed git bisectable issues, with buildman.
• Fixed spi-nor compilation issues
• newly designed changes.

Changes for v5:

• newly designed changes

Testing: $ git clone git://git.denx.de/u-boot-spi.git $ cd u-boot-spi $ git checkout -b spi-nor origin/spi-nor

Jagan Teki (76): mtd: Add m25p80 driver mtd: Add Kconfig entry for MTD_M25P80 mtd: Add SPI-NOR core support doc: device-tree-bindings: jedec,spi-nor mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS mtd: spi-nor: Add MTD support mtd: spi-nor: Add spi_nor support in m25p80 mtd: spi-nor: Add dm spi-nor probing mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor mtd: spi-nor: m25p80: Add spi_nor support for non-dm sf: Rename erase_size to erasesize sf: Use erasesize instead of sector_size sf: Use uint64_t for flash->size spi_flash: Use mtd_info operation for SPI-NOR spi_flash: Use spi_flash_t instead of struct spi_flash mtd: spi-nor: Move spi_read_then_write to spi layer spi: Rename spi_read_then_write to spi_write_then_read mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR mtd: spi-nor: Copy spl files from drivers/mtd/spi mtd: spi-nor: spl: Follow ascending order of include headers mtd: spi-nor: fsl_espi_spl: Use mtd_info mtd: spi-nor: spi_spl_load: Use mtd_info mtd: spi-nor: Add flash vendor Kconfig entries arm: zynq: Kconfig: Select MTD uclass arm: zynq: Kconfig: Drop DM_SPI_FLASH defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80 defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR spl: Add CONFIG_SPL_SPI_NOR_SUPPORT configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT configs: zynq: Use CONFIG_SPL_MTD_SUPPORT mtd: spi-nor: Copy sf_dataflash mtd: dataflash: Remove unneeded spi data mtd: dataflash: Move flash id detection into jedec_probe mtd: dataflash: Fix add_dataflash return logic mtd: dataflash: Add UCLASS_MTD support mtd: dataflash: Use spi_write_then_read mtd: dataflash: Drop sf_internal.h mtd: dataflash: Minor cleanups mtd: Rename sf_dataflash.c to mtd_dataflash.c mtd: spi-nor: Add Kconfig entry for mtd_dataflash mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH defconfig: ls1021aqds_qspi: Enable SPI-NOR defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH

Can you pls- test the dataflash changes? use u-boot-spi/spi-nor

Jagan,

I am getting there. Will test sf probe/read/write and probably boot on selected platforms. Is there any specific platform/test in your mind?

Can you check test failures also? I re-enabled the SPI tests (see u-boot-dm/master) and applied this series but get build warnings and a test failure.

Yes I will add those fixes as well.

Also I see that the MTD uclass has replaced SPI flash. But the MTD uclass does not have any operations...it does not seem to fit correctly with driver model.

True, we need to add these as well. Since MTD is common for most of the flash's, we need to discuss for proper additions.

thanks!

On 02/29/2016 04:26 AM, Jagan Teki wrote:

Hi York,

On 27 February 2016 at 02:14, york sun york.sun@nxp.com wrote:

...

On 02/22/2016 10:18 AM, Jagan Teki wrote:

...

Hi York,

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)

Changes for v6:

• Fixed git bisectable issues, with buildman.
• Fixed spi-nor compilation issues
• newly designed changes.

Changes for v5:

• newly designed changes

Testing: $ git clone git://git.denx.de/u-boot-spi.git $ cd u-boot-spi $ git checkout -b spi-nor origin/spi-nor

Jagan Teki (76): mtd: Add m25p80 driver mtd: Add Kconfig entry for MTD_M25P80 mtd: Add SPI-NOR core support doc: device-tree-bindings: jedec,spi-nor mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS mtd: spi-nor: Add MTD support mtd: spi-nor: Add spi_nor support in m25p80 mtd: spi-nor: Add dm spi-nor probing mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor mtd: spi-nor: m25p80: Add spi_nor support for non-dm sf: Rename erase_size to erasesize sf: Use erasesize instead of sector_size sf: Use uint64_t for flash->size spi_flash: Use mtd_info operation for SPI-NOR spi_flash: Use spi_flash_t instead of struct spi_flash mtd: spi-nor: Move spi_read_then_write to spi layer spi: Rename spi_read_then_write to spi_write_then_read mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR mtd: spi-nor: Copy spl files from drivers/mtd/spi mtd: spi-nor: spl: Follow ascending order of include headers mtd: spi-nor: fsl_espi_spl: Use mtd_info mtd: spi-nor: spi_spl_load: Use mtd_info mtd: spi-nor: Add flash vendor Kconfig entries arm: zynq: Kconfig: Select MTD uclass arm: zynq: Kconfig: Drop DM_SPI_FLASH defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80 defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR spl: Add CONFIG_SPL_SPI_NOR_SUPPORT configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT configs: zynq: Use CONFIG_SPL_MTD_SUPPORT mtd: spi-nor: Copy sf_dataflash mtd: dataflash: Remove unneeded spi data mtd: dataflash: Move flash id detection into jedec_probe mtd: dataflash: Fix add_dataflash return logic mtd: dataflash: Add UCLASS_MTD support mtd: dataflash: Use spi_write_then_read mtd: dataflash: Drop sf_internal.h mtd: dataflash: Minor cleanups mtd: Rename sf_dataflash.c to mtd_dataflash.c mtd: spi-nor: Add Kconfig entry for mtd_dataflash mtd: dataflash: Add MTD_DATAFLASH_WRITE_VERIFY mtd: spi-nor: Add kconfig MTD_DATAFLASH_WRITE_VERIFY configs: ls1021aqds: Drop DM_SPI_FLASH and DATAFLASH defconfig: ls1021aqds_qspi: Enable SPI-NOR defconfig: ls1021aqds_qspi: Enable CONFIG_MTD_DATAFLASH

Can you pls- test the dataflash changes? use u-boot-spi/spi-nor

Jagan,

I am getting there. Will test sf probe/read/write and probably boot on selected platforms. Is there any specific platform/test in your mind?

Yes, these tests OK. and if possible please verify 'sf protect' as well.

Jagan,

Sorry for the delay. I am having issue with both ls1021aqds and ls1043aqds. Need to work with internal team to sort it out.

My understanding the tests you need are for spi-nor, in my case, fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only have ls1021aqds and ls1043aqds with such support.

York

Hi, Jagan,

On 03/03/2016 01:06 PM, york sun wrote:

...

On 02/29/2016 04:26 AM, Jagan Teki wrote:

...

Hi York,

On 27 February 2016 at 02:14, york sun york.sun@nxp.com wrote:

...

On 02/22/2016 10:18 AM, Jagan Teki wrote:

<snip>

...

...

...

...

Can you pls- test the dataflash changes? use u-boot-spi/spi-nor

Jagan,

I am getting there. Will test sf probe/read/write and probably boot on selected platforms. Is there any specific platform/test in your

mind?

...

...

Yes, these tests OK. and if possible please verify 'sf protect' as

well.

...

...

Jagan,

Sorry for the delay. I am having issue with both ls1021aqds and ls1043aqds. Need to work with internal team to sort it out.

My understanding the tests you need are for spi-nor, in my case, fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only have ls1021aqds and ls1043aqds with such support.

Jagan,

Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some issues. They will post their findings (and possible fix) to this thread.

[Alison Wang] I verified QSPI boot on LS1021AQDS and LS1021ATWR boards based on u-boot-spi/spi-nor branch. As we also support QSPI in SD boot, some modifications are needed for ls1021aqds_sdcard_qspi_defconfig and ls1021atwr_sdcard_qspi_defconfig. I submitted a set for the modifications, please help to review. http://patchwork.ozlabs.org/patch/594819/ http://patchwork.ozlabs.org/patch/594820/

BTW, I have a concern about so much debugging information. Could we print them only when debugging?

drivers/mtd/spi-nor/m25p80.c: printf("m25p80: 0x%p => cmd = { 0x%02x 0x%02x%02x%02x } chunk_len = %zu\n", buf, flash->command[0], flash->command[1], flash->command[2], flash->command[3], len);

=> run upqspiboot Speed: 1000, full duplex Using eTSEC3 device TFTP from server 10.192.208.233; our IP address is 10.193.20.116 Filename 'wh/ls1/u-boot-qspiboot-swap.bin'. Load address: 0x82000000 Loading: ################################### 1.5 MiB/s done Bytes transferred = 508532 (7c274 hex) m25p80: erase d8 1 0 0 (10000) m25p80: erase d8 2 0 0 (20000) m25p80: erase d8 3 0 0 (30000) m25p80: erase d8 4 0 0 (40000) m25p80: erase d8 5 0 0 (50000) m25p80: erase d8 6 0 0 (60000) m25p80: erase d8 7 0 0 (70000) m25p80: erase d8 8 0 0 (80000) m25p80: erase d8 9 0 0 (90000) SF: 589824 bytes @ 0x10000 Erased: OK device 0 offset 0x10000, size 0x80000 m25p80: 0x82000000 => cmd = { 0x02 0x010000 } chunk_len = 64 m25p80: 0x82000040 => cmd = { 0x02 0x010040 } chunk_len = 64 m25p80: 0x82000080 => cmd = { 0x02 0x010080 } chunk_len = 64 m25p80: 0x820000c0 => cmd = { 0x02 0x0100c0 } chunk_len = 64 m25p80: 0x82000100 => cmd = { 0x02 0x010100 } chunk_len = 64 m25p80: 0x82000140 => cmd = { 0x02 0x010140 } chunk_len = 64 m25p80: 0x82000180 => cmd = { 0x02 0x010180 } chunk_len = 64 m25p80: 0x820001c0 => cmd = { 0x02 0x0101c0 } chunk_len = 64 m25p80: 0x82000200 => cmd = { 0x02 0x010200 } chunk_len = 64 m25p80: 0x82000240 => cmd = { 0x02 0x010240 } chunk_len = 64 m25p80: 0x82000280 => cmd = { 0x02 0x010280 } chunk_len = 64 m25p80: 0x820002c0 => cmd = { 0x02 0x0102c0 } chunk_len = 64 m25p80: 0x82000300 => cmd = { 0x02 0x010300 } chunk_len = 64 m25p80: 0x82000340 => cmd = { 0x02 0x010340 } chunk_len = 64 m25p80: 0x82000380 => cmd = { 0x02 0x010380 } chunk_len = 64 m25p80: 0x820003c0 => cmd = { 0x02 0x0103c0 } chunk_len = 64 .... (So much..)

Best Regards, Alison Wang

On 9 March 2016 at 13:37, Qianyu Gong qianyu.gong@nxp.com wrote:

Hi Jagan,

...

-----Original Message----- From: york sun Sent: Tuesday, March 08, 2016 12:46 AM To: Jagan Teki jteki@openedev.com; Huan Wang alison.wang@nxp.com; Qianyu Gong qianyu.gong@nxp.com Cc: u-boot@lists.denx.de; Siva Durga Prasad Paladugu sivadur@xilinx.com; Stefan Roese sr@denx.de; Michal Simek michal.simek@xilinx.com; Tom Rini trini@konsulko.com Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

On 03/03/2016 01:06 PM, york sun wrote:

...

On 02/29/2016 04:26 AM, Jagan Teki wrote:

...

Hi York,

On 27 February 2016 at 02:14, york sun york.sun@nxp.com wrote:

...

On 02/22/2016 10:18 AM, Jagan Teki wrote:

<snip>

...

...

...

...

Can you pls- test the dataflash changes? use u-boot-spi/spi-nor

Jagan,

I am getting there. Will test sf probe/read/write and probably boot on selected platforms. Is there any specific platform/test in your mind?

Yes, these tests OK. and if possible please verify 'sf protect' as well.

Jagan,

Sorry for the delay. I am having issue with both ls1021aqds and ls1043aqds. Need to work with internal team to sort it out.

My understanding the tests you need are for spi-nor, in my case, fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only have ls1021aqds and ls1043aqds with such support.

Jagan,

Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some issues. They will post their findings (and possible fix) to this thread.

York

I tested on LS1043AQDS board based on your spi-nor branch. The 'spi_flash_probe' failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is not defined for the board but it could be selected if CONFIG_MTD && CONFIG_DM_SPI, correct?

So after I moved CONFIG_MTD to the defconfig file, the probing could work now.

And there is another small effect on our Fman driver. It would like to read ucode blob from the QSPI flash. As the 'spi_flash_read' interface is changed, I've modified the address value to an offset value in flash.

Qianyu,

Here are my patches: http://patchwork.ozlabs.org/patch/594872/ http://patchwork.ozlabs.org/patch/594873/ http://patchwork.ozlabs.org/patch/594874/

I have applied 3rd patch on my test branch, and remaining two will go in another time like once spi-nor got merged.

Qianyu/Alison Wang,

Please test this[1] branch for your new changes and let me know for any issues.

[1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor-...

-----Original Message----- From: Jagan Teki [mailto:jagannadh.teki@gmail.com] Sent: Tuesday, March 15, 2016 7:18 PM To: Qianyu Gong qianyu.gong@nxp.com; Huan Wang alison.wang@nxp.com Cc: york sun york.sun@nxp.com; Tom Rini trini@konsulko.com; Siva Durga Prasad Paladugu sivadur@xilinx.com; Michal Simek michal.simek@xilinx.com; u-boot@lists.denx.de; Stefan Roese sr@denx.de; Mingkai Hu mingkai.hu@nxp.com Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

On 9 March 2016 at 13:37, Qianyu Gong qianyu.gong@nxp.com wrote:

...

Hi Jagan,

...

-----Original Message----- From: york sun Sent: Tuesday, March 08, 2016 12:46 AM To: Jagan Teki jteki@openedev.com; Huan Wang alison.wang@nxp.com; Qianyu Gong qianyu.gong@nxp.com Cc: u-boot@lists.denx.de; Siva Durga Prasad Paladugu sivadur@xilinx.com; Stefan Roese sr@denx.de; Michal Simek michal.simek@xilinx.com; Tom Rini trini@konsulko.com Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

On 03/03/2016 01:06 PM, york sun wrote:

...

On 02/29/2016 04:26 AM, Jagan Teki wrote:

...

Hi York,

On 27 February 2016 at 02:14, york sun york.sun@nxp.com wrote:

...

On 02/22/2016 10:18 AM, Jagan Teki wrote:

<snip>

...

...

...

> > Can you pls- test the dataflash changes? use u-boot-spi/spi-nor > Jagan,

I am getting there. Will test sf probe/read/write and probably boot on selected platforms. Is there any specific platform/test in your mind?

Yes, these tests OK. and if possible please verify 'sf protect' as well.

Jagan,

Sorry for the delay. I am having issue with both ls1021aqds and ls1043aqds. Need to work with internal team to sort it out.

My understanding the tests you need are for spi-nor, in my case, fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only have ls1021aqds and ls1043aqds with such support.

Jagan,

Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some issues. They will post their findings (and possible fix) to this thread.

York

I tested on LS1043AQDS board based on your spi-nor branch. The

'spi_flash_probe'

...

failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is not defined for the board but it could be selected if CONFIG_MTD &&

CONFIG_DM_SPI, correct?

...

So after I moved CONFIG_MTD to the defconfig file, the probing could work now.

And there is another small effect on our Fman driver. It would like to read ucode blob from the QSPI flash. As the 'spi_flash_read' interface is changed, I've modified the address value to an offset value in flash.

Qianyu,

...

Here are my patches: http://patchwork.ozlabs.org/patch/594872/ http://patchwork.ozlabs.org/patch/594873/ http://patchwork.ozlabs.org/patch/594874/

I have applied 3rd patch on my test branch, and remaining two will go in another time like once spi-nor got merged.

Qianyu/Alison Wang,

Please test this[1] branch for your new changes and let me know for any issues.

[1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor- next

-- Jagan.

Hi Jagan,

Both DSPI and QSPI work well on LS1043ARDB/LS1043AQDS board. Thanks!

Regards, Qianyu

Hi Mugunthan,

On 16 March 2016 at 19:50, Jagan Teki jagannadh.teki@gmail.com wrote:

On 16 March 2016 at 09:14, Qianyu Gong qianyu.gong@nxp.com wrote:

...

...

-----Original Message----- From: Jagan Teki [mailto:jagannadh.teki@gmail.com] Sent: Tuesday, March 15, 2016 7:18 PM To: Qianyu Gong qianyu.gong@nxp.com; Huan Wang alison.wang@nxp.com Cc: york sun york.sun@nxp.com; Tom Rini trini@konsulko.com; Siva Durga Prasad Paladugu sivadur@xilinx.com; Michal Simek michal.simek@xilinx.com; u-boot@lists.denx.de; Stefan Roese sr@denx.de; Mingkai Hu mingkai.hu@nxp.com Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

On 9 March 2016 at 13:37, Qianyu Gong qianyu.gong@nxp.com wrote:

...

Hi Jagan,

...

-----Original Message----- From: york sun Sent: Tuesday, March 08, 2016 12:46 AM To: Jagan Teki jteki@openedev.com; Huan Wang alison.wang@nxp.com; Qianyu Gong qianyu.gong@nxp.com Cc: u-boot@lists.denx.de; Siva Durga Prasad Paladugu sivadur@xilinx.com; Stefan Roese sr@denx.de; Michal Simek michal.simek@xilinx.com; Tom Rini trini@konsulko.com Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

On 03/03/2016 01:06 PM, york sun wrote:

...

On 02/29/2016 04:26 AM, Jagan Teki wrote: > Hi York, > > On 27 February 2016 at 02:14, york sun york.sun@nxp.com wrote: >> On 02/22/2016 10:18 AM, Jagan Teki wrote:

<snip>

...

>>> >>> Can you pls- test the dataflash changes? use u-boot-spi/spi-nor >>> >> Jagan, >> >> I am getting there. Will test sf probe/read/write and probably >> boot on selected platforms. Is there any specific platform/test in your mind? > > Yes, these tests OK. and if possible please verify 'sf protect' as well. >

Jagan,

Sorry for the delay. I am having issue with both ls1021aqds and ls1043aqds. Need to work with internal team to sort it out.

My understanding the tests you need are for spi-nor, in my case, fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only have ls1021aqds and ls1043aqds with such support.

Jagan,

Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were some issues. They will post their findings (and possible fix) to this thread.

York

I tested on LS1043AQDS board based on your spi-nor branch. The

'spi_flash_probe'

...

failed during QSPI boot. Then I found that CONFIG_DM_MTD_SPI_NOR is not defined for the board but it could be selected if CONFIG_MTD &&

CONFIG_DM_SPI, correct?

...

So after I moved CONFIG_MTD to the defconfig file, the probing could work now.

And there is another small effect on our Fman driver. It would like to read ucode blob from the QSPI flash. As the 'spi_flash_read' interface is changed, I've modified the address value to an offset value in flash.

Qianyu,

...

Here are my patches: http://patchwork.ozlabs.org/patch/594872/ http://patchwork.ozlabs.org/patch/594873/ http://patchwork.ozlabs.org/patch/594874/

I have applied 3rd patch on my test branch, and remaining two will go in another time like once spi-nor got merged.

Qianyu/Alison Wang,

Please test this[1] branch for your new changes and let me know for any issues.

[1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor- next

-- Jagan.

Hi Jagan,

Both DSPI and QSPI work well on LS1043ARDB/LS1043AQDS board. Thanks!

thanks!

Mugunthan/Alison Wang,

Please use u-boot-spi/spi-nor-test for your testing.

Please test this?

thanks!