date:20130920

chip-ecc.hwctl() is used for preparing the H/W controller before read/write
NAND accesses (like assigning data-buf, enabling ECC scheme configs, etc.)

Though all ECC schemes in OMAP NAND driver use GPMC controller for generating
ECC syndrome (for both Read/Write accesses). But but in current code
HAM1_ECC and BCHx_ECC schemes implement individual function to achieve this.
This patch
(1) removes omap_hwecc_init() and omap_hwecc_init_bch()
as chip-ecc.hwctl will re-initializeGPMC before every read/write call.
omap_hwecc_init_bch() - omap_enable_ecc_bch()

(2) merges the GPMC configuration code for all ECC schemes into
single omap_enable_hwecc(), thus adding scalability for future ECC schemes.
omap_enable_hwecc() + omap_enable_ecc_bch() - omap_enable_hwecc()

Signed-off-by: Pekon Gupta pe...@ti.com
---
 arch/arm/include/asm/omap_gpmc.h |   7 --
 drivers/mtd/nand/omap_gpmc.c | 196 ---
 2 files changed, 58 insertions(+), 145 deletions(-)

diff --git a/arch/arm/include/asm/omap_gpmc.h b/arch/arm/include/asm/omap_gpmc.h
index dd40cb6..9660842 100644
--- a/arch/arm/include/asm/omap_gpmc.h
+++ b/arch/arm/include/asm/omap_gpmc.h
@@ -14,13 +14,6 @@
 #define GPMC_BUF_EMPTY 0
 #define GPMC_BUF_FULL  1
 
-#define ECCCLEAR   (0x1  8)
-#define ECCRESULTREG1  (0x1  0)
-#define ECCSIZE512BYTE 0xFF
-#define ECCSIZE1   (ECCSIZE512BYTE  22)
-#define ECCSIZE0   (ECCSIZE512BYTE  12)
-#define ECCSIZE0SEL(0x000  0)
-
 /* Generic ECC Layouts */
 /* Large Page x8 NAND device Layout */
 #ifdef GPMC_NAND_ECC_LP_x8_LAYOUT
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 6b86c49..cf0da60 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -19,6 +19,8 @@
 
 #define BADBLOCK_MARKER_LENGTH 2
 #define SECTOR_BYTES   512
+#define ECCCLEAR   (0x1  8)
+#define ECCRESULTREG1  (0x1  0)
 
 static uint8_t cs;
 static __maybe_unused struct nand_ecclayout omap_ecclayout;
@@ -60,21 +62,6 @@ int omap_spl_dev_ready(struct mtd_info *mtd)
 }
 #endif
 
-/*
- * omap_hwecc_init - Initialize the Hardware ECC for NAND flash in
- *   GPMC controller
- * @mtd:MTD device structure
- *
- */
-static void __maybe_unused omap_hwecc_init(struct nand_chip *chip)
-{
-   /*
-* Init ECC Control Register
-* Clear all ECC | Enable Reg1
-*/
-   writel(ECCCLEAR | ECCRESULTREG1, gpmc_cfg-ecc_control);
-   writel(ECCSIZE1 | ECCSIZE0 | ECCSIZE0SEL, gpmc_cfg-ecc_size_config);
-}
 
 /*
  * gen_true_ecc - This function will generate true ECC value, which
@@ -192,38 +179,6 @@ static int __maybe_unused omap_calculate_ecc(struct 
mtd_info *mtd,
 }
 
 /*
- * omap_enable_ecc - This function enables the hardware ecc functionality
- * @mtd:MTD device structure
- * @mode:   Read/Write mode
- */
-static void __maybe_unused omap_enable_hwecc(struct mtd_info *mtd, int32_t 
mode)
-{
-   struct nand_chip *chip = mtd-priv;
-   uint32_t val, dev_width = (chip-options  NAND_BUSWIDTH_16)  1;
-
-   switch (mode) {
-   case NAND_ECC_READ:
-   case NAND_ECC_WRITE:
-   /* Clear the ecc result registers, select ecc reg as 1 */
-   writel(ECCCLEAR | ECCRESULTREG1, gpmc_cfg-ecc_control);
-
-   /*
-* Size 0 = 0xFF, Size1 is 0xFF - both are 512 bytes
-* tell all regs to generate size0 sized regs
-* we just have a single ECC engine for all CS
-*/
-   writel(ECCSIZE1 | ECCSIZE0 | ECCSIZE0SEL,
-   gpmc_cfg-ecc_size_config);
-   val = (dev_width  7) | (cs  1) | (0x1);
-   writel(val, gpmc_cfg-ecc_config);
-   break;
-   default:
-   printf(Error: Unrecognized Mode[%d]!\n, mode);
-   break;
-   }
-}
-
-/*
  * Generic BCH interface
  */
 struct nand_bch_priv {
@@ -263,103 +218,69 @@ static __maybe_unused struct nand_bch_priv bch_priv = {
 };
 
 /*
- * omap_hwecc_init_bch - Initialize the BCH Hardware ECC for NAND flash in
- * GPMC controller
+ * omap_enable_hwecc - configures GPMC as per ECC scheme before read/write
  * @mtd:   MTD device structure
  * @mode:  Read/Write mode
  */
 __maybe_unused
-static void omap_hwecc_init_bch(struct nand_chip *chip, int32_t mode)
+static void omap_enable_hwecc(struct mtd_info *mtd, int32_t mode)
 {
-   uint32_t val;
-   uint32_t dev_width = (chip-options  NAND_BUSWIDTH_16)  1;
-   uint32_t unused_length = 0;
-   uint32_t wr_mode = BCH_WRAPMODE_6;
-   struct nand_bch_priv *bch = chip-priv;
-
-   /* Clear the ecc result registers, select ecc reg as 1 */
-   writel(ECCCLEAR | ECCRESULTREG1, gpmc_cfg-ecc_control);
-
-   if (bch-ecc_scheme == OMAP_ECC_BCH8_CODE_HW) {
-   wr_mode = BCH_WRAPMODE_1;
-
-   switch (bch-nibbles) {
-   case ECC_BCH4_NIBBLES:
-

[U-Boot] [PATCH v6 (cosmetic) 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform

BCH8_ECC scheme implemented in omap_gpmc.c driver has following favours
+---+-+-+
|ECC Scheme | ECC Calculation | Error Detection |
+---+-+-+
|OMAP_ECC_BCH8_CODE_HW  |GPMC |ELM H/W engine   |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |GPMC |S/W BCH library  |
+---+-+-+

Current implementation limits the BCH8_CODE_HW only for AM33xx device family.
(using CONFIG_AM33XX). However, other SoC families (like TI81xx) also have
ELM hardware module, and can support ECC error detection using ELM.

This patch
- removes CONFIG_AM33xx
Thus this driver can be reused by all devices having ELM h/w engine.
- removes CONFIG_NAND_OMAP_BCH8 and adds new CONFIG_NAND_OMAP_ECCSCHEME
CONFIG_NAND_OMAP_ECCSCHEME determines ecc-scheme to be used
refer doc/README.nand and board/ti/am335x/README
- adds omap_select_ecc_scheme()
A common function to handle ecc-scheme related configurations. This
can be used both during device-probe and via user-space u-boot commads
to change ecc-scheme. During device probe ecc-scheme is selected based
on CONFIG_NAND_OMAP_ECCSCHEME.
- enables CONFIG_BCH
S/W library (lib/bch.c) required by OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
is enabled by CONFIG_BCH.
- enables CONFIG_SYS_NAND_ONFI_DETECTION
for auto-detection of ONFI compliant NAND devices
- updates following README doc
doc/README.nand
board/ti/am335x/README
doc/README.omap3

Signed-off-by: Pekon Gupta pe...@ti.com
---
 arch/arm/include/asm/arch-am33xx/omap_gpmc.h |  52 ++---
 doc/README.nand  |  30 +++
 doc/README.omap3 |   4 +-
 drivers/mtd/nand/omap_gpmc.c | 292 ---
 include/configs/am335x_evm.h |   9 +-
 include/configs/tricorder.h  |   3 +-
 6 files changed, 223 insertions(+), 167 deletions(-)

diff --git a/arch/arm/include/asm/arch-am33xx/omap_gpmc.h 
b/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
index 00ad1d0..62f608e 100644
--- a/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
+++ b/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
@@ -7,42 +7,20 @@
 #ifndef __ASM_ARCH_OMAP_GPMC_H
 #define __ASM_ARCH_OMAP_GPMC_H
 
-/* These GPMC_NAND_HW_BCHx_ECC_LAYOUT defines are based on AM33xx ELM */
-#define GPMC_NAND_HW_BCH4_ECC_LAYOUT {\
-   .eccbytes = 32,\
-   .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
-   16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,\
-   28, 29, 30, 31, 32, 33},\
-   .oobfree = {\
-   {.offset = 34,\
-.length = 30 } } \
-}
+enum omap_ecc {
+   /* 1-bit  ECC calculation by Software, Error detection by Software */
+   OMAP_ECC_HAM1_CODE_SW = 1, /* avoid un-initialized int can be 0x0 */
+   /* 1-bit  ECC calculation by GPMC, Error detection by Software */
+   /* ECC layout compatible to legacy ROMCODE. */
+   OMAP_ECC_HAM1_CODE_HW,
+   /* 4-bit  ECC calculation by GPMC, Error detection by Software */
+   OMAP_ECC_BCH4_CODE_HW_DETECTION_SW,
+   /* 4-bit  ECC calculation by GPMC, Error detection by ELM */
+   OMAP_ECC_BCH4_CODE_HW,
+   /* 8-bit  ECC calculation by GPMC, Error detection by Software */
+   OMAP_ECC_BCH8_CODE_HW_DETECTION_SW,
+   /* 8-bit  ECC calculation by GPMC, Error detection by ELM */
+   OMAP_ECC_BCH8_CODE_HW,
+};
 
-#define GPMC_NAND_HW_BCH8_ECC_LAYOUT {\
-   .eccbytes = 56,\
-   .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
-   16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,\
-   28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,\
-   40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51,\
-   52, 53, 54, 55, 56, 57},\
-   .oobfree = {\
-   {.offset = 58,\
-.length = 6 } } \
-}
-
-#define GPMC_NAND_HW_BCH16_ECC_LAYOUT {\
-   .eccbytes = 104,\
-   .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
-   16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,\
-   28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,\
-   40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51,\
-   52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,\
-   64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75,\
-   76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87,\
-   88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99,\
-   100, 101, 102, 103, 104, 105},\
-

[U-Boot] [PATCH v6 (cosmetic) 3/5] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes

chip-ecc.calculate() is used for calculating and fetching of ECC syndrome by
processing the data passed during Read/Write accesses.

All H/W based ECC schemes use GPMC controller to calculate ECC syndrome.
But each BCHx_ECC scheme has its own implemetation of post-processing and
fetching ECC syndrome from GPMC controller.

This patch updates OMAP_ECC_BCH8_CODE_HW ECC scheme in following way:
- merges multiple chip-calculate API for different ECC schemes
  omap_calculate_ecc() + omap_calculate_ecc_bch() + omap_calculate_ecc_bch_sw()
== omap_calculate_ecc()
- removes omap_ecc_disable() and instead uses it as inline.

Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/nand/omap_gpmc.c | 220 ---
 1 file changed, 59 insertions(+), 161 deletions(-)

diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index cf0da60..9bfa405 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -21,7 +21,10 @@
 #define SECTOR_BYTES   512
 #define ECCCLEAR   (0x1  8)
 #define ECCRESULTREG1  (0x1  0)
-
+#ifdef CONFIG_BCH
+static u8  bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09, 0xed, 0x93, 0x9a, 0xc2,
+   0x97, 0x79, 0xe5, 0x24, 0xb5};
+#endif
 static uint8_t cs;
 static __maybe_unused struct nand_ecclayout omap_ecclayout;
 
@@ -143,42 +146,6 @@ static int __maybe_unused omap_correct_data(struct 
mtd_info *mtd, uint8_t *dat,
 }
 
 /*
- *  omap_calculate_ecc - Generate non-inverted ECC bytes.
- *
- *  Using noninverted ECC can be considered ugly since writing a blank
- *  page ie. padding will clear the ECC bytes. This is no problem as
- *  long nobody is trying to write data on the seemingly unused page.
- *  Reading an erased page will produce an ECC mismatch between
- *  generated and read ECC bytes that has to be dealt with separately.
- *  E.g. if page is 0xFF (fresh erased), and if HW ECC engine within GPMC
- *  is used, the result of read will be 0x0 while the ECC offsets of the
- *  spare area will be 0xFF which will result in an ECC mismatch.
- *  @mtd:  MTD structure
- *  @dat:  unused
- *  @ecc_code: ecc_code buffer
- */
-static int __maybe_unused omap_calculate_ecc(struct mtd_info *mtd,
-   const uint8_t *dat, uint8_t *ecc_code)
-{
-   u_int32_t val;
-
-   /* Start Reading from HW ECC1_Result = 0x200 */
-   val = readl(gpmc_cfg-ecc1_result);
-
-   ecc_code[0] = val  0xFF;
-   ecc_code[1] = (val  16)  0xFF;
-   ecc_code[2] = ((val  8)  0x0F) | ((val  20)  0xF0);
-
-   /*
-* Stop reading anymore ECC vals and clear old results
-* enable will be called if more reads are required
-*/
-   writel(0x000, gpmc_cfg-ecc_config);
-
-   return 0;
-}
-
-/*
  * Generic BCH interface
  */
 struct nand_bch_priv {
@@ -194,12 +161,7 @@ struct nand_bch_priv {
 #define ECC_BCH8   1
 #define ECC_BCH16  2
 
-/* GPMC ecc engine settings */
-#define BCH_WRAPMODE_1 1   /* BCH wrap mode 1 */
-#define BCH_WRAPMODE_6 6   /* BCH wrap mode 6 */
-
 /* BCH nibbles for diff bch levels */
-#define NAND_ECC_HW_BCH ((uint8_t)(NAND_ECC_HW_OOB_FIRST) + 1)
 #define ECC_BCH4_NIBBLES   13
 #define ECC_BCH8_NIBBLES   26
 #define ECC_BCH16_NIBBLES  52
@@ -211,7 +173,6 @@ struct nand_bch_priv {
  * When some users with other BCH strength will exists this have to change!
  */
 static __maybe_unused struct nand_bch_priv bch_priv = {
-   .mode = NAND_ECC_HW_BCH,
.type = ECC_BCH8,
.nibbles = ECC_BCH8_NIBBLES,
.control = NULL
@@ -284,54 +245,71 @@ static void omap_enable_hwecc(struct mtd_info *mtd, 
int32_t mode)
 }
 
 /*
- * omap_ecc_disable - Disable H/W ECC calculation
- *
- * @mtd:   MTD device structure
- */
-static void __maybe_unused omap_ecc_disable(struct mtd_info *mtd)
-{
-   writel((readl(gpmc_cfg-ecc_config)  ~0x1), gpmc_cfg-ecc_config);
-}
-
-/*
- * BCH support using ELM module
- */
-/*
- * omap_read_bch8_result - Read BCH result for BCH8 level
+ *  omap_calculate_ecc - Read ECC result
+ *  @mtd:  MTD structure
+ *  @dat:  unused
+ *  @ecc_code: ecc_code buffer
  *
- * @mtd:   MTD device structure
- * @big_endian:When set read register 3 first
- * @ecc_code:  Read syndrome from BCH result registers
+ *  Using noninverted ECC can be considered ugly since writing a blank
+ *  page ie. padding will clear the ECC bytes. This is no problem as
+ *  long nobody is trying to write data on the seemingly unused page.
+ *  Reading an erased page will produce an ECC mismatch between
+ *  generated and read ECC bytes that has to be dealt with separately.
+ *  E.g. if page is 0xFF (fresh erased), and if HW ECC engine within GPMC
+ *  is used, the result of read will be 0x0 while the ECC offsets of the
+ *  spare area will be 0xFF which will result in an ECC mismatch.
  */
-static void omap_read_bch8_result(struct

[U-Boot] [PATCH v6 (cosmetic) 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver

*changes in v6*
[PATCH 1/5] incorporated feedbacks from Scott Wood scottw...@freescale.com
- renamed CONFIG_SYS_NAND_ECCSCHEME to CONFIG_NAND_OMAP_ECCSCHEME
- updated omap_select_ecc_scheme() to handle error conditions without
depending on caller.
- renamed OMAP_ECC_HAM1_CODE_HW_ROMCODE to OMAP_ECC_HAM1_CODE_HW 
to keep it naming compatible to linux kernel
- updated doc/README.nand and doc/README.omap3
[PATCH 2/5] minor code clean-up
[PATCH 3/5] minor code clean-up 
[PATCH 4/5] no update
[PATCH 5/5] moved CONFIG_NAND_OMAP_ECCSCHEME description to README.nand


*changes in v5*
This version of patch is tested on am335x-evm with x8 NAND device, and boots
SPL and u-boot from NAND
[PATCH 1/5]
- re-added omap_read_page_bch(): needed proper sequence of while reading
DATA and ECC from NAND page, so that calc_ecc generated from GPMC
is understood by ELM.
- added check to see if NAND OOB can accomodate ECC for entire page
[PATCH 2/5] fixed device-width in GPMC_CONFIG1_X to support x16 devices
[PATCH 3/5] code clean-up for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW mode
[PATCH 4/5]
- fixed omap_correct_data_bch() for correcting bit-flips using ELM
- code-cleanup + added omap_reverse_list()
[PATCH 5/5] incorporated feedbacks from Peter Korsgaard jac...@sunsite.dk


*changes in v4*
[PATCH 1/5]
- removed omap_read_page_bch(): chip-ecc.read_page uses default API
nand_read_page_hwecc() in nand_base.c
- updated tricorder.h: added new CONFIGS for ECCSCHEME  ONFI_DETECTION
- converted printf(ECC-SCHEME) to debug(ECC-SCHEME)
[PATCH 2/5] minor code clean-up
[PATCH 3/5] no update
[PATCH 4/5] no update
[PATCH 5/5] updated README as per feedbacks from tr...@ti.com


*changes in v3*
[PATCH 1/5] (complete change) 
- ecc-scheme is selection is controller by s/w, not CONFIG_NAND_xx
- added omap_select_ecc_scheme(), as common function to handle all
  ecc-scheme related configurations for both board_nand_init() 
  omap_nand_switch_ecc().
- removed un-used defines from asm/arch-am33xx/omap_gpmc.h
- updated doc/REAME.nand
[PATCH 2/5] removed un-used defines from asm/omap_gpmc.h
[PATCH 3/5] removed omap_calculate_ecc_bch_sw() and omap_calculate_ecc()
and merged their logic into omap_calculate_ecc_bch()
[PATCH 4/5] updated return error-code in-case of invalid conditions
[PATCH 5/5] (new) for board/ti/am335x/README


*changes in v2*
- added documentation for CONFIG_NAND_OMAP_xx in doc/README.nand
- added CONFIG_BCH along with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
  to include software library lib/bch.c
- fixed board_nand_init() and omap_enable_hwecc()


*original v1*
This patch series updates BCH8_ECC schemes in mtd/nand/omap_gpmc.c driver
- adds scalability for higher ECC schemes in future.
- removes CONFIG_AM335x and it makes it generic for all platforms.
- optimizes read_data paths

Pekon Gupta (5):
[PATCH 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic 
platform
[PATCH 2/5] mtd: nand: omap: optimize chip-ecc.hwctl() for H/W ECC schemes
[PATCH 3/5] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes
[PATCH 4/5] mtd: nand: omap: optimized chip-ecc.correct() for H/W ECC schemes
[PATCH 5/5] board/ti/am335x/README: update for NAND boot

 arch/arm/include/asm/arch-am33xx/omap_gpmc.h |  52 +-
 arch/arm/include/asm/omap_gpmc.h |   7 -
 board/ti/am335x/README   |  53 +-
 doc/README.nand  |  30 +
 doc/README.omap3 |   4 +-
 drivers/mtd/nand/omap_gpmc.c | 831 +++
 include/configs/am335x_evm.h |   9 +-
 include/configs/tricorder.h  |   3 +-
 8 files changed, 427 insertions(+), 562 deletions(-)

-- 
1.8.1

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

[U-Boot] [PATCH v6 (cosmetic) 4/5] mtd: nand: omap: optimized chip-ecc.correct() for H/W ECC schemes

chip-ecc.correct() is used for detecting and correcting bit-flips during read
operations. In omap-nand driver it implemented as:
(a) omap_correct_data(): for h/w based ECC_HAM1 scheme
(b) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
for ECC_BCH8 scheme using GPMC and software lib/bch.c
(c) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW
for ECC_BCH8 scheme using GPMC and ELM

This patch updates (c)
- checks for calc_ecc[]==0x00 so that error_correction is not required for
  known good pages.
- adds scalability for other ECC_BCHx scheme by merging following
  omap_rotate_ecc_bch() + omap_fix_errors_bch() = omap_correct_data_bch()
- fixing logic for bit-flip correction based on error_loc[count]

Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/nand/omap_gpmc.c | 159 +++
 1 file changed, 69 insertions(+), 90 deletions(-)

diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 9bfa405..68786f9 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -21,6 +21,9 @@
 #define SECTOR_BYTES   512
 #define ECCCLEAR   (0x1  8)
 #define ECCRESULTREG1  (0x1  0)
+/* 4 bit padding to make byte aligned, 56 = 52 + 4 */
+#define BCH4_BIT_PAD   4
+
 #ifdef CONFIG_BCH
 static u8  bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09, 0xed, 0x93, 0x9a, 0xc2,
0x97, 0x79, 0xe5, 0x24, 0xb5};
@@ -179,6 +182,23 @@ static __maybe_unused struct nand_bch_priv bch_priv = {
 };
 
 /*
+ * omap_reverse_list - re-orders list elements in reverse order [internal]
+ * @list:  pointer to start of list
+ * @length:length of list
+*/
+void omap_reverse_list(u8 *list, unsigned int length)
+{
+   unsigned int i, j;
+   unsigned int half_length = length / 2;
+   u8 tmp;
+   for (i = 0, j = length - 1; i  half_length; i++, j--) {
+   tmp = list[i];
+   list[i] = list[j];
+   list[j] = tmp;
+   }
+}
+
+/*
  * omap_enable_hwecc - configures GPMC as per ECC scheme before read/write
  * @mtd:   MTD device structure
  * @mode:  Read/Write mode
@@ -313,77 +333,6 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const 
uint8_t *dat,
 }
 
 /*
- * omap_rotate_ecc_bch - Rotate the syndrome bytes
- *
- * @mtd:   MTD device structure
- * @calc_ecc:  ECC read from ECC registers
- * @syndrome:  Rotated syndrome will be retuned in this array
- *
- */
-static void omap_rotate_ecc_bch(struct mtd_info *mtd, uint8_t *calc_ecc,
-   uint8_t *syndrome)
-{
-   struct nand_chip *chip = mtd-priv;
-   struct nand_bch_priv *bch = chip-priv;
-   uint8_t n_bytes = 0;
-   int8_t i, j;
-
-   switch (bch-type) {
-   case ECC_BCH4:
-   n_bytes = 8;
-   break;
-
-   case ECC_BCH16:
-   n_bytes = 28;
-   break;
-
-   case ECC_BCH8:
-   default:
-   n_bytes = 13;
-   break;
-   }
-
-   for (i = 0, j = (n_bytes-1); i  n_bytes; i++, j--)
-   syndrome[i] =  calc_ecc[j];
-}
-
-/*
- * omap_fix_errors_bch - Correct bch error in the data
- *
- * @mtd:   MTD device structure
- * @data:  Data read from flash
- * @error_count:Number of errors in data
- * @error_loc: Locations of errors in the data
- *
- */
-static void omap_fix_errors_bch(struct mtd_info *mtd, uint8_t *data,
-   uint32_t error_count, uint32_t *error_loc)
-{
-   struct nand_chip *chip = mtd-priv;
-   struct nand_bch_priv *bch = chip-priv;
-   uint8_t count = 0;
-   uint32_t error_byte_pos;
-   uint32_t error_bit_mask;
-   uint32_t last_bit = (bch-nibbles * 4) - 1;
-
-   /* Flip all bits as specified by the error location array. */
-   /* FOR( each found error location flip the bit ) */
-   for (count = 0; count  error_count; count++) {
-   if (error_loc[count]  last_bit) {
-   /* Remove the ECC spare bits from correction. */
-   error_loc[count] -= (last_bit + 1);
-   /* Offset bit in data region */
-   error_byte_pos = ((512 * 8) -
-   (error_loc[count]) - 1) / 8;
-   /* Error Bit mask */
-   error_bit_mask = 0x1  (error_loc[count] % 8);
-   /* Toggle the error bit to make the correction. */
-   data[error_byte_pos] ^= error_bit_mask;
-   }
-   }
-}
-
-/*
  * omap_correct_data_bch - Compares the ecc read from nand spare area
  * with ECC registers values and corrects one bit error if it has occured
  *
@@ -399,40 +348,70 @@ static int omap_correct_data_bch(struct mtd_info *mtd, 
uint8_t *dat,
 {
struct nand_chip *chip = mtd-priv;
struct nand_bch_priv *bch = chip-priv;
-   uint8_t syndrome[28];
-   uint32_t

[U-Boot] [PATCH v6 (cosmetic) 5/5] board/ti/am335x/README: update for NAND boot

NAND boot mode on AM335x EVM has been verified, and steps
to use it has been documented and update in this README

Signed-off-by: Pekon Gupta pe...@ti.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
---
 board/ti/am335x/README | 53 ++
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/board/ti/am335x/README b/board/ti/am335x/README
index 2a30ab8..b35e24e 100644
--- a/board/ti/am335x/README
+++ b/board/ti/am335x/README
@@ -46,23 +46,42 @@ NAND
 The AM335x GP EVM ships with a 256MiB NAND available in most profiles.  In
 this example to program the NAND we assume that an SD card has been
 inserted with the files to write in the first SD slot and that mtdparts
-have been configured correctly for the board.  As a time saving measure we
-load MLO into memory in one location, copy it into the three locatations
-that the ROM checks for additional valid copies, then load U-Boot into
-memory.  We then write that whole section of memory to NAND.
-
-U-Boot # mmc rescan
-U-Boot # env default -f -a
-U-Boot # nand erase.chip
-U-Boot # saveenv
-U-Boot # load mmc 0 8100 MLO
-U-Boot # cp.b 8100 8102 2
-U-Boot # cp.b 8100 8104 2
-U-Boot # cp.b 8100 8106 2
-U-Boot # load mmc 0 8108 u-boot.img
-U-Boot # nand write 8100 0 26
-U-Boot # load mmc 0 ${loadaddr} uImage
-U-Boot # nand write ${loadaddr} kernel 50
+have been configured correctly for the board. All images are first loaded
+into memory, then written to NAND.
+
+Step-1: Building u-boot for NAND boot
+   Set following CONFIGxx options for NAND device.
+   CONFIG_SYS_NAND_PAGE_SIZE   number of main bytes in NAND page
+   CONFIG_SYS_NAND_OOBSIZE number of OOB bytes in NAND page
+   CONFIG_SYS_NAND_BLOCK_SIZE  number of bytes in NAND erase-block
+   CONFIG_SYS_NAND_ECCPOS  ECC map for NAND page
+   CONFIG_NAND_OMAP_ECCSCHEME  (refer doc/README.nand)
+
+Step-2: Flashing NAND via MMC/SD
+   # select BOOTSEL to MMC/SD boot and boot from MMC/SD card
+   U-Boot # mmc rescan
+   # erase flash
+   U-Boot # nand erase.chip
+   U-Boot # env default -f -a
+   U-Boot # saveenv
+   # flash MLO. Redundant copies of MLO are kept for failsafe
+   U-Boot # load mmc 0 0x8200 MLO
+   U-Boot # nand write 0x8200 0x0 0x2
+   U-Boot # nand write 0x8200 0x2 0x2
+   U-Boot # nand write 0x8200 0x4 0x2
+   U-Boot # nand write 0x8200 0x6 0x2
+   # flash u-boot.img
+   U-Boot # load mmc 0 0x8200 u-boot.img
+   U-Boot # nand write 0x8200 0x8 0x6
+   # flash kernel image
+   U-Boot # load mmc 0 0x8200 uImage
+   U-Boot # nand write 0x8200 ${nandsrcaddr} ${nandimgsize}
+   # flash filesystem image
+   U-Boot # load mmc 0 0x8200 filesystem.img
+   U-Boot # nand write 0x8200 {loadaddress} 0x30
+
+Step-3: Set BOOTSEL pin to select NAND boot, and POR the device.
+   The device should boot from images flashed on NAND device.
 
 NOR
 ===
-- 
1.8.1

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

Re: [U-Boot] [PATCH V4 01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT

Dear Troy Kisky,

 i.mx6 has 1 otg controller, and 3 host ports. So,
 CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
 even though only 1 device mode controller is supported.
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 

The problem is, will the 3 additional ports still work? I suspect they will, 
but 
then if you run 'usb reset', the gadget port will also be switched back into 
USB 
Host function, no

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

Re: [U-Boot] [PATCH V4 02/17] usb: ehci-mx6: add support for host mode otg port

Dear Troy Kisky,

 Previously, only host1 was supported using an index of 0.
 Now, otg has index 0, host1 is 1, host2 is 2, host3 is 3.
 Since OTG requires usbmode to be set after reset, I added
 a weak function ehci_hcd_init_after_reset to handle this,
 and removed it from ehci_hcd_init. I also added a weak
 function board_ehci_power to handle turning power on/off
 for otg.
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 
 ---
 V4: new patch, replaces usb: gadget: mv_udc: fix hardware udc address for
 i.MX6 and has the bonus of giving OTG host mode support
 ---

Would it be a problem to implement this in ehci_hcd_init() call instead of 
adding a new call?

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

Re: [U-Boot] [PATCH V4 03/17] usb: gadget: ether set wMaxPacketSize

Dear Troy Kisky,

 set wMaxPacketSize for full speed descriptors
 fs_source_desc, fs_sink_desc to 64.
 
 Full-speed bulk endpoint can have a maximum packet size of
 8, 16, 32, or 64 bytes, so choice 64.
 
 The hs_source_desc, hs_sink_desc, already have their wMaxPacketSize
 set to 512. That is the only legal value for high speed bulk endpoints.
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

Why do we need this patch? What issue does this fix ?

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

Re: [U-Boot] [PATCH V4 04/17] usb: gadget: ether: return error from rx_submit if no request

Dear Troy Kisky,

 This prevents a crash if tftpboot is given a bad filename.
 
 rx_req will be released by eth_reset_config
 which is called by eth_disconnect,
 which is called using the .disconnect member of usb_gadget_driver by
 mv_pullup in mv_udc which is called using the .pullup member of
 usb_gadget_ops by usb_gadget_disconnect which is called by usb_eth_halt
 which is called using the .halt member of eth_device by eth_halt
 which is called by TftpHandler when TFTP_ERR_FILE_NOT_FOUND or
 TFTP_ERR_ACCESS_DENIED occurs
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 

How do I trigger this? It'd be nice to have a test-case in the commit message.

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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file

Dear Troy Kisky,

 Move common definitions to udc.h
 This allows musb_udc.h to be removed as well.
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 
 ---
 v4: updated commit message
 removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
 is the only legal value, it shouldn't be overridden.

[...]

  #endif
 diff --git a/include/usb/udc.h b/include/usb/udc.h
 new file mode 100644
 index 000..3bcbbbc
 --- /dev/null
 +++ b/include/usb/udc.h
 @@ -0,0 +1,61 @@
 +/*
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +#ifndef USB_UDC_H
 +#define USB_UDC_H
 +
 +#ifndef EP0_MAX_PACKET_SIZE
 +#define EP0_MAX_PACKET_SIZE 64
 +#endif
 +
 +#ifndef EP_MAX_PACKET_SIZE
 +#define EP_MAX_PACKET_SIZE   64
 +#endif
 +
 +#ifndef UDC_OUT_PACKET_SIZE
 +#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
 +#endif
 +
 +#ifndef UDC_IN_PACKET_SIZE
 +#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
 +#endif
 +
 +#ifndef UDC_INT_PACKET_SIZE
 +#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
 +#endif
 +
 +#ifndef UDC_BULK_PACKET_SIZE
 +#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
 +#endif

Do you expect these values to change on per-controller basis? Or why do you 
have 
these ifndefs here ?

 +#define UDC_BULK_HS_PACKET_SIZE  512
 +
 +#ifndef UDC_INT_ENDPOINT
 +#define UDC_INT_ENDPOINT 1
 +#endif
 +
 +#ifndef UDC_OUT_ENDPOINT
 +#define UDC_OUT_ENDPOINT 2
 +#endif
 +
 +#ifndef UDC_IN_ENDPOINT
 +#define UDC_IN_ENDPOINT  3
 +#endif

[...]

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

Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce

Dear Troy Kisky,

 Only perform one copy, either in the bounce
 routine for IN transfers, or the debounce
 rtn for OUT transfer.
 
 On out transfers, only copy the number
 of bytes received from the bounce buffer
 
 Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
 
 ---
 v4: no change

Just a question here. Are you sure we never Send AND Reserve the data in one 
turn? Because that would need two copyings.

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

[U-Boot] [PATCH] Tegra114: Fix PLLX M, N, P init settings

From: Jimmy Zhang jimmzh...@nvidia.com

The M, N and P width have been changed from Tegra30. The maximum value
for N is limited to 255. So, the tegra_pll_x_table for Tegra114 should
be set accordingly.

Signed-off-by: Jimmy Zhang jimmzh...@nvidia.com
Reviewed-by: Tom Warren twar...@nvidia.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
 arch/arm/cpu/arm720t/tegra-common/cpu.c | 36 +++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index 9294611..2c50034 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -50,7 +50,13 @@ int get_num_cpus(void)
  */
 struct clk_pll_table tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
/* T20: 1 GHz */
-   /*  n,  m, p, cpcon */
+   /*
+* Field Bits Width
+*  n17:8  10
+*  m 4:0   5
+*  p22:20  3
+*/
+/*  n,  m, p, cpcon */
{{ 1000, 13, 0, 12},/* OSC 13M */
 { 625,  12, 0, 8}, /* OSC 19.2M */
 { 1000, 12, 0, 12},/* OSC 12M */
@@ -58,6 +64,12 @@ struct clk_pll_table 
tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
},
 
/* T25: 1.2 GHz */
+   /*
+* Field Bits Width
+*  n17:8  10
+*  m 4:0   5
+*  p22:20  3
+*/
{{ 923, 10, 0, 12},
 { 750, 12, 0, 8},
 { 600,  6, 0, 12},
@@ -65,17 +77,29 @@ struct clk_pll_table 
tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
},
 
/* T30: 1.4 GHz */
+   /*
+* Field Bits Width
+*  n17:8  10
+*  m 4:0   5
+*  p22:20  3
+*/
{{ 862, 8, 0, 8},
 { 583, 8, 0, 4},
 { 700, 6, 0, 8},
 { 700, 13, 0, 8},
},
 
-   /* T114: 1.4 GHz */
-   {{ 862, 8, 0, 8},
-{ 583, 8, 0, 4},
-{ 696, 12, 0, 8},
-{ 700, 13, 0, 8},
+   /* T114: 1.9 GHz*/
+   /*
+* Field Bits Width
+*  n15:8   8
+*  m 7:0   8
+*  p23:20  4
+*/
+   {{ 108, 1, 1, 8},   /* actual: 702.0 MHz */
+{ 73, 1, 1, 4},/* actual: 700.8 MHz */
+{ 116, 1, 1, 8},   /* actual: 696.0 MHz */
+{ 108, 2, 1, 8},   /* actual: 702.0 MHz */
},
 };
 
-- 
1.8.4

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

Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30

On Wed, Sep 04, 2013 at 11:59:44AM -0600, Stephen Warren wrote:
 On 09/04/2013 07:00 AM, Alban Bedel wrote:
  Add the Tegra30 SKU b1 and treat it like other Tegra30 chips.
 
 CC'ing the Tegra maintainer would be helpful (Tom Warren; I CC'd him here)
 
  diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c
 
  @@ -71,6 +71,7 @@ int tegra_get_chip_sku(void)
  switch (sku_id) {
  case SKU_ID_T33:
  case SKU_ID_T30:
  +   case SKU_ID_T30MQS:
 
 Where does the name T30MQS come from? Tom, can you verify what we call
 the SKUs internally?

It seems like this is indeed called T30MQS internally. Actually it's
called TM30MQS-A3. I can provide an internal reference if required.

Thierry


pgpT49EEACR0x.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V6 0/3] Introduce Samsung's new board Trats2

This patchset add support for a new Samsung board Trats2.
Multi i2c file is updated for third soft I2C adapter for Trats2 board
Battery support is added for Trats2.

This patchset depends on:
http://patchwork.ozlabs.org/patch/245307/

Changes in v6:
- fixed build issue for other board.

Changes in v5:
- updated Maintainer entry
- removed direct access to registers
- in board_mmc_init error is return only if both mmc card init fails

Changes in v4:
- rebased on the latest tree
- modified default boot envs

Changes in v3:
- add Maintainer entry
- changed T-flash detect pin to GPX3[3]
- removed MMC_ASYNC
- use only software i2c

Changes in v2:
- removed lcd callback in panel_info
- changed i2c from hardware to software
- use max77693 multifunction pmic

Piotr Wilczek (3):
  power:battery: add battery support for Trats2 board
  samsung:common:i2c: add definions for third soft I2C adapter for
Trats2 board
  samsung: trats2: add support for new board Trats2

 board/samsung/common/multi_i2c.c   |   12 +
 board/samsung/trats2/Makefile  |   34 +++
 board/samsung/trats2/trats2.c  |  513 
 boards.cfg |1 +
 drivers/power/battery/Makefile |1 +
 drivers/power/battery/bat_trats2.c |   65 +
 include/configs/trats2.h   |  311 ++
 7 files changed, 937 insertions(+)
 create mode 100644 board/samsung/trats2/Makefile
 create mode 100644 board/samsung/trats2/trats2.c
 create mode 100644 drivers/power/battery/bat_trats2.c
 create mode 100644 include/configs/trats2.h

-- 
1.7.9.5

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

[U-Boot] [PATCH V6 1/3] power:battery: add battery support for Trats2 board

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes in v6: none
Changes in v5: none
Changes in v4: none
Changes in v3: none
Changes in v2: none

 drivers/power/battery/Makefile |1 +
 drivers/power/battery/bat_trats2.c |   65 
 2 files changed, 66 insertions(+)
 create mode 100644 drivers/power/battery/bat_trats2.c

diff --git a/drivers/power/battery/Makefile b/drivers/power/battery/Makefile
index 637d1ff..4bf315d 100644
--- a/drivers/power/battery/Makefile
+++ b/drivers/power/battery/Makefile
@@ -10,6 +10,7 @@ include $(TOPDIR)/config.mk
 LIB:= $(obj)libbattery.o
 
 COBJS-$(CONFIG_POWER_BATTERY_TRATS) += bat_trats.o
+COBJS-$(CONFIG_POWER_BATTERY_TRATS2) += bat_trats2.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/power/battery/bat_trats2.c 
b/drivers/power/battery/bat_trats2.c
new file mode 100644
index 000..f264832
--- /dev/null
+++ b/drivers/power/battery/bat_trats2.c
@@ -0,0 +1,65 @@
+/*
+ *  Copyright (C) 2013 Samsung Electronics
+ *  Piotr Wilczek p.wilc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include power/pmic.h
+#include power/battery.h
+#include power/max8997_pmic.h
+#include errno.h
+
+static struct battery battery_trats;
+
+static int power_battery_charge(struct pmic *bat)
+{
+   struct power_battery *p_bat = bat-pbat;
+
+   if (bat-chrg-chrg_state(p_bat-chrg, CHARGER_ENABLE, 450))
+   return -1;
+
+   return 0;
+}
+
+static int power_battery_init_trats2(struct pmic *bat_,
+   struct pmic *fg_,
+   struct pmic *chrg_,
+   struct pmic *muic_)
+{
+   bat_-pbat-fg = fg_;
+   bat_-pbat-chrg = chrg_;
+   bat_-pbat-muic = muic_;
+
+   bat_-fg = fg_-fg;
+   bat_-chrg = chrg_-chrg;
+   bat_-chrg-chrg_type = muic_-chrg-chrg_type;
+   return 0;
+}
+
+static struct power_battery power_bat_trats2 = {
+   .bat = battery_trats,
+   .battery_init = power_battery_init_trats2,
+   .battery_charge = power_battery_charge,
+};
+
+int power_bat_init(unsigned char bus)
+{
+   static const char name[] = BAT_TRATS2;
+   struct pmic *p = pmic_alloc();
+
+   if (!p) {
+   printf(%s: POWER allocation error!\n, __func__);
+   return -ENOMEM;
+   }
+
+   debug(Board BAT init\n);
+
+   p-interface = PMIC_NONE;
+   p-name = name;
+   p-bus = bus;
+
+   p-pbat = power_bat_trats2;
+   return 0;
+}
-- 
1.7.9.5

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

[U-Boot] [PATCH V6 2/3] samsung:common:i2c: add definions for third soft I2C adapter for Trats2 board

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Lukasz Majewski l.majew...@samsung.com
---
Changes in v6: fixed build iss for other board
Changes in v5: updated for new i2c framework
Changes in v4: none
Changes in v3: none
Changes in v2: none

 board/samsung/common/multi_i2c.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/board/samsung/common/multi_i2c.c b/board/samsung/common/multi_i2c.c
index 084858d..71c32c0 100644
--- a/board/samsung/common/multi_i2c.c
+++ b/board/samsung/common/multi_i2c.c
@@ -8,6 +8,14 @@
 #include common.h
 #include i2c.h
 
+#ifndef CONFIG_SOFT_I2C_I2C10_SCL
+#define CONFIG_SOFT_I2C_I2C10_SCL 0
+#endif
+
+#ifndef CONFIG_SOFT_I2C_I2C10_SDA
+#define CONFIG_SOFT_I2C_I2C10_SDA 0
+#endif
+
 /* Handle multiple I2C buses instances */
 int get_multi_scl_pin(void)
 {
@@ -18,6 +26,8 @@ int get_multi_scl_pin(void)
return CONFIG_SOFT_I2C_I2C5_SCL;
case I2C_1:
return CONFIG_SOFT_I2C_I2C9_SCL;
+   case I2C_2:
+   return CONFIG_SOFT_I2C_I2C10_SCL;
default:
printf(I2C_%d not supported!\n, bus);
};
@@ -34,6 +44,8 @@ int get_multi_sda_pin(void)
return CONFIG_SOFT_I2C_I2C5_SDA;
case I2C_1:
return CONFIG_SOFT_I2C_I2C9_SDA;
+   case I2C_2:
+   return CONFIG_SOFT_I2C_I2C10_SDA;
default:
printf(I2C_%d not supported!\n, bus);
};
-- 
1.7.9.5

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

[U-Boot] [PATCH V6 3/3] samsung: trats2: add support for new board Trats2

This patch add support for a new Samsung board Trats2.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
---
Changes in v6:
- none

Changes in v5:
- updated Maintainer entry
- removed direct access to registers
- in board_mmc_init error is return only if both mmc card init fails

Changes in v4:
- rebased on the latest tree
- modified default boot envs

Changes in v3:
- add Maintainer entry
- changed T-flash detect pin to GPX3[3]
- removed MMC_ASYNC
- use only software i2c

Changes in v2:
- removed lcd callback in panel_info
- changed i2c from hardware to software
- use max77693 multifunction pmic

 board/samsung/trats2/Makefile |   34 +++
 board/samsung/trats2/trats2.c |  513 +
 boards.cfg|1 +
 include/configs/trats2.h  |  311 +
 4 files changed, 859 insertions(+)
 create mode 100644 board/samsung/trats2/Makefile
 create mode 100644 board/samsung/trats2/trats2.c
 create mode 100644 include/configs/trats2.h

diff --git a/board/samsung/trats2/Makefile b/board/samsung/trats2/Makefile
new file mode 100644
index 000..4cc3f10
--- /dev/null
+++ b/board/samsung/trats2/Makefile
@@ -0,0 +1,34 @@
+#
+# Copyright (c) 2000 - 2013 Samsung Electronics Co., Ltd. All rights reserved.
+# Sanghee Kim sh0130@samsung.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y:= trats2.o
+
+SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+clean:
+   rm -f $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
new file mode 100644
index 000..d44d825
--- /dev/null
+++ b/board/samsung/trats2/trats2.c
@@ -0,0 +1,513 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd. All rights reserved.
+ * Sanghee Kim sh0130@samsung.com
+ * Piotr Wilczek p.wilc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include lcd.h
+#include asm/io.h
+#include asm/arch/gpio.h
+#include asm/arch/mmc.h
+#include asm/arch/power.h
+#include asm/arch/clk.h
+#include asm/arch/clock.h
+#include asm/arch/mipi_dsim.h
+#include asm/arch/pinmux.h
+#include asm/arch/power.h
+#include power/pmic.h
+#include power/max77686_pmic.h
+#include power/battery.h
+#include power/max77693_pmic.h
+#include power/max77693_muic.h
+#include power/max77693_fg.h
+#include libtizen.h
+#include errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct exynos4x12_gpio_part1 *gpio1;
+static struct exynos4x12_gpio_part2 *gpio2;
+
+static unsigned int board_rev = -1;
+
+static inline u32 get_model_rev(void);
+
+static void check_hw_revision(void)
+{
+   int modelrev = 0;
+   int i;
+
+   gpio2 = (struct exynos4x12_gpio_part2 *)EXYNOS4X12_GPIO_PART2_BASE;
+
+   /*
+* GPM1[1:0]: MODEL_REV[1:0]
+* Don't set as pull-none for these N/C pin.
+* TRM say that it may cause unexcepted state and leakage current.
+* and pull-none is only for output function.
+*/
+   for (i = 0; i  2; i++)
+   s5p_gpio_cfg_pin(gpio2-m1, i, GPIO_INPUT);
+
+   /* GPM1[5:2]: HW_REV[3:0] */
+   for (i = 2; i  6; i++) {
+   s5p_gpio_cfg_pin(gpio2-m1, i, GPIO_INPUT);
+   s5p_gpio_set_pull(gpio2-m1, i, GPIO_PULL_NONE);
+   }
+
+   /* GPM1[1:0]: MODEL_REV[1:0] */
+   for (i = 0; i  2; i++)
+   modelrev |= (s5p_gpio_get_value(gpio2-m1, i)  i);
+
+   /* board_rev[15:8] = model */
+   board_rev = modelrev  8;
+}
+
+#ifdef CONFIG_DISPLAY_BOARDINFO
+int checkboard(void)
+{
+   puts(Board:\tTRATS2\n);
+   return 0;
+}
+#endif
+
+static void show_hw_revision(void)
+{
+   printf(HW Revision:\t0x%04x\n, board_rev);
+}
+
+u32 get_board_rev(void)
+{
+   return board_rev;
+}
+
+static inline u32 get_model_rev(void)
+{
+   return (board_rev  8)  0xff;
+}
+
+static void board_external_gpio_init(void)
+{
+   gpio2 = (struct exynos4x12_gpio_part2 *)EXYNOS4X12_GPIO_PART2_BASE;
+
+   /*
+* some pins which in alive block are connected with external pull-up
+* but it's default setting is pull-down.
+* if that pin set as input then that floated
+*/
+
+   s5p_gpio_set_pull(gpio2-x0, 2, GPIO_PULL_NONE);   /* PS_ALS_INT */
+   s5p_gpio_set_pull(gpio2-x0, 4, GPIO_PULL_NONE);   /* TSP_nINT */
+   s5p_gpio_set_pull(gpio2-x0, 7, GPIO_PULL_NONE);   /* AP_PMIC_IRQ*/
+

[U-Boot] [PATCH 2/2] image: Only relocate ramdisk when necessary

If a ramdisk has been loaded to low memory to begin with, there's no
need to relocate it.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 common/image.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/common/image.c b/common/image.c
index 47336f2..d19c0e6 100644
--- a/common/image.c
+++ b/common/image.c
@@ -968,6 +968,8 @@ int boot_get_ramdisk(int argc, char * const argv[], 
bootm_headers_t *images,
  * boot_ramdisk_high() takes a relocation hint from initrd_high environement
  * variable and if requested ramdisk data is moved to a specified location. If
  * no such hint is given, the default is to relocate the initrd to low memory.
+ * If the ramdisk is already in a proper location, skip relocation and use it
+ * in-place.
  *
  * Initrd_start and initrd_end are set to final (after relocation) ramdisk
  * start/end addresses if ramdisk image start and len were provided,
@@ -1006,6 +1008,16 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, 
ulong rd_len,
initrd_high, initrd_copy_to_ram);
 
if (rd_data) {
+   /*
+* Only copy initrd if necessary. If it has been loaded to
+* low memory, just skip relocation and use it in-place.
+*/
+   ulong bootm_start = getenv_bootm_low();
+   ulong rd_end = rd_data + rd_len;
+
+   if (rd_data = bootm_start  rd_end = initrd_high)
+   initrd_copy_to_ram = 0;
+
if (!initrd_copy_to_ram) {  /* zero-copy ramdisk support */
debug(   in-place initrd\n);
*initrd_start = rd_data;
-- 
1.8.4

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

[U-Boot] [PATCH 1/2] image: Don't relocate ramdisk to highmem

The Linux kernel cannot unpack a ramdisk that's stored in high memory.
Unless the initrd_high environment variable is explicitly set, abide by
that restriction using the getenv_bootm_low() and getenv_bootm_mapsize()
helpers.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v2:
- update function header comment

 common/image.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/common/image.c b/common/image.c
index 2c88091..47336f2 100644
--- a/common/image.c
+++ b/common/image.c
@@ -966,7 +966,8 @@ int boot_get_ramdisk(int argc, char * const argv[], 
bootm_headers_t *images,
  *  end address (after possible relocation)
  *
  * boot_ramdisk_high() takes a relocation hint from initrd_high environement
- * variable and if requested ramdisk data is moved to a specified location.
+ * variable and if requested ramdisk data is moved to a specified location. If
+ * no such hint is given, the default is to relocate the initrd to low memory.
  *
  * Initrd_start and initrd_end are set to final (after relocation) ramdisk
  * start/end addresses if ramdisk image start and len were provided,
@@ -991,8 +992,8 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, ulong 
rd_len,
if (initrd_high == ~0)
initrd_copy_to_ram = 0;
} else {
-   /* not set, no restrictions to load high */
-   initrd_high = ~0;
+   /* make sure to put ramdisk in low memory */
+   initrd_high = getenv_bootm_low() + getenv_bootm_mapsize();
}
 
 
-- 
1.8.4

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

Re: [U-Boot] [PATCH] mx6sabresd: Fix the fdt file for the mx6dl version

Hi Eric,

On 18/09/2013 15:48, Eric Nelson wrote:
 
 This allows the boot script to produce the DTB name as shown
 here:
 
 https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/nitrogen6x/6x_bootscript.txt#L72
 
 
 If/when you move to a single binary for DQ/DL, you won't have
 a separate choice as shown above.
 
 Let me know your thoughts on this.

It would be helpful if we agree on a set of common variables (across
architectures) to be automatically set by u-boot at the startup.

The proposed mechanism is already used in u-boot: see the dieid#
variable for TI's OMAP.

Regards,
Stefano


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

Re: [U-Boot] [PATCH] mx6sabresd: Fix the fdt file for the mx6dl version


 
 At least for the upcoming 2013.10, it would be nice to have my
 original patch of this thread applied for sabresd though.

Agree. I will merge it, and we can then discuss for improvements.

Regards,
Stefano


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

Re: [U-Boot] [PATCH v6 (cosmetic) 5/5] board/ti/am335x/README: update for NAND boot

2013-09-20 Thread Tom Rini

On Fri, Sep 20, 2013 at 03:10:59PM +0530, Pekon Gupta wrote:

 NAND boot mode on AM335x EVM has been verified, and steps
 to use it has been documented and update in this README
 
 Signed-off-by: Pekon Gupta pe...@ti.com
 Acked-by: Peter Korsgaard jac...@sunsite.dk
 ---
  board/ti/am335x/README | 53 
 ++
  1 file changed, 36 insertions(+), 17 deletions(-)
 
 diff --git a/board/ti/am335x/README b/board/ti/am335x/README
 index 2a30ab8..b35e24e 100644
 --- a/board/ti/am335x/README
 +++ b/board/ti/am335x/README
 @@ -46,23 +46,42 @@ NAND
  The AM335x GP EVM ships with a 256MiB NAND available in most profiles.  In
  this example to program the NAND we assume that an SD card has been
  inserted with the files to write in the first SD slot and that mtdparts
 -have been configured correctly for the board.  As a time saving measure we
 -load MLO into memory in one location, copy it into the three locatations
 -that the ROM checks for additional valid copies, then load U-Boot into
 -memory.  We then write that whole section of memory to NAND.
 -
 -U-Boot # mmc rescan
 -U-Boot # env default -f -a
 -U-Boot # nand erase.chip
 -U-Boot # saveenv
 -U-Boot # load mmc 0 8100 MLO
 -U-Boot # cp.b 8100 8102 2
 -U-Boot # cp.b 8100 8104 2
 -U-Boot # cp.b 8100 8106 2
 -U-Boot # load mmc 0 8108 u-boot.img
 -U-Boot # nand write 8100 0 26
 -U-Boot # load mmc 0 ${loadaddr} uImage
 -U-Boot # nand write ${loadaddr} kernel 50
 +have been configured correctly for the board. All images are first loaded
 +into memory, then written to NAND.
 +
 +Step-1: Building u-boot for NAND boot
 + Set following CONFIGxx options for NAND device.
 + CONFIG_SYS_NAND_PAGE_SIZE   number of main bytes in NAND page
 + CONFIG_SYS_NAND_OOBSIZE number of OOB bytes in NAND page
 + CONFIG_SYS_NAND_BLOCK_SIZE  number of bytes in NAND erase-block
 + CONFIG_SYS_NAND_ECCPOS  ECC map for NAND page
 + CONFIG_NAND_OMAP_ECCSCHEME  (refer doc/README.nand)
 +
 +Step-2: Flashing NAND via MMC/SD
 + # select BOOTSEL to MMC/SD boot and boot from MMC/SD card
 + U-Boot # mmc rescan
 + # erase flash
 + U-Boot # nand erase.chip
 + U-Boot # env default -f -a
 + U-Boot # saveenv
 + # flash MLO. Redundant copies of MLO are kept for failsafe
 + U-Boot # load mmc 0 0x8200 MLO
 + U-Boot # nand write 0x8200 0x0 0x2
 + U-Boot # nand write 0x8200 0x2 0x2
 + U-Boot # nand write 0x8200 0x4 0x2
 + U-Boot # nand write 0x8200 0x6 0x2
 + # flash u-boot.img
 + U-Boot # load mmc 0 0x8200 u-boot.img
 + U-Boot # nand write 0x8200 0x8 0x6
 + # flash kernel image
 + U-Boot # load mmc 0 0x8200 uImage
 + U-Boot # nand write 0x8200 ${nandsrcaddr} ${nandimgsize}
 + # flash filesystem image
 + U-Boot # load mmc 0 0x8200 filesystem.img
 + U-Boot # nand write 0x8200 {loadaddress} 0x30

Missing $ on {loadaddress}.  Fine with fixing this up as part of
applying so:

Acked-by: Tom Rini tr...@ti.com

-- 
Tom


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

[U-Boot] [PATCH] pci: Properly configure prefetchable memory region

Forcibly set hose-pci_prefetch to NULL to make sure it will be setup.
This will help if for any reason callers didn't make sure themselves to
NULL the field.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/pci/pci_auto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index c4ed8ba..86ba6b5 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -297,7 +297,7 @@ void pciauto_config_init(struct pci_controller *hose)
 {
int i;
 
-   hose-pci_io = hose-pci_mem = NULL;
+   hose-pci_io = hose-pci_mem = hose-pci_prefetch = NULL;
 
for (i = 0; i  hose-region_count; i++) {
switch(hose-regions[i].flags) {
-- 
1.8.4

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

Re: [U-Boot] [PATCH] ARM: arch-mx6: fix PLL2_PFD2_FREQ

On 11/09/2013 15:30, Markus Niebel wrote:
 From: Markus Niebel markus.nie...@tqs.de
 
 according to the manual frequency of PLL2 PFD2 is 396.000.000
 instead of 400.000.000
 
 Signed-off-by: Markus Niebel markus.nie...@tqs.de
 ---
  arch/arm/include/asm/arch-mx6/crm_regs.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
 b/arch/arm/include/asm/arch-mx6/crm_regs.h
 index 74aefe6..2813593 100644
 --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
 +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
 @@ -892,7 +892,7 @@ struct mxc_ccm_reg {
  
  #define PLL2_PFD0_FREQ   35200
  #define PLL2_PFD1_FREQ   59400
 -#define PLL2_PFD2_FREQ   4
 +#define PLL2_PFD2_FREQ   39600
  #define PLL2_PFD2_DIV_FREQ   2
  #define PLL3_PFD0_FREQ   72000
  #define PLL3_PFD1_FREQ   54000
 

Acked-by: Stefano Babic sba...@denx.de

Best regards,
Stefano Babic

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

[U-Boot] [PATCH 2/4] net: rtl8169: Improve cache maintenance

Instead of directly calling the low-level invalidate_dcache_range() and
flush_cache() functions, provide thin wrappers that take into account
alignment requirements.

While at it, fix a case where the cache was flushed but should have been
invalidated, two cases where the buffer data was flushed instead of the
descriptor and a missing cache invalidation before reading the packet
data that the NIC just wrote to memory.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/net/rtl8169.c | 61 ---
 1 file changed, 53 insertions(+), 8 deletions(-)

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 0e6f2ad..c61e015 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -394,6 +394,50 @@ match:
return 0;
 }
 
+/*
+ * Cache maintenance functions. These are simple wrappers around the more
+ * general purpose flush_cache() and invalidate_dcache_range() functions.
+ */
+
+static void rtl_inval_rx_desc(struct RxDesc *desc)
+{
+   unsigned long start = (unsigned long)desc  ~(ARCH_DMA_MINALIGN - 1);
+   unsigned long end = ALIGN(start + sizeof(*desc), ARCH_DMA_MINALIGN);
+
+   invalidate_dcache_range(start, end);
+}
+
+static void rtl_flush_rx_desc(struct RxDesc *desc)
+{
+   flush_cache((unsigned long)desc, sizeof(*desc));
+}
+
+static void rtl_inval_tx_desc(struct TxDesc *desc)
+{
+   unsigned long start = (unsigned long)desc  ~(ARCH_DMA_MINALIGN - 1);
+   unsigned long end = ALIGN(start + sizeof(*desc), ARCH_DMA_MINALIGN);
+
+   invalidate_dcache_range(start, end);
+}
+
+static void rtl_flush_tx_desc(struct TxDesc *desc)
+{
+   flush_cache((unsigned long)desc, sizeof(*desc));
+}
+
+static void rtl_inval_buffer(void *buf, size_t size)
+{
+   unsigned long start = (unsigned long)buf  ~(ARCH_DMA_MINALIGN - 1);
+   unsigned long end = ALIGN(start + size, ARCH_DMA_MINALIGN);
+
+   invalidate_dcache_range(start, end);
+}
+
+static void rtl_flush_buffer(void *buf, size_t size)
+{
+   flush_cache((unsigned long)buf, size);
+}
+
 /**
 RECV - Receive a frame
 ***/
@@ -411,14 +455,16 @@ static int rtl_recv(struct eth_device *dev)
ioaddr = dev-iobase;
 
cur_rx = tpc-cur_rx;
-   flush_cache((unsigned long)tpc-RxDescArray[cur_rx],
-   sizeof(struct RxDesc));
+
+   rtl_inval_rx_desc(tpc-RxDescArray[cur_rx]);
+
if ((le32_to_cpu(tpc-RxDescArray[cur_rx].status)  OWNbit) == 0) {
if (!(le32_to_cpu(tpc-RxDescArray[cur_rx].status)  RxRES)) {
unsigned char rxdata[RX_BUF_LEN];
length = (int) (le32_to_cpu(tpc-RxDescArray[cur_rx].
status)  0x1FFF) - 4;
 
+   rtl_inval_buffer(tpc-RxBufferRing[cur_rx], length);
memcpy(rxdata, tpc-RxBufferRing[cur_rx], length);
NetReceive(rxdata, length);
 
@@ -430,8 +476,7 @@ static int rtl_recv(struct eth_device *dev)
cpu_to_le32(OWNbit + RX_BUF_SIZE);
tpc-RxDescArray[cur_rx].buf_addr =

cpu_to_le32(bus_to_phys(tpc-RxBufferRing[cur_rx]));
-   flush_cache((unsigned long)tpc-RxBufferRing[cur_rx],
-   RX_BUF_SIZE);
+   rtl_flush_rx_desc(tpc-RxDescArray[cur_rx]);
} else {
puts(Error Rx);
}
@@ -473,7 +518,7 @@ static int rtl_send(struct eth_device *dev, void *packet, 
int length)
/* point to the current txb incase multiple tx_rings are used */
ptxb = tpc-Tx_skbuff[entry * MAX_ETH_FRAME_SIZE];
memcpy(ptxb, (char *)packet, (int)length);
-   flush_cache((unsigned long)ptxb, length);
+   rtl_flush_buffer(ptxb, length);
 
while (len  ETH_ZLEN)
ptxb[len++] = '\0';
@@ -489,13 +534,13 @@ static int rtl_send(struct eth_device *dev, void *packet, 
int length)
cpu_to_le32((OWNbit | EORbit | FSbit | LSbit) |
((len  ETH_ZLEN) ? len : ETH_ZLEN));
}
+   rtl_flush_tx_desc(tpc-TxDescArray[entry]);
RTL_W8(TxPoll, 0x40);   /* set polling bit */
 
tpc-cur_tx++;
to = currticks() + TX_TIMEOUT;
do {
-   flush_cache((unsigned long)tpc-TxDescArray[entry],
-   sizeof(struct TxDesc));
+   rtl_inval_tx_desc(tpc-TxDescArray[entry]);
} while ((le32_to_cpu(tpc-TxDescArray[entry].status)  OWNbit)
 (currticks()  to)); /* wait */
 
@@ -638,7 +683,7 @@ static void rtl8169_init_ring(struct eth_device *dev)
tpc-RxBufferRing[i] = rxb[i * RX_BUF_SIZE];

[U-Boot] [PATCH 1/4] net: rtl8169: Fix format string

currticks() is defined as get_timer(0), which returns an unsigned long,
so use %lu instead of %d to print the result.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/net/rtl8169.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 13fa9c0..0e6f2ad 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -502,7 +502,7 @@ static int rtl_send(struct eth_device *dev, void *packet, 
int length)
if (currticks() = to) {
 #ifdef DEBUG_RTL8169_TX
puts (tx timeout/error\n);
-   printf (%s elapsed time : %d\n, __FUNCTION__, 
currticks()-stime);
+   printf (%s elapsed time : %lu\n, __FUNCTION__, 
currticks()-stime);
 #endif
ret = 0;
} else {
@@ -604,7 +604,7 @@ static void rtl8169_hw_start(struct eth_device *dev)
RTL_W16(MultiIntr, RTL_R16(MultiIntr)  0xF000);
 
 #ifdef DEBUG_RTL8169
-   printf (%s elapsed time : %d\n, __FUNCTION__, currticks()-stime);
+   printf (%s elapsed time : %lu\n, __FUNCTION__, currticks()-stime);
 #endif
 }
 
@@ -642,7 +642,7 @@ static void rtl8169_init_ring(struct eth_device *dev)
}
 
 #ifdef DEBUG_RTL8169
-   printf (%s elapsed time : %d\n, __FUNCTION__, currticks()-stime);
+   printf (%s elapsed time : %lu\n, __FUNCTION__, currticks()-stime);
 #endif
 }
 
@@ -683,7 +683,7 @@ static int rtl_reset(struct eth_device *dev, bd_t *bis)
txb[5] = dev-enetaddr[5];
 
 #ifdef DEBUG_RTL8169
-   printf (%s elapsed time : %d\n, __FUNCTION__, currticks()-stime);
+   printf (%s elapsed time : %lu\n, __FUNCTION__, currticks()-stime);
 #endif
return 0;
 }
-- 
1.8.4

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

[U-Boot] [PATCH 4/4] net: rtl8169: Add support for RTL8168evl/8111evl

This chip is compatible with other RTL8168 chips and can be found on the
NVIDIA Cardhu and Beaver boards.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/net/rtl8169.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index c217e6f..c87ea74 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -247,6 +247,7 @@ static struct {
{RTL-8168b/8111sb,0x30, 0xff7e1880,},
{RTL-8168b/8111sb,0x38, 0xff7e1880,},
{RTL-8168d/8111d, 0x28, 0xff7e1880,},
+   {RTL-8168evl/8111evl, 0x2e, 0xff7e1880,},
{RTL-8101e,   0x34, 0xff7e1880,},
{RTL-8100e,   0x32, 0xff7e1880,},
 };
-- 
1.8.4

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

[U-Boot] [PATCH 3/4] net: rtl8169: Add support for RTL8168d/8111d

This chip is compatible with the existing driver, except that it uses
BAR2 instead of BAR1 for the I/O memory region. Using this patch I can
use the PCIe ethernet interface on the CompuLab Trimslice to boot from
the network.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/net/rtl8169.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index c61e015..c217e6f 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -246,6 +246,7 @@ static struct {
{RTL-8169sc/8110sc,   0x18, 0xff7e1880,},
{RTL-8168b/8111sb,0x30, 0xff7e1880,},
{RTL-8168b/8111sb,0x38, 0xff7e1880,},
+   {RTL-8168d/8111d, 0x28, 0xff7e1880,},
{RTL-8101e,   0x34, 0xff7e1880,},
{RTL-8100e,   0x32, 0xff7e1880,},
 };
@@ -314,6 +315,7 @@ static const unsigned int rtl8169_rx_config =
 
 static struct pci_device_id supported[] = {
{PCI_VENDOR_ID_REALTEK, 0x8167},
+   {PCI_VENDOR_ID_REALTEK, 0x8168},
{PCI_VENDOR_ID_REALTEK, 0x8169},
{}
 };
@@ -914,11 +916,25 @@ int rtl8169_initialize(bd_t *bis)
int idx=0;
 
while(1){
+   unsigned int region;
+   u16 device;
+
/* Find RTL8169 */
if ((devno = pci_find_devices(supported, idx++))  0)
break;
 
-   pci_read_config_dword(devno, PCI_BASE_ADDRESS_1, iobase);
+   pci_read_config_word(devno, PCI_DEVICE_ID, device);
+   switch (device) {
+   case 0x8168:
+   region = 2;
+   break;
+
+   default:
+   region = 1;
+   break;
+   }
+
+   pci_read_config_dword(devno, PCI_BASE_ADDRESS_0 + (region * 4), 
iobase);
iobase = ~0xf;
 
debug (rtl8169: REALTEK RTL8169 @0x%x\n, iobase);
-- 
1.8.4

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

[U-Boot] [PATCH] ARM: mxs: Add PPC-AG BG0900 board

This board supports FEC Ethernet, SPI NOR and NAND flash.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Christoph Baumann c.baum...@ppc-ag.de
---
 board/ppcag/bg0900/Makefile   |  31 ++
 board/ppcag/bg0900/bg0900.c   |  86 ++
 board/ppcag/bg0900/spl_boot.c | 140 ++
 boards.cfg|   1 +
 include/configs/bg0900.h  |  97 +
 5 files changed, 355 insertions(+)
 create mode 100644 board/ppcag/bg0900/Makefile
 create mode 100644 board/ppcag/bg0900/bg0900.c
 create mode 100644 board/ppcag/bg0900/spl_boot.c
 create mode 100644 include/configs/bg0900.h

diff --git a/board/ppcag/bg0900/Makefile b/board/ppcag/bg0900/Makefile
new file mode 100644
index 000..e17c0a5
--- /dev/null
+++ b/board/ppcag/bg0900/Makefile
@@ -0,0 +1,31 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifndef CONFIG_SPL_BUILD
+COBJS  := bg0900.o
+else
+COBJS  := spl_boot.o
+endif
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/ppcag/bg0900/bg0900.c b/board/ppcag/bg0900/bg0900.c
new file mode 100644
index 000..14d84a4
--- /dev/null
+++ b/board/ppcag/bg0900/bg0900.c
@@ -0,0 +1,86 @@
+/*
+ * PPC-AG BG0900 board
+ *
+ * Copyright (C) 2013 Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/imx-regs.h
+#include asm/arch/iomux-mx28.h
+#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
+#include linux/mii.h
+#include miiphy.h
+#include netdev.h
+#include errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Functions
+ */
+int board_early_init_f(void)
+{
+   /* IO0 clock at 480MHz */
+   mxs_set_ioclk(MXC_IOCLK0, 48);
+   /* IO1 clock at 480MHz */
+   mxs_set_ioclk(MXC_IOCLK1, 48);
+
+   /* SSP2 clock at 160MHz */
+   mxs_set_sspclk(MXC_SSPCLK2, 16, 0);
+
+   return 0;
+}
+
+int dram_init(void)
+{
+   return mxs_dram_init();
+}
+
+int board_init(void)
+{
+   /* Adress of boot parameters */
+   gd-bd-bi_boot_params = PHYS_SDRAM_1 + 0x100;
+
+   return 0;
+}
+
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bis)
+{
+   struct mxs_clkctrl_regs *clkctrl_regs =
+   (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
+   struct eth_device *dev;
+   int ret;
+
+   ret = cpu_eth_init(bis);
+
+   /* BG0900 uses ENET_CLK PAD to drive FEC clock */
+   writel(CLKCTRL_ENET_TIME_SEL_RMII_CLK | CLKCTRL_ENET_CLK_OUT_EN,
+   clkctrl_regs-hw_clkctrl_enet);
+
+   /* Reset FEC PHYs */
+   gpio_direction_output(MX28_PAD_ENET0_RX_CLK__GPIO_4_13, 0);
+   udelay(200);
+   gpio_set_value(MX28_PAD_ENET0_RX_CLK__GPIO_4_13, 1);
+
+   ret = fecmxc_initialize_multi(bis, 0, 0, MXS_ENET0_BASE);
+   if (ret) {
+   puts(FEC MXS: Unable to init FEC0\n);
+   return ret;
+   }
+
+   dev = eth_get_dev_by_name(FEC0);
+   if (!dev) {
+   puts(FEC MXS: Unable to get FEC0 device entry\n);
+   return -EINVAL;
+   }
+
+   return ret;
+}
+
+#endif
diff --git a/board/ppcag/bg0900/spl_boot.c b/board/ppcag/bg0900/spl_boot.c
new file mode 100644
index 000..2616e1f
--- /dev/null
+++ b/board/ppcag/bg0900/spl_boot.c
@@ -0,0 +1,140 @@
+/*
+ * PPC-AG BG0900 Boot setup
+ *
+ * Copyright (C) 2013 Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include config.h
+#include asm/io.h
+#include asm/arch/iomux-mx28.h
+#include asm/arch/imx-regs.h
+#include asm/arch/sys_proto.h
+
+#defineMUX_CONFIG_GPMI (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
+#defineMUX_CONFIG_ENET (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI  (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+#defineMUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+
+const iomux_cfg_t iomux_setup[] = {
+   /* DUART */
+   MX28_PAD_PWM0__DUART_RX,
+   MX28_PAD_PWM1__DUART_TX,
+
+   /* GPMI NAND */
+   MX28_PAD_GPMI_D00__GPMI_D0 | MUX_CONFIG_GPMI,
+   MX28_PAD_GPMI_D01__GPMI_D1 | MUX_CONFIG_GPMI,
+   MX28_PAD_GPMI_D02__GPMI_D2 | MUX_CONFIG_GPMI,
+   MX28_PAD_GPMI_D03__GPMI_D3 | MUX_CONFIG_GPMI,
+   MX28_PAD_GPMI_D04__GPMI_D4 | MUX_CONFIG_GPMI,
+   MX28_PAD_GPMI_D05__GPMI_D5 | MUX_CONFIG_GPMI,
+

Re: [U-Boot] [PATCH] mx6sabresd: Fix the fdt file for the mx6dl version


Thanks, Stefano,

On 09/20/2013 06:43 AM, Stefano Babic wrote:

Hi Eric,

On 18/09/2013 15:48, Eric Nelson wrote:


This allows the boot script to produce the DTB name as shown
here:
 
https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/nitrogen6x/6x_bootscript.txt#L72


If/when you move to a single binary for DQ/DL, you won't have
a separate choice as shown above.

Let me know your thoughts on this.


It would be helpful if we agree on a set of common variables (across
architectures) to be automatically set by u-boot at the startup.

The proposed mechanism is already used in u-boot: see the dieid#
variable for TI's OMAP.



This maps to the get_imx_type() routine pretty nicely, though
the hash in the environment variable seems weird.

We'll want a board identifier as well, and see other boards
using CONFIG_SYS_BOARD, which seems very reasonable, but the
Nitrogen6x/SABRE Lite will need some additional logic.

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

Re: [U-Boot] Pull request: u-boot-mmc

2013-09-20 Thread Tom Rini

On Tue, Sep 17, 2013 at 08:11:30PM +0300, Pantelis Antoniou wrote:

 Hi Tom,
 
 The following changes since commit 46ef4faed18196472eb95216b2f74c1397ecf024:
 
   Prepare v2013.10-rc3 (2013-09-16 20:08:33 -0400)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-mmc.git master
 
 for you to fetch changes up to b31c9beb9bdde1714b1131cf0e64b8b68350e824:
 
   mmc: don't support write  erase for SPL builds (2013-09-17 20:03:44 +0300)
 
 
 Jaehoon Chung (1):
   mmc: sdhci: use the SDHCI_QUIRK_USE_WIDE8 for samsung SoC
 
 Lubomir Popov (1):
   ARM: OMAP: Enable 8-bit eMMC access for OMAP4/5/DRA7xx
 
 Oleksandr Tyshchenko (2):
   mmc: Remove unused variable backup from mmc_send_cmd()
   omap_hsmmc: omap4+/am335x: modify MMC controller internal fsm reset func
 
 Paul Burton (5):
   spl: remove unnecessary ( ARM specific) include of asm/utils.h
   spl_mmc: only call printf or puts with CONFIG_SPL_LIBCOMMON_SUPPORT
   mmc: don't call *printf or puts when SPL  !CONFIG_SPL_LIBCOMMON_SUPPORT
   mmc: size optimization when !CONFIG_MMC_SPI
   mmc: don't support write  erase for SPL builds

For the record, this has v2 of mmc: don't support write  erase for SPL
builds and a new PR will be made soon.

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: arch-mx6: fix PLL2_PFD2_FREQ

2013-09-20 Thread Pierre Aubert

Stefano Babic wrote
 On 11/09/2013 15:30, Markus Niebel wrote:
 From: Markus Niebel lt;

 Markus.Niebel@

 gt;
 
 according to the manual frequency of PLL2 PFD2 is 396.000.000
 instead of 400.000.000
 
 Signed-off-by: Markus Niebel lt;

 Markus.Niebel@

 gt;
 ---
  arch/arm/include/asm/arch-mx6/crm_regs.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
 b/arch/arm/include/asm/arch-mx6/crm_regs.h
 index 74aefe6..2813593 100644
 --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
 +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
 @@ -892,7 +892,7 @@ struct mxc_ccm_reg {
  
  #define PLL2_PFD0_FREQ  35200
  #define PLL2_PFD1_FREQ  59400
 -#define PLL2_PFD2_FREQ  4
 +#define PLL2_PFD2_FREQ  39600
  #define PLL2_PFD2_DIV_FREQ  2
  #define PLL3_PFD0_FREQ  72000
  #define PLL3_PFD1_FREQ  54000
 
 
 Acked-by: Stefano Babic lt;

 sbabic@

 gt;

Hello Markus, Hello Stephano
I think it's better to compute  this frequencies rather than hard coding
values. The default PFD frequencies are not the same for the Quad and for
the other Socs.
Furthermore, if you modify PLL2_PFD2_FREQ, you must also change
PLL2_PFD2_DIV_FREQ.

Please, see the patch I've submitted yesterday ([PATCH V2] mx6: compute PLL
PFD frequencies rather than using defines)

Best regards




--
View this message in context: 
http://u-boot.10912.n7.nabble.com/PATCH-ARM-arch-mx6-fix-PLL2-PFD2-FREQ-tp162976p163654.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX6SL pad declarations (was [RFC PATCH 4/3] i.MX6DQ/DLS: remove unused pad declarations)

Thanks Shawn,

I noticed that Otavio's e-mail had a bad reference for the list,
and we've veered off the original topic.

On 09/20/2013 01:44 AM, Shawn Guo wrote:

On Thu, Sep 19, 2013 at 07:08:35AM -0700, Eric Nelson wrote:

There are currently 8 pads defined in U-Boot that aren't defined
in the Linux kernel sources:

SD2_CLK__USDHC2_CLK
SD2_CMD__USDHC2_CMD
SD2_DAT0__USDHC2_DAT0
SD2_DAT1__USDHC2_DAT1
SD2_DAT2__USDHC2_DAT2
SD2_DAT3__USDHC2_DAT3

They are the following ones in kernel.

MX6QDL_PAD_SD2_CLK__SD2_CLK
MX6QDL_PAD_SD2_CMD__SD2_CMD
MX6QDL_PAD_SD2_DAT0__SD2_DATA0
MX6QDL_PAD_SD2_DAT1__SD2_DATA1
MX6QDL_PAD_SD2_DAT2__SD2_DATA2
MX6QDL_PAD_SD2_DAT3__SD2_DATA3

This comment was about SL, not DQ or DLS.

And my comments were wrong.

I used a tool to do a quick comparison and didn't check my work.

The reality is that U-Boot's pad declarations for SL are
almost non-existent:

http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx6/mx6sl_pins.h;h=b39a354f39568b11ea010ae08485ded610b00f1a;hb=HEAD

The 8 declarations that are present all have name mis-matches
with the Linux kernel (USDHC2 vs. SD2, UART1_RXD vs. UART1_RX_DATA).

They are named per IOMUXC registers description in reference manual.

UART1_RXD__UART1_RXD
UART1_TXD__UART1_TXD

Yes, kernel does not define them. That's because the reference manual
does not define them. The macros in kernel are generated from reference
manual data source.

Cool. Thanks for your work on the kernel side. Things there
are in much better shape than in the U-Boot source tree.

Regards,

Eric

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

Re: [U-Boot] [PATCH 05/12 V3] Exynos5420: Modify TZPC init to support 5420

Hi Rajeshwari,

On Fri, Sep 20, 2013 at 3:32 AM, Rajeshwari Birje 
rajeshwari.bi...@gmail.com wrote:

 Hi Simon

 Thank you for coments.

 Regards,
 Rajeshwari Shinde

 On Thu, Sep 19, 2013 at 11:27 AM, Simon Glass s...@chromium.org wrote:

 Hi Rajeshwari,

 On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde 
 rajeshwar...@samsung.com wrote:

  From: Akshay Saraswat aksha...@samsung.com
 
  Currently, part of TZPC init code for Exynos5 starts setting DECPROT
  from the base address 0x1010 upto 0x1019 but in case of
  Exynos5420 we need it to start from 0x0100E and keep end address
  same as 0x1019.
 
  Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
  Signed-off-by: Akshay Saraswat aksha...@samsung.com
  ---
  Changes in V2:
  - None
  Changes in V3:
  - None
   arch/arm/cpu/armv7/exynos/tzpc.c | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)
 
  diff --git a/arch/arm/cpu/armv7/exynos/tzpc.c
  b/arch/arm/cpu/armv7/exynos/tzpc.c
  index 395077c..1102596 100644
  --- a/arch/arm/cpu/armv7/exynos/tzpc.c
  +++ b/arch/arm/cpu/armv7/exynos/tzpc.c
  @@ -23,7 +23,12 @@ void tzpc_init(void)
  else if (cpu_is_exynos4())
  end = start + ((EXYNOS4_NR_TZPC_BANKS - 1) *
  TZPC_BASE_OFFSET);
 
  -   for (addr = start; addr = end; addr += TZPC_BASE_OFFSET) {
  +   if (proid_is_exynos5420())
  +   addr = start - 0x2;
 

 Shouldn't this be in a #define somewhere?

 Instead of having a  #define  we get the start address via
 samsung_get_base_tzpc, since there exception in case of 5420 where we need
 to start from 0x100E we put a if condition.


Does that mean that the address returned by  samsung_get_base_tzpc() should
be different for 5250 and 5420?



  +   else
  +   addr = start;
  +
  +   for (; addr = end; addr += TZPC_BASE_OFFSET) {
  tzpc = (struct exynos_tzpc *)addr;
 
  if (addr == start)
  --
  1.7.12.4
 
 

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

Re: [U-Boot] NAND flash question

2013-09-20 Thread ANDY KENNEDY

 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On 
 Behalf Of Peter Barada
 Sent: Thursday, September 19, 2013 3:26 PM
 To: u-boot@lists.denx.de; Peter Barada
 Subject: Re: [U-Boot] NAND flash question

 On 09/19/2013 04:04 PM, ANDY KENNEDY wrote:
  All,

  We have a design that has NAND as a secondary device (not the boot
  device).  The last four pages of the NAND flash are reported as bad.
  Should this be true for all NAND flash devices we have?

 No, I wouldn't think so.  Manufacturers qualify their parts and mark bad
 blocks found during qualification testing.  Most data sheets indicate
 that the number of bad blocks marked bad during manufacturer is below a
 set percentage(if above thent he part is rejected).  Some parts that are
 meant to be used during boot (such as NAND meant for OMAP parts) will
 have certain blocks that are guaranteed good (i.e. the boot blocks).
 Past that bad blocks could be anywhere in a particular device.

Okay, well, next question:  So on EVERY unit we have designed with a
NAND flash, when u-Boot reads the NAND flash it reports that it couldn't
locate a bad block table and states that it cannot read the last four
pages of the flash.  Next, when one does a 'nand bad' on these boards,
these last four pages are reported by u-Boot as bad.  Looking at the
code, we believe that this is by design.  Is that correct?  Has anyone
else done a 'nand bad' on a board and seen the same information?

Thanks again for any information you can provide,

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

Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Check the result from malloc()

On 12/09/2013 15:35, Fabio Estevam wrote:
 malloc can fail, so we should better check its return value before using it.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] mx28evk: Fix checkpatch warning

On 15/09/2013 00:34, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 Fix the following checkpatch warning:
 
 $ ./tools/checkpatch.pl -F board/freescale/mx28evk/mx28evk.c 
 CHECK: Alignment should match open parenthesis
 #109: FILE: freescale/mx28evk/mx28evk.c:109:
 + writel(CLKCTRL_ENET_TIME_SEL_RMII_CLK | CLKCTRL_ENET_CLK_OUT_EN,
 + clkctrl_regs-hw_clkctrl_enet);
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH v3] doc: README.mxs: Add instruction to install 'libssl-dev'

On 16/09/2013 16:25, Fabio Estevam wrote:
 Since commit bce883707 (ARM: mxs: tools: Add mkimage support for MXS 
 bootstream)
 the following build error is seen when doing a MAKEALL build:
 
 $ ./MAKEALL mx28evk
 Configuring for mx28evk - Board: mx28evk, Options: ENV_IS_IN_MMC
 mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory
 
 Add an entry about the need of installing the 'libssl-dev' package.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] mx6sabresd: Fix the fdt file for the mx6dl version

On 18/09/2013 03:55, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 We need to load 'imx6dl-sabresd.dtb' in the mx6dl version.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH v2 2/2] mx6slevk: Add Ethernet support

On 13/09/2013 05:36, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 mx6slevk has a SMSC8720 connected in RMII mode.
 
 Add support for it.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH v2] net: fec_mxc: Fix timeouts during tftp transfer

On 18/09/2013 04:13, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 Performing tftp transfers on mx28 results in random timeouts.
 
 Hector Palacios and Robert Hodaszi analyzed the root cause being related to 
 the 
 wrong alignment of the 'buff' buffer inside fec_recv().
 
 Benoît Thébaudeau provided an excellent analysis of the alignment bug that is
 present on older versions, such as GCC 4.5.4:
 
 http://marc.info/?l=u-bootm=137942904906131w=2 
 
 Use ALLOC_CACHE_ALIGN_BUFFER() to avoid alignment issues from older GCC 
 versions.
 
 Reported-by: Hector Palacios hector.palac...@digi.com
 Tested-by: Oliver Metz oli...@freetz.org
 Tested-by: Hector Palacios hector.palac...@digi.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] i.MX6DL/S: add drive-strength back to pads DISP0_DAT2/DAT10

On 13/09/2013 18:19, Eric Nelson wrote:
 This patch fixes a regression introduced by commit 87d720e0.
 
 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH 1/2] net: fec_mxc: Add support for mx6 solo-lite

On 13/09/2013 00:41, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 Similarly as mx25 and mx53, mx6solo-lite needs to setup the MII gasket for 
 RMII
 mode.
 
 Add support for mx6solo-lite.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

[U-Boot] Pull request: u-boot-mmc #2

2013-09-20 Thread Pantelis Antoniou

Hi Tom,

The following changes since commit 46ef4faed18196472eb95216b2f74c1397ecf024:

  Prepare v2013.10-rc3 (2013-09-16 20:08:33 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-mmc.git master

for you to fetch changes up to 2c011847c129491084a19c753a039a3441b7dce4:

  Fix wrong sdhci host control register read and write (2013-09-20 19:02:29 
+0300)


Jaehoon Chung (1):
  mmc: sdhci: use the SDHCI_QUIRK_USE_WIDE8 for samsung SoC

Juhyun \(Justin\) Oh (1):
  Fix wrong sdhci host control register read and write

Lubomir Popov (1):
  ARM: OMAP: Enable 8-bit eMMC access for OMAP4/5/DRA7xx

Mischa Jonker (3):
  mmc/dw_mmc: Fix DMA descriptor corruption
  mmc/dw_mmc: Allocate the correct amount of descriptors
  Add parentheses to ALLOC_ALIGN_BUFFER macro's

Oleksandr Tyshchenko (2):
  mmc: Remove unused variable backup from mmc_send_cmd()
  omap_hsmmc: omap4+/am335x: modify MMC controller internal fsm reset func

Paul Burton (5):
  spl: remove unnecessary ( ARM specific) include of asm/utils.h
  spl_mmc: only call printf or puts with CONFIG_SPL_LIBCOMMON_SUPPORT
  mmc: don't call *printf or puts when SPL  !CONFIG_SPL_LIBCOMMON_SUPPORT
  mmc: size optimization when !CONFIG_MMC_SPI
  mmc: don't support write  erase for SPL builds

 common/spl/spl_mmc.c  |  17 +-
 drivers/mmc/Makefile  |   2 ++
 drivers/mmc/dw_mmc.c  |   9 +++---
 drivers/mmc/mmc.c | 205 
+
 drivers/mmc/mmc_private.h |  45 ++
 drivers/mmc/mmc_write.c   | 179 
++
 drivers/mmc/omap_hsmmc.c  |  41 ++--
 drivers/mmc/s5p_sdhci.c   |   4 ++-
 drivers/mmc/sdhci.c   |  18 +--
 include/common.h  |   4 +--
 include/mmc.h |   4 +++
 include/sdhci.h   |   3 ++
 12 files changed, 336 insertions(+), 195 deletions(-)
 create mode 100644 drivers/mmc/mmc_private.h
 create mode 100644 drivers/mmc/mmc_write.c

Regards

-- Pantelis

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

Re: [U-Boot] [PATCH] Tegra114: Fix PLLX M, N, P init settings

2013-09-20 Thread Tom Warren

Including Jimmy, since he wrote this patch originally.

 -Original Message-
 From: Stephen Warren [mailto:swar...@wwwdotorg.org]
 Sent: Friday, September 20, 2013 9:19 AM
 To: Thierry Reding
 Cc: Tom Warren; u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] Tegra114: Fix PLLX M, N, P init settings

 On 09/20/2013 06:40 AM, Thierry Reding wrote:
  From: Jimmy Zhang jimmzh...@nvidia.com

  The M, N and P width have been changed from Tegra30. The maximum
 value
  for N is limited to 255. So, the tegra_pll_x_table for Tegra114 should
  be set accordingly.

  diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
  b/arch/arm/cpu/arm720t/tegra-common/cpu.c

   struct clk_pll_table
 tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
  /* T20: 1 GHz */
  -   /*  n,  m, p, cpcon */
  +   /*
  +* Field Bits Width
  +*  n17:8  10
  +*  m 4:0   5
  +*  p22:20  3

 It'd be nice to document the cpcon field size/position here too.
CPCON is always bits 11:8. Unfortunately, it appears CPCON is gone from 
PLLX_MISC on T114, or at least it's not documented in the TRM. It was there in 
T30.

 Nit: The various comments aren't consistent in their alignment (i.e.
 width left/right justified, some bits values don't line up with others,
 etc.)

  +*/
  +/*  n,  m, p, cpcon */
  {{ 1000, 13, 0, 12},/* OSC 13M */
   { 625,  12, 0, 8}, /* OSC 19.2M */
   { 1000, 12, 0, 12},/* OSC 12M */

 It might be useful to label all the table entries with the OSC frequency that
 they apply to. But, perhaps that could be a different patch.

  -   /* T114: 1.4 GHz */
  -   {{ 862, 8, 0, 8},
  -{ 583, 8, 0, 4},
  -{ 696, 12, 0, 8},
  -{ 700, 13, 0, 8},
  +   /* T114: 1.9 GHz*/

 What does 1.9 GHz mean here? Is that the/a max frequency the chip
 supports? If so, it seems like a single value can't be accurate, since max
 frequency is SKU-specific. As such, I wonder if it's even worth including a
 number here?

 I assume that the new table entries set up the same frequencies as what was
 intended before; it's just that the old values were calculated incorrectly. In
 other words, this patch is a bug-fix, not a change.

  +   /*
  +* Field Bits Width
  +*  n15:8   8
  +*  m 7:0   8
  +*  p23:20  4
  +*/
  +   {{ 108, 1, 1, 8},   /* actual: 702.0 MHz */
  +{ 73, 1, 1, 4},/* actual: 700.8 MHz */
  +{ 116, 1, 1, 8},   /* actual: 696.0 MHz */
  +{ 108, 2, 1, 8},   /* actual: 702.0 MHz */
--
nvpublic

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

Re: [U-Boot] [PATCH v3] powerpc/p1010rdb: update readme for p1010rdb-pb board

2013-09-20 Thread York Sun

On 09/09/2013 02:10 AM, Shengzhou Liu wrote:
 - Remove duplicate doc/README.p1010rdb
 - Update for P1010RDB-PB board
 
 P1010RDB-PB is a variation of previous P1010RDB-PA board.
 Henceforth we support P1010RDB-PB board instead of P1010RDB-PA.
 
 Signed-off-by: Shengzhou Liu shengzhou@freescale.com
 ---
 v3: add frequency combination support
 v2: removed duplicate doc/README.p1010rdb

Shengzhou,

You have this patch and http://patchwork.ozlabs.org/patch/274662/. I
think this is conflict regarding if p1010rdb-pa is supported. Do I miss
another patch or version?

York


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

Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads

2013-09-20 Thread Jeroen Hofstee


Hello Tom,

On 09/19/2013 11:16 PM, Tom Rini wrote:

On Sat, Aug 24, 2013 at 01:55:38PM +0200, Jeroen Hofstee wrote:


The movt/movw instruction can be used to hardcode an
memory location in the instruction itself. The linker
starts complaining about this if the compiler decides
to do so: relocation R_ARM_MOVW_ABS_NC against `a local
symbol' can not be used and it is not support by U-boot
as well. Prevent their use by requiring word relocations.
This allows u-boot to be build at other optimalization
levels then -Os.

Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
Cc: tiger...@viatech.com.cn
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
  arch/arm/config.mk | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

Is this also something we need for llvm?


You guessed that right, for clang actually (llvm has
already been taught to not emit movw/movt pairs,
when requested not to do so). So with the
-mword-relocations || present I can teach clang to tell llvm
not to do it.

I am not aware of any reason why gcc could not
decide to do the same in future releases. A pointer
comparison e.g. is of exactly the same size (afaik).
In this case U-boot will no longer compile without
mentioned flag.


I am hesitant here because as
Wolfgang points out, -O0 is usually the wrong way to debug a problem and
I'll add we're well into the age where debuggers work just fine with
optimized code.


mmm, I don't share your concern here. Not that I
disagree with what Wolfgang said, but since it is
unrelated to the patch itself. What I read was that
Wolfgang tried to explain to a ML poster without a
proper name that it might be even harder at times to
find a bug at -O0, since it is a different binary and
that it is not considered a bug. I assume the fast
majority of U-boot developers know these to debug
things..

If you really have that little trust in U-boot developers
a more proper way would be to actually create a make
rule checking cflags and point them to a nice debugging
document. And I really hope you don't do that ;)

One thing I can think of in favour of -O0 is for educational
purposes. You can run u-boot in qemu then without the,
at times weird optimized jumps, to get an idea about basic
code flow.


If there's some -O2 enabled gcc flag we want because of
a measurable performance win, we should add it specifically to -Os.


First of all the default -Os is unchanged and I have no
intention to change it. -O2 won't build without the patch
last time I checked ;)

Anyway, I like the flag since it helps to not special case
clang and it guarantees builds with gcc at all optimisation
levels, now and in the future. I don't care if it goes in this
release or the next one.

Regards,
Jeroen



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

Re: [U-Boot] [PATCH] wandboard: Use imx6dl-wandboard.dtb for the solo version

On 09/09/2013 23:28, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 The wandboard solo version should boot the 'imx6dl-wandboard.dtb' file, since
 dual-lite and solo variants are the same SoC with only the number of cores 
 being
 different.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30

2013-09-20 Thread Tom Warren

Alban,

Were you going to do a V2 of this patchset? 

Tom

 -Original Message-
 From: Stephen Warren [mailto:swar...@wwwdotorg.org]
 Sent: Friday, September 20, 2013 9:04 AM
 To: Thierry Reding
 Cc: Tom Warren; Alban Bedel; u-boot@lists.denx.de; julian.scheel@avionic-
 design.de
 Subject: Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30

 On 09/20/2013 06:45 AM, Thierry Reding wrote:
  On Wed, Sep 04, 2013 at 11:59:44AM -0600, Stephen Warren wrote:
  On 09/04/2013 07:00 AM, Alban Bedel wrote:
  Add the Tegra30 SKU b1 and treat it like other Tegra30 chips.

  CC'ing the Tegra maintainer would be helpful (Tom Warren; I CC'd him
  here)

  diff --git a/arch/arm/cpu/tegra-common/ap.c
  b/arch/arm/cpu/tegra-common/ap.c

  @@ -71,6 +71,7 @@ int tegra_get_chip_sku(void) switch (sku_id)
  { case SKU_ID_T33: case SKU_ID_T30: + case
 SKU_ID_T30MQS:

  Where does the name T30MQS come from? Tom, can you verify what
 we
  call the SKUs internally?

  It seems like this is indeed called T30MQS internally. Actually it's
  called TM30MQS-A3. I can provide an internal reference if required.

 As long as it's been checked, I don't think we need to document it. In which
 case, IIRC, the patch was fine.
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT


On 9/20/2013 3:45 AM, Marek Vasut wrote:

Dear Troy Kisky,


i.mx6 has 1 otg controller, and 3 host ports. So,
CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
even though only 1 device mode controller is supported.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com


The problem is, will the 3 additional ports still work? I suspect they will, but
then if you run 'usb reset', the gadget port will also be switched back into USB
Host function, no

Best regards,
Marek Vasut

The next patch checks the OTG id before switching to host mode. If it is 
grounded, then it enters
host mode, otherwise it doesn't.  But, running 'usb reset' on a 
netconsole may kill your connection.
I haven't tested that.  Do you have a suggestion to fix that? I've been 
testing with tftp transfers only.


Thanks
Troy

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

Re: [U-Boot] [PATCH V4 02/17] usb: ehci-mx6: add support for host mode otg port


On 9/20/2013 3:51 AM, Marek Vasut wrote:

Dear Troy Kisky,


Previously, only host1 was supported using an index of 0.
Now, otg has index 0, host1 is 1, host2 is 2, host3 is 3.
Since OTG requires usbmode to be set after reset, I added
a weak function ehci_hcd_init_after_reset to handle this,
and removed it from ehci_hcd_init. I also added a weak
function board_ehci_power to handle turning power on/off
for otg.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

---
V4: new patch, replaces usb: gadget: mv_udc: fix hardware udc address for
i.MX6 and has the bonus of giving OTG host mode support
---

Would it be a problem to implement this in ehci_hcd_init() call instead of
adding a new call?

Best regards,
Marek Vasut



Maybe. I could try defining CONFIG_EHCI_HCD_INIT_AFTER_RESET and see if 
anything breaks.
Although, I suspect the processor may hang if the clocks aren't setup 
before ehci_reset.

I'll give it a try and let you know.


Thanks
Troy

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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file


On 9/20/2013 3:55 AM, Marek Vasut wrote:

Dear Troy Kisky,


Move common definitions to udc.h
This allows musb_udc.h to be removed as well.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

---
v4: updated commit message
removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
is the only legal value, it shouldn't be overridden.

[...]


  #endif
diff --git a/include/usb/udc.h b/include/usb/udc.h
new file mode 100644
index 000..3bcbbbc
--- /dev/null
+++ b/include/usb/udc.h
@@ -0,0 +1,61 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef USB_UDC_H
+#define USB_UDC_H
+
+#ifndef EP0_MAX_PACKET_SIZE
+#define EP0_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef EP_MAX_PACKET_SIZE
+#define EP_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef UDC_OUT_PACKET_SIZE
+#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_IN_PACKET_SIZE
+#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_INT_PACKET_SIZE
+#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_BULK_PACKET_SIZE
+#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
+#endif

Do you expect these values to change on per-controller basis? Or why do you have
these ifndefs here ?


I don't know why they change but

include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE 
EP_MIN_PACKET_SIZE/* 8 */

include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16

include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE 
UDC_IN_PACKET_SIZE   /* 8 */

include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16

include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE 
EP_MIN_PACKET_SIZE/* */



+#define UDC_BULK_HS_PACKET_SIZE512
+
+#ifndef UDC_INT_ENDPOINT
+#define UDC_INT_ENDPOINT   1
+#endif
+
+#ifndef UDC_OUT_ENDPOINT
+#define UDC_OUT_ENDPOINT   2
+#endif
+
+#ifndef UDC_IN_ENDPOINT
+#define UDC_IN_ENDPOINT3
+#endif

[...]

Best regards,
Marek Vasut



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

Re: [U-Boot] [PATCH V4 03/17] usb: gadget: ether set wMaxPacketSize


On 9/20/2013 3:52 AM, Marek Vasut wrote:

Dear Troy Kisky,


set wMaxPacketSize for full speed descriptors
fs_source_desc, fs_sink_desc to 64.

Full-speed bulk endpoint can have a maximum packet size of
8, 16, 32, or 64 bytes, so choice 64.

The hs_source_desc, hs_sink_desc, already have their wMaxPacketSize
set to 512. That is the only legal value for high speed bulk endpoints.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

Why do we need this patch? What issue does this fix ?

Best regards,
Marek Vasut

I could try full speed mode without this and see how linux behaves when 
given bad data,
but that would not says anything about other O.S.es. It seems safer just 
not to give out

bad data.

Troy

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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file

Dear Troy Kisky,

 On 9/20/2013 3:55 AM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  Move common definitions to udc.h
  This allows musb_udc.h to be removed as well.
  
  Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
  
  ---
  v4: updated commit message
  removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
  is the only legal value, it shouldn't be overridden.
  
  [...]
  
#endif
  
  diff --git a/include/usb/udc.h b/include/usb/udc.h
  new file mode 100644
  index 000..3bcbbbc
  --- /dev/null
  +++ b/include/usb/udc.h
  @@ -0,0 +1,61 @@
  +/*
  + * SPDX-License-Identifier:   GPL-2.0+
  + */
  +#ifndef USB_UDC_H
  +#define USB_UDC_H
  +
  +#ifndef EP0_MAX_PACKET_SIZE
  +#define EP0_MAX_PACKET_SIZE 64
  +#endif
  +
  +#ifndef EP_MAX_PACKET_SIZE
  +#define EP_MAX_PACKET_SIZE64
  +#endif
  +
  +#ifndef UDC_OUT_PACKET_SIZE
  +#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_IN_PACKET_SIZE
  +#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_INT_PACKET_SIZE
  +#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_BULK_PACKET_SIZE
  +#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
  +#endif
  
  Do you expect these values to change on per-controller basis? Or why do
  you have these ifndefs here ?
 
 I don't know why they change but
 
 include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
 EP_MIN_PACKET_SIZE/* 8 */
 include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16
 
 include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
 UDC_IN_PACKET_SIZE   /* 8 */
 include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16
 
 include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
 EP_MIN_PACKET_SIZE/* */

Are you sure this is not OHCI ?

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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file


On 9/20/2013 11:52 AM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 3:55 AM, Marek Vasut wrote:

Dear Troy Kisky,


Move common definitions to udc.h
This allows musb_udc.h to be removed as well.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

---
v4: updated commit message
removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
is the only legal value, it shouldn't be overridden.

[...]


   #endif

diff --git a/include/usb/udc.h b/include/usb/udc.h
new file mode 100644
index 000..3bcbbbc
--- /dev/null
+++ b/include/usb/udc.h
@@ -0,0 +1,61 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef USB_UDC_H
+#define USB_UDC_H
+
+#ifndef EP0_MAX_PACKET_SIZE
+#define EP0_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef EP_MAX_PACKET_SIZE
+#define EP_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef UDC_OUT_PACKET_SIZE
+#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_IN_PACKET_SIZE
+#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_INT_PACKET_SIZE
+#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_BULK_PACKET_SIZE
+#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
+#endif

Do you expect these values to change on per-controller basis? Or why do
you have these ifndefs here ?

I don't know why they change but

include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
EP_MIN_PACKET_SIZE/* 8 */
include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16

include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
UDC_IN_PACKET_SIZE   /* 8 */
include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16

include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
EP_MIN_PACKET_SIZE/* */

Are you sure this is not OHCI ?

Best regards,
Marek Vasut



I don't know.
I don't understand the relevance of the question. Can you explain the 
issue a little more

for me.

Thanks
Troy

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

Re: [U-Boot] [PATCH] mx35pdk: Remove CONFIG_SYS_CACHELINE_SIZE

On 12/09/2013 21:56, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 In arch/arm/cpu/arm1136/cpu.c we have:
 
 #ifndef CONFIG_SYS_CACHELINE_SIZE
 #define CONFIG_SYS_CACHELINE_SIZE 32
 #endif
 
 ,so there is no need to define 'CONFIG_SYS_CACHELINE_SIZE' with the default
 size in the board config file.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

[U-Boot] [PATCH 3/3] mx35pdk: Fix error handling in board_late_init()

2013-09-20 Thread Fabio Estevam

From: Fabio Estevam fabio.este...@freescale.com

If smc911x_initialize() fails we should return the error immediately.

While at it, also check the error from cpu_eth_init().

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 board/freescale/mx35pdk/mx35pdk.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/board/freescale/mx35pdk/mx35pdk.c 
b/board/freescale/mx35pdk/mx35pdk.c
index 427c83a..9fabef5 100644
--- a/board/freescale/mx35pdk/mx35pdk.c
+++ b/board/freescale/mx35pdk/mx35pdk.c
@@ -251,14 +251,12 @@ int board_late_init(void)
 
 int board_eth_init(bd_t *bis)
 {
-   int rc = -ENODEV;
 #if defined(CONFIG_SMC911X)
-   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+   int rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+   if (rc)
+   return rc;
 #endif
-
-   cpu_eth_init(bis);
-
-   return rc;
+   return cpu_eth_init(bis);
 }
 
 #if defined(CONFIG_FSL_ESDHC)
-- 
1.8.1.2

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

Re: [U-Boot] [PATCH 1/2] mx6sabresd: Return error if cpu_eth_init() fails

On 13/09/2013 03:03, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 Currently board_eth_init() always return 0, but we should propagate the error 
 when cpu_eth_init() fails.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

[U-Boot] [PATCH 1/3] mx28evk: Propagate the error if cpu_eth_init() fails

2013-09-20 Thread Fabio Estevam

From: Fabio Estevam fabio.este...@freescale.com

If cpu_eth_init() fails we should return the error immediately.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 board/freescale/mx28evk/mx28evk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/freescale/mx28evk/mx28evk.c 
b/board/freescale/mx28evk/mx28evk.c
index 3abf1fd..5005fe2 100644
--- a/board/freescale/mx28evk/mx28evk.c
+++ b/board/freescale/mx28evk/mx28evk.c
@@ -103,6 +103,8 @@ int board_eth_init(bd_t *bis)
int ret;
 
ret = cpu_eth_init(bis);
+   if (ret)
+   return ret;
 
/* MX28EVK uses ENET_CLK PAD to drive FEC clock */
writel(CLKCTRL_ENET_TIME_SEL_RMII_CLK | CLKCTRL_ENET_CLK_OUT_EN,
-- 
1.8.1.2

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

Re: [U-Boot] [PATCH] ARM: arch-mx6: fix PLL2_PFD2_FREQ

On 11/09/2013 15:30, Markus Niebel wrote:
 From: Markus Niebel markus.nie...@tqs.de
 
 according to the manual frequency of PLL2 PFD2 is 396.000.000
 instead of 400.000.000
 
 Signed-off-by: Markus Niebel markus.nie...@tqs.de
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file

Dear Troy Kisky,

 On 9/20/2013 11:52 AM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  On 9/20/2013 3:55 AM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  Move common definitions to udc.h
  This allows musb_udc.h to be removed as well.
  
  Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
  
  ---
  v4: updated commit message
  removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
  is the only legal value, it shouldn't be overridden.
  
  [...]
  
 #endif
  
  diff --git a/include/usb/udc.h b/include/usb/udc.h
  new file mode 100644
  index 000..3bcbbbc
  --- /dev/null
  +++ b/include/usb/udc.h
  @@ -0,0 +1,61 @@
  +/*
  + * SPDX-License-Identifier: GPL-2.0+
  + */
  +#ifndef USB_UDC_H
  +#define USB_UDC_H
  +
  +#ifndef EP0_MAX_PACKET_SIZE
  +#define EP0_MAX_PACKET_SIZE 64
  +#endif
  +
  +#ifndef EP_MAX_PACKET_SIZE
  +#define EP_MAX_PACKET_SIZE  64
  +#endif
  +
  +#ifndef UDC_OUT_PACKET_SIZE
  +#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_IN_PACKET_SIZE
  +#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_INT_PACKET_SIZE
  +#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_BULK_PACKET_SIZE
  +#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
  +#endif
  
  Do you expect these values to change on per-controller basis? Or why do
  you have these ifndefs here ?
  
  I don't know why they change but
  
  include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
  EP_MIN_PACKET_SIZE/* 8 */
  include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16
  
  include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
  UDC_IN_PACKET_SIZE   /* 8 */
  include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16
  
  include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
  EP_MIN_PACKET_SIZE/* */
  
  Are you sure this is not OHCI ?
  
  Best regards,
  Marek Vasut
 
 I don't know.
 I don't understand the relevance of the question. Can you explain the
 issue a little more
 for me.

OMAP1510 has only OHCI controller in it, dunno about MPC8xx, but that seems to 
be the case as well. Therefore, in OHCI case, the max packet is 16 and in ehci 
it's 64 . Check the specs ;-)

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

[U-Boot] [PATCH] tools/imximage.c: Fix compiling warning

2013-09-20 Thread York Sun

Convert set_hdr_func(struct imx_header *imxhdr) to set_hdr_func(void)
to get rid of the warning

warning: ‘imxhdr’ is used uninitialized in this function

Signed-off-by: York Sun york...@freescale.com
---
 tools/imximage.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/imximage.c b/tools/imximage.c
index c87669b..32e4efe 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -259,7 +259,7 @@ static void set_imx_hdr_v2(struct imx_header *imxhdr, 
uint32_t dcd_len,
csf_ptr = fhdr_v2-csf;
 }
 
-static void set_hdr_func(struct imx_header *imxhdr)
+static void set_hdr_func(void)
 {
switch (imximage_version) {
case IMXIMAGE_V1:
@@ -358,7 +358,7 @@ static void parse_cfg_cmd(struct imx_header *imxhdr, 
int32_t cmd, char *token,
exit(EXIT_FAILURE);
}
cmd_ver_first = 1;
-   set_hdr_func(imxhdr);
+   set_hdr_func();
break;
case CMD_BOOT_FROM:
imximage_ivt_offset = get_table_entry_id(imximage_boot_offset,
@@ -563,7 +563,7 @@ static void imximage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
/* Be able to detect if the cfg file has no BOOT_FROM tag */
imximage_ivt_offset = FLASH_OFFSET_UNDEFINED;
imximage_csf_size = 0;
-   set_hdr_func(imxhdr);
+   set_hdr_func();
 
/* Parse dcd configuration file */
dcd_len = parse_cfg_file(imxhdr, params-imagename);
@@ -631,7 +631,7 @@ static int imximage_generate(struct mkimage_params *params,
/* Be able to detect if the cfg file has no BOOT_FROM tag */
imximage_ivt_offset = FLASH_OFFSET_UNDEFINED;
imximage_csf_size = 0;
-   set_hdr_func(imxhdr);
+   set_hdr_func();
 
/* Parse dcd configuration file */
parse_cfg_file(imximage_header, params-imagename);
-- 
1.7.9.5


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

[U-Boot] [PATCH] i2c:zynq: I2C multi-bus support on Zynq

2013-09-20 Thread Michael Burr

Changes:
'zynq_i2c.c':
Adapted driver for compliance with new I2C driver model
(CONFIG_SYS_I2C).
Support for 0-length register address in 'i2c_write', 'i2c_read'.
'i2c.h', 'i2c_core.c':
Support for Texas Instruments PCA9548 bus multiplexer.

Tested:
Xilinx ZC702 eval board (single bus master 'I2C0' with multiplexer
PCA9548).
Write and read registers with addresses of length 0 and 1.

Note:
Mainline code does not work out of the box on ZC702 at this time;
ad hoc adaptations based on 'u-boot-xlnx' repository were needed
in order to test on this board. (Those adapatations are not included
with this patch.)

Signed-off-by: Michael Burr michael.b...@logicpd.com
Cc: Heiko Schocher h...@denx.de
Cc: Michal Simek mon...@monstr.eu
---
 drivers/i2c/i2c_core.c |5 ++
 drivers/i2c/zynq_i2c.c |  148 +---
 include/i2c.h  |3 +
 3 files changed, 97 insertions(+), 59 deletions(-)

diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index d1072e8..b263562 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -138,6 +138,11 @@ static int i2c_mux_set(struct i2c_adapter *adap, int 
mux_id, int chip,
return -1;
buf = (uint8_t)((channel  0x07) | (1  3));
break;
+   case I2C_MUX_PCA9548_ID:
+   if (channel  7)
+   return -1;
+   buf = (uint8_t)(0x01  channel);
+   break;
default:
printf(%s: wrong mux id: %d\n, __func__, mux_id);
return -1;
diff --git a/drivers/i2c/zynq_i2c.c b/drivers/i2c/zynq_i2c.c
index ce2d23f..be27966 100644
--- a/drivers/i2c/zynq_i2c.c
+++ b/drivers/i2c/zynq_i2c.c
@@ -7,6 +7,8 @@
  *
  * Copyright (c) 2012-2013 Xilinx, Michal Simek
  *
+ * Copyright (c) 2013 Logic PD, Michael Burr
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
@@ -64,18 +66,28 @@ struct zynq_i2c_registers {
 #define ZYNQ_I2C_FIFO_DEPTH16
 #define ZYNQ_I2C_TRANSFERT_SIZE_MAX255 /* Controller transfer limit */
 
-#if defined(CONFIG_ZYNQ_I2C0)
-# define ZYNQ_I2C_BASE ZYNQ_I2C_BASEADDR0
-#else
-# define ZYNQ_I2C_BASE ZYNQ_I2C_BASEADDR1
-#endif
-
-static struct zynq_i2c_registers *zynq_i2c =
-   (struct zynq_i2c_registers *)ZYNQ_I2C_BASE;
+static struct zynq_i2c_registers *i2c_select(struct i2c_adapter *adap)
+{
+   return adap-hwadapnr ?
+  /* Zynq PS I2C1 */
+  (struct zynq_i2c_registers *)ZYNQ_I2C_BASEADDR1 :
+  /* Zynq PS I2C0 */
+  (struct zynq_i2c_registers *)ZYNQ_I2C_BASEADDR0;
+}
 
 /* I2C init called by cmd_i2c when doing 'i2c reset'. */
-void i2c_init(int requested_speed, int slaveadd)
+static void zynq_i2c_init(struct i2c_adapter *adap, int speed, int slaveaddr)
 {
+   struct zynq_i2c_registers *zynq_i2c = i2c_select(adap);
+
+   if (speed != 10)
+   debug(Warning: requested speed not supported.\n);
+   if (slaveaddr)
+   debug(Warning: slave mode not supported.\n);
+
+   /* The following _assumes_ clock rate cpu_1x = 111 MHz */
+   /* This could use improvement! Also see 'i2c_set_bus_speed' below */
+
/* 111MHz / ( (3 * 17) * 22 ) = ~100KHz */
writel((16  ZYNQ_I2C_CONTROL_DIV_B_SHIFT) |
(2  ZYNQ_I2C_CONTROL_DIV_A_SHIFT), zynq_i2c-control);
@@ -86,7 +98,7 @@ void i2c_init(int requested_speed, int slaveadd)
 }
 
 #ifdef DEBUG
-static void zynq_i2c_debug_status(void)
+static void zynq_i2c_debug_status(struct zynq_i2c_registers *zynq_i2c)
 {
int int_status;
int status;
@@ -128,7 +140,7 @@ static void zynq_i2c_debug_status(void)
 #endif
 
 /* Wait for an interrupt */
-static u32 zynq_i2c_wait(u32 mask)
+static u32 zynq_i2c_wait(struct zynq_i2c_registers *zynq_i2c, u32 mask)
 {
int timeout, int_status;
 
@@ -139,7 +151,7 @@ static u32 zynq_i2c_wait(u32 mask)
break;
}
 #ifdef DEBUG
-   zynq_i2c_debug_status();
+   zynq_i2c_debug_status(zynq_i2c);
 #endif
/* Clear interrupt status flags */
writel(int_status  mask, zynq_i2c-interrupt_status);
@@ -151,17 +163,19 @@ static u32 zynq_i2c_wait(u32 mask)
  * I2C probe called by cmd_i2c when doing 'i2c probe'.
  * Begin read, nak data byte, end.
  */
-int i2c_probe(u8 dev)
+static int zynq_i2c_probe(struct i2c_adapter *adap, uint8_t chip)
 {
+   struct zynq_i2c_registers *zynq_i2c = i2c_select(adap);
+
/* Attempt to read a byte */
setbits_le32(zynq_i2c-control, ZYNQ_I2C_CONTROL_CLR_FIFO |
ZYNQ_I2C_CONTROL_RW);
clrbits_le32(zynq_i2c-control, ZYNQ_I2C_CONTROL_HOLD);
writel(0xFF, zynq_i2c-interrupt_status);
-   writel(dev, zynq_i2c-address);
+   writel(chip, zynq_i2c-address);
writel(1, zynq_i2c-transfer_size);
 
-   return (zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP |
+   return (zynq_i2c_wait(zynq_i2c, ZYNQ_I2C_INTERRUPT_COMP |

[U-Boot] [PATCH 2/3] mx28evk: Propagate the error if cpu_eth_init() fails

2013-09-20 Thread Fabio Estevam

From: Fabio Estevam fabio.este...@freescale.com

If cpu_eth_init() fails we should return the error immediately.

Cc: Marek Vasut ma...@denx.de
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 board/denx/m28evk/m28evk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index f4453d6..33d38cf 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -116,6 +116,8 @@ int board_eth_init(bd_t *bis)
int ret;
 
ret = cpu_eth_init(bis);
+   if (ret)
+   return ret;
 
clrsetbits_le32(clkctrl_regs-hw_clkctrl_enet,
CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
-- 
1.8.1.2

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

Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected

On 11/09/2013 23:14, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 Since commit d9b894603 (mx6sabresd: Add LVDS splash screen support) the
 following hang happens if the HDMI cable is not connected or the 'panel'
 variable is not set:
 
 U-Boot 2013.10-rc2-12978-g47ac53d-dirty (Sep 11 2013 - 15:07:38)  
  
   
  
 CPU:   Freescale i.MX6Q rev1.2 at 792 MHz 
  
 Reset cause: POR  
  
 Board: MX6-SabreSD
  
 DRAM:  1 GiB  
  
 MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
 ...
 
 Provide a check to 'dev-detect' in order to prevent the hang.
 
 Reported-by: Pardeep Kumar Singla b45...@freescale.com
 Suggested-by: Eric Bénard e...@eukrea.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30

2013-09-20 Thread Stephen Warren

On 09/20/2013 06:45 AM, Thierry Reding wrote:
 On Wed, Sep 04, 2013 at 11:59:44AM -0600, Stephen Warren wrote:
 On 09/04/2013 07:00 AM, Alban Bedel wrote:
 Add the Tegra30 SKU b1 and treat it like other Tegra30 chips.
 
 CC'ing the Tegra maintainer would be helpful (Tom Warren; I CC'd
 him here)
 
 diff --git a/arch/arm/cpu/tegra-common/ap.c
 b/arch/arm/cpu/tegra-common/ap.c
 
 @@ -71,6 +71,7 @@ int tegra_get_chip_sku(void) switch (sku_id)
 { case SKU_ID_T33: case SKU_ID_T30: +   case SKU_ID_T30MQS:
 
 Where does the name T30MQS come from? Tom, can you verify what
 we call the SKUs internally?
 
 It seems like this is indeed called T30MQS internally. Actually
 it's called TM30MQS-A3. I can provide an internal reference if
 required.

As long as it's been checked, I don't think we need to document it. In
which case, IIRC, the patch was fine.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] mx6sabresd: Reset counter to prevent error message

On 11/09/2013 23:14, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 If a HDMI cable is not connected, the following message is seen on boot:
 
 CPU:   Freescale i.MX6Q rev1.1 at 792 MHz 
   
 Reset cause: POR  
   
 Board: MX6-SabreSD
   
 DRAM:  1 GiB  
   
 MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2  
   
 No panel detected: default to HDMI
   
 unsupported panel HDMI 
 
 Reset the 'i' variable to fix the 'unsupported panel' message.
 
 This follows the same idea of commit 47ac53d7ae (imx: 
 nitrogen6x/mx6qsabrelite: 
 Fix bug in board_video_skip).
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file

Dear Troy Kisky,

 On 9/20/2013 12:53 PM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  On 9/20/2013 11:52 AM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  On 9/20/2013 3:55 AM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  Move common definitions to udc.h
  This allows musb_udc.h to be removed as well.
  
  Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
  
  ---
  v4: updated commit message
  removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
  is the only legal value, it shouldn't be overridden.
  
  [...]
  
  #endif
  
  diff --git a/include/usb/udc.h b/include/usb/udc.h
  new file mode 100644
  index 000..3bcbbbc
  --- /dev/null
  +++ b/include/usb/udc.h
  @@ -0,0 +1,61 @@
  +/*
  + * SPDX-License-Identifier:   GPL-2.0+
  + */
  +#ifndef USB_UDC_H
  +#define USB_UDC_H
  +
  +#ifndef EP0_MAX_PACKET_SIZE
  +#define EP0_MAX_PACKET_SIZE 64
  +#endif
  +
  +#ifndef EP_MAX_PACKET_SIZE
  +#define EP_MAX_PACKET_SIZE64
  +#endif
  +
  +#ifndef UDC_OUT_PACKET_SIZE
  +#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_IN_PACKET_SIZE
  +#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_INT_PACKET_SIZE
  +#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_BULK_PACKET_SIZE
  +#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
  +#endif
  
  Do you expect these values to change on per-controller basis? Or why
  do you have these ifndefs here ?
  
  I don't know why they change but
  
  include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
  EP_MIN_PACKET_SIZE/* 8 */
  include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16
  
  include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
  UDC_IN_PACKET_SIZE   /* 8 */
  include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16
  
  include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
  EP_MIN_PACKET_SIZE/* */
  
  Are you sure this is not OHCI ?
  
  Best regards,
  Marek Vasut
  
  I don't know.
  I don't understand the relevance of the question. Can you explain the
  issue a little more
  for me.
  
  OMAP1510 has only OHCI controller in it, dunno about MPC8xx, but that
  seems to be the case as well. Therefore, in OHCI case, the max packet is
  16 and in ehci it's 64 . Check the specs ;-)
  
  Best regards,
  Marek Vasut
 
 Ok, I checked the spec for the OMAP1510, and found Table 14–23.
 Endpoint n Size Values
 lists maximum packet sizes of 8, 16, 32, or 64 bytes for Non-isochronous
 endpoints, and 8, 16, 32, 64, 128, 256, 512 for Isochronous endpoints
 
 So, I still don't understand the limit of 16, but that isn't required.
 
 
 So, are you saying I should edit omap1510_udc.h and add
 
 #define EP_MAX_PACKET_SIZE 16
 
 
 and remove
 #ifndef UDC_BULK_PACKET_SIZE
 
 in udc.h and do
 
 #define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
 
 unconditionally?

I'd say you should check if the controller is OHCI or EHCI , check what kind of 
endpoint it is and based on that , configure the max packet size. Or is this 
really controller specific ? What do the OHCI and EHCI specs say ?

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

Re: [U-Boot] [PATCH] Tegra114: Fix PLLX M, N, P init settings

2013-09-20 Thread Tom Warren

Thierry,

 -Original Message-
 From: Thierry Reding [mailto:thierry.red...@gmail.com]
 Sent: Friday, September 20, 2013 5:41 AM
 To: Tom Warren
 Cc: u-boot@lists.denx.de
 Subject: [PATCH] Tegra114: Fix PLLX M, N, P init settings
 
 From: Jimmy Zhang jimmzh...@nvidia.com
 
 The M, N and P width have been changed from Tegra30. The maximum value
 for N is limited to 255. So, the tegra_pll_x_table for Tegra114 should be set
 accordingly.
 
 Signed-off-by: Jimmy Zhang jimmzh...@nvidia.com
 Reviewed-by: Tom Warren twar...@nvidia.com
 Signed-off-by: Thierry Reding tred...@nvidia.com
 ---
  arch/arm/cpu/arm720t/tegra-common/cpu.c | 36
 +++--
  1 file changed, 30 insertions(+), 6 deletions(-)
 
 diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
 b/arch/arm/cpu/arm720t/tegra-common/cpu.c
 index 9294611..2c50034 100644
 --- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
 +++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
 @@ -50,7 +50,13 @@ int get_num_cpus(void)
   */
  struct clk_pll_table
 tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
   /* T20: 1 GHz */
 - /*  n,  m, p, cpcon */
 + /*
 +  * Field Bits Width
 +  *  n17:8  10
 +  *  m 4:0   5
 +  *  p22:20  3
 +  */
 +  /*  n,  m, p, cpcon */
   {{ 1000, 13, 0, 12},/* OSC 13M */
{ 625,  12, 0, 8}, /* OSC 19.2M */
{ 1000, 12, 0, 12},/* OSC 12M */
 @@ -58,6 +64,12 @@ struct clk_pll_table
 tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
   },
 
   /* T25: 1.2 GHz */
 + /*
 +  * Field Bits Width
 +  *  n17:8  10
 +  *  m 4:0   5
 +  *  p22:20  3
 +  */
   {{ 923, 10, 0, 12},
{ 750, 12, 0, 8},
{ 600,  6, 0, 12},
 @@ -65,17 +77,29 @@ struct clk_pll_table
 tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
   },
 
   /* T30: 1.4 GHz */
 + /*
 +  * Field Bits Width
 +  *  n17:8  10
 +  *  m 4:0   5
 +  *  p22:20  3
 +  */
   {{ 862, 8, 0, 8},
{ 583, 8, 0, 4},
{ 700, 6, 0, 8},
{ 700, 13, 0, 8},
   },
 
 - /* T114: 1.4 GHz */
 - {{ 862, 8, 0, 8},
 -  { 583, 8, 0, 4},
 -  { 696, 12, 0, 8},
 -  { 700, 13, 0, 8},
 + /* T114: 1.9 GHz*/
 + /*
 +  * Field Bits Width
 +  *  n15:8   8
 +  *  m 7:0   8
 +  *  p23:20  4
 +  */
 + {{ 108, 1, 1, 8},   /* actual: 702.0 MHz */
 +  { 73, 1, 1, 4},/* actual: 700.8 MHz */
 +  { 116, 1, 1, 8},   /* actual: 696.0 MHz */
 +  { 108, 2, 1, 8},   /* actual: 702.0 MHz */
   },
  };
 
 --
 1.8.4
LGTM. Thanks for doing this.
Acked-by: Tom Warren twar...@nvidia.com

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

Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads

2013-09-20 Thread Tom Rini

On Fri, Sep 20, 2013 at 07:15:29PM +0200, Jeroen Hofstee wrote:
 Hello Tom,
 
 On 09/19/2013 11:16 PM, Tom Rini wrote:
 On Sat, Aug 24, 2013 at 01:55:38PM +0200, Jeroen Hofstee wrote:
 
 The movt/movw instruction can be used to hardcode an
 memory location in the instruction itself. The linker
 starts complaining about this if the compiler decides
 to do so: relocation R_ARM_MOVW_ABS_NC against `a local
 symbol' can not be used and it is not support by U-boot
 as well. Prevent their use by requiring word relocations.
 This allows u-boot to be build at other optimalization
 levels then -Os.
 
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
 Cc: tiger...@viatech.com.cn
 Cc: Albert ARIBAUD albert.u.b...@aribaud.net
 ---
   arch/arm/config.mk | 8 ++--
   1 file changed, 6 insertions(+), 2 deletions(-)
 Is this also something we need for llvm?
 
 You guessed that right, for clang actually (llvm has
 already been taught to not emit movw/movt pairs,
 when requested not to do so). So with the
 -mword-relocations || present I can teach clang to tell llvm
 not to do it.
 
 I am not aware of any reason why gcc could not
 decide to do the same in future releases. A pointer
 comparison e.g. is of exactly the same size (afaik).
 In this case U-boot will no longer compile without
 mentioned flag.

OK.

[snip]
 If there's some -O2 enabled gcc flag we want because of
 a measurable performance win, we should add it specifically to -Os.
 
 First of all the default -Os is unchanged and I have no
 intention to change it. -O2 won't build without the patch
 last time I checked ;)
 
 Anyway, I like the flag since it helps to not special case
 clang and it guarantees builds with gcc at all optimisation
 levels, now and in the future. I don't care if it goes in this
 release or the next one.

Right, I'm OK picking this patch up then, on the grounds of making
clang/llvm work now, and potentially keeping a future gcc happy.

-- 
Tom


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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file


On 9/20/2013 2:20 PM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 12:53 PM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 11:52 AM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 3:55 AM, Marek Vasut wrote:

Dear Troy Kisky,


Move common definitions to udc.h
This allows musb_udc.h to be removed as well.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

---
v4: updated commit message
removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
is the only legal value, it shouldn't be overridden.

[...]


 #endif

diff --git a/include/usb/udc.h b/include/usb/udc.h
new file mode 100644
index 000..3bcbbbc
--- /dev/null
+++ b/include/usb/udc.h
@@ -0,0 +1,61 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef USB_UDC_H
+#define USB_UDC_H
+
+#ifndef EP0_MAX_PACKET_SIZE
+#define EP0_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef EP_MAX_PACKET_SIZE
+#define EP_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef UDC_OUT_PACKET_SIZE
+#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_IN_PACKET_SIZE
+#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_INT_PACKET_SIZE
+#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_BULK_PACKET_SIZE
+#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
+#endif

Do you expect these values to change on per-controller basis? Or why
do you have these ifndefs here ?

I don't know why they change but

include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
EP_MIN_PACKET_SIZE/* 8 */
include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16

include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
UDC_IN_PACKET_SIZE   /* 8 */
include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16

include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
EP_MIN_PACKET_SIZE/* */

Are you sure this is not OHCI ?

Best regards,
Marek Vasut

I don't know.
I don't understand the relevance of the question. Can you explain the
issue a little more
for me.

OMAP1510 has only OHCI controller in it, dunno about MPC8xx, but that
seems to be the case as well. Therefore, in OHCI case, the max packet is
16 and in ehci it's 64 . Check the specs ;-)

Best regards,
Marek Vasut

Ok, I checked the spec for the OMAP1510, and found Table 14–23.
Endpoint n Size Values
lists maximum packet sizes of 8, 16, 32, or 64 bytes for Non-isochronous
endpoints, and 8, 16, 32, 64, 128, 256, 512 for Isochronous endpoints

So, I still don't understand the limit of 16, but that isn't required.


So, are you saying I should edit omap1510_udc.h and add

#define EP_MAX_PACKET_SIZE 16


and remove
#ifndef UDC_BULK_PACKET_SIZE

in udc.h and do

#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE

unconditionally?

I'd say you should check if the controller is OHCI or EHCI , check what kind of
endpoint it is and based on that , configure the max packet size. Or is this
really controller specific ? What do the OHCI and EHCI specs say ?

Best regards,
Marek Vasut



The omap1510 does have an OHCI host controller, I don't know how that 
relates to the device

controller so I think a check would just be confusing.

Troy

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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file


On 9/20/2013 12:53 PM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 11:52 AM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 3:55 AM, Marek Vasut wrote:

Dear Troy Kisky,


Move common definitions to udc.h
This allows musb_udc.h to be removed as well.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

---
v4: updated commit message
removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
is the only legal value, it shouldn't be overridden.

[...]


#endif

diff --git a/include/usb/udc.h b/include/usb/udc.h
new file mode 100644
index 000..3bcbbbc
--- /dev/null
+++ b/include/usb/udc.h
@@ -0,0 +1,61 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef USB_UDC_H
+#define USB_UDC_H
+
+#ifndef EP0_MAX_PACKET_SIZE
+#define EP0_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef EP_MAX_PACKET_SIZE
+#define EP_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef UDC_OUT_PACKET_SIZE
+#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_IN_PACKET_SIZE
+#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_INT_PACKET_SIZE
+#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_BULK_PACKET_SIZE
+#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
+#endif

Do you expect these values to change on per-controller basis? Or why do
you have these ifndefs here ?

I don't know why they change but

include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
EP_MIN_PACKET_SIZE/* 8 */
include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16

include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
UDC_IN_PACKET_SIZE   /* 8 */
include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16

include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
EP_MIN_PACKET_SIZE/* */

Are you sure this is not OHCI ?

Best regards,
Marek Vasut

I don't know.
I don't understand the relevance of the question. Can you explain the
issue a little more
for me.

OMAP1510 has only OHCI controller in it, dunno about MPC8xx, but that seems to
be the case as well. Therefore, in OHCI case, the max packet is 16 and in ehci
it's 64 . Check the specs ;-)

Best regards,
Marek Vasut

Ok, I checked the spec for the OMAP1510, and found Table 14–23. 
Endpoint n Size Values

lists maximum packet sizes of 8, 16, 32, or 64 bytes for Non-isochronous
endpoints, and 8, 16, 32, 64, 128, 256, 512 for Isochronous endpoints

So, I still don't understand the limit of 16, but that isn't required.


So, are you saying I should edit omap1510_udc.h and add

#define EP_MAX_PACKET_SIZE 16


and remove
#ifndef UDC_BULK_PACKET_SIZE

in udc.h and do

#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE

unconditionally?


Thanks
Troy


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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file

Dear Troy Kisky,

 On 9/20/2013 2:20 PM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  On 9/20/2013 12:53 PM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  On 9/20/2013 11:52 AM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  On 9/20/2013 3:55 AM, Marek Vasut wrote:
  Dear Troy Kisky,
  
  Move common definitions to udc.h
  This allows musb_udc.h to be removed as well.
  
  Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
  
  ---
  v4: updated commit message
  removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
  is the only legal value, it shouldn't be overridden.
  
  [...]
  
   #endif
  
  diff --git a/include/usb/udc.h b/include/usb/udc.h
  new file mode 100644
  index 000..3bcbbbc
  --- /dev/null
  +++ b/include/usb/udc.h
  @@ -0,0 +1,61 @@
  +/*
  + * SPDX-License-Identifier: GPL-2.0+
  + */
  +#ifndef USB_UDC_H
  +#define USB_UDC_H
  +
  +#ifndef EP0_MAX_PACKET_SIZE
  +#define EP0_MAX_PACKET_SIZE 64
  +#endif
  +
  +#ifndef EP_MAX_PACKET_SIZE
  +#define EP_MAX_PACKET_SIZE  64
  +#endif
  +
  +#ifndef UDC_OUT_PACKET_SIZE
  +#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_IN_PACKET_SIZE
  +#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_INT_PACKET_SIZE
  +#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
  +#endif
  +
  +#ifndef UDC_BULK_PACKET_SIZE
  +#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
  +#endif
  
  Do you expect these values to change on per-controller basis? Or
  why do you have these ifndefs here ?
  
  I don't know why they change but
  
  include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
  EP_MIN_PACKET_SIZE/* 8 */
  include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16
  
  include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
  UDC_IN_PACKET_SIZE   /* 8 */
  include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16
  
  include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
  EP_MIN_PACKET_SIZE/* */
  
  Are you sure this is not OHCI ?
  
  Best regards,
  Marek Vasut
  
  I don't know.
  I don't understand the relevance of the question. Can you explain the
  issue a little more
  for me.
  
  OMAP1510 has only OHCI controller in it, dunno about MPC8xx, but that
  seems to be the case as well. Therefore, in OHCI case, the max packet
  is 16 and in ehci it's 64 . Check the specs ;-)
  
  Best regards,
  Marek Vasut
  
  Ok, I checked the spec for the OMAP1510, and found Table 14–23.
  Endpoint n Size Values
  lists maximum packet sizes of 8, 16, 32, or 64 bytes for Non-isochronous
  endpoints, and 8, 16, 32, 64, 128, 256, 512 for Isochronous endpoints
  
  So, I still don't understand the limit of 16, but that isn't required.
  
  
  So, are you saying I should edit omap1510_udc.h and add
  
  #define EP_MAX_PACKET_SIZE 16
  
  
  and remove
  #ifndef UDC_BULK_PACKET_SIZE
  
  in udc.h and do
  
  #define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
  
  unconditionally?
  
  I'd say you should check if the controller is OHCI or EHCI , check what
  kind of endpoint it is and based on that , configure the max packet
  size. Or is this really controller specific ? What do the OHCI and EHCI
  specs say ?
  
  Best regards,
  Marek Vasut
 
 The omap1510 does have an OHCI host controller, I don't know how that
 relates to the device
 controller so I think a check would just be confusing.

I see the difference now. For EHCI UDC, the max packet sizes are as they are. 
For OMAP/MPC8xx, these are non-standard arbitrary values, it's just that the 
name is the same.

This is pretty ugly and confusing, ick. I'd say you #ifdef this stuff like this:
#ifdef OMAP1510 ... 
#elif MPC8xx
#elif 
#endif

And put a comment around it that the old UDCs simply follow no standard.

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

Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce


On 9/20/2013 3:58 AM, Marek Vasut wrote:

Dear Troy Kisky,


Only perform one copy, either in the bounce
routine for IN transfers, or the debounce
rtn for OUT transfer.

On out transfers, only copy the number
of bytes received from the bounce buffer

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

---
v4: no change

Just a question here. Are you sure we never Send AND Reserve the data in one
turn? Because that would need two copyings.


 ???   s/Reserve/Receive/

As far as I'm aware, a single buffer is only ever used to capture or 
provide data not both.
But, if 2 transfers were queued, an OUT and then an IN using the same 
buffer, if it worked before

this patch, it should work after as well.


Best regards,
Marek Vasut



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

Re: [U-Boot] [PATCH 2/2] mx6qsabreauto: Return error if cpu_eth_init() fails

On 13/09/2013 03:03, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 Currently board_eth_init() always return 0, but we should propagate the error 
 when cpu_eth_init() fails.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---


Applied to u-boot-imx, thanks!

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] powerpc/c29xpcie: Getting DDR SPD image from 16-bit sub-address EEPROM

2013-09-20 Thread York Sun

On 08/20/2013 11:26 PM, Po Liu wrote:
 Currently, there is only one EEPROM on c29xpcie board which isAT24C1024.
 We program the SPD data at beginning of the AT24C1024.But the AT24C1024
 has a 16-bit sub-address mode. This patch is tomake it work when getting
 SPD in a 16-bit sub-address EEPROM.
 
 Signed-off-by: Po Liu po@freescale.com
 ---
  board/freescale/c29xpcie/ddr.c | 12 
  1 file changed, 12 insertions(+)
 
 diff --git a/board/freescale/c29xpcie/ddr.c b/board/freescale/c29xpcie/ddr.c
 index 3337d6c..28f1bd2 100644
 --- a/board/freescale/c29xpcie/ddr.c
 +++ b/board/freescale/c29xpcie/ddr.c
 @@ -84,3 +84,15 @@ void fsl_ddr_board_options(memctl_options_t *popts,
   popts-cs_local_opts[i].odt_wr_cfg = FSL_DDR_ODT_CS;
   }
  }
 +
 +void get_spd(generic_spd_eeprom_t *spd, u8 i2c_address)
 +{
 + int ret = i2c_read(i2c_address, 0, 2, (uchar *)spd,
 + sizeof(generic_spd_eeprom_t));
 +
 + if (ret) {
 + printf(DDR: failed to read SPD from address %u\n,
 + i2c_address);
 + memset(spd, 0, sizeof(generic_spd_eeprom_t));
 + }
 +}
 

Please fix the compiling warning. You need to include i2c.h, per
internal review.

York


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

[U-Boot] [PATCH] i.MX6DQ/DLS: Add pad MX6_PAD_GPIO_1__USB_OTG_ID

This patch adds the pad to i.MX6DQ and changes the i.MX6DLS
declaration to match the Linux kernel declaration.

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
Note that this is needed for OTG/UDC work Troy is prepping for i.MX6
and that the previous declaration of MX6_PAD_GPIO_1__USBOTG_ID was 
not previously used.

 arch/arm/include/asm/arch-mx6/mx6dl_pins.h | 2 +-
 arch/arm/include/asm/arch-mx6/mx6q_pins.h  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h 
b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
index ad537b4..b5df68a 100644
--- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
@@ -1043,7 +1043,7 @@ enum {
MX6_PAD_GPIO_1__ESAI1_SCKR  = IOMUX_PAD(0x05E0, 0x0210, 0, 
0x083C, 1, 0),
MX6_PAD_GPIO_1__WDOG2_WDOG_B= IOMUX_PAD(0x05E0, 0x0210, 1, 
0x, 0, 0),
MX6_PAD_GPIO_1__KPP_ROW_5   = IOMUX_PAD(0x05E0, 0x0210, 2, 
0x08CC, 1, 0),
-   MX6_PAD_GPIO_1__USBOTG_ID   = IOMUX_PAD(0x05E0, 0x0210, 3, 
0x0790, 1, 0),
+   MX6_PAD_GPIO_1__USB_OTG_ID  = IOMUX_PAD(0x05E0, 0x0210, 3, 
0x0790, 1, 0),
MX6_PAD_GPIO_1__PWM2_PWMO   = IOMUX_PAD(0x05E0, 0x0210, 4, 
0x, 0, 0),
MX6_PAD_GPIO_1__GPIO_1_1= IOMUX_PAD(0x05E0, 0x0210, 5, 
0x, 0, 0),
MX6_PAD_GPIO_1__USDHC1_CD   = IOMUX_PAD(0x05E0, 0x0210, 6, 
0x, 0, 0),
diff --git a/arch/arm/include/asm/arch-mx6/mx6q_pins.h 
b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
index 94df007..a951a6e 100644
--- a/arch/arm/include/asm/arch-mx6/mx6q_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
@@ -984,6 +984,7 @@ enum {
MX6_PAD_GPIO_1__ESAI1_SCKR  = IOMUX_PAD(0x05F4, 0x0224, 0, 
0x086C, 1, 0),
MX6_PAD_GPIO_1__WDOG2_WDOG_B= IOMUX_PAD(0x05F4, 0x0224, 1, 
0x, 0, 0),
MX6_PAD_GPIO_1__KPP_ROW_5   = IOMUX_PAD(0x05F4, 0x0224, 2, 
0x08F4, 0, 0),
+   MX6_PAD_GPIO_1__USB_OTG_ID  = IOMUX_PAD(0x05E0, 0x0210, 3, 
0x0790, 1, 0),
MX6_PAD_GPIO_1__PWM2_PWMO   = IOMUX_PAD(0x05F4, 0x0224, 4, 
0x, 0, 0),
MX6_PAD_GPIO_1__GPIO_1_1= IOMUX_PAD(0x05F4, 0x0224, 5, 
0x, 0, 0),
MX6_PAD_GPIO_1__USDHC1_CD   = IOMUX_PAD(0x05F4, 0x0224, 6, 
0x, 0, 0),
-- 
1.8.1.2

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

Re: [U-Boot] [RFC PATCH 0/3] i.MX6 (DQ/DLS): consolidate mux and pad names


On 09/16/2013 02:26 PM, Eric Nelson wrote:

This patch set begins the process of consolidating mux and pad
declarations for the i.MX6 Dual/Quad and Dual-Lite/Solo processor
variants.

Patch 1 replaces the mux/pad names with their equivalents from
the Linux kernel (from linux-next). This
Patch 2 removes a set of completely useless pad declarations
Patch 3 adds a number of registers that are defined in the Linux
kernel and in the DLS variant, but not in the DQ.

After this patch, there are still more than 400 pad differences
between the two variants. These represent mux/pad declarations
that are not present in the Linux kernel. A combined list of these
is available at:
http://linode.boundarydevices.com/u-boot-pads.lst

The majority of these are diagnostic settings and a large number
of these appear unlikely to ever be used. The primary reason this
is being sent as an RFC is to get feedback about what should be
done with them:
1. Delete them all
2. Walk through them and delete some and add others
3. Add them all and consolidate the names.



Shawn and Fabio: I'd like to find out what you think about
how to handle the pads that aren't in the kernel tree.

Please advise,


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

Re: [U-Boot] [PATCH V4 06/17] usb: udc: add udc.h include file


On 9/20/2013 3:01 PM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 2:20 PM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 12:53 PM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 11:52 AM, Marek Vasut wrote:

Dear Troy Kisky,


On 9/20/2013 3:55 AM, Marek Vasut wrote:

Dear Troy Kisky,


Move common definitions to udc.h
This allows musb_udc.h to be removed as well.

Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com

---
v4: updated commit message
removed ifdef UDC_BULK_HS_PACKET_SIZE since 512
is the only legal value, it shouldn't be overridden.

[...]


  #endif

diff --git a/include/usb/udc.h b/include/usb/udc.h
new file mode 100644
index 000..3bcbbbc
--- /dev/null
+++ b/include/usb/udc.h
@@ -0,0 +1,61 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef USB_UDC_H
+#define USB_UDC_H
+
+#ifndef EP0_MAX_PACKET_SIZE
+#define EP0_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef EP_MAX_PACKET_SIZE
+#define EP_MAX_PACKET_SIZE 64
+#endif
+
+#ifndef UDC_OUT_PACKET_SIZE
+#define UDC_OUT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_IN_PACKET_SIZE
+#define UDC_IN_PACKET_SIZE  EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_INT_PACKET_SIZE
+#define UDC_INT_PACKET_SIZE EP_MAX_PACKET_SIZE
+#endif
+
+#ifndef UDC_BULK_PACKET_SIZE
+#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE
+#endif

Do you expect these values to change on per-controller basis? Or
why do you have these ifndefs here ?

I don't know why they change but

include/usb/mpc8xx_udc.h:#define UDC_BULK_PACKET_SIZE
EP_MIN_PACKET_SIZE/* 8 */
include/usb/omap1510_udc.h:#define UDC_BULK_PACKET_SIZE 16

include/usb/mpc8xx_udc.h:#define UDC_INT_PACKET_SIZE
UDC_IN_PACKET_SIZE   /* 8 */
include/usb/omap1510_udc.h:#define UDC_INT_PACKET_SIZE  16

include/usb/mpc8xx_udc.h:#define UDC_OUT_PACKET_SIZE
EP_MIN_PACKET_SIZE/* */

Are you sure this is not OHCI ?

Best regards,
Marek Vasut

I don't know.
I don't understand the relevance of the question. Can you explain the
issue a little more
for me.

OMAP1510 has only OHCI controller in it, dunno about MPC8xx, but that
seems to be the case as well. Therefore, in OHCI case, the max packet
is 16 and in ehci it's 64 . Check the specs ;-)

Best regards,
Marek Vasut

Ok, I checked the spec for the OMAP1510, and found Table 14–23.
Endpoint n Size Values
lists maximum packet sizes of 8, 16, 32, or 64 bytes for Non-isochronous
endpoints, and 8, 16, 32, 64, 128, 256, 512 for Isochronous endpoints

So, I still don't understand the limit of 16, but that isn't required.


So, are you saying I should edit omap1510_udc.h and add

#define EP_MAX_PACKET_SIZE 16


and remove
#ifndef UDC_BULK_PACKET_SIZE

in udc.h and do

#define UDC_BULK_PACKET_SIZEEP_MAX_PACKET_SIZE

unconditionally?

I'd say you should check if the controller is OHCI or EHCI , check what
kind of endpoint it is and based on that , configure the max packet
size. Or is this really controller specific ? What do the OHCI and EHCI
specs say ?

Best regards,
Marek Vasut

The omap1510 does have an OHCI host controller, I don't know how that
relates to the device
controller so I think a check would just be confusing.

I see the difference now. For EHCI UDC, the max packet sizes are as they are.
For OMAP/MPC8xx, these are non-standard arbitrary values, it's just that the
name is the same.

This is pretty ugly and confusing, ick. I'd say you #ifdef this stuff like this:
#ifdef OMAP1510 ...
#elif MPC8xx
#elif 
#endif

And put a comment around it that the old UDCs simply follow no standard.

Best regards,

I suspect omap1510 will work with a value of 64 for the sizes, since it 
and mpc8xx

were added by Bryan O'Donoghue - 29 May 2006

I've added him to the CC.
Bryan, can you test changing

include/usb/omap1510_udc.h
#define UDC_INT_PACKET_SIZE 16
#define UDC_BULK_PACKET_SIZE 16

or on a very old u-boot
include/usbdcore_omap1510.h
#define UDC_INT_PKTSIZE16
#define UDC_BULK_PKTSIZE 16


from 16 to 64? Or maybe you remember the reason 16 was needed?
Also, do your remember anything about the MPC885 family and why
endpoint 0 could be 16 bytes, but bulk endpoints are limited to 8?

Thanks, I'd like my comments to be accurate...

Troy

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

[U-Boot] [PATCH v3 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h

There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.

Since the IGEPv2 board and the IGEP COM Module use a TI
OMAP35xx/DM37xx processor, is better to rename its board
config to use this naming scheme.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Enric Balletbo i Serra eballe...@iseebcn.com
---

Changes since v2:
 - Rebase patch to adapt to new boards.cfg file format.

Changes since v1:
 - Fix some issues in the commit changelog pointed out by Enric Balletbo.

 boards.cfg   | 10 +-
 include/configs/{igep00x0.h = omap3_igep00x0.h} |  0
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename include/configs/{igep00x0.h = omap3_igep00x0.h} (100%)

diff --git a/boards.cfg b/boards.cfg
index 310c034..075c81c 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -307,11 +307,11 @@ Active  arm armv7  omap3   comelit
 dig297
 Active  arm armv7  omap3   compulabcm_t35  
cm_t35   -  

   Igor Grinberg grinb...@compulab.co.il
 Active  arm armv7  omap3   corscience  tricorder   
tricorder-  

   Thomas Weber we...@corscience.de
 Active  arm armv7  omap3   htkwmcx 
mcx  -  

   Ilya Yanok ya...@emcraft.com
-Active  arm armv7  omap3   iseeigep00x0
igep0020 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND  
  Enric Balletbo i Serra 
eballe...@iseebcn.com
-Active  arm armv7  omap3   iseeigep00x0
igep0020_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND 
  -
-Active  arm armv7  omap3   iseeigep00x0
igep0030 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND  
  Enric Balletbo i Serra 
eballe...@iseebcn.com
-Active  arm armv7  omap3   iseeigep00x0
igep0030_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND 
  -
-Active  arm armv7  omap3   iseeigep00x0
igep0032 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND  
  Enric Balletbo i Serra 
eballe...@iseebcn.com
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0020   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra 
eballe...@iseebcn.com
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0020_nand  
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND   
-
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0030   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra 
eballe...@iseebcn.com
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0030_nand  
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND   
-
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0032   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra 
eballe...@iseebcn.com
 Active  arm armv7  omap3   logicpd am3517evm   
am3517_evm   -

[U-Boot] [PATCH v3 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h

There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.

Since the IGEP COM AQUILA use TI AM335x processors, is better
to rename its board config to use this naming scheme.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Enric Balletbo i Serra eballe...@iseebcn.com
---

Changes since v2:
 - Rebase patch to adapt to new boards.cfg file format.

Changes since v1:
 - Fix some issues in the commit changelog pointed out by Enric Balletbo.

 boards.cfg| 2 +-
 include/configs/{igep0033.h = am335x_igep0033.h} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename include/configs/{igep0033.h = am335x_igep0033.h} (100%)

diff --git a/boards.cfg b/boards.cfg
index dbd8479..310c034 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -243,7 +243,7 @@ Active  arm arm946es   -   armltd   
   integrator
 Active  arm armv7  -   armltd  vexpress
vexpress_ca15_tc2-  

   -
 Active  arm armv7  -   armltd  vexpress
vexpress_ca5x2   -  

   Matt Waddel matt.wad...@linaro.org
 Active  arm armv7  -   armltd  vexpress
vexpress_ca9x4   -  

   Matt Waddel matt.wad...@linaro.org
-Active  arm armv7  am33xx  iseeigep0033
igep0033 -  

   Enric Balletbo i Serra eballe...@iseebcn.com
+Active  arm armv7  am33xx  iseeigep0033
am335x_igep0033  -  

   Enric Balletbo i Serra eballe...@iseebcn.com
 Active  arm armv7  am33xx  phytec  pcm051  
pcm051   pcm051 

   Lars Poeschel poesc...@lemonage.de
 Active  arm armv7  am33xx  siemens dxr2
dxr2 -  

   Roger Meier r.me...@siemens.com
 Active  arm armv7  am33xx  siemens pxm2
pxm2 -  

   Roger Meier r.me...@siemens.com
diff --git a/include/configs/igep0033.h b/include/configs/am335x_igep0033.h
similarity index 100%
rename from include/configs/igep0033.h
rename to include/configs/am335x_igep0033.h
-- 
1.8.4.rc3

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

[U-Boot] [PATCH v3 1/2] ARM: IGEP0033: rename config file to am335x_igep0033.h

There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.

Since the IGEP COM AQUILA use TI AM335x processors, is better
to rename its board config to use this naming scheme.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Enric Balletbo i Serra eballe...@iseebcn.com
---

Changes since v2:
 - Rebase patch to adapt to new boards.cfg file format.

Changes since v1:
 - Fix some issues in the commit changelog pointed out by Enric Balletbo.

 boards.cfg| 2 +-
 include/configs/{igep0033.h = am335x_igep0033.h} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename include/configs/{igep0033.h = am335x_igep0033.h} (100%)

diff --git a/boards.cfg b/boards.cfg
index dbd8479..310c034 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -243,7 +243,7 @@ Active  arm arm946es   -   armltd   
   integrator
 Active  arm armv7  -   armltd  vexpress
vexpress_ca15_tc2-  

   -
 Active  arm armv7  -   armltd  vexpress
vexpress_ca5x2   -  

   Matt Waddel matt.wad...@linaro.org
 Active  arm armv7  -   armltd  vexpress
vexpress_ca9x4   -  

   Matt Waddel matt.wad...@linaro.org
-Active  arm armv7  am33xx  iseeigep0033
igep0033 -  

   Enric Balletbo i Serra eballe...@iseebcn.com
+Active  arm armv7  am33xx  iseeigep0033
am335x_igep0033  -  

   Enric Balletbo i Serra eballe...@iseebcn.com
 Active  arm armv7  am33xx  phytec  pcm051  
pcm051   pcm051 

   Lars Poeschel poesc...@lemonage.de
 Active  arm armv7  am33xx  siemens dxr2
dxr2 -  

   Roger Meier r.me...@siemens.com
 Active  arm armv7  am33xx  siemens pxm2
pxm2 -  

   Roger Meier r.me...@siemens.com
diff --git a/include/configs/igep0033.h b/include/configs/am335x_igep0033.h
similarity index 100%
rename from include/configs/igep0033.h
rename to include/configs/am335x_igep0033.h
-- 
1.8.4.rc3

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

[U-Boot] [PATCH v3 2/2] OMAP3: igep00x0: rename config file to omap3_igep00x0.h

There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.

Since the IGEPv2 board and the IGEP COM Module use a TI
OMAP35xx/DM37xx processor, is better to rename its board
config to use this naming scheme.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Enric Balletbo i Serra eballe...@iseebcn.com
---

Changes since v2:
 - Rebase patch to adapt to new boards.cfg file format.

Changes since v1:
 - Fix some issues in the commit changelog pointed out by Enric Balletbo.

 boards.cfg   | 10 +-
 include/configs/{igep00x0.h = omap3_igep00x0.h} |  0
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename include/configs/{igep00x0.h = omap3_igep00x0.h} (100%)

diff --git a/boards.cfg b/boards.cfg
index 310c034..075c81c 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -307,11 +307,11 @@ Active  arm armv7  omap3   comelit
 dig297
 Active  arm armv7  omap3   compulabcm_t35  
cm_t35   -  

   Igor Grinberg grinb...@compulab.co.il
 Active  arm armv7  omap3   corscience  tricorder   
tricorder-  

   Thomas Weber we...@corscience.de
 Active  arm armv7  omap3   htkwmcx 
mcx  -  

   Ilya Yanok ya...@emcraft.com
-Active  arm armv7  omap3   iseeigep00x0
igep0020 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND  
  Enric Balletbo i Serra 
eballe...@iseebcn.com
-Active  arm armv7  omap3   iseeigep00x0
igep0020_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND 
  -
-Active  arm armv7  omap3   iseeigep00x0
igep0030 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND  
  Enric Balletbo i Serra 
eballe...@iseebcn.com
-Active  arm armv7  omap3   iseeigep00x0
igep0030_nand
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND 
  -
-Active  arm armv7  omap3   iseeigep00x0
igep0032 
igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND  
  Enric Balletbo i Serra 
eballe...@iseebcn.com
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0020   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_ONENAND
Enric Balletbo i Serra 
eballe...@iseebcn.com
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0020_nand  
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0020,BOOT_NAND   
-
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0030   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND
Enric Balletbo i Serra 
eballe...@iseebcn.com
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0030_nand  
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND   
-
+Active  arm armv7  omap3   iseeigep00x0
omap3_igep0032   
omap3_igep00x0:MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND
Enric Balletbo i Serra 
eballe...@iseebcn.com
 Active  arm armv7  omap3   logicpd am3517evm   
am3517_evm   -

Re: [U-Boot] [PATCH v2] FIT: delete unnecessary casts

On Wed, Sep 18, 2013 at 9:10 PM, Masahiro Yamada
yamad...@jp.panasonic.comwrote:

 Becuase fdt_check_header function takes (const void *)
 type argument, the argument should be passed to it
 without being casted to (char *).

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com


Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] i2c: fix init on generic board

Hi Philippe,

On Thu, Sep 19, 2013 at 12:41 PM, Philippe Reynes trem...@yahoo.fr wrote:


 Signed-off-by: Philippe Reynes trem...@yahoo.fr


It looks good, but please can we have an explanation in the commit message?



 ---
  common/board_f.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/common/board_f.c b/common/board_f.c
 index 0ada1af..f0664bc 100644
 --- a/common/board_f.c
 +++ b/common/board_f.c
 @@ -249,7 +249,11 @@ void dram_init_banksize(void)
  static int init_func_i2c(void)
  {
 puts(I2C:   );
 +#ifdef CONFIG_SYS_I2C
 +   i2c_init_all();
 +#else
 i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
 +#endif
 puts(ready\n);
 return 0;
  }
 --
 1.7.4.4

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


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

Re: [U-Boot] [PATCH 01/12 V3] EXYNOS5: Create a common board file

Hi Rajeshwari,

On Wed, Sep 11, 2013 at 4:01 AM, Rajeshwari S Shinde 
rajeshwar...@samsung.com wrote:

 Create a common board.c file for all functions which are common across
 all EXYNOS5 platforms.

 exynos_init function is provided for platform cpecific code.

 Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com


I have a few more comments after trying this out on Pit.

My source tree is here, in branch try-5420.

git://git.denx.de/u-boot-x86.git

This includes a few modifications to your patches to make them apply on
mainline, and also one patch to fix Pit:

- add a device tree
- fix a few defines (CONFIG_POWER... instead of CONFIG_PMIC)
- define CONFIG_POWER to get PS HOLD asserted (otherwise it powers off
after 1 second)
- disable MAX77686 PMIC (there is no driver for 77802)
- remove PMIC code in smdk5420.c since it is already in
board/samsung/common/board.c
- serial support for SPL, not really needed
- fix boards.cfg format
- hack tools/Makefile

With this I can boot to a prompt on Pit (I just type 'crosfw' inside the
Chrome OS chroot to build and download over USB). I suspect SMDK5420 does
not need PS_HOLD, and I think your PMIC code is not being included.

I hope this helps with your patch preparation for v4 - it would be great if
you could include Pit support as well as smdk5420. Hopefully they can use
the same config, just a different device tree.

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

Re: [U-Boot] [PATCH] arm: prevent using movt/movw address loads