mtd: Add SPI-NOR core support

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)

Quoted 75 lines · Jagan Teki

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

Quoted 4 lines

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 <[email protected]>

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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?

Quoted 92 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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

Quoted 6 lines

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?

Quoted 92 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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

Quoted 6 lines

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?

Hi Bin,

Quoted 106 lines · Bin Meng

Quoted 92 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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

Quoted 6 lines

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'

Quoted 1 line

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!
--
Jagan.

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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?

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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?

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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

thanks!
--
Jagan.

Hi Jagan,

Quoted 108 lines · Jagan Teki

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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.

Quoted 9 lines

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

Quoted 153 lines · Bin Meng

Hi Jagan,

Quoted 108 lines · Jagan Teki

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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.

Quoted 9 lines

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

Quoted 8 lines

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 :)

Hi Jagan,

Quoted 108 lines · Jagan Teki

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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.

Quoted 9 lines

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

Hi Jagan,

Quoted 153 lines · Bin Meng

Hi Jagan,

Quoted 108 lines · Jagan Teki

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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.

Quoted 9 lines

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

Quoted 9 lines

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.

Hi Jagan,

Quoted 184 lines · Bin Meng

Hi Jagan,

Quoted 153 lines · Bin Meng

Hi Jagan,

Quoted 108 lines · Jagan Teki

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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.

Quoted 9 lines

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

Quoted 9 lines

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

Quoted 5 lines

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?

Quoted 193 lines · Bin Meng

Hi Jagan,

Quoted 189 lines · Bin Meng

Hi Jagan,

Quoted 153 lines · Bin Meng

Hi Jagan,

Quoted 108 lines · Jagan Teki

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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.

Quoted 9 lines

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

Quoted 9 lines

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.

Quoted 2 lines

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.

Quoted 5 lines

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?

Hi Bin,

Quoted 194 lines · Bin Meng

Quoted 193 lines · Bin Meng

Hi Jagan,

Quoted 189 lines · Bin Meng

Hi Jagan,

Quoted 153 lines · Bin Meng

Hi Jagan,

Quoted 108 lines · Jagan Teki

Hi Bin,

Quoted 102 lines · Jagan Teki

Hi Bin,

Quoted 97 lines · Bin Meng

Hi Jagan,

Quoted 76 lines · Jagan Teki

Quoted 75 lines · Jagan Teki

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

Quoted 8 lines

Quoted 4 lines

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 <[email protected]>

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.

Quoted 9 lines

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

Quoted 9 lines

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.

Quoted 13 lines

Quoted 2 lines

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.

Quoted 5 lines

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/

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

Hi Jagan,

Quoted 88 lines · Jagan Teki

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

Quoted 4 lines

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.

Hi Simon,

Quoted 96 lines · Simon Glass

Hi Jagan,

Quoted 92 lines · Jagan Teki

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

Quoted 1 line

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.

Quoted 4 lines

67: configs: Use CONFIG_SPI_NOR_MISC

       arm: (for 1/1 boards)  all +2434.0  bss +56.0  rodata +1994.0

text +384.0

Quoted 3 lines

There are also bisectability problems (build errors for some commits)
- e.g. chromebook_jerry.

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

Hi Jagan,

Quoted 85 lines · Jagan Teki

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.

Quoted 7 lines

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.

Hi Simon,

Quoted 98 lines · Simon Glass

Hi Jagan,

Quoted 85 lines · Jagan Teki

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.

Quoted 7 lines

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?

Quoted 6 lines

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.

Hi Jagan,

Quoted 85 lines · Jagan Teki

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.

Quoted 7 lines

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.

Hi Simon,

Quoted 96 lines · Simon Glass

Hi Jagan,

Quoted 85 lines · Jagan Teki

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.

Quoted 7 lines

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

Quoted 8 lines

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/

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

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

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

Hi York,

Quoted 135 lines · Jagan Teki

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

Quoted 8 lines

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

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

Quoted 1 line · Jagan Teki

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

Does not even build for me (mx6qsabresd_defconfig) :

Hi Fabio,

Quoted 5 lines · Fabio Estevam

Quoted 1 line · Jagan Teki

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.

Quoted 5 lines · Jagan Teki

Hi Fabio,

Quoted 2 lines · Fabio Estevam

On Mon, Feb 22, 2016 at 3:17 PM, Jagan Teki <[email protected]> wrote:

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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.

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

Quoted 1 line · Jagan Teki

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

I tested it last week and it worked fine.

Hi York,

Quoted 135 lines · Jagan Teki

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

Quoted 8 lines

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

Quoted 147 lines · Jagan Teki

Hi York,

Quoted 143 lines · Jagan Teki

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

Quoted 2 lines

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?

Hi Jagan,

Quoted 150 lines · york sun

Quoted 149 lines · Jagan Teki

Hi York,

Quoted 135 lines · Jagan Teki

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

Quoted 8 lines

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

Quoted 4 lines

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.

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.

Quoted 147 lines · Jagan Teki

Hi York,

Quoted 143 lines · Jagan Teki

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

Quoted 2 lines

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?

Hi York,

Quoted 148 lines · york sun

Quoted 147 lines · Jagan Teki

Hi York,

Quoted 143 lines · Jagan Teki

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

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 5 lines · Jagan Teki

Quoted 4 lines

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

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?

Quoted 2 lines

Quoted 2 lines

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

well.

Quoted 11 lines

Quoted 1 line

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.

-----Original Message-----
From: york sun
Sent: Tuesday, March 08, 2016 12:46 AM
To: Jagan Teki <[email protected]>; Huan Wang <[email protected]>; Qianyu Gong <[email protected]>
Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <[email protected]>; Stefan Roese <[email protected]>; Michal Simek <[email protected]>; Tom Rini <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 5 lines · york sun

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 9 lines

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

Hi Jagan,

Quoted 40 lines

-----Original Message-----
From: york sun
Sent: Tuesday, March 08, 2016 12:46 AM
To: Jagan Teki <[email protected]>; Huan Wang <[email protected]>; Qianyu Gong <[email protected]>
Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <[email protected]>; Stefan Roese <[email protected]>; Michal Simek <[email protected]>; Tom Rini <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 5 lines · york sun

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 9 lines

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.

Quoted 6 lines

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.

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

Quoted 53 lines · Qianyu Gong

Hi Jagan,

Quoted 40 lines

-----Original Message-----
From: york sun
Sent: Tuesday, March 08, 2016 12:46 AM
To: Jagan Teki <[email protected]>; Huan Wang <[email protected]>; Qianyu Gong <[email protected]>
Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <[email protected]>; Stefan Roese <[email protected]>; Michal Simek <[email protected]>; Tom Rini <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 5 lines · york sun

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 9 lines

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.

Quoted 6 lines

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?

Quoted 5 lines

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,

Quoted 4 lines

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.

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, March 15, 2016 7:18 PM
To: Qianyu Gong <[email protected]>; Huan Wang <[email protected]>
Cc: york sun <[email protected]>; Tom Rini <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>; Michal Simek <[email protected]>; u-boot at lists.denx.de; Stefan Roese <[email protected]>; Mingkai Hu <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 42 lines · Qianyu Gong

Hi Jagan,

Quoted 40 lines

-----Original Message-----
From: york sun
Sent: Tuesday, March 08, 2016 12:46 AM
To: Jagan Teki <[email protected]>; Huan Wang <[email protected]>; Qianyu Gong <[email protected]>
Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <[email protected]>; Stefan Roese <[email protected]>; Michal Simek <[email protected]>; Tom Rini <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 5 lines · york sun

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 20 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 6 lines

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'

Quoted 2 lines

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?

Quoted 6 lines

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,

Quoted 4 lines

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.

Quoted 90 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, March 15, 2016 7:18 PM
To: Qianyu Gong <[email protected]>; Huan Wang <[email protected]>
Cc: york sun <[email protected]>; Tom Rini <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>; Michal Simek <[email protected]>; u-boot at lists.denx.de; Stefan Roese <[email protected]>; Mingkai Hu <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 42 lines · Qianyu Gong

Hi Jagan,

Quoted 40 lines

-----Original Message-----
From: york sun
Sent: Tuesday, March 08, 2016 12:46 AM
To: Jagan Teki <[email protected]>; Huan Wang <[email protected]>; Qianyu Gong <[email protected]>
Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <[email protected]>; Stefan Roese <[email protected]>; Michal Simek <[email protected]>; Tom Rini <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 5 lines · york sun

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 20 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 6 lines

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'

Quoted 2 lines

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?

Quoted 6 lines

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,

Quoted 4 lines

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

Quoted 2 lines

--
Jagan.

Hi Jagan,

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

Quoted 95 lines · Qianyu Gong

Quoted 85 lines

-----Original Message-----
From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
Sent: Tuesday, March 15, 2016 7:18 PM
To: Qianyu Gong <[email protected]>; Huan Wang <[email protected]>
Cc: york sun <[email protected]>; Tom Rini <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>; Michal Simek <[email protected]>; u-boot at lists.denx.de; Stefan Roese <[email protected]>; Mingkai Hu <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 42 lines · Qianyu Gong

Hi Jagan,

Quoted 40 lines

-----Original Message-----
From: york sun
Sent: Tuesday, March 08, 2016 12:46 AM
To: Jagan Teki <[email protected]>; Huan Wang <[email protected]>; Qianyu Gong <[email protected]>
Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <[email protected]>; Stefan Roese <[email protected]>; Michal Simek <[email protected]>; Tom Rini <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 5 lines · york sun

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 20 lines

Quoted 10 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 6 lines

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'

Quoted 2 lines

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?

Quoted 6 lines

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,

Quoted 4 lines

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,

Quoted 7 lines

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,

Quoted 2 lines

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.

Quoted 28 lines

Hi Jagan,

Quoted 26 lines

-----Original Message-----
From: york sun
Sent: Tuesday, March 08, 2016 12:46 AM
To: Jagan Teki <[email protected]>; Huan Wang <[email protected]>; Qianyu Gong <[email protected]>
Cc: u-boot at lists.denx.de; Siva Durga Prasad Paladugu <[email protected]>; Stefan Roese <[email protected]>; Michal Simek <[email protected]>; Tom Rini <[email protected]>
Subject: Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

Quoted 5 lines · york sun

Quoted 4 lines · Jagan Teki

Hi York,

Quoted 1 line · york sun

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

<snip>

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

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?

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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

well.

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 1 line

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.

Quoted 4 lines

Quoted 4 lines

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.

Quoted 4 lines

Quoted 2 lines

York

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

'spi_flash_probe'

Quoted 2 lines

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?

Quoted 2 lines

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

work now.

Quoted 4 lines

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,

Quoted 4 lines

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