[PATCH V3 4/4] xilinx: versal: enable gigadevice

2023-01-09 Thread Victor Lim
enabling gigadevice in the related files

Signed-off-by: Victor Lim 
---
 configs/xilinx_versal_mini_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_versal_mini_qspi_defconfig 
b/configs/xilinx_versal_mini_qspi_defconfig
index 9ca9b7e68a..11aff80f14 100644
--- a/configs/xilinx_versal_mini_qspi_defconfig
+++ b/configs/xilinx_versal_mini_qspi_defconfig
@@ -62,6 +62,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SF_DEFAULT_SPEED=3000
 # CONFIG_SPI_FLASH_SMART_HWCAPS is not set
 # CONFIG_SPI_FLASH_UNLOCK_ALL is not set
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
-- 
2.34.1



[PATCH V3 3/4] arm64: zynqmp: enable gigadevice

2023-01-09 Thread Victor Lim
enabling gigadevice in the related files

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_mini_qspi_defconfig | 1 +
 configs/xilinx_zynqmp_virt_defconfig  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index 6861f73980..7ef62dbcda 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -79,6 +79,7 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
 # CONFIG_MMC is not set
 # CONFIG_SPI_FLASH_SMART_HWCAPS is not set
 # CONFIG_SPI_FLASH_UNLOCK_ALL is not set
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index ab2a542651..c40490a9f8 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -159,6 +159,7 @@ CONFIG_NAND_ARASAN=y
 CONFIG_SYS_NAND_ONFI_DETECTION=y
 CONFIG_SYS_NAND_MAX_CHIPS=2
 CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
-- 
2.34.1



[PATCH V3 2/4] configs: zynq: enable gigadevice

2023-01-09 Thread Victor Lim
enabling gigadevice in the related files

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynq_virt_defconfig | 1 +
 configs/zynq_cse_qspi_defconfig| 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/xilinx_zynq_virt_defconfig 
b/configs/xilinx_zynq_virt_defconfig
index 610d9de2a6..0ae771da81 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -119,6 +119,7 @@ CONFIG_MTD_RAW_NAND=y
 CONFIG_NAND_ZYNQ=y
 CONFIG_SYS_NAND_ONFI_DETECTION=y
 CONFIG_SF_DEFAULT_SPEED=3000
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index c623caf564..bebbb3435f 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -82,6 +82,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 # CONFIG_MMC is not set
 CONFIG_SF_DEFAULT_SPEED=3000
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
-- 
2.34.1



[PATCH V3 1/4] mtd: spi-nor-ids: add gigadevice part #

2023-01-09 Thread Victor Lim
adding gigadevice part numbers

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 68 +++
 1 file changed, 68 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 5f8f3ec955..f97e10da87 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -118,6 +118,36 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   /* adding these 3V QSPI flash parts */
+   {INFO("gd25b256", 0xc84019, 0, 64 * 1024, 512,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)  },
+   {INFO("gd25b512", 0xc8471A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b01g", 0xc8471B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b02g", 0xc8471C, 0, 64 * 1024, 4096, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25f64", 0xc84317, 0, 64 * 1024, 128,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f128", 0xc84318, 0, 64 * 1024, 256,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f256", 0xc84319, 0, 64 * 1024, 512,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd55f512", 0xc8431A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd25t512", 0xc8461A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55t01g", 0xc8461B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55t02g",   0xc8461C, 0, 64 * 1024, 4096,   SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   /* adding these 3V OSPI flash parts */
+   {INFO("gd25x512", 0xc8481A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55x01g", 0xc8481B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55x02g", 0xc8481C, 0, 64 * 1024, 4096, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
@@ -128,10 +158,48 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   /* adding these 1.8V QSPI flash parts */
+   {INFO("gd25lb256", 0xc86719, 0, 64 * 1024, 512, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lb512", 0xc8671A, 0, 64 * 1024, 1024,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lb01g", 0xc8671B, 0, 64 * 1024, 2048,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lb02g", 0xc8671C, 0, 64 * 1024, 4096,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lf80", 0xc86314, 0, 64 * 1024, 16,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25lf16", 0xc86315, 0, 64 * 1024, 32,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25lf32", 0xc86316, 0, 64 * 1024, 64,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
+   {INFO("gd25lf64", 0xc86317, 0, 64 * 1024, 128,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
+   {INFO("gd25lf128", 0xc86318, 0, 64 * 1024, 256, SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
+   {INFO("gd25lf255", 0xc86319, 0, 64 * 1024, 512, SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lf511", 0xc8631A, 0, 64 * 1024, 1024,SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lt256", 0xc86619, 0, 64 * 1024, 512, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lt512", 0xc8661A, 0, 6

[PATCH V3 0/4] Enable gigadevice and add new part #s

2023-01-09 Thread Victor Lim
Changes in V2:

Adding the following parts to the list
gd25b256: 3V QSPI, QE=1, 256Mbit
gd25b512: 3V QSPI, QE=1, 512Mbit
gd55b01g: 3V QSPI, QE=1, 1Gbit
gd55b02g: 3V QSPI, QE=1, 2Gbit
gd25f64: 3V QSPI, QE=1, 64Mbit, high performance
gd25f128: 3V QSPI, QE=1, 128Mbit, high performance
gd25f256: 3V QSPI, QE=1, 256Mbit, high performance
gd55f512: 3V QSPI, QE=1, 512Mbit, high performance
gd25t512: 3V QSPI, 512Mbit, ultra high performance
gd55t01g: 3V QSPI, 1Gbit, ultra high performance
gd55t02g: 3V QSPI, 2Gbit, ultra high performance
gd25x512: 3V OSPI, 512Mbit, ultra high performance
gd55x01g: 3V OSPI, 1Gbit, ultra high performance
gd55x02g: 3V OSPI, 2Gbit, ultra high performance
gd25lb256: 1.8V QSPI, QE=1, 256Mbit
gd25lb512: 1.8V QSPI, QE=1, 512Mbit
gd55lb01g: 1.8V QSPI, QE=1, 1Gbit
gd55lb02g: 1.8V QSPI, QE=1, 2Gbit
gd25lf64: 1.8V QSPI, QE=1, 64Mbit, high performance
gd25lf128: 1.8V QSPI, QE=1, 128Mbit, high performance
gd25lf256: 1.8V QSPI, QE=1, 256Mbit, high performance
gd55lf512: 1.8V QSPI, QE=1, 512Mbit, high performance
gd25lt512: 1.8V QSPI, 512Mbit, ultra high performance
gd55lt01g: 1.8V QSPI, 1Gbit, ultra high performance
gd55lt02g: 1.8V QSPI, 2Gbit, ultra high performance
gd25lx512: 1.8V OSPI, 512Mbit, ultra high performance
gd55lx01g: 1.8V OSPI, 1Gbit, ultra high performance
gd55lx02g: 1.8V OSPI, 2Gbit, ultra high performance

This is the link to the datasheet.
https://www.gigadevice.com/products/memory/flash/spi-nor/

Victor Lim (4):
  mtd: spi-nor-ids: add gigadevice part #
  configs: zynq: enable gigadevice
  arm64: zynqmp: enable gigadevice
  xilinx: versal: enable gigadevice

 configs/xilinx_versal_mini_qspi_defconfig |  1 +
 configs/xilinx_zynq_virt_defconfig|  1 +
 configs/xilinx_zynqmp_mini_qspi_defconfig |  1 +
 configs/xilinx_zynqmp_virt_defconfig  |  1 +
 configs/zynq_cse_qspi_defconfig   |  1 +
 drivers/mtd/spi/spi-nor-ids.c | 68 +++
 6 files changed, 73 insertions(+)

-- 
2.34.1



[PATCH 1/4] xilinx: zynq: Enable gigadevice

2022-12-20 Thread Victor Lim
Enable gigadevice part #s

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynq_virt_defconfig | 1 +
 configs/zynq_cse_qspi_defconfig| 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/xilinx_zynq_virt_defconfig 
b/configs/xilinx_zynq_virt_defconfig
index 611c5e993c..fe2321d658 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -103,6 +103,7 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index 60f0d7cac4..d58db07e71 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -71,6 +71,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_ARM_DCC=y
 CONFIG_ZYNQ_QSPI=y
-- 
2.25.1



[PATCH 4/4] mtd: spi-nor-ids: add gigadevice part #

2022-12-20 Thread Victor Lim
Adding the following parts to the list

gd25b256: 3V QSPI, QE=1, 256Mbit
gd25b512: 3V QSPI, QE=1, 512Mbit
gd55b01g: 3V QSPI, QE=1, 1Gbit
gd55b02g: 3V QSPI, QE=1, 2Gbit
gd25f64: 3V QSPI, QE=1, 64Mbit, high performance
gd25f128: 3V QSPI, QE=1, 128Mbit, high performance
gd25f256: 3V QSPI, QE=1, 256Mbit, high performance
gd55f512: 3V QSPI, QE=1, 512Mbit, high performance
gd25t512: 3V QSPI, 512Mbit, ultra high performance
gd55t01g: 3V QSPI, 1Gbit, ultra high performance
gd55t02g: 3V QSPI, 2Gbit, ultra high performance
gd25x512: 3V OSPI, 512Mbit, ultra high performance
gd55x01g: 3V OSPI, 1Gbit, ultra high performance
gd55x02g: 3V OSPI, 2Gbit, ultra high performance
gd25lb256: 1.8V QSPI, QE=1, 256Mbit
gd25lb512: 1.8V QSPI, QE=1, 512Mbit
gd55lb01g: 1.8V QSPI, QE=1, 1Gbit
gd55lb02g: 1.8V QSPI, QE=1, 2Gbit
gd25lf64: 1.8V QSPI, QE=1, 64Mbit, high performance
gd25lf128: 1.8V QSPI, QE=1, 128Mbit, high performance
gd25lf256: 1.8V QSPI, QE=1, 256Mbit, high performance
gd55lf512: 1.8V QSPI, QE=1, 512Mbit, high performance
gd25lt512: 1.8V QSPI, 512Mbit, ultra high performance
gd55lt01g: 1.8V QSPI, 1Gbit, ultra high performance
gd55lt02g: 1.8V QSPI, 2Gbit, ultra high performance
gd25lx512: 1.8V OSPI, 512Mbit, ultra high performance
gd55lx01g: 1.8V OSPI, 1Gbit, ultra high performance
gd55lx02g: 1.8V OSPI, 2Gbit, ultra high performance

This is the link to the datasheet.
https://www.gigadevice.com/products/memory/flash/spi-nor/

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 68 +++
 1 file changed, 68 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 74e93d6209..ba73eef87f 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -118,6 +118,36 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   /* adding these 3V QSPI flash parts */
+   {INFO("gd25b256", 0xc84019, 0, 64 * 1024, 512,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)  },
+   {INFO("gd25b512", 0xc8471A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b01g", 0xc8471B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b02g", 0xc8471C, 0, 64 * 1024, 4096, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25f64", 0xc84317, 0, 64 * 1024, 128,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f128", 0xc84318, 0, 64 * 1024, 256,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f256", 0xc84319, 0, 64 * 1024, 512,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd55f512", 0xc8431A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd25t512", 0xc8461A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55t01g", 0xc8461B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55t02g",   0xc8461C, 0, 64 * 1024, 4096,   SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   /* adding these 3V OSPI flash parts */
+   {INFO("gd25x512", 0xc8481A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55x01g", 0xc8481B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55x02g", 0xc8481C, 0, 64 * 1024, 4096, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
@@ -128,10 +158,48 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   /* adding these 1.8V QSPI flash parts */
+   {INFO("gd25lb256", 0xc86719, 0, 64 * 1024, 512, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lb512", 0xc8671A, 0, 64 * 1024, 1024,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lb01g", 0xc8671B, 0, 64 * 1024, 2048,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lb

[PATCH 3/4] xilinx: versal: Enable gigadevice parts

2022-12-20 Thread Victor Lim
Enable gigadevice in this file

Signed-off-by: Victor Lim 
---
 configs/xilinx_versal_mini_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_versal_mini_qspi_defconfig 
b/configs/xilinx_versal_mini_qspi_defconfig
index bb53e6c913..247a011dae 100644
--- a/configs/xilinx_versal_mini_qspi_defconfig
+++ b/configs/xilinx_versal_mini_qspi_defconfig
@@ -65,6 +65,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 # CONFIG_POWER is not set
 CONFIG_ARM_DCC=y
-- 
2.25.1



[PATCH 2/4] arm64: zynqmp: Enable gigadevice

2022-12-20 Thread Victor Lim
Enable gigadevice part #

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_mini_qspi_defconfig | 1 +
 configs/xilinx_zynqmp_virt_defconfig  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index c6401c2a54..2171d09fc3 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -69,6 +69,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 # CONFIG_POWER is not set
 CONFIG_ARM_DCC=y
diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index e63b19b911..2893fdaa82 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -147,6 +147,7 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MARVELL=y
-- 
2.25.1



[PATCH 0/4] Enable gigadevice and add new part #s

2022-12-20 Thread Victor Lim
Enabling gigadevice part #s.
These are the part #s added,
gd25b256: 3V QSPI, QE=1, 256Mbit
gd25b512: 3V QSPI, QE=1, 512Mbit
gd55b01g: 3V QSPI, QE=1, 1Gbit
gd55b02g: 3V QSPI, QE=1, 2Gbit
gd25f64: 3V QSPI, QE=1, 64Mbit, high performance
gd25f128: 3V QSPI, QE=1, 128Mbit, high performance
gd25f256: 3V QSPI, QE=1, 256Mbit, high performance
gd55f512: 3V QSPI, QE=1, 512Mbit, high performance
gd25t512: 3V QSPI, 512Mbit, ultra high performance
gd55t01g: 3V QSPI, 1Gbit, ultra high performance
gd55t02g: 3V QSPI, 2Gbit, ultra high performance
gd25x512: 3V OSPI, 512Mbit, ultra high performance
gd55x01g: 3V OSPI, 1Gbit, ultra high performance
gd55x02g: 3V OSPI, 2Gbit, ultra high performance
gd25lb256: 1.8V QSPI, QE=1, 256Mbit
gd25lb512: 1.8V QSPI, QE=1, 512Mbit
gd55lb01g: 1.8V QSPI, QE=1, 1Gbit
gd55lb02g: 1.8V QSPI, QE=1, 2Gbit
gd25lf64: 1.8V QSPI, QE=1, 64Mbit, high performance
gd25lf128: 1.8V QSPI, QE=1, 128Mbit, high performance
gd25lf256: 1.8V QSPI, QE=1, 256Mbit, high performance
gd55lf512: 1.8V QSPI, QE=1, 512Mbit, high performance
gd25lt512: 1.8V QSPI, 512Mbit, ultra high performance
gd55lt01g: 1.8V QSPI, 1Gbit, ultra high performance
gd55lt02g: 1.8V QSPI, 2Gbit, ultra high performance
gd25lx512: 1.8V OSPI, 512Mbit, ultra high performance
gd55lx01g: 1.8V OSPI, 1Gbit, ultra high performance
gd55lx02g: 1.8V OSPI, 2Gbit, ultra high performance

This is the link to the datasheet.
https://www.gigadevice.com/products/memory/flash/spi-nor/


Victor Lim (4):
  xilinx: zynq: Enable gigadevice
  arm64: zynqmp: Enable gigadevice
  xilinx: versal: Enable gigadevice parts
  mtd: spi-nor-ids: add gigadevice part #

 configs/xilinx_versal_mini_qspi_defconfig |  1 +
 configs/xilinx_zynq_virt_defconfig|  1 +
 configs/xilinx_zynqmp_mini_qspi_defconfig |  1 +
 configs/xilinx_zynqmp_virt_defconfig  |  1 +
 configs/zynq_cse_qspi_defconfig   |  1 +
 drivers/mtd/spi/spi-nor-ids.c | 68 +++
 6 files changed, 73 insertions(+)

-- 
2.25.1



[PATCH V2 1/1] Configs: enable gigadevice xilinx_zynqmp_mini_qspi_defconfig

2022-12-12 Thread Victor Lim
enabling gigadevice in this file

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_mini_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index c6401c2a54..2171d09fc3 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -69,6 +69,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 # CONFIG_POWER is not set
 CONFIG_ARM_DCC=y
-- 
2.25.1



[PATCH V2 1/1] Configs: enable gigadevice

2022-12-12 Thread Victor Lim
enabling gigadevice in this file

Signed-off-by: Victor Lim 
---
 configs/zynq_cse_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index 60f0d7cac4..d58db07e71 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -71,6 +71,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_ARM_DCC=y
 CONFIG_ZYNQ_QSPI=y
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55lx02g

2022-12-11 Thread Victor Lim
adding gd55lx02g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 726781f15b..a729575979 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -194,6 +194,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{INFO("gd55lx01g", 0xc8681B, 0, 64 * 1024, 2048,SECT_4K |
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lx02g", 0xc8681C, 0, 64 * 1024, 4096,SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
 #endif
 #ifdef CONFIG_SPI_FLASH_ISSI   /* ISSI */
/* ISSI */
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55lx01g

2022-12-11 Thread Victor Lim
adding gd55lx01g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 370d1f7698..726781f15b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -192,6 +192,8 @@ const struct flash_info spi_nor_ids[] = {
},
{INFO("gd25lx512", 0xc8681A, 0, 64 * 1024, 1024,SECT_4K |
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lx01g", 0xc8681B, 0, 64 * 1024, 2048,SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
 #endif
 #ifdef CONFIG_SPI_FLASH_ISSI   /* ISSI */
/* ISSI */
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lx512

2022-12-11 Thread Victor Lim
adding gd25lx512 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 8bead629f4..370d1f7698 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -190,6 +190,8 @@ const struct flash_info spi_nor_ids[] = {
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
},
+   {INFO("gd25lx512", 0xc8681A, 0, 64 * 1024, 1024,SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
 #endif
 #ifdef CONFIG_SPI_FLASH_ISSI   /* ISSI */
/* ISSI */
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55lt02g

2022-12-11 Thread Victor Lim
adding gd55lt02g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a90b1a2e3c..8bead629f4 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -184,6 +184,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55lt01g", 0xc8661B, 0, 64 * 1024, 2048,SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lt02g", 0xc8661C, 0, 64 * 1024, 4096,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55lt01g

2022-12-11 Thread Victor Lim
adding gd55lt01g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 0419dca074..a90b1a2e3c 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -182,6 +182,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd25lt512", 0xc8661A, 0, 64 * 1024, 1024,SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lt01g", 0xc8661B, 0, 64 * 1024, 2048,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lt512

2022-12-11 Thread Victor Lim
adding gd25lt512 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 7dd1b63faa..0419dca074 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -180,6 +180,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{INFO("gd25lt256", 0xc86619, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lt512", 0xc8661A, 0, 64 * 1024, 1024,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lt256

2022-12-11 Thread Victor Lim
adding gd25lt256 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 6634e9ceb1..7dd1b63faa 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -178,6 +178,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{INFO("gd25lf511", 0xc8631A, 0, 64 * 1024, 1024,SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lt256", 0xc86619, 0, 64 * 1024, 512, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lf511

2022-12-11 Thread Victor Lim
adding gd25lf511 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4aeaccd6d1..6634e9ceb1 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -176,6 +176,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
{INFO("gd25lf255", 0xc86319, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lf511", 0xc8631A, 0, 64 * 1024, 1024,SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lf255

2022-12-11 Thread Victor Lim
adding gd25lf255 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index d3dba87c22..4aeaccd6d1 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -174,6 +174,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
{INFO("gd25lf128", 0xc86318, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
+   {INFO("gd25lf255", 0xc86319, 0, 64 * 1024, 512, SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lf128

2022-12-11 Thread Victor Lim
adding gd25lf128 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 86e97dcb4e..d3dba87c22 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -172,6 +172,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
{INFO("gd25lf64", 0xc86317, 0, 64 * 1024, 128,  SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
+   {INFO("gd25lf128", 0xc86318, 0, 64 * 1024, 256, SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lf64

2022-12-11 Thread Victor Lim
adding gd25lf64 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 758aca20fd..86e97dcb4e 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -170,6 +170,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{INFO("gd25lf32", 0xc86316, 0, 64 * 1024, 64,   SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
+   {INFO("gd25lf64", 0xc86317, 0, 64 * 1024, 128,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lf32

2022-12-11 Thread Victor Lim
adding gd25lf32 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index dbf8b8e298..758aca20fd 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -168,6 +168,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{INFO("gd25lf16", 0xc86315, 0, 64 * 1024, 32,   SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25lf32", 0xc86316, 0, 64 * 1024, 64,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)   },
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lf16

2022-12-11 Thread Victor Lim
adding gd25lf16 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 158b0057a5..dbf8b8e298 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -166,6 +166,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd25lf80", 0xc86314, 0, 64 * 1024, 16,   SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25lf16", 0xc86315, 0, 64 * 1024, 32,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lf80

2022-12-11 Thread Victor Lim
adding gd25lf80 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 5d8a08bfe2..158b0057a5 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -164,6 +164,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55lb02g", 0xc8671C, 0, 64 * 1024, 4096,SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lf80", 0xc86314, 0, 64 * 1024, 16,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55lb02g

2022-12-11 Thread Victor Lim
adding gd55lb02g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index b9381042ac..5d8a08bfe2 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -162,6 +162,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55lb01g", 0xc8671B, 0, 64 * 1024, 2048,SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lb02g", 0xc8671C, 0, 64 * 1024, 4096,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55lb01g

2022-12-11 Thread Victor Lim
adding gd55lb01g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 213a404604..b9381042ac 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -160,6 +160,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd25lb512", 0xc8671A, 0, 64 * 1024, 1024,SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55lb01g", 0xc8671B, 0, 64 * 1024, 2048,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lb512

2022-12-11 Thread Victor Lim
adding gd25lb512 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 00c46f75be..213a404604 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -158,6 +158,8 @@ const struct flash_info spi_nor_ids[] = {
},
{INFO("gd25lb256", 0xc86719, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25lb512", 0xc8671A, 0, 64 * 1024, 1024,SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25lb256

2022-12-11 Thread Victor Lim
adding gd25lb256 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 133550dd3b..00c46f75be 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -156,6 +156,8 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   {INFO("gd25lb256", 0xc86719, 0, 64 * 1024, 512, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
 SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55x02g

2022-12-11 Thread Victor Lim
adding gd55x02g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index f6ca16ac62..133550dd3b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -144,6 +144,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{INFO("gd55x01g", 0xc8481B, 0, 64 * 1024, 2048, SECT_4K |
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55x02g", 0xc8481C, 0, 64 * 1024, 4096, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55x01g

2022-12-11 Thread Victor Lim
adding gd55x01g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 741b40fbde..f6ca16ac62 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -142,6 +142,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd25x512", 0xc8481A, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55x01g", 0xc8481B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd25x512

2022-12-11 Thread Victor Lim
adding gd25x512 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a4eebebc7d..741b40fbde 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -140,6 +140,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55t02g",   0xc8461C, 0, 64 * 1024, 4096,   SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25x512", 0xc8481A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55t02g

2022-12-11 Thread Victor Lim
Adding gd55t02g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 6301b4704b..a4eebebc7d 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -138,6 +138,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55t01g", 0xc8461B, 0, 64 * 1024, 2048, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55t02g",   0xc8461C, 0, 64 * 1024, 4096,   SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: gd55t01g

2022-12-11 Thread Victor Lim
adding gd55t01g to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4c384fd5d3..6301b4704b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -136,6 +136,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{INFO("gd25t512", 0xc8461A, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55t01g", 0xc8461B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: add gd25t512

2022-12-11 Thread Victor Lim
Adding gd25t512 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index f429b7349b..4c384fd5d3 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -134,6 +134,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{INFO("gd55f512", 0xc8431A, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd25t512", 0xc8461A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp:zynq: add gd55f512

2022-12-11 Thread Victor Lim
Adding gd55f512 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index bb28dcefc0..f429b7349b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -132,6 +132,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{INFO("gd25f256", 0xc84319, 0, 64 * 1024, 512,  SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd55f512", 0xc8431A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: zynq: add gd25f256

2022-12-11 Thread Victor Lim
add gd25f256 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index b5ce527433..bb28dcefc0 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -130,6 +130,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{INFO("gd25f128", 0xc84318, 0, 64 * 1024, 256,  SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f256", 0xc84319, 0, 64 * 1024, 512,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: zynqmp: Zynq: add gd25f128

2022-12-11 Thread Victor Lim
Adding gd25f128 to this file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3236afc127..b5ce527433 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -128,6 +128,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd25f64", 0xc84317, 0, 64 * 1024, 128,   SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f128", 0xc84318, 0, 64 * 1024, 256,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: ZynqMP: Zynq: gd25f64 added to the list

2022-12-11 Thread Victor Lim
Adding gd25f64 to the file

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index b153bbb05a..3236afc127 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -126,6 +126,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55b02g", 0xc8471C, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd25f64", 0xc84317, 0, 64 * 1024, 128,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: Zynqmp: Zynq: adding gd55b02g

2022-12-11 Thread Victor Lim
Adding gd55b02g to the list

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 1c9cb26008..b153bbb05a 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -124,6 +124,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55b01g", 0xc8471B, 0, 64 * 1024, 2048, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b02g", 0xc8471C, 0, 64 * 1024, 4096, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch v2: SPI NOR: ZynqMP: Zynq: adding gd55b01g to the list

2022-12-11 Thread Victor Lim
adding gd55b01g to the list

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index fa8320eac2..1c9cb26008 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -122,6 +122,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)  },
{INFO("gd25b512", 0xc8471A, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b01g", 0xc8471B, 0, 64 * 1024, 2048, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch V2: SPI NOR: ZynqMP: Zynq: GD25Q512: adding part # to the list

2022-12-11 Thread Victor Lim
Adding GD25Q512 to the part # list.

Signed-off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 92d3a4aa5d..fa8320eac2 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -120,6 +120,8 @@ const struct flash_info spi_nor_ids[] = {
},
{INFO("gd25b256", 0xc84019, 0, 64 * 1024, 512,  SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)  },
+   {INFO("gd25b512", 0xc8471A, 0, 64 * 1024, 1024, SECT_4K |
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.25.1



[PATCH] patch: SPI NOR: versal_net_virt: Enabling gigadevice parts

2022-12-11 Thread Victor Lim
Enabling gigadevice parts in the config file.

Signed-off-by: Victor Lim 
---
 configs/xilinx_versal_net_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_versal_net_virt_defconfig 
b/configs/xilinx_versal_net_virt_defconfig
index 6339b17d20..86e18807c3 100644
--- a/configs/xilinx_versal_net_virt_defconfig
+++ b/configs/xilinx_versal_net_virt_defconfig
@@ -119,5 +119,6 @@ CONFIG_USB_GADGET_MANUFACTURER="Xilinx"
 CONFIG_USB_GADGET_VENDOR_NUM=0x03FD
 CONFIG_USB_GADGET_PRODUCT_NUM=0x0300
 CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_USB_FUNCTION_THOR=y
 CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.25.1



[PATCH] SPI NOR: versal_virt: enabling gigadevice part #s

2022-12-11 Thread Victor Lim
Enabling gigadevice part # in this config file

Signed-off-by: Victor Lim 
---
 configs/xilinx_versal_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_versal_virt_defconfig 
b/configs/xilinx_versal_virt_defconfig
index 49cf7c30a8..732806559e 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -134,3 +134,4 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x0300
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_FUNCTION_THOR=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
-- 
2.25.1



[PATCH] SPI NOR: zynq_virt: enabling Gigadevice part # in zynq virt config file

2022-12-11 Thread Victor Lim
Enabling Gigadevice part # in this config file

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynq_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_zynq_virt_defconfig 
b/configs/xilinx_zynq_virt_defconfig
index 611c5e993c..6506cc7ecc 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -131,3 +131,4 @@ CONFIG_SPL_GZIP=y
 CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
-- 
2.25.1



[PATCH] patch: SPI: NOR: zynqmp_virt: enabling Gigadevice part #

2022-12-11 Thread Victor Lim
Enabling Gigadevice part # in this config file

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index e63b19b911..f1e58426aa 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -218,3 +218,4 @@ CONFIG_EFI_SET_TIME=y
 CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
-- 
2.25.1



[PATCH] patch V2: SPI: NOR: ZynqMp: enabling gigadevice part #

2022-12-10 Thread Victor Lim
Enabling Gigadevice in the config file

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_mini_qspi_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index 75014117f1..5e81dc193a 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -69,6 +69,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 # CONFIG_POWER is not set
 CONFIG_ARM_DCC=y
@@ -78,4 +79,4 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_PANIC_HANG=y
 # CONFIG_GZIP is not set
 # CONFIG_LMB is not set
-CONFIG_SPI_FLASH_GIGADEVICE=y
+
-- 
2.25.1



[PATCH] patch V2: SPI: NOR: Enable GIGADEVICE in the config file

2022-12-10 Thread Victor Lim
Working with Xilinx team to add Gigadevice part # to uboot

Signed-off-by: Victor Lim 
---
 configs/zynq_cse_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index 60f0d7cac4..cd245906ab 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -76,3 +76,4 @@ CONFIG_ARM_DCC=y
 CONFIG_ZYNQ_QSPI=y
 # CONFIG_GZIP is not set
 # CONFIG_LMB is not set
+CONFIG_SPI_FLASH_GIGADEVICE=y
-- 
2.25.1



[PATCH] SPI: GD SPI: added Gigadevice part #s in the ids.c file

2022-11-21 Thread Victor Lim
Updated the ids.c file with Gigadevice SPI NOR part #s.

Signed-Off-by: Victor Lim 
---
 drivers/mtd/spi/spi-nor-ids.c | 137 +++---
 1 file changed, 92 insertions(+), 45 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 74e93d6209..662628b739 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -87,51 +87,98 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("en25s64",0x1c3817, 0, 64 * 1024,  128, SECT_4K) },
 #endif
 #ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */
-   /* GigaDevice */
-   {
-   INFO("gd25q16", 0xc84015, 0, 64 * 1024,  32,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25q32", 0xc84016, 0, 64 * 1024,  64,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq32", 0xc86016, 0, 64 * 1024, 64,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq64c", 0xc86017, 0, 64 * 1024, 128,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
-   SECT_4K | SPI_NOR_DUAL_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq256d", 0xc86019, 0, 64 * 1024, 512,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
-SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-   },
+/* GigaDevice - GD25Q or B series  */
+   {INFO("gd25q16", 0xc84015, 0, 64 * 1024,  32,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25q32", 0xc84016, 0, 64 * 1024,  64,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ   |   SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25b series 256Mbit", 0xc84019, 0, 64 * 1024, 512,  SECT_4K 
|
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)  },
+   {INFO("gd25b series 512Mbit", 0xc8471A, 0, 64 * 1024, 1024, SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b series 1Gbit", 0xc8471B, 0, 64 * 1024, 2048,   SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b series 2Gbit", 0xc8471C, 0, 64 * 1024, 4096,   SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+/* GigaDevice - GD25F series */
+   {INFO("gd25f series 64Mbit", 0xc84317, 0, 64 * 1024, 128,   SECT_4K 
|
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f series 128Mbit", 0xc84318, 0, 64 * 1024, 256,  SECT_4K 
|
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f series 256Mbit", 0xc84319, 0, 64 * 1024, 512,  SECT_4K 
|
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+   {INFO("gd55f series 512Mbit", 0xc8431A, 0, 64 * 1024, 1024, SECT_4K 
|
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)},
+/* GigaDevice - GD25T series */
+   {INFO("gd25t series 512Mbit", 0xc8461A, 0, 64 * 1024, 1024, SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55t series 1Gbit", 0xc8461B, 0, 64 * 1024, 2048,   SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_

[PATCH] SPI: GD SPI, enable GIGADEVICE in the config file

2022-11-21 Thread Victor Lim
Added GIGADEVICE=y in the defconfig files

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_mini_qspi_defconfig | 1 +
 configs/zynq_cse_qspi_defconfig   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index c6401c2a54..75014117f1 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -78,3 +78,4 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_PANIC_HANG=y
 # CONFIG_GZIP is not set
 # CONFIG_LMB is not set
+CONFIG_SPI_FLASH_GIGADEVICE=y
diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index 60f0d7cac4..cd245906ab 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -76,3 +76,4 @@ CONFIG_ARM_DCC=y
 CONFIG_ZYNQ_QSPI=y
 # CONFIG_GZIP is not set
 # CONFIG_LMB is not set
+CONFIG_SPI_FLASH_GIGADEVICE=y
-- 
2.25.1



[PATCH] Subject: [patch]SPI: GD SPI: Add Gigadevice SPI NOR part numbers

2022-11-17 Thread Victor lim
added gigadevice in the defconfig file and ID in the ids.c file

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_mini_qspi_defconfig |   1 +
 configs/zynq_cse_qspi_defconfig   |   1 +
 drivers/mtd/spi/spi-nor-ids.c | 137 +++---
 3 files changed, 94 insertions(+), 45 deletions(-)

diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index c6401c2a54..75014117f1 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -78,3 +78,4 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_PANIC_HANG=y
 # CONFIG_GZIP is not set
 # CONFIG_LMB is not set
+CONFIG_SPI_FLASH_GIGADEVICE=y
diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index 60f0d7cac4..cd245906ab 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -76,3 +76,4 @@ CONFIG_ARM_DCC=y
 CONFIG_ZYNQ_QSPI=y
 # CONFIG_GZIP is not set
 # CONFIG_LMB is not set
+CONFIG_SPI_FLASH_GIGADEVICE=y
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 7d66f9ef36..7cb183c1a3 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -87,51 +87,98 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("en25s64",0x1c3817, 0, 64 * 1024,  128, SECT_4K) },
 #endif
 #ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */
-   /* GigaDevice */
-   {
-   INFO("gd25q16", 0xc84015, 0, 64 * 1024,  32,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25q32", 0xc84016, 0, 64 * 1024,  64,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq32", 0xc86016, 0, 64 * 1024, 64,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq64c", 0xc86017, 0, 64 * 1024, 128,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
-   SECT_4K | SPI_NOR_DUAL_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lq256d", 0xc86019, 0, 64 * 1024, 512,
-   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
-   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
-   },
-   {
-   INFO("gd25lx256e", 0xc86819, 0, 64 * 1024, 512,
-SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)
-   },
+/* GigaDevice - GD25Q or B series  */
+   {INFO("gd25q16", 0xc84015, 0, 64 * 1024,  32,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25q32", 0xc84016, 0, 64 * 1024,  64,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25q64", 0xc84017, 0, 64 * 1024, 128,   SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,  SECT_4K |
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ   |   SPI_NOR_HAS_LOCK | 
SPI_NOR_HAS_TB)},
+   {INFO("gd25b series 256Mbit", 0xc84019, 0, 64 * 1024, 512,  SECT_4K 
|
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | 
SPI_NOR_4B_OPCODES)  },
+   {INFO("gd25b series 512Mbit", 0xc8471A, 0, 64 * 1024, 1024, SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b series 1Gbit", 0xc8471B, 0, 64 * 1024, 2048,   SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+   {INFO("gd55b series 2Gbit", 0xc8471C, 0, 64 * 1024, 4096,   SECT_4K 
|
+   SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+/* GigaDevice - GD25F series */
+   {INFO("gd25f series 64Mbit", 0xc84317, 0, 64 * 1024, 128,   SECT_4K 
|
+   SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
+   {INFO("gd25f series 128Mbit

[U-Boot] RPi3B rainbow screen for u-boot v2019.07 rpi_3_32b_defconfig

2019-07-10 Thread Victor Seryodkin
u-boot v2019.07 (rpi_3_32b_defconfig) failed to boot on Raspberry Pi3B

Configuration

Raspberry Pi 3B (not 3B plus)
OS: Raspbian stretch lite
Distro: 2018-11-13-raspbian-stretch.zip
http://downloads.raspberrypi.org/raspbian/images/raspbian-2018-11-15/2018-11-13-raspbian-stretch.zip

Booting RPi from microSD card.

Kernel is 32bit from Raspbian distro without any modifications:
Linux raspberrypi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l
GNU/Linux

Initrd is not used.

u-boot executable is produced by local native build on RPi.

Results:
1) Default Raspberry bootloader (not u-boot) - RPi is booting and working
fine.
2) u-boot v2019.04 (configured only with rpi_3_32b_defconfig) - RPi is
booting and working fine.
3) u-boot v2019.07 (configured only with rpi_3_32b_defconfig) - got rainbow
screen on power on (boot failed).

Files for analysis are inside the archive
u-boot_v2019.07_rpi3b_rainbow-screen.tgz
https://drive.google.com/open?id=1i7LpbA8SK6bV2gWM0XPERA4RuJGUGAJh

u-boot_v2019.07_rpi3b_rainbow-screen.tgz content:

u-boot_v2019.04_GOOD/
  .config
  boot.cmd - boot.scr.uimg source
  boot.scr.uimg
  u-boot.bin

u-boot_v2019.07_BAD/.config
  .config
  boot.cmd - boot.scr.uimg source
  boot.scr.uimg
  u-boot.bin

boot/ (files used for both configs "u-boot_v2019.04" and "u-boot_v2019.07")
  bcm2710-rpi-3-b.dtb
  bootcode.bin
  start.elf
  config.txt
  rpiKernel (renamed original file kernel7.img from Raspbian distro)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD

2014-11-17 Thread Victor Ascroft

On Monday 17 November 2014 11:58 AM, Simon Glass wrote:
> Hi Albert,
>
> On 16 November 2014 07:50, Albert ARIBAUD  wrote:
>> Hello Simon,
>>
>> On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass 
>> wrote:
>>> Hi Albert,
>>>
>>> On 15 November 2014 05:30, Albert ARIBAUD  wrote:
>>>> Hello Simon,
>>>>
>>>> On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass 
>>>> wrote:
>>>>
>>>>>> I believe you've built crt0.S for ARM, not Thumb.
>>>>> Yes, but I suspect that is a function of the build system. I checked
>>>>> the rest of U-Boot and most of it (including SPL) is Thumb 2. I
>>>>> suppose we could use Thumb 2 for crt0.S if all the instructions are
>>>>> supported.
>>>> Ok. Just in case, I'll run a check on whether crt0.S can be assembled
>>>> for Thumb and still wrk as expected. :)
>>>>
>>>> Do you have a list of source files which still build for ARM under
>>>> CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for
>>>> consistence, except probably... exception :) entry points -- and even
>>>> these should be able to run in full Thumb 2.
>>> No I don't have a list, but it might be all assembler files. I don't
>>> see why cro0.S would be special.
>> Ok, so after some research, .S files voluntarily not assembled in Thumb
>> mode when -mthumb is defined in gcc because of this:
>>
>> Answer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
>>
>> (summary: -mthumb for gcc means 'use thumb2', while it means 'use
>> dumb, 16-bit, thumb1' for GNU as, so this option is voluntarily not
>> passed on to GNU as. You have to use .thumb in the .S file instead.)
>>
>> Second: getting a successful, though quick'n'dirty, build with vectors.S
>> assembled in Thumb-2 mode needed surprisingly little change in
>> vectors.S. I tried this with mx53loco, and it only required:
>>
>> - adding '.syntax unified';
>>
>> - adding a .thumb directive -- *after* the vectors per se, which
>>   must still be assembled in ARM mode because current hardware
>>   always executes exceptions vectors in ARM mode (1);
>>
>> - using '.balign' instead of '.balignl' which causes the
>>   assembler to complain that it cannot fit an integer
>>   number of '0xdeadbeef' in the filling space;
>>
>> - making macro get_bad_stack use lr instead of r13, which
>>   Thumb does not allow in 'msr spsr,' instructions;
>>
>> - adding '.thumb_func' to all routines so that the linker makes
>>   all references to them odd and therefore, cause the CPU to
>>   enforce Thumb mode when branching to them.
>>
>> (1) although you *could* produce an ARM-based SoC that runs in
>> Thumb mode by default. In this case, you'd have to make the
>> vectors themselves Thumb too.
>>
>> Third: getting a successful *run* of the resulting file will require
>> some work which I'm not going to do without a good incentive :) -- and
>> so does producing a clean vectors.S, i.e. one which will assemble
>> correctly for both ARM and Thumb.
So to use the thumb build correctly, all the .S files have to be changed to use
thumb instructions, by specifying the .thumb option?

-Regards,
Victor.

> That doesn't sound too trciky, but I agree it's not a huge deal. I
> suppose the main benefit is consistency, since the code size
> improvement would be small.
>
> Regards,
> Simon

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD

2014-11-14 Thread Victor Ascroft
On 11/15/2014 10:56 AM, Victor Ascroft wrote:
> On 11/15/2014 07:26 AM, Simon Glass wrote:
>> Hi Albert,
>>
>> On 14 November 2014 08:26, Albert ARIBAUD  wrote:
>>> Hello Simon,
>>>
>>> On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass 
>>> wrote:
>>>> Hi Victor,
>>>>
>>>> On 13 November 2014 09:29, Victor Ascroft  wrote:
>>>>> Hello,
>>>>>
>>>>> I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb 
>>>>> build leads to a saving of almost 1 MB for my u-boot image and 
>>>>> consequently to faster serial downloads I have been looking at this. 
>>>>> Currently enabling this option leads to a hang.
>>>>>
>>>>> After some debugging I have narrowed the place of hang to "ldr pc, 
>>>>> =board_init_r" in arch/arm/lib/crt0.S. My debugging procedure was to put 
>>>>> a branch to a small function which just printed a small message with 
>>>>> puts, just before the ldr instruction and then a printing a small message 
>>>>> with puts just at the start of board_init_r in common/board_r.c . For a 
>>>>> non thumb build, the two messages get printed and I can boot to the 
>>>>> u-boot prompt. For a thumb build, only the first message before the ldr 
>>>>> instruction gets printed.
>>>>>
>>>>> In crt0.S
>>>>> bl debug_print
>>>>> ldr pc, =board_init_r
>>>>>
>>>>> In board_init_r
>>>>> puts("In board_init_r\n"); // Right at start
>>>>>
>>>>> void debug_print(void)
>>>>> {
>>>>> // Defined in board file
>>>>> puts("Debug print\n");
>>>>> }
>>>>>
>>>>> My assembly knowledge is limited and after some consultation with a 
>>>>> senior colleague, he told me things to check.
>>>>>
>>>>> An object dump of the crt0.o shows a branch to an even address. For 
>>>>> thumb, this is expected to be odd. To just try out, I did a change as 
>>>>> below
>>>>> ldr r3, =board_init_r
>>>>> add r3, #1
>>>>> bx r3
>>>>>
>>>>> No change with this. My expectation was the compiler/linker/assembler 
>>>>> would take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. 
>>>>> Frankly speaking I am not sure if this is the complete issue or only a 
>>>>> part of it. I have seen patches with regards to OMAP send in by Aneesh V, 
>>>>> which made changes of the form .type fn_name, %function to all the low 
>>>>> level assembly functions, but, I couldn't dig up much more or variants 
>>>>> thereof. Basically, from what I understand, this takes care of specifying 
>>>>> .thumb_func for a thumb function or so to speak.
>>>>>
>>>>> Any pointers?
>>>
>>> Victor,
>>>
>>> In addition to Simon's question below on the toolchain, I would like to
>>> know which commit you're trying to build.
> 
> I am using u-boot 2014.10, but, I have a modified branch which supports my 
> hardware
> and I also have changes for having USB Host and Client support for the Vybrid 
> platform.
> 
> The toolchain I am using is gcc-linaro-arm-linux-gnueabihf-2012.09-20120921
> 
> http://www.codesourcery.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

http://launchpad.net/linaro-toolchain-binaries/trunk/2012.09/+download/gcc-linaro-arm-linux-gnueabihf-2012.09-20120921_linux.tar.bz2

Sorry I gave the link for the soft floating one by mistake :(.
> 
> I have downloaded it from the above link.
> 
>>>
>>>> I tried this on a peach_pi (Samsung Chromebook 2 13") and it worked OK
>>>> for me. The code sequence you refer to came out as below for me.
>>>>
>>>> 23e01e10 :
>>>> 23e01e10:   e151cmp r0, r1
>>>> 23e01e14:   35802000strcc   r2, [r0]
>>>> 23e01e18:   3284addcc   r0, r0, #4
>>>> 23e01e1c:   3afbbcc 23e01e10 
>>>> 23e01e20:   fa000decblx 23e055d8 
>>>> 23e01e24:   fb000debblx 23e055da 
>>>> 23e01e28:   e1a9mov r0, r9
>>>> 23e01e2c:   e5991030ldr r1, [r9, #48]   ; 0x30
&g

Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD

2014-11-14 Thread Victor Ascroft
On 11/15/2014 07:26 AM, Simon Glass wrote:
> Hi Albert,
> 
> On 14 November 2014 08:26, Albert ARIBAUD  wrote:
>> Hello Simon,
>>
>> On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass 
>> wrote:
>>> Hi Victor,
>>>
>>> On 13 November 2014 09:29, Victor Ascroft  wrote:
>>>> Hello,
>>>>
>>>> I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb 
>>>> build leads to a saving of almost 1 MB for my u-boot image and 
>>>> consequently to faster serial downloads I have been looking at this. 
>>>> Currently enabling this option leads to a hang.
>>>>
>>>> After some debugging I have narrowed the place of hang to "ldr pc, 
>>>> =board_init_r" in arch/arm/lib/crt0.S. My debugging procedure was to put a 
>>>> branch to a small function which just printed a small message with puts, 
>>>> just before the ldr instruction and then a printing a small message with 
>>>> puts just at the start of board_init_r in common/board_r.c . For a non 
>>>> thumb build, the two messages get printed and I can boot to the u-boot 
>>>> prompt. For a thumb build, only the first message before the ldr 
>>>> instruction gets printed.
>>>>
>>>> In crt0.S
>>>> bl debug_print
>>>> ldr pc, =board_init_r
>>>>
>>>> In board_init_r
>>>> puts("In board_init_r\n"); // Right at start
>>>>
>>>> void debug_print(void)
>>>> {
>>>> // Defined in board file
>>>> puts("Debug print\n");
>>>> }
>>>>
>>>> My assembly knowledge is limited and after some consultation with a senior 
>>>> colleague, he told me things to check.
>>>>
>>>> An object dump of the crt0.o shows a branch to an even address. For thumb, 
>>>> this is expected to be odd. To just try out, I did a change as below
>>>> ldr r3, =board_init_r
>>>> add r3, #1
>>>> bx r3
>>>>
>>>> No change with this. My expectation was the compiler/linker/assembler 
>>>> would take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. 
>>>> Frankly speaking I am not sure if this is the complete issue or only a 
>>>> part of it. I have seen patches with regards to OMAP send in by Aneesh V, 
>>>> which made changes of the form .type fn_name, %function to all the low 
>>>> level assembly functions, but, I couldn't dig up much more or variants 
>>>> thereof. Basically, from what I understand, this takes care of specifying 
>>>> .thumb_func for a thumb function or so to speak.
>>>>
>>>> Any pointers?
>>
>> Victor,
>>
>> In addition to Simon's question below on the toolchain, I would like to
>> know which commit you're trying to build.

I am using u-boot 2014.10, but, I have a modified branch which supports my 
hardware
and I also have changes for having USB Host and Client support for the Vybrid 
platform.

The toolchain I am using is gcc-linaro-arm-linux-gnueabihf-2012.09-20120921

http://www.codesourcery.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

I have downloaded it from the above link.

>>
>>> I tried this on a peach_pi (Samsung Chromebook 2 13") and it worked OK
>>> for me. The code sequence you refer to came out as below for me.
>>>
>>> 23e01e10 :
>>> 23e01e10:   e151cmp r0, r1
>>> 23e01e14:   35802000strcc   r2, [r0]
>>> 23e01e18:   3284addcc   r0, r0, #4
>>> 23e01e1c:   3afbbcc 23e01e10 
>>> 23e01e20:   fa000decblx 23e055d8 
>>> 23e01e24:   fb000debblx 23e055da 
>>> 23e01e28:   e1a9mov r0, r9
>>> 23e01e2c:   e5991030ldr r1, [r9, #48]   ; 0x30
>>> 23e01e30:   e59ff008ldr pc, [pc, #8]; 23e01e40
>>> 
>>> 23e01e34:   02073800.word   0x02073800
>>> 23e01e38:   23e41eb0.word   0x23e41eb0
>>> 23e01e3c:   23e77bf0.word   0x23e77bf0
>>> 23e01e40:   23e057a9.word   0x23e057a9
>>>
>>> The 'ldr pc' line is loading from 23e01e40 which does have an odd address.
>>>
>>> What toolchain are you using? I tried with gcc 4.8.2 - including
>>> linaro's 2013.10 release.
>>>
>>> In arch/arm/cpu

Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD

2014-11-13 Thread Victor Ascroft


On 11/14/2014 11:13 AM, Wolfgang Denk wrote:
> Dear Victor,
> 
> In message <54658577.3090...@gmail.com> you wrote:
>>
>>>> I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb 
>>>> build leads to a saving of almost 1 MB for my u-boot image and 
>>>> consequently to faster serial downloads I have been looking at this. 
>>>> Currently enabling this option leads to a hang
>> . 
>>>
>>> Saving 1 MB?  So how big is your U-Boot image, then?
>>
>> To be exact
>>
>> For a thumb build:
>> 363288 bytes
>>
>> For a non thumb build:
>> 482072 bytes
> 
> That saves 118784 bytes or 116 KiB.  This is still a lot, but far from
> the dramatic "1 MB" you claimed...

Argh...Sorry my bad. I made a mistake there in interpreting the KB and MB. 


> 
> Best regards,
> 
> Wolfgang Denk
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD

2014-11-13 Thread Victor Ascroft
Hello,

On 11/14/2014 02:23 AM, Wolfgang Denk wrote:
> Dear Victor Ascroft,
> 
> In message <5464dc59.2040...@gmail.com> you wrote:
>>
>> I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb 
>> build leads to a saving of almost 1 MB for my u-boot image and consequently 
>> to faster serial downloads I have been looking at this. Currently enabling 
>> this option leads to a hang. 
> 
> Saving 1 MB?  So how big is your U-Boot image, then?

To be exact

For a thumb build:
363288 bytes

For a non thumb build:
482072 bytes

> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Query on CONFIG_SYS_THUMB_BUILD

2014-11-13 Thread Victor Ascroft
Hello,

I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb build 
leads to a saving of almost 1 MB for my u-boot image and consequently to faster 
serial downloads I have been looking at this. Currently enabling this option 
leads to a hang. 

After some debugging I have narrowed the place of hang to "ldr pc, 
=board_init_r" in arch/arm/lib/crt0.S. My debugging procedure was to put a 
branch to a small function which just printed a small message with puts, just 
before the ldr instruction and then a printing a small message with puts just 
at the start of board_init_r in common/board_r.c . For a non thumb build, the 
two messages get printed and I can boot to the u-boot prompt. For a thumb 
build, only the first message before the ldr instruction gets printed. 

In crt0.S
bl debug_print
ldr pc, =board_init_r

In board_init_r
puts("In board_init_r\n"); // Right at start

void debug_print(void)
{
// Defined in board file
puts("Debug print\n");
}

My assembly knowledge is limited and after some consultation with a senior 
colleague, he told me things to check.

An object dump of the crt0.o shows a branch to an even address. For thumb, this 
is expected to be odd. To just try out, I did a change as below
ldr r3, =board_init_r
add r3, #1
bx r3

No change with this. My expectation was the compiler/linker/assembler would 
take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. Frankly 
speaking I am not sure if this is the complete issue or only a part of it. I 
have seen patches with regards to OMAP send in by Aneesh V, which made changes 
of the form .type fn_name, %function to all the low level assembly functions, 
but, I couldn't dig up much more or variants thereof. Basically, from what I 
understand, this takes care of specifying .thumb_func for a thumb function or 
so to speak.

Any pointers?

Thanks & Regards,
Sanchayan Maity.  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB mass storage gadget patch

2012-11-21 Thread victor
Lukasz,

> -Original Message-
> From: victor [mailto:vic...@keyasic.com]
> Sent: Tuesday, 6 November, 2012 7:09 PM
> To: 'Lukasz Majewski'
> Cc: 'u-boot@lists.denx.de'; 'Marek Vasut'; 'Kyungmin Park'
> Subject: RE: [U-Boot] USB mass storage gadget patch
> 
> Lukasz,
> 
> > Lukasz,
> >
> > > Hi victor,
> > >
> > > Regarding UMS support:
> > >
> > > The last version posted at u-boot ML can be found at [**]:
> > > http://thread.gmane.org/gmane.comp.boot-loaders.u-
> > > boot/113004/match=ums
> > >
> > >
> > > +if (fsg_fs_bulk_out_desc.bEndpointAddress != 0x1)
> > > + fsg_fs_bulk_out_desc.bEndpointAddress = 0x1;
> > > +
> > >
> > > If possible, please align to patch set [**], so we can have the same
setup.
> > >
> > > However, I will try to find some time to help you with the problem
> > > (that's why I've asked for description of the problem, which you are
> > > trying
> > to fix).
> > >
> >
> > I hardcode bulk out endpoint to EP1 because the hardware only got one
> > endpoint. So the code has to use EP1 for both bulk in and bulk out
> > data transfer. Will this break the usb mass storage gadget code?
> >
> > I will get the file_storage.c  from [**].
> >
> > The short description of the problem:
> > The U-boot usb mass storage gadget driver has problem with buffer
> > management, sometimes the buffer returned by IRQ routine and the
> > get_next_command function are different. It causes problem in
> > processing
> > SCSI_MODE_SELECT_6 command.
> >
> > The detailed description of the problem:
> > When receiving the SCSI_MODE_SELECT_6 command, in
> bulk_out_complete(),
> > the bh pointer is 0x1b872e4. Then, in get_next_command(), before
> > calling start_transfer(), the bh pointer becomes 0x1b87304. This
> > changes in bh pointer can cause data not to be processed by the usb
> > mass storage gadget code.
> >
> > Thanks,
> > Victor
> 
> I use the file_storage.c from [**]. Basically, I replace file_storage.c
and
> hardcode bulk out endpoint to EP1. The IRQ routine can receive the
> SCSI_INQUIRY but the get_next_command() do not process it. The
> get_next_command is listening on a different bh than the one returned by
> IRQ routine.
> 
> Regards,
> victor

Any comments or opinion on the above buffer mismatch issue in usb mass
storage gadget?

Regards,
Victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB mass storage gadget patch

2012-11-06 Thread victor
Lukasz,

> Lukasz,
> 
> > Hi victor,
> >
> > Regarding UMS support:
> >
> > The last version posted at u-boot ML can be found at [**]:
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-
> > boot/113004/match=ums
> >
> >
> > +if (fsg_fs_bulk_out_desc.bEndpointAddress != 0x1)
> > +   fsg_fs_bulk_out_desc.bEndpointAddress = 0x1;
> > +
> >
> > If possible, please align to patch set [**], so we can have the same
setup.
> >
> > However, I will try to find some time to help you with the problem
> > (that's why I've asked for description of the problem, which you are
trying
> to fix).
> >
> 
> I hardcode bulk out endpoint to EP1 because the hardware only got one
> endpoint. So the code has to use EP1 for both bulk in and bulk out data
> transfer. Will this break the usb mass storage gadget code?
> 
> I will get the file_storage.c  from [**].
> 
> The short description of the problem:
> The U-boot usb mass storage gadget driver has problem with buffer
> management, sometimes the buffer returned by IRQ routine and the
> get_next_command function are different. It causes problem in processing
> SCSI_MODE_SELECT_6 command.
> 
> The detailed description of the problem:
> When receiving the SCSI_MODE_SELECT_6 command, in
> bulk_out_complete(), the bh pointer is 0x1b872e4. Then, in
> get_next_command(), before calling start_transfer(), the bh pointer
> becomes 0x1b87304. This changes in bh pointer can cause data not to be
> processed by the usb mass storage gadget code.
> 
> Thanks,
> Victor

I use the file_storage.c from [**]. Basically, I replace file_storage.c and
hardcode bulk out endpoint to EP1. The IRQ routine can receive the
SCSI_INQUIRY but the get_next_command() do not process it. The
get_next_command is listening on a different bh than the one returned by IRQ
routine. 

Regards,
victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB mass storage gadget patch

2012-11-06 Thread victor
Lukasz,

> Hi victor,
> 
> Regarding UMS support:
> 
> The last version posted at u-boot ML can be found at [**]:
> http://thread.gmane.org/gmane.comp.boot-loaders.u-
> boot/113004/match=ums
> 
> 
> +if (fsg_fs_bulk_out_desc.bEndpointAddress != 0x1)
> + fsg_fs_bulk_out_desc.bEndpointAddress = 0x1;
> +
> 
> If possible, please align to patch set [**], so we can have the same
setup.
> 
> However, I will try to find some time to help you with the problem (that's
> why I've asked for description of the problem, which you are trying to
fix).
> 

I hardcode bulk out endpoint to EP1 because the hardware only got one
endpoint. So the code has to use EP1 for both bulk in and bulk out data
transfer. Will this break the usb mass storage gadget code?

I will get the file_storage.c  from [**].

The short description of the problem:
The U-boot usb mass storage gadget driver has problem with buffer
management, sometimes the buffer returned by IRQ routine and the
get_next_command function are different. It causes problem in processing
SCSI_MODE_SELECT_6 command. 

The detailed description of the problem:
When receiving the SCSI_MODE_SELECT_6 command, in bulk_out_complete(), the
bh pointer is 0x1b872e4. Then, in get_next_command(), before calling
start_transfer(), the bh pointer becomes 0x1b87304. This changes in bh
pointer can cause data not to be processed by the usb mass storage gadget
code.

Thanks,
Victor




CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB mass storage gadget patch

2012-11-05 Thread victor
Hi,

>On further research into this, when receiving the SCSI_MODE_SELECT_6
command, in bulk_out_complete(), the bh pointer is 0x1b872e4
>
>== debug statement from console ==
>0x43425355 0x507bc10 0x18 0x1506 0x1810 0x0 0x0 bulk_out_complete
0x1b872e4
>
>Then, in get_next_command(), before calling start_transfer(), the bh
pointer becomes 0x1b87304. 
>
>This changes in bh pointer can cause data not to be processed by the usb
mass storage gadget code. 

Is there any feedback on the buffer management problem in the U-boot usb
mass storage gadget patch? Thanks.

Regards,
Victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB mass storage gadget patch

2012-11-04 Thread victor
Lukasz,

>>> 2) Now I can use the patch and process till SCSI MODE_SELECT_6 
>>> command, and then problem is encountered. Basically the SCSI
>>> MODE_SELECT_6 is sent to EP1 Out, then data is sent to EP1 out, and 
>>> the fsg_main_thread only sees the data. I change the code to force 
>>> the CSW.
>>
>>Can you explain further problems which you encounter?
>>
>>I'm using this UMS version internally (the version which you pointed out
with the link) for debugging our targets.
>>
>>I'm using Debian Linux as a host with standard tools like dd and
parted/fdisk. I don't have any problems with it (even with debug messages
enabled).
>>
>>
>
>In cmd_usb_mass_storage.c, do_usb_mass_storage(), the while(1) loop, the
usb_gadget_handle_interrupts() will handle the interrupts that is triggered,
and received data
> from EP1 out, and bh-state >is set to BUF_STATE_FULL in
bulk_out_complete(). And then fsg_main_thread() in file_storage.c is called.
And then get_next_command() is called. 
>And then start_transfer() is called. In that function, the bh->state will
be set to BUF_STATE_BUSY. Because of this change, for two consecutive data
from EP1 out, one data is missed.

>I can send the full source code to you if it is helpful. Thanks.

On further research into this, when receiving the SCSI_MODE_SELECT_6
command, in bulk_out_complete(), the bh pointer is 0x1b872e4

== debug statement from console ==
0x43425355 0x507bc10 0x18 0x1506 0x1810 0x0 0x0 
bulk_out_complete 0x1b872e4

Then, in get_next_command(), before calling start_transfer(), the bh pointer
becomes 0x1b87304. 

This changes in bh pointer can cause data not to be processed by the usb
mass storage gadget code. 

Regards,
Victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB mass storage gadget patch

2012-11-04 Thread victor
Lukasz,

>> 2) Now I can use the patch and process till SCSI MODE_SELECT_6 
>> command, and then problem is encountered. Basically the SCSI
>> MODE_SELECT_6 is sent to EP1 Out, then data is sent to EP1 out, and 
>> the fsg_main_thread only sees the data. I change the code to force the 
>> CSW.
>
>Can you explain further problems which you encounter?
>
>I'm using this UMS version internally (the version w   hich you
pointed out with the link) for debugging our targets.
>
>I'm using Debian Linux as a host with standard tools like dd and
parted/fdisk. I don't have any problems with it (even with debug messages
enabled).
>
>

In cmd_usb_mass_storage.c, do_usb_mass_storage(), the while(1) loop, the
usb_gadget_handle_interrupts() will handle the interrupts that is triggered,
and received data from EP1 out, and bh->state is set to BUF_STATE_FULL in
bulk_out_complete(). And then fsg_main_thread() in file_storage.c is called.
And then get_next_command() is called. And then start_transfer() is called.
In that function, the bh->state will be set to BUF_STATE_BUSY. Because of
this change, for two consecutive data from EP1 out, one data is missed.

I can send the full source code to you if it is helpful. Thanks.

Regards,
Victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] USB mass storage gadget patch

2012-11-02 Thread victor
>> I attach the file for your reference. Please kindly advise me. Thanks.

The changes of file_storage.c:

--- file_storage.c  2012-11-02 18:27:41.072702402 +0800
+++ file_storage.orig.c 2012-11-02 19:36:37.992528292 +0800

@@ -746,10 +745,6 @@
struct fsg_dev  *fsg = ep->driver_data;
struct fsg_buffhd   *bh = req->context;
 
-ga_bh = bh;
-ga_tag = fsg->tag;
-
dump_msg(fsg, "bulk-out", req->buf, req->actual);
if (req->status || req->actual != bh->bulk_out_intended_length)
DBG(fsg, "%s --> %d, %u/%u\n", __func__,

@@ -1185,9 +1174,6 @@
return rc;
}
 
-bh->inreq->buf = bh->buf;
-
/* If we were asked to read past the end of file,
 * end with an empty buffer. */
if (amount == 0) {
@@ -1575,8 +1560,6 @@
static char vendor_id[] = "Linux   ";
static char product_cdrom_id[] = "File-CD Gadget  ";
 
-bh->inreq->buf = bh->buf;  
 
if (!fsg->curlun) { // Unsupported LUNs are okay
fsg->bad_lun_okay = 1;
@@ -1667,15 +1649,12 @@
int pmi = fsg->cmnd[8];
u8  *buf = (u8 *) bh->buf;
 
-bh->inreq->buf = bh->buf;
/* Check the PMI and LBA fields */
if (pmi > 1 || (pmi == 0 && lba != 0)) {
curlun->sense_data = SS_INVALID_FIELD_IN_CDB;
return -EINVAL;
}
 
@@ -1755,8 +1734,6 @@
curlun->sense_data = SS_SAVING_PARAMETERS_NOT_SUPPORTED;
return -EINVAL;
}
-printf("C %s %x ", __func__, (u8 *)bh->buf);
-bh->inreq->buf = bh->buf;
 
changeable_values = (pc == 1);
all_pages = (page_code == 0x3f);
@@ -1865,8 +1842,6 @@
struct fsg_lun  *curlun = fsg->curlun;
u8  *buf = (u8 *) bh->buf;
 
-printf("%s\n",__func__);
-bh->inreq->buf = bh->buf;
buf[0] = buf[1] = buf[2] = 0;
buf[3] = 8; // Only the Current/Maximum Capacity
Descriptor
buf += 4;
@@ -1956,9 +1931,8 @@
 
nsend = min(fsg->usb_amount_left, (u32) mod_data.buflen);
memset(bh->buf + nkeep, 0, nsend - nkeep);
-   //bh->inreq->length = nsend;
+   bh->inreq->length = nsend;
bh->inreq->zero = 0;
-printf("%s %x %d %d\n", __func__, (u8 *)bh, bh->inreq->length, nsend);
start_transfer(fsg, fsg->bulk_in, bh->inreq,
&bh->inreq_busy, &bh->state);
bh = fsg->next_buffhd_to_fill = bh->next;

@@ -2137,13 +2107,7 @@
 
/* Wait for the next buffer to become available */
bh = fsg->next_buffhd_to_fill;
-printf("%s %x %d\n", __func__,  (u8 *)bh, bh->state);
while (bh->state != BUF_STATE_EMPTY) {
-if (bh->state == BUF_STATE_FULL)
-{
-   bh->state = BUF_STATE_EMPTY;
-   break;
-}
rc = sleep_thread(fsg, __LINE__);
if (rc)
return rc;
@@ -2180,8 +2144,6 @@
 
bh->inreq->length = USB_BULK_CS_WRAP_LEN;
bh->inreq->zero = 0;
-bh->inreq->buf = bh->buf;
-printf("bbb %s %x %d\n", __func__, (u8 *)bh, bh->state);
start_transfer(fsg, fsg->bulk_in, bh->inreq,
&bh->inreq_busy, &bh->state);
 

@@ -2362,12 +2320,9 @@
for (i = 1; i < cmnd_size; ++i) {
if (fsg->cmnd[i] && !(mask & (1 << i))) {
 
if (curlun)
curlun->sense_data =
SS_INVALID_FIELD_IN_CDB;
//return -EINVAL;

}
}

@@ -2669,8 +2620,6 @@
 
 ga_bh->inreq->length = USB_BULK_CS_WRAP_LEN;
 ga_bh->inreq->zero = 0;
-ga_bh->inreq->buf = ga_bh->buf;
-printf("bbb %s %x %d\n", __func__, (u8 *)ga_bh, ga_bh->state);
 start_transfer(fsg, fsg->bulk_in, ga_bh->inreq,
 &(ga_bh->inreq_busy), &(ga_bh->state));
 
@@ -2732,26 +2679,20 @@
/* Queue a request to read a Bulk-only CBW */
set_bulk_out_req_length(fsg, bh, USB_BULK_CB_WRAP_LEN);
bh->outreq->short_not_ok = 1;
-printf("call start_transfer, %x %x\n", (u8 *)bh, (u8 *)(fsg->bulk_out));
-bh->outreq->context = bh;
start_transfer(fsg, fsg->bulk_out, bh->outreq,
&bh->outreq_busy, &bh->state);

@@ -3468,8 +3406,6 @@
ep->driver_data = fsg;  // claim the endpoint
fsg->bulk_out = ep;
 
-if (fsg_fs_bulk_out_desc.bEndpointAddress != 0x1)
-   fsg_fs_bulk_out_desc.bEndpointAddress = 0x1;
 
if (transport_is_cbi()) {
ep = usb_ep_autoconfig(gadget, &fsg_fs_intr_in_desc);



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidentia

[U-Boot] generic mmc bug in reading sd card capacity

2012-11-02 Thread victor
Hi All,

Accord to SD spec 2.0, the formula to find out sd card capacity is:

memory capacity = (C_SIZE+1) * 512K byte 
and
C_SIZE  is from CSD [69:48]

Thus, the code in generic mmc is wrong for the high capacity sd card. My
patch is below.

Thanks,
victor

--- mmc.c   2012-10-09 02:20:28.0 +0800
+++ mmc.c.victor2012-11-02 15:07:16.949207266 +0800
@@ -1068,17 +1104,26 @@
mmc->write_bl_len = 1 << ((cmd.response[3] >> 22) & 0xf);
 
if (mmc->high_capacity) {
-   csize = (mmc->csd[1] & 0x3f) << 16
-   | (mmc->csd[2] & 0x) >> 16;
-   cmult = 8;
+   //csize = (mmc->csd[1] & 0x3f) << 16
+   //  | (mmc->csd[2] & 0x) >> 16;
+   //cmult = 8;
+csize = (mmc->csd[2] & 0x3f) << 16
+  | (mmc->csd[1] & 0x) >> 16;
} else {
csize = (mmc->csd[1] & 0x3ff) << 2
| (mmc->csd[2] & 0xc000) >> 30;
cmult = (mmc->csd[2] & 0x00038000) >> 15;
}
 
-   mmc->capacity = (csize + 1) << (cmult + 2);
-   mmc->capacity *= mmc->read_bl_len;
+   if (mmc->high_capacity) {
+   mmc->capacity = (csize + 1) * 512 * 1024;
+   } else {
+   mmc->capacity = (csize + 1) << (cmult + 2);
+   mmc->capacity *= mmc->read_bl_len;
+   }



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] USB gadget driver

2012-10-29 Thread victor
Hi All,

I am porting the USB gadget driver to a new hardware. Problems I encounter:

1) In bulk_out_complete, the bh->state is set to BUF_STATE_FULL, then after
sleep_thread of the "wait for CBW to arrive", it becomes BUF_STATE_BUSY.

Please help me.

victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] mmc Status Error: 0x01FBB4D0

2012-10-02 Thread victor
Hi All.

I change legacy sd/mmc driver to generic mmc structure, then I run the
u-boot "mmc rescan" command. All looks fine except the:


status reg 0x8c00 0x0
resp1_reg 0x0
Status Error: 0x01FBB4D8

Please help me on the meaning of the status error in mmc.c code. 

Thanks,
Victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Strange behavior in U-boot fatload command for SD/MMC card

2012-10-02 Thread victor
Hi,

 

When using "fatload mmc 0 2e00 u-boot.bin" command, the function handling
that is in common/cmd_fat.c::do_fat_fsload()

 

I put some printf statements in the function:

 

int do_fat_fsload (..)

{

  ..

printf("do_fat_load 1 \n");

dev = (int)simple_strtoul(argv[2], &ep, 16);

dev_desc = get_dev(argv[1],dev);

if (dev_desc == NULL) {

puts("\n** Invalid boot device **\n");

return 1;

}

printf("do_fat_load 2 \n");

  ..

}

 

The output on console is as below. The do_fat_load is hit, but do_fat_load
is not. And the "invalid boot device" is not printed. And it goes to
mmc_init. What mistake that I've made? Thanks.

KA2000# fatload mmc 0 2e00 u-boot.bin

do_fat_load 1

drivers/mmc mmc_init

KA Boot 04240806

Status 20200804

MMC:   ka2000_mmc_init

KA2000#

 

Thanks,

victor



CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and may be 
protected by legal privilege. If you are not the intended addressee (or 
authorized to receive for the addressee). be aware that any disclosure, 
copying, distribution or use of this e-mail or any attachment is prohibited. If 
you have received this e-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.
KeyASIC Inc.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] (no subject)

2011-10-09 Thread victor casunuran
how to reset or re program this part item s29gl064n90tf103.. can you please 
help me


thanks

vic

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ppc4xx: Disable trace broadcast for 44x non debug mode

2010-09-16 Thread Victor Gallardo
By default the trace broadcast is enabled on 44x systems.

To reduce power consumption when instruction tracing is
not needed, disable trace broadcast.

Check External Debug Mode (EDM) bit to detect if it should be
disabled or not.

Resetting system via a debugger will set the DBCR0[EDM] bit.
Resetting via u-boot or OS will not.

Signed-off-by: Victor Gallardo 
---
 arch/powerpc/cpu/ppc4xx/start.S |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S
index 4bad32f..bac8681 100644
--- a/arch/powerpc/cpu/ppc4xx/start.S
+++ b/arch/powerpc/cpu/ppc4xx/start.S
@@ -340,6 +340,9 @@ _start_440:
mfspr   r1,SPRN_DBCR0
andis.  r1, r1, 0x8000  /* test DBCR0[EDM] bit  */
bne skip_debug_init /* if set, don't clear debug register   */
+   mfspr   r1,SPRN_CCR0
+   ori r1,r1,ccr0_...@l /* Disable Trace Broadcast */
+   mtspr   SPRN_CCR0,r1
mtspr   SPRN_DBCR0,r0
mtspr   SPRN_DBCR1,r0
mtspr   SPRN_DBCR2,r0
-- 
1.6.1.rc3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ppc4xx: Fix 440EPx bug in reconfigure_pll()

2010-08-26 Thread Victor Gallardo
Hi Stefan,

> This patch fixes a bug in reconfigure_pll(), where the detection of
> the current bootstrap option is wrong. The ICS bits where incorrectly
> shifted. This bug was found on the lwmon5 board, which uses bootstrap
> option H (I2C bootstrap EEPROM).
>
> Additionally a bit of code was moved into the if statement, since its
> only used after later on. No need to run this code all the time.
>
> Also, a few empty lines are added to make the code better readable.
>

Look good to me.

-Victor Gallardo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

2009-08-20 Thread Victor Gallardo
Hi Vimal,

> > With the current ndfc code, the error correction gets the bits wrong.
> > Switching it back to the original way and the correction is correct.
> >
> > diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
> > index 89bf85a..497e175 100644
> > --- a/drivers/mtd/nand/ndfc.c
> > +++ b/drivers/mtd/nand/ndfc.c
> > @@ -101,9 +101,8 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
> >
> >        wmb();
> >        ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
> > -       /* The NDFC uses Smart Media (SMC) bytes order */
> > -       ecc_code[0] = p[2];
> > -       ecc_code[1] = p[1];
> > +       ecc_code[0] = p[1];
> > +       ecc_code[1] = p[2];
> >        ecc_code[2] = p[3];
> >
> >        return 0;
> >
> > Does anybody see a problem with my method of reproducing the bug? This
> > bug is deadly for our customers. I don't want to make the change unless
> > it is absolutely necessary..
> 
> Just one question: did you enabled MTD_NAND_ECC_SMC in configs?

Yes, it was set.

Best Regards,

Victor Gallardo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

2009-08-20 Thread Victor Gallardo
Hi Sean,

The change is necessary in both Linux and u-boot. Without this change customer 
are seeing the problem.

Best Regards,

Victor Gallardo

> -Original Message-
> From: linuxppc-dev-bounces+vgallardo=amcc@lists.ozlabs.org 
> [mailto:linuxppc-dev-
> bounces+vgallardo=amcc@lists.ozlabs.org] On Behalf Of Sean MacLennan
> Sent: Thursday, August 20, 2009 12:37 PM
> To: Stefan Roese
> Cc: u-boot@lists.denx.de; Feng Kan; linux-...@lists.infradead.org; 
> linuxppc-...@ozlabs.org
> Subject: Re: [U-Boot] NAND ECC Error with wrong SMC ording bug
> 
> On Thu, 20 Aug 2009 07:01:21 +0200
> Stefan Roese  wrote:
> 
> > On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote:
> > > > I see other boards using SMC as well, can someone comment on the
> > > > change I am proposing.
> > > > Should I change the correction algorithm or the calculate
> > > > function? If the later is preferred
> > > > it would mean the change must be pushed in both U-Boot and Linux.
> > >
> > > Odds are the calculate function is wrong. The correction algo is
> > > used by many nand drivers, I *assume* it is correct. The calculate
> > > function was set to agree with u-boot (1.3.0).
> >
> > Yes, it seems that you changed the order in the calculation function
> > while reworking the NDFC driver for arch/powerpc. So we should
> > probably change this order back to the original version. And change
> > it in U-Boot as well.
> >
> > BTW: I didn't see any problems with ECC so far with the current code.
> > Feng, how did you spot this problem?
> 
> Ok, I think I have reproduced the problem programmatically. Basically,
> I force a one bit error with the following patch:
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 8c21b89..91dd5b4 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -1628,11 +1628,22 @@ static void nand_write_page_hwecc(struct mtd_info 
> *mtd, struct nand_chip
> *chip,
>   uint8_t *ecc_calc = chip->buffers->ecccalc;
>   const uint8_t *p = buf;
>   uint32_t *eccpos = chip->ecc.layout->eccpos;
> + static int count;
> 
>   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
>   chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
> - chip->write_buf(mtd, p, eccsize);
> - chip->ecc.calculate(mtd, p, &ecc_calc[i]);
> + if (count == 0) {
> + count = 1;
> + printk("Corrupt one bit: %08x => %08x\n",
> +*p, *p ^ 8);
> + *(uint8_t *)p ^= 8;
> + chip->write_buf(mtd, p, eccsize);
> + *(uint8_t *)p ^= 8;
> + nand_calculate_ecc(mtd, p, &ecc_calc[i]);
> + } else {
> + chip->write_buf(mtd, p, eccsize);
> + chip->ecc.calculate(mtd, p, &ecc_calc[i]);
> + }
>   }
> 
>   for (i = 0; i < chip->ecc.total; i++)
> 
> Basically I write a one bit error to the NAND, but calculate with the
> correct bit. This assumes nand_calculate_ecc is correct.
> 
> I then added debugs to the correction to make sure it corrected
> properly:
> 
> diff --git a/drivers/mtd/nand/nand_ecc.c b/drivers/mtd/nand/nand_ecc.c
> index c0cb87d..57dcaa1 100644
> --- a/drivers/mtd/nand/nand_ecc.c
> +++ b/drivers/mtd/nand/nand_ecc.c
> @@ -483,14 +483,20 @@ int nand_correct_data(struct mtd_info *mtd, unsigned 
> char *buf,
>   byte_addr = (addressbits[b2 & 0x3] << 8) +
>   (addressbits[b1] << 4) + addressbits[b0];
>   bit_addr = addressbits[b2 >> 2];
> +
> + printk("Single bit error: correct %08x => %08x\n",
> +buf[byte_addr], buf[byte_addr] ^ (1 << bit_addr));
> +
>   /* flip the bit */
>   buf[byte_addr] ^= (1 << bit_addr);
>   return 1;
> 
>   }
>   /* count nr of bits; use table lookup, faster than calculating it */
> - if ((bitsperbyte[b0] + bitsperbyte[b1] + bitsperbyte[b2]) == 1)
> + if ((bitsperbyte[b0] + bitsperbyte[b1] + bitsperbyte[b2]) == 1) {
> + printk("ECC DATA BAD\n"); // SAM DBG
>   return 1;   /* error in ecc data; no action needed */
> + }
> 
>   printk(KERN_ERR "uncorrectable error : ");
>   return -1;
> 
> With the current ndfc code, the error correction gets the bits wrong.
> Swit

Re: [U-Boot] [PATCH 1/1 v2] ppc4xx: Reset and relock memory DLL after SDRAM_CLKTR change

2008-10-08 Thread Victor Gallardo
OK. Thanks Stefan.
 
> > We will take a look.
> 
> Thanks.
> 
> > Yes, we ran the test as you mentioned (bootcmd=reset) on both versions of
> > the Kilauea board and let it run for 24 hours without any problems.
> > Hopefully we can reproduce the problem you are seeing.
> 
> I suggest that you use some means to cool down the board and heat it up a
> little bit, to see if it fails in some temperature ranges.
> 
> It happend here with a "cold" board. I powered it on again:
...
>
> I suggest that you use the same object I used. Please find it attached.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1 v2] ppc4xx: Reset and relock memory DLL after SDRAM_CLKTR change

2008-10-08 Thread Victor Gallardo
Hi Stefan,
 
We will take a look. 
 
Yes, we ran the test as you mentioned (bootcmd=reset) on both versions of the 
Kilauea board and let it run for 24 hours without any problems. Hopefully we 
can reproduce the problem you are seeing.
 
Thanks,
 
Victor Gallardo



From: Stefan Roese [mailto:[EMAIL PROTECTED]
Sent: Wed 10/8/2008 2:47 AM
To: u-boot@lists.denx.de
Cc: Adam Graham; Victor Gallardo
Subject: Re: [U-Boot] [PATCH 1/1 v2] ppc4xx: Reset and relock memory DLL after 
SDRAM_CLKTR change



Adam,

On Wednesday 08 October 2008, Stefan Roese wrote:
> On Monday 06 October 2008, Adam Graham wrote:
> > After changing SDRAM_CLKTR phase value rerun the memory preload
> > initialization sequence (INITPLR) to reset and relock the memory
> > DLL. Changing the SDRAM_CLKTR memory clock phase coarse timing
> > adjustment effects the phase relationship of the internal, to the
> > PPC chip, and external, to the PPC chip, versions of MEMCLK_OUT.
>
> Applied ppc4xx/master. Thanks.

Ups. I just gave this version another try on my 600MHz Kilauea board. And as
it seems it definitely works better than without this patch, but it doesn't
work reliably. :-(

Here some outputs after rebooting:


U-Boot 2008.10-rc2-02708-gf8a00de (Oct  8 2008 - 11:40:49)

CPU:   AMCC PowerPC 405EX Rev. C at 600 MHz (PLB=200, OPB=100, EBC=100 MHz)
   Security support
   Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
   16 kB I-Cache 16 kB D-Cache
Board: Kilauea - AMCC PPC405EX Evaluation Board
I2C:   ready
DTT1:  FAILED
DRAM:  256 MB


U-Boot 2008.10-rc2-02708-gf8a00de (Oct  8 2008 - 11:40:49)

CPU:   AMCC PowerPC 405EX Rev. C at 600 MHz (PLB=200, OPB=100, EBC=100 MHz)
   Security support
   Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
   16 kB I-Cache 16 kB D-Cache
Board: Kilauea - AMCC PPC405EX Evaluation Board
I2C:   ready
DTT1:  FAILED
DRAM:  256 MB
Memory error at 01cff924, wrote 0200, read 0200 !


This didn't happen with the temporary patch you sent out a few weeks ago. This
error occurs often after pushing the reset button on the Kilauea. I suggest
that you take another look at this issue on your 600MHz board. Perhaps make a
long test by setting "bootcmd" to "reset". If the board still resets after
running for some hours, then you should be safe.

BTW: I won't ask Wolfgang to pull for now.

Thanks.

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3 v2] ppc4xx: Add AMCC Arches boardsupport(dual 460GT)

2008-10-07 Thread Victor Gallardo
> >
> > I reviewed this again. It cannot be part of default config. We need
> > to do it at PREBOOT because eth_register() updates this variable
> > each time at boot. It assigns ethact to the first ethernet port it
> > discovers. In Arches, we need the second Ethernet port set as ethact.
> > Updating it at preboot allows us to update after eth_register has
> > set it.
> 
> Are you sure? I think there must be something wrong with your
> configuration, then. Did you set "ethprime" ?

How did I miss that. Yes, this is what we should be using.  

Thanks for the help Wolfgang,
 
Victor Gallardo

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3 v2] ppc4xx: Add AMCC Arches boardsupport(dual 460GT)

2008-10-06 Thread Victor Gallardo
Dear Wolfgang,

> > diff --git a/include/configs/canyonlands.h 
> > b/include/configs/canyonlands.h index 2f162e1..acad9b3 100644
> > --- a/include/configs/canyonlands.h
> > +++ b/include/configs/canyonlands.h
> ...
> > +#define CONFIG_PREBOOT \
> > +   "setenv ethact ppc_4xx_eth1;" \
> 
> This should not be done in the preboot command, but as part of the 
> default config instead.

I reviewed this again. It cannot be part of default config. We need
to do it at PREBOOT because eth_register() updates this variable
each time at boot. It assigns ethact to the first ethernet port it
discovers. In Arches, we need the second Ethernet port set as ethact.
Updating it at preboot allows us to update after eth_register has
set it.

Best Regards,

Victor Gallardo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3 v2] ppc4xx: Add AMCC Arches board support(dual 460GT)

2008-10-06 Thread Victor Gallardo
_CMD_NAND
> > +#define CONFIG_CMD_SNTP
> > +#endif
> > +#define CONFIG_CMD_DTT
> >  #define CONFIG_CMD_PCI
> >  #define CONFIG_CMD_SDRAM
> > -#define CONFIG_CMD_SNTP
> >  #ifdef CONFIG_460EX
> >  #define CONFIG_CMD_EXT2
> >  #define CONFIG_CMD_FAT
>
> I think we should separate these tlistrs of commands, so we can keep
> the lists sorted.

OK.

> > +/*
> > + * Arches has 32MBytes of NOR FLASH (Spansion 29GL256) so remap FLASH to
> > + * EBC address which accepts bigger regions:
> > + *   0xfe00. -> 4.ce00.
> > + */
> 
> Cannot we do this automatically, dependent on the actual size of flash
> as determined by the code?
> 

Will investigate.

Best Regards,

Victor Gallardo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] ppc4xx: Fix DDR2 auto calibration on Kilauea 600MHz

2008-09-16 Thread Victor Gallardo

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
Signed-off-by: Adam Graham <[EMAIL PROTECTED]>
---
 v2:
 - Add comments on why this is need for 200MHz PLB bus 
 - Minor coding style cleanup

 board/amcc/kilauea/kilauea.c|   31 +++
 cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c |5 -
 include/asm-ppc/ppc4xx-sdram.h  |6 ++
 3 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/board/amcc/kilauea/kilauea.c b/board/amcc/kilauea/kilauea.c
index 7b10255..fcab9ca 100644
--- a/board/amcc/kilauea/kilauea.c
+++ b/board/amcc/kilauea/kilauea.c
@@ -374,3 +374,34 @@ int post_hotkeys_pressed(void)
return 0;   /* No hotkeys supported */
 }
 #endif /* CONFIG_POST */
+
+#if defined(CONFIG_PPC4xx_DDR_AUTOCALIBRATION)
+/*
+ * This is for quicker auto calibration boot up once WRDTR and CLKTR
+ * values for the kilauea board were determined and are therefore known.
+ *
+ * Use these scan options for PLB bus greater than or equal 200MHz
+ * else use the defaults. These options are known to return a cycle
+ * delay of T2 or better with a 200MHz PLB bus. Scanning the
+ * full list of WDTR/CLKTR should work, but currently it does not.
+ * HW team is investigating.
+ */
+/* List of (SDRAM_WRDTR.[WDTR], SDRAM_CLKTR.[CLKP]) pairs to try */
+struct sdram_timing quick_scan_options[] = {
+   {0, 3}, {1, 1}, {1, 2}, {1, 3},
+   {2, 1}, {2, 2}, {2, 3}, {3, 1},
+   {3, 2}, {4, 1}, {-1, -1}
+};
+
+ulong ddr_scan_option(ulong default_val)
+{
+   PPC4xx_SYS_INFO board_cfg;
+
+   get_sys_info(&board_cfg);
+
+   if (board_cfg.freqPLB >= 2)
+   return (ulong)(quick_scan_options);
+   else
+   return (ulong)default_val;
+}
+#endif /* CONFIG_PPC4xx_DDR_AUTOCALIBRATION */
diff --git a/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c 
b/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
index 83b9883..3ba8176 100644
--- a/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
+++ b/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
@@ -79,11 +79,6 @@ struct ddrautocal {
u32 flags;
 };
 
-struct sdram_timing {
-   u32 wrdtr;
-   u32 clktr;
-};
-
 struct sdram_timing_clks {
u32 wrdtr;
u32 clktr;
diff --git a/include/asm-ppc/ppc4xx-sdram.h b/include/asm-ppc/ppc4xx-sdram.h
index 8efa557..2ba5619 100644
--- a/include/asm-ppc/ppc4xx-sdram.h
+++ b/include/asm-ppc/ppc4xx-sdram.h
@@ -1403,6 +1403,12 @@
 #endif /* CONFIG_SDRAM_PPC4xx_DENALI_DDR2 */
 
 #ifndef __ASSEMBLY__
+
+struct sdram_timing {
+   u32 wrdtr;
+   u32 clktr;
+};
+
 /*
  * Prototypes
  */
-- 
1.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ppc4xx: Fix DDR2 auto calibration on Kilauea 600MHz

2008-09-16 Thread Victor Gallardo
>> +
>> +#if defined(CONFIG_PPC4xx_DDR_AUTOCALIBRATION)
>> +/*
>> + * This is for quicker auto calibration boot up once WRDTR and CLKTR
>> + * values for the kilauea board were determined and are therefore known.
>> + *
>> + * Use these scan options for PLB bus greater than 200MHz else use
>> + * the defaults.
>> + */
>> +/* List of (SDRAM_WRDTR.[WDTR], SDRAM_CLKTR.[CLKP]) pairs to try */ 
>> +struct sdram_timing quick_scan_options[] = {
>> +{0, 3}, {1, 1}, {1, 2}, {1, 3},
>> +{2, 1}, {2, 2}, {2, 3}, {3, 1},
>> +{3, 2}, {4, 1}, {-1, -1}
>> +};
>
> It's not really clear to me, why this reduced list should fix this problem
> seen on the 600MHz boards (it does - I tested successfully on my board).
> From my understanding the scan is now skipping some of the WDTR/CLKTR
> configurations. This will of course result in a quicker scan, but
> autocalibration should still work with the default full list.
>

Hi Stefan, yes you are correct, it should, but for some reason the full list 
causes problem. This is currently being investigated by HW team. Current work 
around is to reduce the WDTR/CLKTR to only those that produce a cycle delay of 
T2 or better.

-Victor Gallardo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ppc4xx: Fix DDR2 auto calibration on Kilauea 600MHz

2008-09-15 Thread Victor Gallardo

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
Signed-off-by: Adam Graham <[EMAIL PROTECTED]>
---
 board/amcc/kilauea/kilauea.c|   31 +++
 cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c |5 -
 include/asm-ppc/ppc4xx-sdram.h  |8 
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/board/amcc/kilauea/kilauea.c b/board/amcc/kilauea/kilauea.c
index 7b10255..8163d16 100644
--- a/board/amcc/kilauea/kilauea.c
+++ b/board/amcc/kilauea/kilauea.c
@@ -374,3 +374,34 @@ int post_hotkeys_pressed(void)
return 0;   /* No hotkeys supported */
 }
 #endif /* CONFIG_POST */
+
+#if defined(CONFIG_PPC4xx_DDR_AUTOCALIBRATION)
+/*
+ * This is for quicker auto calibration boot up once WRDTR and CLKTR
+ * values for the kilauea board were determined and are therefore known.
+ *
+ * Use these scan options for PLB bus greater than 200MHz else use
+ * the defaults.
+ */
+/* List of (SDRAM_WRDTR.[WDTR], SDRAM_CLKTR.[CLKP]) pairs to try */
+struct sdram_timing quick_scan_options[] = {
+   {0, 3}, {1, 1}, {1, 2}, {1, 3},
+   {2, 1}, {2, 2}, {2, 3}, {3, 1},
+   {3, 2}, {4, 1}, {-1, -1}
+};
+
+ulong ddr_scan_option(ulong default_val)
+{
+   u32 sdram_freq;
+   PPC4xx_SYS_INFO board_cfg;
+
+   get_sys_info(&board_cfg);
+   sdram_freq = board_cfg.freqPLB;
+
+   /* PLB bus greater than 200MHz */
+   if (sdram_freq >= 0xbebc200)
+   return (ulong)(quick_scan_options);
+   else
+   return (ulong)default_val;
+}
+#endif /* CONFIG_PPC4xx_DDR_AUTOCALIBRATION */
diff --git a/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c 
b/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
index 83b9883..3ba8176 100644
--- a/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
+++ b/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
@@ -79,11 +79,6 @@ struct ddrautocal {
u32 flags;
 };
 
-struct sdram_timing {
-   u32 wrdtr;
-   u32 clktr;
-};
-
 struct sdram_timing_clks {
u32 wrdtr;
u32 clktr;
diff --git a/include/asm-ppc/ppc4xx-sdram.h b/include/asm-ppc/ppc4xx-sdram.h
index 8efa557..50148c5 100644
--- a/include/asm-ppc/ppc4xx-sdram.h
+++ b/include/asm-ppc/ppc4xx-sdram.h
@@ -1403,6 +1403,14 @@
 #endif /* CONFIG_SDRAM_PPC4xx_DENALI_DDR2 */
 
 #ifndef __ASSEMBLY__
+
+#if defined(CONFIG_PPC4xx_DDR_AUTOCALIBRATION)
+struct sdram_timing {
+   u32 wrdtr;
+   u32 clktr;
+};
+#endif /* CONFIG_PPC4xx_DDR_AUTOCALIBRATION */
+
 /*
  * Prototypes
  */
-- 
1.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] ppc4xx: Allow DTT_I2C_DEV_CODE configured by CFG_I2C_DTT_ADDR

2008-09-10 Thread Victor Gallardo
Hello Stefan,
 
>On Wednesday 10 September 2008, Victor Gallardo wrote:
>> On AMCC Arches board DTT_I2C_DEV_CODE is different then canyonlands and
>> glacier.
>
>This patch is not really ppc4xx related, so please replace the "ppc4xx:" from
>the subject line with "DTT:".
>
>Other than this:
>
>Acked-by: Stefan Roese [EMAIL PROTECTED]

You are correct. I should have used DTT instead. Sorry about that.
 
Wolfgang has accepted in his tree. Do I still need to resubmit to get it in 
your tree?
 
Thanks,
 
Victor Gallardo
 
 
 
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] ppc4xx: Allow DTT_I2C_DEV_CODE configured by CFG_I2C_DTT_ADDR

2008-09-09 Thread Victor Gallardo
On AMCC Arches board DTT_I2C_DEV_CODE is different then canyonlands and glacier.

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
 v2:
 - Add description for CFG_I2C_DTT_ADDR to README

 README   |6 ++
 drivers/hwmon/lm75.c |4 
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/README b/README
index 37449d1..75d9329 100644
--- a/README
+++ b/README
@@ -1392,6 +1392,12 @@ The following options need to be configured:
If defined, then this indicates the I2C bus number for the DTT.
If not defined, then U-Boot assumes that DTT is on I2C bus 0.
 
+   CFG_I2C_DTT_ADDR:
+
+   If defined, specifies the I2C address of the DTT device.
+   If not defined, then U-Boot uses predefined value for
+   specified DTT device.
+
CONFIG_FSL_I2C
 
Define this option if you want to use Freescale's I2C driver in
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 8051cb2..67a18f6 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -38,7 +38,11 @@
 /*
  * Device code
  */
+#if defined(CFG_I2C_DTT_ADDR)
+#define DTT_I2C_DEV_CODE CFG_I2C_DTT_ADDR
+#else
 #define DTT_I2C_DEV_CODE 0x48  /* ON Semi's LM75 device */
+#endif
 #define DTT_READ_TEMP  0x0
 #define DTT_CONFIG 0x1
 #define DTT_TEMP_HYST  0x2
-- 
1.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ppc4xx: Allow DTT_I2C_DEV_CODE configured by CFG_I2C_DTT_ADDR

2008-09-09 Thread Victor Gallardo
On AMCC Arches board DTT_I2C_DEV_CODE is different then canyonlands and glacier.

This patch allows DTT_I2C_DEV_CODE to be configured by CFG_I2C_DTT_ADDR

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
 drivers/hwmon/lm75.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 8051cb2..67a18f6 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -38,7 +38,11 @@
 /*
  * Device code
  */
+#if defined(CFG_I2C_DTT_ADDR)
+#define DTT_I2C_DEV_CODE CFG_I2C_DTT_ADDR
+#else
 #define DTT_I2C_DEV_CODE 0x48  /* ON Semi's LM75 device */
+#endif
 #define DTT_READ_TEMP  0x0
 #define DTT_CONFIG 0x1
 #define DTT_TEMP_HYST  0x2
-- 
1.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


u-boot@lists.denx.de

2008-09-08 Thread Victor Gallardo

Oops, Sorry Stefan my fault for introducing this. 

Thanks for fixing this.

Regards

Victor Gallardo

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Stefan Roese
Sent: Friday, September 05, 2008 5:13 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ppc4xx: Fix compilation warning for
canyonlands &glacier

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 cpu/ppc4xx/miiphy.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/cpu/ppc4xx/miiphy.c b/cpu/ppc4xx/miiphy.c index
d303598..84b1bbe 100644
--- a/cpu/ppc4xx/miiphy.c
+++ b/cpu/ppc4xx/miiphy.c
@@ -236,28 +236,24 @@ unsigned int miiphy_getemac_offset(u8 addr)
#endif
 
 #if defined(CONFIG_460EX) || defined(CONFIG_460GT)
-   u32 mode_reg;
u32 eoffset = 0;
 
switch (addr) {
 #if defined(CONFIG_HAS_ETH1) && defined(CONFIG_GPCS_PHY1_ADDR)
case CONFIG_GPCS_PHY1_ADDR:
-   mode_reg = in_be32((void *)EMAC_M1 + 0x100);
-   if (addr == EMAC_M1_IPPA_GET(mode_reg))
+   if (addr == EMAC_M1_IPPA_GET(in_be32((void *)EMAC_M1 +
0x100)))
eoffset = 0x100;
break;
 #endif
 #if defined(CONFIG_HAS_ETH2) && defined(CONFIG_GPCS_PHY2_ADDR)
case CONFIG_GPCS_PHY2_ADDR:
-   mode_reg = in_be32((void *)EMAC_M1 + 0x300);
-   if (addr == EMAC_M1_IPPA_GET(mode_reg))
+   if (addr == EMAC_M1_IPPA_GET(in_be32((void *)EMAC_M1 +
0x300)))
eoffset = 0x300;
break;
 #endif
 #if defined(CONFIG_HAS_ETH3) && defined(CONFIG_GPCS_PHY3_ADDR)
case CONFIG_GPCS_PHY3_ADDR:
-   mode_reg = in_be32((void *)EMAC_M1 + 0x400);
-   if (addr == EMAC_M1_IPPA_GET(mode_reg))
+   if (addr == EMAC_M1_IPPA_GET(in_be32((void *)EMAC_M1 +
0x400)))
eoffset = 0x400;
break;
 #endif
--
1.5.6.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/1 v4] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-04 Thread Victor Gallardo
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
  v2:
  - Added comments to GPCS PHY setup
  - Minor coding style cleanup

  v3:
  - Generalized the PHY-less configuration even more

  v4:
  - Change "PHY-less" to "Fixed PHY" to standardize

 cpu/ppc4xx/4xx_enet.c |  159 -
 cpu/ppc4xx/miiphy.c   |   41 -
 include/ppc4xx_enet.h |3 +
 3 files changed, 198 insertions(+), 5 deletions(-)

diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..071ac0a 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -198,6 +198,7 @@
 #define BI_PHYMODE_RMII  8
 #endif
 #endif
+#define BI_PHYMODE_SGMII 9
 
 #if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
 defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
@@ -216,6 +217,52 @@
 #define MAL_RX_CHAN_MUL1
 #endif
 
+/*+
+ * Fixed PHY (PHY-less) support for Ethernet Ports.
+ **/
+
+/*
+ * Some boards do not have a PHY for each ethernet port. These ports
+ * are known as Fixed PHY (or PHY-less) ports. For such ports, set
+ * the appropriate CONFIG_PHY_ADDR equal to CONFIG_FIXED_PHY and
+ * then define CFG_FIXED_PHY_PORTS to define what the speed and
+ * duplex should be for these ports in the board configuration
+ * file.
+ *
+ * For Example:
+ * #define CONFIG_FIXED_PHY   0x
+ *
+ * #define CONFIG_PHY_ADDRCONFIG_FIXED_PHY
+ * #define CONFIG_PHY1_ADDR   1
+ * #define CONFIG_PHY2_ADDR   CONFIG_FIXED_PHY
+ * #define CONFIG_PHY3_ADDR   3
+ *
+ * #define CFG_FIXED_PHY_PORT(devnum,speed,duplex) \
+ * {devnum, speed, duplex},
+ *
+ * #define CFG_FIXED_PHY_PORTS \
+ * CFG_FIXED_PHY_PORT(0,1000,FULL) \
+ * CFG_FIXED_PHY_PORT(2,100,HALF)
+ */
+
+#ifndef CONFIG_FIXED_PHY
+#define CONFIG_FIXED_PHY   0x /* Fixed PHY (PHY-less) */
+#endif
+
+#ifndef CFG_FIXED_PHY_PORTS
+#define CFG_FIXED_PHY_PORTS/* default is an empty array */
+#endif
+
+struct fixed_phy_port {
+   unsigned int devnum;/* ethernet port */
+   unsigned int speed; /* specified speed 10,100 or 1000 */
+   unsigned int duplex;/* specified duplex FULL or HALF */
+};
+
+static const struct fixed_phy_port fixed_phy_port[] = {
+   CFG_FIXED_PHY_PORTS /* defined in board configuration file */
+};
+
 
/*-+
  * Global variables. TX and RX descriptors and buffers.
  
*-*/
@@ -611,8 +658,17 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
 
 #if defined(CONFIG_460EX)
mode = 9;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0))
+   mode = 11; /* config SGMII */
 #else
mode = 10;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII2_ENABLE) > 0))
+   mode = 12; /* config SGMII */
 #endif
 
/* TODO:
@@ -635,6 +691,8 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
/*
 * Right now only 2*RGMII is supported. Please extend when needed.
 * sr - 2008-02-19
+* Add SGMII support.
+* vg - 2008-07-28
 */
switch (mode) {
case 1:
@@ -761,6 +819,20 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
bis->bi_phymode[2] = BI_PHYMODE_RGMII;
bis->bi_phymode[3] = BI_PHYMODE_RGMII;
break;
+   case 11:
+   /* 2 SGMII - 460EX */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_NONE;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
+   case 12:
+   /* 3 SGMII - 460GT */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
default:
break;
}
@@ -945,6 +1017,48 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t 
* bis)
out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
 #endif /* defined(CONFIG_440GX) || defined(CONFIG_440SP) */
 
+#if defined(CONFIG_GPCS_PHY_ADDR) || defined(CONFIG_

[U-Boot] [PATCH 1/1] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-04 Thread Victor Gallardo
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
  v2:
  - Added comments to GPCS PHY setup
  - Minor coding style cleanup

  v3:
  - Generalized the PHY-less configuration even more

  v4:
  - Change "PHY-less" to "Fixed PHY" to standardize

 cpu/ppc4xx/4xx_enet.c |  159 -
 cpu/ppc4xx/miiphy.c   |   41 -
 include/ppc4xx_enet.h |3 +
 3 files changed, 198 insertions(+), 5 deletions(-)

diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..071ac0a 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -198,6 +198,7 @@
 #define BI_PHYMODE_RMII  8
 #endif
 #endif
+#define BI_PHYMODE_SGMII 9
 
 #if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
 defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
@@ -216,6 +217,52 @@
 #define MAL_RX_CHAN_MUL1
 #endif
 
+/*+
+ * Fixed PHY (PHY-less) support for Ethernet Ports.
+ **/
+
+/*
+ * Some boards do not have a PHY for each ethernet port. These ports
+ * are known as Fixed PHY (or PHY-less) ports. For such ports, set
+ * the appropriate CONFIG_PHY_ADDR equal to CONFIG_FIXED_PHY and
+ * then define CFG_FIXED_PHY_PORTS to define what the speed and
+ * duplex should be for these ports in the board configuration
+ * file.
+ *
+ * For Example:
+ * #define CONFIG_FIXED_PHY   0x
+ *
+ * #define CONFIG_PHY_ADDRCONFIG_FIXED_PHY
+ * #define CONFIG_PHY1_ADDR   1
+ * #define CONFIG_PHY2_ADDR   CONFIG_FIXED_PHY
+ * #define CONFIG_PHY3_ADDR   3
+ *
+ * #define CFG_FIXED_PHY_PORT(devnum,speed,duplex) \
+ * {devnum, speed, duplex},
+ *
+ * #define CFG_FIXED_PHY_PORTS \
+ * CFG_FIXED_PHY_PORT(0,1000,FULL) \
+ * CFG_FIXED_PHY_PORT(2,100,HALF)
+ */
+
+#ifndef CONFIG_FIXED_PHY
+#define CONFIG_FIXED_PHY   0x /* Fixed PHY (PHY-less) */
+#endif
+
+#ifndef CFG_FIXED_PHY_PORTS
+#define CFG_FIXED_PHY_PORTS/* default is an empty array */
+#endif
+
+struct fixed_phy_port {
+   unsigned int devnum;/* ethernet port */
+   unsigned int speed; /* specified speed 10,100 or 1000 */
+   unsigned int duplex;/* specified duplex FULL or HALF */
+};
+
+static const struct fixed_phy_port fixed_phy_port[] = {
+   CFG_FIXED_PHY_PORTS /* defined in board configuration file */
+};
+
 
/*-+
  * Global variables. TX and RX descriptors and buffers.
  
*-*/
@@ -611,8 +658,17 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
 
 #if defined(CONFIG_460EX)
mode = 9;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0))
+   mode = 11; /* config SGMII */
 #else
mode = 10;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII2_ENABLE) > 0))
+   mode = 12; /* config SGMII */
 #endif
 
/* TODO:
@@ -635,6 +691,8 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
/*
 * Right now only 2*RGMII is supported. Please extend when needed.
 * sr - 2008-02-19
+* Add SGMII support.
+* vg - 2008-07-28
 */
switch (mode) {
case 1:
@@ -761,6 +819,20 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
bis->bi_phymode[2] = BI_PHYMODE_RGMII;
bis->bi_phymode[3] = BI_PHYMODE_RGMII;
break;
+   case 11:
+   /* 2 SGMII - 460EX */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_NONE;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
+   case 12:
+   /* 3 SGMII - 460GT */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
default:
break;
}
@@ -945,6 +1017,48 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t 
* bis)
out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
 #endif /* defined(CONFIG_440GX) || defined(CONFIG_440SP) */
 
+#if defined(CONFIG_GPCS_PHY_ADDR) || defined(CONFIG_

[U-Boot] ppc4xx: glacier broken with latest u-boot

2008-09-04 Thread Victor Gallardo
Hello Stefan,

I just pulled the latest u-boot (git://git.denx.de/u-boot-ppc4xx.git)
and glacier is broken. It builds, but if load the u-boot it hangs. This
is far as it gets.

U-Boot 1.3.4-03965-g7deb3b3 (Sep  4 2008 - 16:26:55)

CPU:   AMCC PowerPC 460GT Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100
MHz)
   Security/Kasumi support
   Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
   Internal PCI arbiter disabled
   32 kB I-Cache 32 kB D-Cache
Board: Glacier - AMCC PPC460GT Evaluation Board, 2*PCIe, Rev. 13
I2C:   ready
DTT:   1 is 35 C
DRAM:  256 MB (ECC not enabled, 400 MHz, CL3)
FLASH: 64 MB
NAND:  32 MiB
PCI:   Bus Dev VenId DevId Class Int
PCIE0: link is not up.
PCIE0: initialization as root-complex failed
PCIE1: link is not up.
PCIE1: initialization as root-complex failed

Regards,

Victor Gallardo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-04 Thread Victor Gallardo
Hi Stefan and Ben,

I saw what Andy Fleming's did. This is a bit to much work for what I
have time for.

I aggree, we need to take baby steps..

For now I'll change PHY-less to Fixed PHY and update some style issues.

-Victor Gallardo

-Original Message-
From: Stefan Roese [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 04, 2008 8:34 AM
To: Ben Warren
Cc: u-boot@lists.denx.de; Victor Gallardo
Subject: Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII
and M88E1112 PHY

On Thursday 04 September 2008, Ben Warren wrote:
> I like the idea very much, but am not sure about the implementation.
> This problem has been around for a while (just search the archives for

> people wondering how to deal with a switch chip connected via rvMII or

> whatever).  The trickiest part of this is how to get the information 
> to the driver.  I've always thought that the best way would be for 
> board code to initialize each controller through proper C code (i.e. 
> not CONFIG macros).  But there's definitely something to be said for 
> doing it all through macros, since that's how Kconfig works.  Please 
> have a look at the code that Andy Fleming recently submitted for the 
> TSEC driver (it's in the main branch now).  He passes a 
> tsec_info_struct into each call of tsec_initialize(), allowing all 
> type of custom information to go in.  In my mind, that could be 
> generalized to something that more than just TSEC, but let's take baby
steps.

Yes, this looks like a good approach. Not sure if we should go all the
way or accept Victors approach for now. Moving to this parameter based
initialization is a different matter that should really be done soon.

> Incidentally, the term "Fixed PHY" has already been coined for what 
> you're calling "PHY-less".  I suggest we standardize.

Yes. Is there already a define available?

> Anyway, I have to go to bed.  Eyes are starting to close and brain's 
> sloowwwiing doowwn.

Heh :)

Best regards,
Stefan

=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-03 Thread Victor Gallardo

>> +
>> +/*
>> + * CFG_PHY_LESS_PORTS tells us about ethernet ports that have no PHY
>> + * attached to them.
>> + */
>> +#ifndef CFG_PHY_LESS_PORTS
>> +#define CFG_PHY_LESS_PORTS
>> +#endif
>> +
>> +struct phy_less_port {
>> +unsigned int devnum;/* ethernet port */
>> +unsigned int speed; /* specified speed 10,100 or 1000 */
>> +unsigned int duplex;/* specified duplex FULL or HALF */
>> +};
>
> Again, if we agree that this is a good "solution", then this should be
moved into a common header, probably net.h.

Maybe a better file for this would be in miiphy.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-03 Thread Victor Gallardo
Hi Stefan,

OK. I agree, I will remove DFLT_PHY_LESS_SPEED and DFLT_PHY_LESS_DUPLEX.

In terms of a generic PHY-less approach. I'll wait for Ben's input.

-Victor Gallardo

-Original Message-
From: Stefan Roese [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 03, 2008 12:23 AM
To: u-boot@lists.denx.de
Cc: Victor Gallardo; Ben Warren
Subject: Re: [U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII
and M88E1112 PHY

On Wednesday 03 September 2008, Victor Gallardo wrote:
> This patch adds GPCS, SGMII and M88E1112 PHY support for the AMCC 
> PPC460GT/EX processors.
>
> Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
> ---

A good idea is to keep a history of what changed in the patch revisions
here in this area (after the "---"). Something like:

v2:
- Added comments to GPCS PHY setup
- Minor coding style cleanup

v3: 
- Generalized the PHY-less configuration even more

Please find some more comments below.

>  cpu/ppc4xx/4xx_enet.c |  162
> - cpu/ppc4xx/miiphy.c
|  
> 41 -
>  include/ppc4xx_enet.h |3 +
>  3 files changed, 201 insertions(+), 5 deletions(-)
>
> diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c index 
> 8a38335..e137bac 100644
> --- a/cpu/ppc4xx/4xx_enet.c
> +++ b/cpu/ppc4xx/4xx_enet.c
> @@ -198,6 +198,7 @@
>  #define BI_PHYMODE_RMII  8
>  #endif
>  #endif
> +#define BI_PHYMODE_SGMII 9
>
>  #if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
>  defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \ @@ -216,6 
> +217,52 @@
>  #define MAL_RX_CHAN_MUL  1
>  #endif
>
> +/*---
> +-+
> + * PHY-less support for Ethernet Ports.
> + 
> +*
> +*/
> +
> +/*
> + * Some boards do not have a PHY for each ethernet port.
> + * For example on Arches board (2 CPU system) eth0 does not have
> + * a PHY, both CPU's are wired directly together (AC coupled)
> + * using SGMII0.
> + *
> + * In these cases :
> + *1) set the appropriate CONFIG_PHY_ADDR equal to CONFIG_PHY_LESS
> + *   to detect that the specified ethernet port does not have a
PHY.
> + *2) Then define CFG_PHY_LESS_PORT and CFG_PHY_LESS_PORTS in
board
> + *   configuration file. For example on the Arches board we would
do
> + *   the following.
> + * #define CFG_PHY_LESS_PORT(devnum,speed,duplex) \
> + * { devnum, speed, duplex},
> + * #define CFG_PHY_LESS_PORTS \
> + * CFG_PHY_LESS_PORT(0,1000,FULL)
> + */
> +#if !defined(CONFIG_PHY_LESS)
> +#define CONFIG_PHY_LESS  0x /* PHY-less mode */
> +#endif

If we agree that this is a good generic approach for this PHY-less
handling, then we should probably move this to a common header so that
other ethernet driver can use this too.

Ben, what do you think?

And the description should be moved to a common place too. Either the
toplevel README, or a new README.xxx in the doc directory.

> +
> +#define DFLT_PHY_LESS_SPEED  100
> +#define DFLT_PHY_LESS_DUPLEX FULL

Do we really need these defaults? Please see my comment further down.

> +
> +/*
> + * CFG_PHY_LESS_PORTS tells us about ethernet ports that have no PHY
> + * attached to them.
> + */
> +#ifndef CFG_PHY_LESS_PORTS
> +#define CFG_PHY_LESS_PORTS
> +#endif
> +
> +struct phy_less_port {
> + unsigned int devnum;/* ethernet port */
> + unsigned int speed; /* specified speed 10,100 or 1000 */
> + unsigned int duplex;/* specified duplex FULL or HALF */
> +};

Again, if we agree that this is a good "solution", then this should be
moved into a common header, probably net.h.



> - speed = miiphy_speed (dev->name, reg);
> - duplex = miiphy_duplex (dev->name, reg);
> +get_speed:
> + if (reg == CONFIG_PHY_LESS) {
> + speed = DFLT_PHY_LESS_SPEED;
> + duplex = DFLT_PHY_LESS_DUPLEX;

I don't think we need this defaults here. Remove them and...

> + for (i = 0; i < ARRAY_SIZE(phy_less_port); i++) {
> + if (devnum == phy_less_port[i].devnum) {
> + speed = phy_less_port[i].speed;
> + duplex = phy_less_port[i].duplex;
> + break;
> + }
> + }

...add this here:

if (i == ARRAY_SIZE(phy_less_port)) {
printf("ERROR: PHY (%s) not configured
correctly!\n",
dev->name);
return -1;
}

If the PHY-less device is not in the list, then this 

[U-Boot] [PATCH 1/1 v3] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-02 Thread Victor Gallardo
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
 cpu/ppc4xx/4xx_enet.c |  162 -
 cpu/ppc4xx/miiphy.c   |   41 -
 include/ppc4xx_enet.h |3 +
 3 files changed, 201 insertions(+), 5 deletions(-)

diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..e137bac 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -198,6 +198,7 @@
 #define BI_PHYMODE_RMII  8
 #endif
 #endif
+#define BI_PHYMODE_SGMII 9
 
 #if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
 defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
@@ -216,6 +217,52 @@
 #define MAL_RX_CHAN_MUL1
 #endif
 
+/*+
+ * PHY-less support for Ethernet Ports.
+ **/
+
+/*
+ * Some boards do not have a PHY for each ethernet port.
+ * For example on Arches board (2 CPU system) eth0 does not have
+ * a PHY, both CPU's are wired directly together (AC coupled)
+ * using SGMII0.
+ *
+ * In these cases :
+ *1) set the appropriate CONFIG_PHY_ADDR equal to CONFIG_PHY_LESS
+ *   to detect that the specified ethernet port does not have a PHY.
+ *2) Then define CFG_PHY_LESS_PORT and CFG_PHY_LESS_PORTS in board
+ *   configuration file. For example on the Arches board we would do
+ *   the following.
+ * #define CFG_PHY_LESS_PORT(devnum,speed,duplex) \
+ * { devnum, speed, duplex},
+ * #define CFG_PHY_LESS_PORTS \
+ * CFG_PHY_LESS_PORT(0,1000,FULL)
+ */
+#if !defined(CONFIG_PHY_LESS)
+#define CONFIG_PHY_LESS0x /* PHY-less mode */
+#endif
+
+#define DFLT_PHY_LESS_SPEED100
+#define DFLT_PHY_LESS_DUPLEX   FULL
+
+/*
+ * CFG_PHY_LESS_PORTS tells us about ethernet ports that have no PHY
+ * attached to them.
+ */
+#ifndef CFG_PHY_LESS_PORTS
+#define CFG_PHY_LESS_PORTS
+#endif
+
+struct phy_less_port {
+   unsigned int devnum;/* ethernet port */
+   unsigned int speed; /* specified speed 10,100 or 1000 */
+   unsigned int duplex;/* specified duplex FULL or HALF */
+};
+
+static const struct phy_less_port phy_less_port[] = {
+   CFG_PHY_LESS_PORTS  /* defined in board configuration file */
+};
+
 
/*-+
  * Global variables. TX and RX descriptors and buffers.
  
*-*/
@@ -611,8 +658,17 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
 
 #if defined(CONFIG_460EX)
mode = 9;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0))
+   mode = 11; /* config SGMII */
 #else
mode = 10;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII2_ENABLE) > 0))
+   mode = 12; /* config SGMII */
 #endif
 
/* TODO:
@@ -635,6 +691,8 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
/*
 * Right now only 2*RGMII is supported. Please extend when needed.
 * sr - 2008-02-19
+* Add SGMII support.
+* vg - 2008-07-28
 */
switch (mode) {
case 1:
@@ -761,6 +819,20 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
bis->bi_phymode[2] = BI_PHYMODE_RGMII;
bis->bi_phymode[3] = BI_PHYMODE_RGMII;
break;
+   case 11:
+   /* 2 SGMII - 460EX */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_NONE;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
+   case 12:
+   /* 3 SGMII - 460GT */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
default:
break;
}
@@ -945,6 +1017,48 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t 
* bis)
out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
 #endif /* defined(CONFIG_440GX) || defined(CONFIG_440SP) */
 
+#if defined(CONFIG_GPCS_PHY_ADDR) || defined(CONFIG_GPCS_PHY1_ADDR) || \
+defined(CONFIG_GPCS_PHY2_ADDR) || defined(CONFIG_GPCS_PHY3_ADDR)
+   if (bis->bi_phymode[devnum] == BI_PHYMODE_SGMII) {
+   /*
+

Re: [U-Boot] [PATCH 1/1] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-09-02 Thread Victor Gallardo
Hi Ben,

OK. You are correct. I will update this area and resubmit.

-Victor Gallardo


-Original Message-
From: Ben Warren [mailto:[EMAIL PROTECTED] 
Sent: Saturday, August 30, 2008 9:34 AM
To: Victor Gallardo
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 1/1] ppc4xx: Add support for GPCS, SGMII
and M88E1112 PHY

On Fri, Aug 29, 2008 at 11:20 PM, Victor Gallardo <[EMAIL PROTECTED]>
wrote:
> This patch adds GPCS, SGMII and M88E1112 PHY support for the AMCC 
> PPC460GT/EX processors.
>
> Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
> ---
>  cpu/ppc4xx/4xx_enet.c |  116
-
>  cpu/ppc4xx/miiphy.c   |   40 -
>  include/ppc4xx_enet.h |4 ++
>  3 files changed, 155 insertions(+), 5 deletions(-)
>
> diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c index 
> 8a38335..4729800 100644
> --- a/cpu/ppc4xx/4xx_enet.c
> +++ b/cpu/ppc4xx/4xx_enet.c
> @@ -198,6 +198,7 @@
>  #define BI_PHYMODE_RMII  8
>  #endif
>  #endif
> +#define BI_PHYMODE_SGMII 9
>
>  #if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
> defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \ @@ -216,6 
> +217,12 @@
>  #define MAL_RX_CHAN_MUL1
>  #endif
>
> +#if !defined(CONFIG_PHY_LESS)
> +#define CONFIG_PHY_LESS0x /* PHY-less mode */
> +#define CONFIG_PHY_LESS_SPEED  1000
> +#define CONFIG_PHY_LESS_DUPLEX FULL
> +#endif
> +
Sorry, but this is not scalable.  There are many real-world examples of
boards where one controller is connected to a PHY, and another has a
FIXED link to a switch or something else.  This driver is already an
unwieldy mess and adding this sort of thing only makes it worse.  If you
want to add fixed-link capabilities, please re-direct your efforts
towards a more generic, scalable solution.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Burning U-boot on 460EX using BDI3000

2008-09-01 Thread Victor Gallardo
 
Hi Felix,

Here is my BDI configuration file for Canyonlands.

This one should work for you. This one configures OCM instead DDR.

-Victor Gallardo


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Felix Radensky
Sent: Monday, September 01, 2008 9:43 AM
To: U-Boot
Subject: [U-Boot] Burning U-boot on 460EX using BDI3000

Hi,

Can U-boot be burned on 460EX based board (using BDI3000) without
configuring DDR controller ? The BDI configuration file for Canyonlands
board on Denx site
http://www.denx.de/wiki/view/DULG/Appendix#Section_13.1.
has no DDR setup, but also doesn't work on Canyonlands (fails on flash
erase). The configuration file from AMCC site does work, but it contains
full DDR setup.

Thanks a lot.

Felix.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


amcc_evb460ex.cfg
Description: amcc_evb460ex.cfg
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/1] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-08-30 Thread Victor Gallardo
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
 cpu/ppc4xx/4xx_enet.c |  122 -
 cpu/ppc4xx/miiphy.c   |   41 +++-
 include/ppc4xx_enet.h |3 +
 3 files changed, 161 insertions(+), 5 deletions(-)

diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..f6cbf2b 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -198,6 +198,7 @@
 #define BI_PHYMODE_RMII  8
 #endif
 #endif
+#define BI_PHYMODE_SGMII 9
 
 #if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
 defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
@@ -216,6 +217,20 @@
 #define MAL_RX_CHAN_MUL1
 #endif
 
+/*
+ * Some boards do not have a PHY for each ethernet port.
+ * For example on Arches board (2 CPU system) eth0 does not have
+ * a PHY, both CPU's are wired directly together (AC coupled)
+ * using SGMII0. In these cases set the appropriate
+ * CONFIG_PHY_ADDR equal to CONFIG_PHY_LESS to detect that
+ * the specified ethernet port does not have a PHY.
+ */
+#if !defined(CONFIG_PHY_LESS)
+#define CONFIG_PHY_LESS0x /* PHY-less mode */
+#define CONFIG_PHY_LESS_SPEED  1000
+#define CONFIG_PHY_LESS_DUPLEX FULL
+#endif
+
 
/*-+
  * Global variables. TX and RX descriptors and buffers.
  
*-*/
@@ -611,8 +626,17 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
 
 #if defined(CONFIG_460EX)
mode = 9;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0))
+   mode = 11; /* config SGMII */
 #else
mode = 10;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII2_ENABLE) > 0))
+   mode = 12; /* config SGMII */
 #endif
 
/* TODO:
@@ -635,6 +659,8 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
/*
 * Right now only 2*RGMII is supported. Please extend when needed.
 * sr - 2008-02-19
+* Add SGMII support.
+* vg - 2008-07-28
 */
switch (mode) {
case 1:
@@ -761,6 +787,20 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
bis->bi_phymode[2] = BI_PHYMODE_RGMII;
bis->bi_phymode[3] = BI_PHYMODE_RGMII;
break;
+   case 11:
+   /* 2 SGMII - 460EX */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_NONE;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
+   case 12:
+   /* 3 SGMII - 460GT */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
default:
break;
}
@@ -945,6 +985,48 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t 
* bis)
out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
 #endif /* defined(CONFIG_440GX) || defined(CONFIG_440SP) */
 
+#if defined(CONFIG_GPCS_PHY_ADDR) || defined(CONFIG_GPCS_PHY1_ADDR) || \
+defined(CONFIG_GPCS_PHY2_ADDR) || defined(CONFIG_GPCS_PHY3_ADDR)
+   if (bis->bi_phymode[devnum] == BI_PHYMODE_SGMII) {
+   /*
+* In SGMII mode, GPCS access is needed for
+* communication with the internal SGMII SerDes.
+*/
+   switch (devnum) {
+#if defined(CONFIG_GPCS_PHY_ADDR)
+   case 0:
+   reg = CONFIG_GPCS_PHY_ADDR;
+   break;
+#endif
+#if defined(CONFIG_GPCS_PHY1_ADDR)
+   case 1:
+   reg = CONFIG_GPCS_PHY1_ADDR;
+   break;
+#endif
+#if defined(CONFIG_GPCS_PHY2_ADDR)
+   case 2:
+   reg = CONFIG_GPCS_PHY2_ADDR;
+   break;
+#endif
+#if defined(CONFIG_GPCS_PHY3_ADDR)
+   case 3:
+   reg = CONFIG_GPCS_PHY3_ADDR;
+   break;
+#endif
+   }
+
+   mode_reg = in_be32((void *)EMAC_M1 + hw_p->hw_addr);
+   mode_reg |= EMAC_M1_MF_1000GPCS | EMAC_M1_IPPA_SET(reg);
+   out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
+
+   /* Configure GPCS interface to recommended setting for SGMII */
+  

[U-Boot] [PATCH 1/1] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

2008-08-29 Thread Victor Gallardo
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
 cpu/ppc4xx/4xx_enet.c |  116 -
 cpu/ppc4xx/miiphy.c   |   40 -
 include/ppc4xx_enet.h |4 ++
 3 files changed, 155 insertions(+), 5 deletions(-)

diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 8a38335..4729800 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -198,6 +198,7 @@
 #define BI_PHYMODE_RMII  8
 #endif
 #endif
+#define BI_PHYMODE_SGMII 9
 
 #if defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
 defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
@@ -216,6 +217,12 @@
 #define MAL_RX_CHAN_MUL1
 #endif
 
+#if !defined(CONFIG_PHY_LESS)
+#define CONFIG_PHY_LESS0x /* PHY-less mode */
+#define CONFIG_PHY_LESS_SPEED  1000
+#define CONFIG_PHY_LESS_DUPLEX FULL
+#endif
+
 
/*-+
  * Global variables. TX and RX descriptors and buffers.
  
*-*/
@@ -611,8 +618,19 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
 
 #if defined(CONFIG_460EX)
mode = 9;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0)) {
+   mode = 11; /* config SGMII */
+}
 #else
mode = 10;
+   mfsdr(SDR0_ETH_CFG, eth_cfg);
+   if (((eth_cfg & SDR0_ETH_CFG_SGMII0_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII1_ENABLE) > 0) &&
+   ((eth_cfg & SDR0_ETH_CFG_SGMII2_ENABLE) > 0)) {
+   mode = 12; /* config SGMII */
+}
 #endif
 
/* TODO:
@@ -635,6 +653,8 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
/*
 * Right now only 2*RGMII is supported. Please extend when needed.
 * sr - 2008-02-19
+* Add SGMII support.
+* vg - 2008-07-28
 */
switch (mode) {
case 1:
@@ -761,6 +781,20 @@ int ppc_4xx_eth_setup_bridge(int devnum, bd_t * bis)
bis->bi_phymode[2] = BI_PHYMODE_RGMII;
bis->bi_phymode[3] = BI_PHYMODE_RGMII;
break;
+   case 11:
+   /* 2 SGMII - 460EX */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_NONE;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
+   case 12:
+   /* 3 SGMII - 460GT */
+   bis->bi_phymode[0] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[1] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[2] = BI_PHYMODE_SGMII;
+   bis->bi_phymode[3] = BI_PHYMODE_NONE;
+   break;
default:
break;
}
@@ -945,6 +979,48 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t 
* bis)
out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
 #endif /* defined(CONFIG_440GX) || defined(CONFIG_440SP) */
 
+#if defined(CONFIG_GPCS_PHY_ADDR) || defined(CONFIG_GPCS_PHY1_ADDR) || \
+defined(CONFIG_GPCS_PHY2_ADDR) || defined(CONFIG_GPCS_PHY3_ADDR)
+   if (bis->bi_phymode[devnum] == BI_PHYMODE_SGMII) {
+   /*
+* In SGMII mode, GPCS access is needed for
+* communication with the internal SGMII SerDes.
+*/
+   switch (devnum) {
+#if defined(CONFIG_GPCS_PHY_ADDR)
+   case 0:
+   reg = CONFIG_GPCS_PHY_ADDR;
+   break;
+#endif
+#if defined(CONFIG_GPCS_PHY1_ADDR)
+   case 1:
+   reg = CONFIG_GPCS_PHY1_ADDR;
+   break;
+#endif
+#if defined(CONFIG_GPCS_PHY2_ADDR)
+   case 2:
+   reg = CONFIG_GPCS_PHY2_ADDR;
+   break;
+#endif
+#if defined(CONFIG_GPCS_PHY3_ADDR)
+   case 3:
+   reg = CONFIG_GPCS_PHY3_ADDR;
+   break;
+#endif
+   }
+
+   mode_reg = in_be32((void *)EMAC_M1 + hw_p->hw_addr);
+   mode_reg |= EMAC_M1_MF_1000GPCS | EMAC_M1_IPPA_SET(reg);
+   out_be32((void *)EMAC_M1 + hw_p->hw_addr, mode_reg);
+
+   /* Configure the GPCS interface */
+   miiphy_reset(dev->name, reg);
+   miiphy_write(dev->name, reg, 0x04, 0x8120);
+   miiphy_write(dev->name, reg, 0x07, 0x2801);
+   miiphy_write(dev->name, reg, 0x00, 0x0140);
+   }
+#endif /* defined(CONFIG_GPCS_PHY_ADDR) */
+
/* wait for PHY to complete auto negotiation */
reg_short = 0;
 #ifndef CONFIG_CS8952_PHY

[U-Boot] [PATCH 1/1] ppc4xx: fix UIC external_interrupt hang on UIC0

2008-08-28 Thread Victor Gallardo
This patch fixes a UIC external_interrupt hang if critical or non-critical
interrupt is set at the same time as a normal interrupt is set on UIC0.

Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
 cpu/ppc4xx/uic.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpu/ppc4xx/uic.c b/cpu/ppc4xx/uic.c
index 7944c6c..a95d1cb 100644
--- a/cpu/ppc4xx/uic.c
+++ b/cpu/ppc4xx/uic.c
@@ -129,11 +129,11 @@ void external_interrupt(struct pt_regs *regs)
uic_interrupt(UIC3_DCR_BASE, 96);
 #endif
 
+   mtdcr(uic0sr, (uic_msr & UICB0_ALL));
+
if (uic_msr & ~(UICB0_ALL))
uic_interrupt(UIC0_DCR_BASE, 0);
 
-   mtdcr(uic0sr, uic_msr);
-
return;
 }
 
-- 
1.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot