[U-Boot] [PATCH v2] arm, am33xx: add defines for gmii_sel_register bits

[Heiko Schocher]

move gmii_sel register defines from board code to common place.

Signed-off-by: Heiko Schocher h...@denx.de
Cc: Chandan Nath chandan.n...@ti.com
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Lars Poeschel poesc...@lemonage.de
Cc: Enric Balletbo i Serra eballe...@iseebcn.com

---
- changes for v2:
  defined all bits used in the gmii_sel register as
  Tom Rini suggested

 arch/arm/include/asm/arch-am33xx/cpu.h | 21 +
 board/isee/igep0033/board.c|  7 ++-
 board/phytec/pcm051/board.c|  2 --
 board/ti/am335x/board.c|  6 +-
 4 Dateien geändert, 24 Zeilen hinzugefügt(+), 12 Zeilen entfernt(-)

diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h 
b/arch/arm/include/asm/arch-am33xx/cpu.h
index fb44654..98e15c0 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -364,6 +364,27 @@ struct ctrl_dev {
unsigned int resv4[4];
unsigned int miisel;/* offset 0x50 */
 };
+
+/* gmii_sel register defines */
+#define GMII1_SEL_MII  0x0
+#define GMII1_SEL_RMII 0x1
+#define GMII1_SEL_RGMII0x2
+#define GMII1_SEL_NOTUSED  0x3
+#define GMII2_SEL_MII  0x0
+#define GMII2_SEL_RMII 0x4
+#define GMII2_SEL_RGMII0x8
+#define GMII2_SEL_NOTUSED  0xc
+#define RGMII1_IDMODE  BIT(4)
+#define RGMII2_IDMODE  BIT(5)
+#define RMII1_IO_CLK_ENBIT(6)
+#define RMII2_IO_CLK_ENBIT(7)
+
+#define MII_MODE_ENABLE(GMII1_SEL_MII | GMII2_SEL_MII)
+#define RMII_MODE_ENABLE(GMII1_SEL_RMII | GMII2_SEL_RMII)
+#define RGMII_MODE_ENABLE  (GMII1_SEL_RGMII | GMII2_SEL_RGMII)
+#define RGMII_INT_DELAY(RGMII1_IDMODE | RGMII2_IDMODE)
+#define RMII_CHIPCKL_ENABLE (RMII1_IO_CLK_EN | RMII2_IO_CLK_EN)
+
 #endif /* __ASSEMBLY__ */
 #endif /* __KERNEL_STRICT_NAMES */
 
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index 842051f..d7cf7d0 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -36,10 +36,6 @@
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
-
-/* MII mode defines */
-#define RMII_MODE_ENABLE   0x4D
-
 static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
 
 static const struct ddr_data ddr3_data = {
@@ -182,7 +178,8 @@ int board_eth_init(bd_t *bis)
eth_setenv_enetaddr(ethaddr, mac_addr);
}
 
-   writel(RMII_MODE_ENABLE, cdev-miisel);
+   writel((GMII1_SEL_RMII | GMII2_SEL_NOTUSED | RMII1_IO_CLK_EN),
+  cdev-miisel);
 
rv = cpsw_register(cpsw_data);
if (rv  0)
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 72c5612..d0314e4 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -41,8 +41,6 @@ DECLARE_GLOBAL_DATA_PTR;
 static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
 
 /* MII mode defines */
-#define MII_MODE_ENABLE0x0
-#define RGMII_MODE_ENABLE  0xA
 #define RMII_RGMII2_MODE_ENABLE0x49
 
 static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index b04e385..6b96f84 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -39,10 +39,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
 
-/* MII mode defines */
-#define MII_MODE_ENABLE0x0
-#define RGMII_MODE_ENABLE  0x3A
-
 /* GPIO that controls power to DDR on EVM-SK */
 #define GPIO_DDR_VTT_EN7
 
@@ -465,7 +461,7 @@ int board_eth_init(bd_t *bis)
cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
PHY_INTERFACE_MODE_MII;
} else {
-   writel(RGMII_MODE_ENABLE, cdev-miisel);
+   writel((RGMII_MODE_ENABLE | RGMII_INT_DELAY), cdev-miisel);
cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
PHY_INTERFACE_MODE_RGMII;
}
-- 
1.7.11.7

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

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lokesh Vutla]

On Wednesday 05 June 2013 02:36 AM, Tom Rini wrote:

On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:

Hi Lokesh,


Hi Lubomir,
On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:

Hi Lokesh,

On 30/05/13 16:19, Lokesh Vutla wrote:

From: Balaji T K balaj...@ti.com

add dra mmc pbias support and ldo1 power on

Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
   drivers/mmc/omap_hsmmc.c   |   26 ++
   drivers/power/palmas.c |   25 -
   include/configs/omap5_common.h |4 
   include/configs/omap5_uevm.h   |5 -
   include/palmas.h   |6 +-
   6 files changed, 49 insertions(+), 20 deletions(-)


[snip]

+   /* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
TPS659038), you should add some comment above.

Ok ll add the comment.



+   val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are
defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/
tested/acked/nacked/whatever by nobody (except possibly a quick look by
Nishanth Menon, who had some objections). I wrote it when bringing up a
custom OMAP5 board, and most probably it shall not go into mainline in
its current form, if ever. I gave it only as an example of how things
could be done cleaner. Feel free to use the code as you wish, but I'm
afraid that applying it as a patch to your tree and basing upon it might
run you into problems when you later sync with mainline.

Tom, your opinion?


OK, so at the time it was nothing will really use this code except test
functions.  Looks like we have a use for mmc1_ldo9 code at least, so
lets rework the first patch for adding that + cleanups wrt constants.

Ok. Ill add the first patch + cleanups and resend it.

Thanks,
Lokesh




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

[U-Boot] [PATCH V4] lcd: align bmp header when uncopmressing image

[Piotr Wilczek]

When compressed image is loaded, it must be decompressed
to an aligned address + 2 to avoid unaligned access exception
on some ARM platforms.

Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Anatolij Gustschin ag...@denx.de
CC: Wolfgang Denk w...@denx.de
---
Changes for V4:
- dropped the if condition

Changes for V3:
- add comment on why extra space is allocated for uncompressed bmp header
- change the + 2 aligment method as Wolfgang Denk suggested

Changes for V2:
- add additional space for uncompressed bmp header due to alignment requirements
- fix to 32-bit-aligned-address + 2 alignent

 common/cmd_bmp.c |   42 --
 include/lcd.h|3 ++-
 2 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index 5a52edd..675f47a 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -38,14 +38,19 @@ static int bmp_info (ulong addr);
 /*
  * Allocate and decompress a BMP image using gunzip().
  *
- * Returns a pointer to the decompressed image data. Must be freed by
- * the caller after use.
+ * Returns a pointer to the decompressed image data. This pointer is
+ * is aligned to 32-bit-aligned-address + 2.
+ * See doc/README.displaying-bmps for explanation.
+ *
+ * The allocation address is passed to 'alloc_addr' and must be freed
+ * by the caller after use.
  *
  * Returns NULL if decompression failed, or if the decompressed data
  * didn't contain a valid BMP signature.
  */
 #ifdef CONFIG_VIDEO_BMP_GZIP
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+   void **alloc_addr)
 {
void *dst;
unsigned long len;
@@ -55,12 +60,19 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long 
*lenp)
 * Decompress bmp image
 */
len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
-   dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+   /* allocate extra 3 bytes for 32-bit-aligned-address + 2 alignment */
+   dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE + 3);
if (dst == NULL) {
puts(Error: malloc in gunzip failed!\n);
return NULL;
}
-   if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) != 
0) {
+
+   bmp = dst;
+
+   /* align to 32-bit-aligned-address + 2 */
+   bmp = (bmp_image_t *)unsigned int)dst + 1)  ~3) + 2);
+
+   if (gunzip(bmp, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) != 
0) {
free(dst);
return NULL;
}
@@ -68,8 +80,6 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long 
*lenp)
puts(Image could be truncated
 (increase 
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)!\n);
 
-   bmp = dst;
-
/*
 * Check for bmp mark 'BM'
 */
@@ -81,10 +91,12 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long 
*lenp)
 
debug(Gzipped BMP image detected!\n);
 
+   *alloc_addr = dst;
return bmp;
 }
 #else
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+   void **alloc_addr)
 {
return NULL;
 }
@@ -189,11 +201,12 @@ U_BOOT_CMD(
 static int bmp_info(ulong addr)
 {
bmp_image_t *bmp=(bmp_image_t *)addr;
+   void *bmp_alloc_addr = NULL;
unsigned long len;
 
if (!((bmp-header.signature[0]=='B') 
  (bmp-header.signature[1]=='M')))
-   bmp = gunzip_bmp(addr, len);
+   bmp = gunzip_bmp(addr, len, bmp_alloc_addr);
 
if (bmp == NULL) {
printf(There is no valid bmp file at the given address\n);
@@ -205,8 +218,8 @@ static int bmp_info(ulong addr)
printf(Bits per pixel: %d\n, le16_to_cpu(bmp-header.bit_count));
printf(Compression   : %d\n, le32_to_cpu(bmp-header.compression));
 
-   if ((unsigned long)bmp != addr)
-   free(bmp);
+   if (bmp_alloc_addr)
+   free(bmp_alloc_addr);
 
return(0);
 }
@@ -225,11 +238,12 @@ int bmp_display(ulong addr, int x, int y)
 {
int ret;
bmp_image_t *bmp = (bmp_image_t *)addr;
+   void *bmp_alloc_addr = NULL;
unsigned long len;
 
if (!((bmp-header.signature[0]=='B') 
  (bmp-header.signature[1]=='M')))
-   bmp = gunzip_bmp(addr, len);
+   bmp = gunzip_bmp(addr, len, bmp_alloc_addr);
 
if (!bmp) {
printf(There is no valid bmp file at the given address\n);
@@ -244,8 +258,8 @@ int bmp_display(ulong addr, int x, int y)
 # error bmp_display() requires CONFIG_LCD or CONFIG_VIDEO
 #endif
 
-   if ((unsigned long)bmp != addr)
-   free(bmp);
+   if (bmp_alloc_addr)
+   free(bmp_alloc_addr);
 
return ret;
 }
diff --git 

[U-Boot] [PATCH V4 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lokesh Vutla]

From: Balaji T K balaj...@ti.com

add dra mmc pbias support and ldo1 power on

Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Changes since V3:
* Addressed comments from Tom

 arch/arm/include/asm/arch-omap5/omap.h |2 +-
 drivers/mmc/omap_hsmmc.c   |   26 +++---
 drivers/power/palmas.c |   37 ++--
 include/configs/omap5_common.h |4 
 include/configs/omap5_uevm.h   |5 -
 include/palmas.h   |   12 +--
 6 files changed, 59 insertions(+), 27 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 9010666..abf6837 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -106,9 +106,9 @@
 /* CONTROL_EFUSE_2 */
 #define CONTROL_EFUSE_2_NMOS_PMOS_PTV_CODE_1   0x00ffc000
 
+#define SDCARD_BIAS_PWRDNZ (1  27)
 #define SDCARD_PWRDNZ  (1  26)
 #define SDCARD_BIAS_HIZ_MODE   (1  25)
-#define SDCARD_BIAS_PWRDNZ (1  22)
 #define SDCARD_PBIASLITE_VMODE (1  21)
 
 #ifndef __ASSEMBLY__
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index afdfa88..3d3281e 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -113,23 +113,25 @@ static void omap5_pbias_config(struct mmc *mmc)
u32 value = 0;
 
value = readl((*ctrl)-control_pbias);
-   value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
-   value |= SDCARD_BIAS_HIZ_MODE;
+   value = ~SDCARD_PWRDNZ;
+   writel(value, (*ctrl)-control_pbias);
+   udelay(10); /* wait 10 us */
+   value = ~SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
 
-   palmas_mmc1_poweron_ldo();
+#if defined(CONFIG_DRA7XX)
+   tps659038_mmc1_poweron_ldo1();
+#else
+   palmas_mmc1_poweron_ldo9();
+#endif
 
value = readl((*ctrl)-control_pbias);
-   value = ~SDCARD_BIAS_HIZ_MODE;
-   value |= SDCARD_PBIASLITE_VMODE | SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ;
+   value |= SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
-
-   value = readl((*ctrl)-control_pbias);
-   if (value  (1  23)) {
-   value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
-   value |= SDCARD_BIAS_HIZ_MODE;
-   writel(value, (*ctrl)-control_pbias);
-   }
+   udelay(150); /* wait 150 us */
+   value |= SDCARD_PWRDNZ;
+   writel(value, (*ctrl)-control_pbias);
+   udelay(150); /* wait 150 us */
 }
 #endif
 
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..71c4bdc 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -28,23 +28,46 @@ void palmas_init_settings(void)
return;
 }
 
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
 {
u8 val = 0;
 
/* set LDO9 TWL6035 to 3V */
-   val = 0x2b; /* (3 -.9)*28 +1 */
+   val = LDO_VOLT_3V0;
 
-   if (palmas_i2c_write_u8(0x48, LDO9_VOLTAGE, val)) {
-   printf(twl6035: could not set LDO9 voltage.\n);
+   if (palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_VOLTAGE, val)) {
+   printf(twl603x: could not set LDO9 voltage.\n);
return 1;
}
 
/* TURN ON LDO9 */
-   val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+   val = LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
 
-   if (palmas_i2c_write_u8(0x48, LDO9_CTRL, val)) {
-   printf(twl6035: could not turn on LDO9.\n);
+   if (palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_CTRL, val)) {
+   printf(twl603x: could not turn on LDO9.\n);
+   return 1;
+   }
+
+   return 0;
+}
+
+int tps659038_mmc1_poweron_ldo1(void)
+{
+   u8 val = 0;
+
+   /* set LDO1 to 3V */
+   val = LDO_VOLT_3V0;
+
+   if (palmas_i2c_write_u8(TPS659038_CHIP_P1, LDO1_VOLTAGE, val)) {
+   printf(tps659038: could not set LDO1 voltage\n);
+   return 1;
+   }
+
+   /* TURN ON LDO1 */
+   val = LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+
+   if (palmas_i2c_write_u8(TPS659038_CHIP_P1, LDO1_CTRL, val)) {
+   printf(tps659038: could not turn on LDO1\n);
return 1;
}
 
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 83b91d1..ddf2ad4 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -238,6 +238,10 @@
 #define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
 #endif
 
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PALMAS_POWER
+#endif
+
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SPL_FRAMEWORK
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index ba81e30..f4a2d31 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ 

[U-Boot] [PATCH 1/1 RESEND] NET: Fix system hanging if NET device is not installed

[Jim Lin]

If we try to boot from NET device, NetInitLoop in net.c will be invoked.
If NET device is not installed, eth_get_dev() function will return
eth_current value, which is NULL.
When NetInitLoop is called, eth_get_dev-enetaddr will access
restricted memory area and therefore cause hanging.
This issue is found on Tegra30 Cardhu platform after adding
CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file.

Signed-off-by: Jim Lin ji...@nvidia.com
---
 net/net.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/net.c b/net/net.c
index df94789..7663b9c 100644
--- a/net/net.c
+++ b/net/net.c
@@ -271,7 +271,8 @@ static void NetInitLoop(void)
 #endif
env_changed_id = env_id;
}
-   memcpy(NetOurEther, eth_get_dev()-enetaddr, 6);
+   if (eth_get_dev())
+   memcpy(NetOurEther, eth_get_dev()-enetaddr, 6);
 
return;
 }
-- 
1.7.7

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

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lubomir Popov]

Hi Tom,

On 05/06/13 00:06, Tom Rini wrote:
 On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
 Hi Lokesh,

 Hi Lubomir,
 On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
 Hi Lokesh,

 On 30/05/13 16:19, Lokesh Vutla wrote:
 From: Balaji T K balaj...@ti.com

 add dra mmc pbias support and ldo1 power on

 Signed-off-by: Balaji T K balaj...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
   drivers/mmc/omap_hsmmc.c   |   26 ++
   drivers/power/palmas.c |   25 -
   include/configs/omap5_common.h |4 
   include/configs/omap5_uevm.h   |5 -
   include/palmas.h   |6 +-
   6 files changed, 49 insertions(+), 20 deletions(-)

 [snip]
 + /* set LDO9 TWL6035 to 3V */
 LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
 TPS659038), you should add some comment above.
 Ok ll add the comment.

 + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
 Why not use definitions for the voltage? You could take them from
 http://patchwork.ozlabs.org/patch/244103/ where some values are
 defined.
 Yes, Ill rebase this patch on top of your patch and use those defines.
 Please be aware that my above mentioned patch has not been reviewed/
 tested/acked/nacked/whatever by nobody (except possibly a quick look by
 Nishanth Menon, who had some objections). I wrote it when bringing up a
 custom OMAP5 board, and most probably it shall not go into mainline in
 its current form, if ever. I gave it only as an example of how things
 could be done cleaner. Feel free to use the code as you wish, but I'm
 afraid that applying it as a patch to your tree and basing upon it might
 run you into problems when you later sync with mainline.

 Tom, your opinion?
 
 OK, so at the time it was nothing will really use this code except test
 functions.  Looks like we have a use for mmc1_ldo9 code at least, so
 lets rework the first patch for adding that + cleanups wrt constants.
Well, I'm not quite sure that this LDO9 function would be the only one
used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
set to 'Forced PWM' mode in order to reduce board noise - there sure has
been a reason to do so and sacrifice converter efficiency. Therefore I
added similar functionality in my patch to the Palmas driver (and am
explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
as well, if hardware is designed such that the SD card socket has a
separate fixed 3.3 V supply which also powers the LDO9 input (the
uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
different and this does not apply.

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

Re: [U-Boot] [PATCH] video:lcd:cfb_console: cm_t35: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO

[Igor Grinberg]

Hi Robert,

On 06/04/13 21:11, Robert Winkler wrote:
 Adding Anatolij to the CC list.
 
 On Tue, Jun 4, 2013 at 8:10 AM, Robert Winkler
 robert.wink...@boundarydevices.com wrote:
 Hi Igor,

 On Mon, Jun 3, 2013 at 11:10 PM, Igor Grinberg grinb...@compulab.co.il 
 wrote:
 Hi Robert,

 On 06/03/13 20:20, Robert Winkler wrote:
 Also change splash_screen_prepare to a weak function.

 You should be able to make a commit message a bit better.
 Also, personally, I see here two functional changes and it would be better
 to separate them into two patches:
 1) Make the splash_screen_prepare() weak (I don't like this approach,
explanation below)
 2) Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO

 We have considered making the splash_screen_prepare() function weak
 in the past, but decided to make it a config option instead.
 This way it is documented in the README and is selectable in the
 board config.
 Once you change it to be weak, there is no point in the config option
 anymore... Personally, I don't like this approach.

 Wolfgang said as long as I was fixing the bug of SPLASH_SCREEN_PREPARE
 not working
 for CONFIG_VIDEO I should change it to a weak function so that's what I did.

 See the email here:
 http://lists.denx.de/pipermail/u-boot/2013-May/155478.html

Ok.
The major benefit of the construct (which Wolfgang wants to remove) is
clear code with no #ifdefs inside functions.
I don't have any special feelings for that construct, but I'd like to
keep #ifdefs out of any functions (the benefit).


 I agree with you about the pointlessness of the CONFIG option and I
 too like having
 it documented in the README.  That's the only reason I left the
 #ifdefs in at all because
 I didn't want to/didn't think I should remove the CONFIG altogether.

 I'm not sure what the solution is.

...
some thoughts below...




 Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
 ---
  board/compulab/cm_t35/cm_t35.c |  2 +-
  common/lcd.c   | 10 --
  drivers/video/cfb_console.c| 14 ++
  3 files changed, 19 insertions(+), 7 deletions(-)

 diff --git a/board/compulab/cm_t35/cm_t35.c 
 b/board/compulab/cm_t35/cm_t35.c
 index b0b80e5..95098af 100644
 --- a/board/compulab/cm_t35/cm_t35.c
 +++ b/board/compulab/cm_t35/cm_t35.c
 @@ -120,7 +120,7 @@ static inline int splash_load_from_nand(void)
  }
  #endif /* CONFIG_CMD_NAND */

 -int board_splash_screen_prepare(void)
 +int splash_screen_prepare(void)
  {
   char *env_splashimage_value;
   u32 bmp_load_addr;
 diff --git a/common/lcd.c b/common/lcd.c
 index edae835..90f1143 100644
 --- a/common/lcd.c
 +++ b/common/lcd.c
 @@ -1069,15 +1069,13 @@ int lcd_display_bitmap(ulong bmp_image, int x, int 
 y)
  #endif

  #ifdef CONFIG_SPLASH_SCREEN_PREPARE
 -static inline int splash_screen_prepare(void)
 -{
 - return board_splash_screen_prepare();
 -}
 -#else
 -static inline int splash_screen_prepare(void)
 +int __splash_screen_prepare(void)
  {
   return 0;
  }
 +
 +int splash_screen_prepare(void)
 + __attribute__ ((weak, alias(__splash_screen_prepare)));
  #endif

 You remove the #else statement, apparently you break the compilation for
 !CONFIG_SPLASH_SCREEN_PREPARE, as the below lcd_logo() function references
 the splash_screen_prepare() function.
 Also, this means you force the code to have the ugly #ifdefs inside
 functions - that is not really nice.


  static void *lcd_logo(void)
 diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
 index 0793f07..9180998 100644
 --- a/drivers/video/cfb_console.c
 +++ b/drivers/video/cfb_console.c
 @@ -1966,6 +1966,16 @@ static void plot_logo_or_black(void *screen, int 
 width, int x, int y, int black)
  #endif
  }

 +#ifdef CONFIG_SPLASH_SCREEN_PREPARE
 +int __splash_screen_prepare(void)
 +{
 + return 0;
 +}
 +
 +int splash_screen_prepare(void)
 + __attribute__ ((weak, alias(__splash_screen_prepare)));
 +#endif

 Why duplicate the above?
 Probably, just place it in a common location?
 I asked Wolfgang about this in the original thread but haven't heard
 back so I just submitted it
 like this with the thought that CONFIG_VIDEO and CONFIG_LCD are never
 used simultaneously and are
 designed not to be (I could easily be wrong about that).


 +
  static void *video_logo(void)
  {
   char info[128];
 @@ -1996,6 +2006,10 @@ static void *video_logo(void)
   s = getenv(splashimage);
   if (s != NULL) {

 +#ifdef CONFIG_SPLASH_SCREEN_PREPARE
 + splash_screen_prepare();
 +#endif

 These are the ugly #ifdefs, I was talking about...
 Agreed

 I would recommend to just move the splash_screen_prepare() function 
 definition
 to a common location and add the above function call (with no #ifdef 
 around).

 And keep the meaningless CONFIG?

While I was writing the above, I meant to keep the #ifdef ... #else ... #endif
construct.

So currently, after reading the link you've provided,
I can see two reasonable solutions:

1) Keep the 

Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write

[Jagan Teki]

On Wed, Jun 5, 2013 at 10:10 AM, Insop Song insop.s...@cohere.net wrote:
 Hi Jagan,

 Thank you for your feedback.

 -Original Message-
 From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
 Sent: Monday, June 03, 2013 10:31 PM
 To: Insop Song
 Cc: u-boot@lists.denx.de; york...@freescale.com
 Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A  add flag
 status check during SPI Flash write
 
  I've made a change and add spi_flash_cmd_wait_program to align with
 existing code structure.
  Please see the patch below.
  Erase is okay without checking, so I didn't add the check.

 No i see without the check in erase when i erase and read back i couldn't see
 0xff Please check.

 I've tested on the N25Q512A erase without the flag check went okay.
 However, adding the check to the erase would be safe, and I've tested erase 
 with flag status check.
 Here is the diff of this change. I will use the format-patch when we finalize 
 the change.

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 4240e9d..9cf5aaf 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -247,6 +247,10 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 
 offset, size_t len)
 if (ret)
 goto out;

 + ret = spi_flash_cmd_wait_program(flash, SPI_FLASH_PROG_TIMEOUT);
 + if (ret)
 + break;
 +
 ret = spi_flash_cmd_wait_ready(flash, 
 SPI_FLASH_PAGE_ERASE_TIMEOUT);
 if (ret)
 goto out;


 
  I am not sure I'd agree with you on that you are putting the device check 
  in
 spi_flash_cmd_poll_bit().
  I am more inclined to make the change at the level where we call
 spi_flash_cmd_poll_bit() if we have to distinguish per devices.

 spi_flash_cmd_poll_bit() is common call for poll for read_status, as write 
 call
 is common to all making changes to
 spi_flash_cmd_poll_bit() is valid i guess.
 Write call is a global which is used by
 so many user, i don't like to add the flag status there and make the 
 confusion
 user.


 To your comment on confusion to users, I agree on that.
 With that argument, your patch is better since it hides the flag status check.

 And how about this?  can we add flag_status_check flag somewhere, and if 
 the device is needed then we set the flag during device discovery.
 Then call the flag check function if the flag is set.
 I think this way might be more generic then what you did in your patch.

 What do you think?

 Thank you,

Can u just send pseudo code about your logic, i couldn't get u exactly sorry.

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

Re: [U-Boot] net, cpsw: disable gigabit support through plattform data

[Heiko Schocher]

Hello Mugunthan, Tom,

Am 04.06.2013 17:29, schrieb Mugunthan V N:
 On 6/4/2013 8:45 PM, Heiko Schocher wrote:
 Hello Wolfgang,

 Am 04.06.2013 17:00, schrieb Wolfgang Denk:
 Dear Heiko,

 In message 1370335914-14027-1-git-send-email...@denx.de you wrote:
 add possibility to disable gigabit support through
 plattform data. Current boards should not be affected
 through this patch.
 ...
 +  if (phy-speed == 1000) {
 +  if (priv-data.gigabit_en) {
 +  mac_control |= GIGABITEN;
 +  } else {
 +  /* Disable gigabit as it's non-functional */
 +  mac_control = ~GIGABITEN;
 +  phy-speed = 100;
 Is this reliable?  I mean, how do we know it's a 100 Mbps connection
 (and not for example a 10 Mbs one) ?
 Phy speed info will be read from phy status itself for configuring
 mac ctrl reg.
 Indeed. Anyway, I have to check, if this patch is necessary, as Tom
 noted ...

 bye,
 Heiko
 As Tom mentioned this patch is applicable only for initial samples
 as there was a issue with Gig mode packet transfer.
 Now there is no issue with having Gig enabled by default.

Indeed, ethernet works fine without this patch :-)

Sorry for the noise. I delete this patch in patchwork.

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm, arm335x: add watchdog support

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/05/2013 01:22 AM, Heiko Schocher wrote:
 Hello Tom,
 
 Am 04.06.2013 23:24, schrieb Tom Rini:
 On Tue, Jun 04, 2013 at 10:55:36AM +0200, Heiko Schocher wrote:
 
 Add TI OMAP 16xx  24xx/34xx 32KHz (non-secure) watchdog 
 support.
 
 Signed-off-by: Heiko Schocher h...@denx.de Cc: Albert Aribaud 
 albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com
 
 Reviewed-by: Tom Rini tr...@ti.com
 
 But this is also unused code right now.  Enabling on the 
 am335x_evm config is a good place-holder and easy for you to
 test I assume platform until you can also post the custom board
 you're working on.
 
 I repost this patch with the board support, ok?

OK, thanks.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRryzkAAoJENk4IS6UOR1WX0UP/jxsDh51DNxGlUEtqg03LxhR
FV4bN1yMrcFogeBacW3YIDhq0kgZ+afvxSo3yigExZt0FnWpnAUN1AD4W3fwtB4D
UyNWfmI0KIGyY0/N83hNX1ABtmdILr6eDZEf9xoNfNGh4IQZDGXgaAcgincwZ10d
HioI1cYOHRvMG/VZ4LFj7b5QrhSax2fm5dm51bq0ioII1qdfE4vV+bNgX271mPdB
hfV2XCVsB1wm7MuC1v8NdRDXUly5g2ARIcHq9smdVOiwHl94nS8KOiaM6QAcwB0R
wN/x/h6hYcDVXIrxLvVn+ZRYk96RzurywylNws4xQco7WHKISKTrsWXXmj+ecodX
DWVC1Dk+Ch/V/sJyf+1+p7ctg/PfA/P9VYqdjwrhoTrVTj+4Ds34qOwqW+cx0I+J
Eb5SbeTtjBzMoMWl9f11eJiQ7HqhR6qSijJ2HQlJgVOqMeBbpv1PKAdzRoGWVz2a
QsXUcALr1IkHzn4lKJ2qFDf+erZhTCyWOpeL4BTsqp3hSOJs1BxkRtanpZJU8tzj
9shXkwyCyzXMIxT98WmNB3+p5HaCMoQFOvebVSxTTx9jziuz8+Y9b9+xe7AAcZoU
yAA1a+DmZufkc2sygrC2XENWkEukLro1ir1ivi2sInpA6+i2iWv+YmBgdUpXZIjC
Q6zC5K0jO13kA2wmrY8P
=e8Ph
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm: dra7xx: Update the EXTRA_ENV_SETTINGS

[Dan Murphy]

On 06/04/2013 04:35 PM, Tom Rini wrote:
 On Tue, Jun 04, 2013 at 10:26:06AM -0500, Dan Murphy wrote:
 Update the EXTRA_ENV_SETTING for the dra7xx.
 The console needs to be set to ttyO0 and the
 findfdt needs to be updated to load the
 dra7xx-evm.dtb file.

 Signed-off-by: Dan Murphy dmur...@ti.com
 ---
 v2 - Updated with side bar maintainer comments.
  include/configs/omap5_common.h |   12 ++--
  1 files changed, 10 insertions(+), 2 deletions(-)

 diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
 index deb5e9f..c5061dd 100644
 --- a/include/configs/omap5_common.h
 +++ b/include/configs/omap5_common.h
 @@ -142,9 +142,15 @@
  #define PARTS_DEFAULT
  #endif
  
 +#ifdef CONFIG_DRA7XX
 +#define CONFIG_CONSOLE_DEV  ttyO0
 +#else
 +#define CONFIG_CONSOLE_DEV  ttyO2
 +#endif
 +
  #define CONFIG_EXTRA_ENV_SETTINGS \
  loadaddr=0x8200\0 \
 -console=ttyO2,115200n8\0 \
 +console= CONFIG_CONSOLE_DEV ,115200n8\0 \
 Sorry, when we chatted on IRC I was being a bit more literal than you
 did.  I want dra7xx_evm.h to have '#define CONSOLEDEV ttyO0' and
 omap5_uevm.h to have '#define CONSOLEDEV ttyO2' and omap5_common.h to
 have:
 console= CONSOLEDEV ,115200n8\0 \
OK I got it.  Change a comin.
 @@ -174,7 +180,9 @@
  bootz ${loadaddr} - ${fdtaddr}\0 \
  findfdt=\
  if test $board_name = omap5_uevm; then  \
 -setenv fdtfile omap5-uevm.dtb; fi;\0  \
 +setenv fdtfile omap5-uevm.dtb; fi;  \
 +if test $board_name = dra7xx; then  \
 +setenv fdtfile dra7-evm.dtb; fi;\0  \
 This part is fine, thanks.  If you've got time, add something like:
 if test -z $fdtfile; then
   echo WARNING: Could not determine device tree to use
 fi

 After testing I got the syntax right, thanks!


What does the -z do?  Could not find any info on that.

-- 
--
Dan Murphy

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

Re: [U-Boot] [PATCH v4 1/9] at91: Correct CONFIG_AUTOBOOT_PROMPT definition for pm9263

[Tom Rini]

On Wed, May 15, 2013 at 09:23:53AM -0700, Simon Glass wrote:

 This is not currently used, since autoboot is not enabled for this
 board, but the string is missing a parameter. Add it.
 
 
 Signed-off-by: Simon Glass s...@chromium.org

Along with the rest of the series, applied to u-boot/master, thanks!

-- 
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 v3 0/10] image: Reduce code duplication and refactor

[Tom Rini]

On Thu, May 16, 2013 at 04:53:18PM -0700, Simon Glass wrote:

 In creating a new feature[*] I found that the image code includes quite
 a bit of duplication in places. In particular the code to load a kernel,
 FDT and ramdisk is all fairly similar, but subtly different.
 
 This series introduces a new function fit_image_load() which loads an image
 from a FIT and supports the various features. For the bootstage updates,
 these are standardised so that each file has its own range and the events
 within that range have corresponding numbers. This means that the boot
 progress numbers will change slightly with this series.
 
 The image.c file is still very long. Rather than perpetuate the #ifdefs
 in the code I have split out the image.c code that is dependent on
 CONFIG_OF_LIBFDT into image-fdt.c.
 
 Several architectures have their own way of setting up a ramdisk and FDT
 for booting. An attempt is made here to unify these by providing a function
 image_setup_linux() to handle the overall task, and image_setup_fdt() to set
 up the FDT.
 
 For ARM, the bootm code is a maze of #ifdefs, which means that many boards
 compile the code differently and it takes longer to detect breakages. To get
 around this, some defines are added to ARM's bootm.h to permit the use of
 if() instead of #ifdef, making use of the compiler's dead code elimination.
 
 Also this series introduces a very basic test of image loading using sandbox.
 Some patches add bootm support for sandbox, and also a 'sb save' command to
 save memory to a host file (used to check that the bootm actually worked).
 
 A test program for sandbox is added as a basic sanity check of image loading
 as performed by bootm.
 
 * The new feature is support for FIT booting on x86, available in patchwork
 starting here:
 
 http://patchwork.ozlabs.org/patch/211526/
 
 Changes in v3:
 - Rebase without verified boot patches
 
 Changes in v2:
 - Add workaround for ELDK-4.2 to avoid cast warning
 - Put quotes around error when selected FIT config cannot be found
 - Correct definition of IMAGE_ENABLE_BEST_MATCH
 - Fix checkpatch checks about parenthesis alignment
 - Rebase on previous patches
 - Add workaround for ELDK-4.2 to avoid cast warning
 
 Simon Glass (10):
   bootstage: Introduce sub-IDs for use with image loading
   mkimage: Add map_sysmem() and IH_ARCH_DEFAULT to simplfy building
   image: Introduce fit_image_load() to load images from FITs
   image: Use fit_image_load() to load ramdisk
   image: Use fit_image_load() to load FDT
   sandbox: Adjust bootm command to work with sandbox
   image: Use fit_image_load() to load kernel
   sandbox: image: Adjust FIT image printing to work with sandbox
   bootstage: Remove unused entries related to kernel/ramdisk/fdt load
   sandbox: image: Create a test for loading FIT images
 
  common/cmd_bootm.c | 170 +++-
  common/image-fdt.c | 207 
  common/image-fit.c | 310 +---
  common/image.c | 122 ++
  include/bootstage.h|  51 +++---
  include/image.h| 105 +++-
  test/image/test-fit.py | 422 
 +
  tools/mkimage.h|  12 ++
  8 files changed, 846 insertions(+), 553 deletions(-)
  create mode 100755 test/image/test-fit.py

Applied to u-boot/master, thanks!

-- 
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] fdt: allow bootdelay to be specified via device tree

[Tom Rini]

On Tue, May 14, 2013 at 08:02:56AM -, Stephen Warren wrote:

 From: Stephen Warren swar...@nvidia.com
 
 This can be useful to force bootcmd to execute as soon as U-Boot has
 started.
 
 My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with
 an image to be written to device boot flash, with the DT config property
 bootcmd set to contain a command to write that image to flash. In this
 scenario, we don't want to allow any stale bootdelay value taken from
 the current flash content to affect how long it takes before the
 flashing process starts.
 
 Signed-off-by: Stephen Warren swar...@nvidia.com
 Acked-by: Simon Glass s...@chromium.org
 Acked-by: Gerald Van Baren vanba...@cideas.com

Applied to u-boot/master, thanks!

-- 
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] input: fix unaligned access in key_matrix_decode_fdt()

[Tom Rini]

On Wed, May 22, 2013 at 08:48:18AM -, Stephen Warren wrote:

 From: Stephen Warren swar...@nvidia.com
 
 Initialized character arrays on the stack can cause gcc to emit code that
 performs unaligned accessess. Make the data static to avoid this.
 
 Note that the unaligned accesses are made when copying data to prefix[] on
 the stack from .rodata. By making the data static, the copy is completely
 avoided. All explicitly written code treats the data as u8[], so will never
 cause any unaligned accesses.
 
 Signed-off-by: Stephen Warren swar...@nvidia.com
 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot/master, thanks!

-- 
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] disk: Fix possible out-of-bounds access in part_efi.c

[Tom Rini]

On Sun, May 19, 2013 at 12:53:34PM -, Marek Vasut wrote:

 Make sure to never access beyond bounds of either EFI partition name
 or DOS partition name. This situation is happening:
 
 part.h: disk_partition_t-name is 32-byte long
 part_efi.h: gpt_entry-partition_name is 36-bytes long
 
 The loop in part_efi.c copies over 36 bytes and thus accesses beyond
 the disk_partition_t-name .
 
 Fix this by picking the shortest of source and destination arrays and
 make sure the destination array is cleared so the trailing bytes are
 zeroed-out and don't cause issues with string manipulation.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Tom Rini tr...@ti.com
 Cc: Simon Glass s...@chromium.org

Applied to u-boot/master, thanks!

-- 
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] input: simplify key_matrix_decode_fdt()

[Tom Rini]

On Thu, May 23, 2013 at 12:09:57PM -, Stephen Warren wrote:

 From: Stephen Warren swar...@nvidia.com
 
 We know the exact property names that the code wants to process. Look
 these up directly with fdt_get_property(), rather than iterating over
 all properties within the node, and checking each property's name, in
 a convoluted fashion, against the expected name.
 
 Signed-off-by: Stephen Warren swar...@nvidia.com

Applied to u-boot/master, thanks!

-- 
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] common: board_f: Do not call board_postclk_init twice

[Tom Rini]

On Tue, May 21, 2013 at 09:08:09PM -, Masahiro Yamada wrote:

 The generic-board board_init_f function called board_postclk_init twice.
 
 The first one came from arch/arm/lib/board.c, while the second one
 from arch/powerpc/lib/board.c.
 
 This commit deletes the first occurrence.
 In addition, the second get_clocks call is moved after
 board_postclk_init in order to keep the function call order
 both for ARM and PowerPC.
 ARM board calles get_clocks function after board_postclk_init.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Applied to u-boot/master, thanks!

-- 
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 v2] arm: dra7xx: Update the EXTRA_ENV_SETTINGS

[Tom Rini]

On Wed, Jun 05, 2013 at 07:27:05AM -0500, Dan Murphy wrote:
 On 06/04/2013 04:35 PM, Tom Rini wrote:
  On Tue, Jun 04, 2013 at 10:26:06AM -0500, Dan Murphy wrote:
  Update the EXTRA_ENV_SETTING for the dra7xx.
  The console needs to be set to ttyO0 and the
  findfdt needs to be updated to load the
  dra7xx-evm.dtb file.
 
  Signed-off-by: Dan Murphy dmur...@ti.com
  ---
  v2 - Updated with side bar maintainer comments.
   include/configs/omap5_common.h |   12 ++--
   1 files changed, 10 insertions(+), 2 deletions(-)
 
  diff --git a/include/configs/omap5_common.h 
  b/include/configs/omap5_common.h
  index deb5e9f..c5061dd 100644
  --- a/include/configs/omap5_common.h
  +++ b/include/configs/omap5_common.h
  @@ -142,9 +142,15 @@
   #define PARTS_DEFAULT
   #endif
   
  +#ifdef CONFIG_DRA7XX
  +#define CONFIG_CONSOLE_DEVttyO0
  +#else
  +#define CONFIG_CONSOLE_DEVttyO2
  +#endif
  +
   #define CONFIG_EXTRA_ENV_SETTINGS \
 loadaddr=0x8200\0 \
  -  console=ttyO2,115200n8\0 \
  +  console= CONFIG_CONSOLE_DEV ,115200n8\0 \
  Sorry, when we chatted on IRC I was being a bit more literal than you
  did.  I want dra7xx_evm.h to have '#define CONSOLEDEV ttyO0' and
  omap5_uevm.h to have '#define CONSOLEDEV ttyO2' and omap5_common.h to
  have:
  console= CONSOLEDEV ,115200n8\0 \
 OK I got it.  Change a comin.
  @@ -174,7 +180,9 @@
 bootz ${loadaddr} - ${fdtaddr}\0 \
 findfdt=\
 if test $board_name = omap5_uevm; then  \
  -  setenv fdtfile omap5-uevm.dtb; fi;\0  \
  +  setenv fdtfile omap5-uevm.dtb; fi;  \
  +  if test $board_name = dra7xx; then  \
  +  setenv fdtfile dra7-evm.dtb; fi;\0  \
  This part is fine, thanks.  If you've got time, add something like:
  if test -z $fdtfile; then
echo WARNING: Could not determine device tree to use
  fi
 
  After testing I got the syntax right, thanks!
 
 
 What does the -z do?  Could not find any info on that.

If it works, it's like regular shell scripts, and we test that the
contents are empty (so, I forgot quotes, after double checking fedora's
arm-boot-config, if test -z $fdtfile ...)

-- 
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] dfu: make data buffer size configurable

[Tom Rini]

On Wed, Jun 05, 2013 at 06:53:53AM +0200, Heiko Schocher wrote:
 Hello Tom,
 
 Am 04.06.2013 22:04, schrieb Tom Rini:
  On Tue, Jun 04, 2013 at 11:22:54AM +0200, Heiko Schocher wrote:
  
  Dfu transfer uses a buffer before writing data to the
  raw storage device. Make the size (in bytes) of this buffer
  configurable.
  
  NAK.
 
 :-(
 
  +  CONFIG_SYS_DFU_DATA_BUF_SIZE
  +  Dfu transfer uses a buffer before writing data to the
  +  raw storage device. Make the size (in bytes) of this buffer
  +  configurable.
  +
 CONFIG_SYS_DFU_MAX_FILE_SIZE
 When updating files rather than the raw storage device,
 we use a static buffer to copy the file into and then write
  
  The point of the buffer being configurable is to allow for larger files,
  right?  We need to fix CONFIG_SYS_DFU_MAX_FILE_SIZE so that..
 
 In current code CONFIG_SYS_DFU_MAX_FILE_SIZE is not used in dfu_nand.c,

Nor anywhere else.  As I said in the DFU + UBI thread, there's a bug
here :)

 as if buffer is full, it is immediately flushed to nand.
 Also default value from CONFIG_SYS_DFU_MAX_FILE_SIZE is smaller (4MiB)
 as default value of CONFIG_SYS_DFU_DATA_BUF_SIZE (8MiB) ...

Right, and the commit that did it was about increasing the size of the
kernel that could be sent over.

 I used on my upcoming board port a CONFIG_SYS_DFU_DATA_BUF_SIZE from
 1MiB and that worked perfectly, when transferring a file  200MB.
 The default value from 8MiB sometimes caused an error on the host:
 
 []# date;dfu-util -a rootfs -D 
 dxr2-org/dxr2.xx-release-image-UNKNOWN-dxr2.ubi;date
 Di 28. Mai 14:20:44 CEST 2013
 dfu-util 0.5
 [...]
 Copying data from PC to DFU device
 Starting download: 
 [#dfu_download: 
 libusb_control_transfer returned -7
 Error during download
 
 Why we have a buffersize from 8MiB for raw writes, but a max file size
 from 4MiB only?

Then we need to poke around the code here a bit more and see what's
going on, and fix things so that we can both do larger (say, 8MiB)
filesystem transfers and not have dfu-util get mad sometimes.

  -#define DFU_DATA_BUF_SIZE (1024*1024*8)   /* 8 MiB */
  +#ifndef CONFIG_SYS_DFU_DATA_BUF_SIZE
  +#define CONFIG_SYS_DFU_DATA_BUF_SIZE  (1024*1024*8)   /* 8 
  MiB */
  +#endif
   #ifndef CONFIG_SYS_DFU_MAX_FILE_SIZE
   #define CONFIG_SYS_DFU_MAX_FILE_SIZE  (4  20)   /* 4 MiB */
   #endif
  
  We use one variable for both spots.  Or is there some case I'm missing
  where we need to buffer 8MiB at a time for raw writes?  In which case we
  still need to make CONFIG_SYS_DFU_MAX_FILE_SIZE be used :)
 
 I do not really know, why we have 2 defines here!

File size vs buffer size?  I'm not quite certain it was the right way to
go either.

-- 
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 v2 0/7] cleanup in the 'ifm AC14xx' board support

[Gerhard Sittig]

this change set adjusts the configuration of the 'ifm AC14xx' board
to get closer to mainline philosophy and slightly improves builtin
diagnostics and robustness after setup failure


changes in v2:
- address a potential NULL pointer dereference in the diagnostics
  code path as well (previously unhandled in mainline)
- split the previous convoluted v1 patch into a series of
  individual patches, each addressing one specific issue,
  to aid in the review process


Gerhard Sittig (7):
  ac14xx: fix a potential NULL deref in diagnostics
  ac14xx: cleanup comments in the board support
  ac14xx: minor improvement in diagnostics
  ac14xx: re-order the recovery condition checks
  ac14xx: remove obsolete board config items
  ac14xx: use the official product name everywhere
  ac14xx: rephrase network boot config for development

 board/ifm/ac14xx/ac14xx.c |   50 -
 include/configs/ac14xx.h  |   28 ++---
 2 files changed, 38 insertions(+), 40 deletions(-)

-- 
1.7.10.4

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

[U-Boot] [PATCH v2 1/7] ac14xx: fix a potential NULL deref in diagnostics

[Gerhard Sittig]

getenv() immediately after setenv() may perfectly legally return NULL, so
make sure to not deference an invalid pointer when creating diagnostic output

Signed-off-by: Gerhard Sittig g...@denx.de
---
 board/ifm/ac14xx/ac14xx.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index 7442591..f200b45 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -209,6 +209,7 @@ static int read_eeprom(void)
 int mac_read_from_eeprom(void)
 {
const u8 *mac;
+   const char *mac_txt;
 
if (read_eeprom()) {
printf(I2C EEPROM read failed.\n);
@@ -230,8 +231,11 @@ int mac_read_from_eeprom(void)
 
if (mac  is_valid_ether_addr(mac)) {
eth_setenv_enetaddr(ethaddr, mac);
-   printf(DIAG: %s() MAC value [%s]\n,
-   __func__, getenv(ethaddr));
+   mac_txt = getenv(ethaddr);
+   if (mac_txt)
+   printf(DIAG: MAC value [%s]\n, mac_txt);
+   else
+   printf(DIAG: failed to setup MAC env\n);
}
 
return 0;
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 3/7] ac14xx: minor improvement in diagnostics

[Gerhard Sittig]

- minor rewording of diagnostics output
- make diagnostics optional and off by default

Signed-off-by: Gerhard Sittig g...@denx.de
---
 board/ifm/ac14xx/ac14xx.c |   34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index d45b7b2..c8e88cc 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -23,6 +23,10 @@
 #include i2c.h
 #endif
 
+static int eeprom_diag;
+static int mac_diag;
+static int gpio_diag;
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static void gpio_configure(void)
@@ -126,8 +130,6 @@ static u32 gpio_querykbd(void)
 
 /* excerpt from the recovery's hw_info.h */
 
-static int eeprom_diag = 1;
-
 struct __attribute__ ((__packed__)) eeprom_layout {
charmagic[3];   /** 'ifm' */
u8  len[2]; /** content length without magic/len fields */
@@ -231,11 +233,13 @@ int mac_read_from_eeprom(void)
 
if (mac  is_valid_ether_addr(mac)) {
eth_setenv_enetaddr(ethaddr, mac);
-   mac_txt = getenv(ethaddr);
-   if (mac_txt)
-   printf(DIAG: MAC value [%s]\n, mac_txt);
-   else
-   printf(DIAG: failed to setup MAC env\n);
+   if (mac_diag) {
+   mac_txt = getenv(ethaddr);
+   if (mac_txt)
+   printf(DIAG: MAC value [%s]\n, mac_txt);
+   else
+   printf(DIAG: failed to setup MAC env\n);
+   }
}
 
return 0;
@@ -337,29 +341,31 @@ int misc_init_r(void)
 */
want_recovery = 0;
keys = gpio_querykbd();
-   printf(GPIO keyboard status [0x%08X]\n, keys);
+   if (gpio_diag)
+   printf(GPIO keyboard status [0x%02X]\n, keys);
if ((keys  GPIOKEY_BITS_RECOVERY) == GPIOKEY_BITS_RECOVERY) {
-   printf(GPIO keyboard requested RECOVERY\n);
+   printf(detected recovery request (keyboard)\n);
want_recovery = 1;
}
s = getenv(install_in_progress);
if ((s != NULL)  (*s != '\0')) {
-   printf(previous installation aborted, running RECOVERY\n);
+   printf(previous installation has not completed\n);
want_recovery = 1;
}
s = getenv(install_failed);
if ((s != NULL)  (*s != '\0')) {
-   printf(previous installation FAILED, running RECOVERY\n);
+   printf(previous installation has failed\n);
want_recovery = 1;
}
s = getenv(want_recovery);
if ((s != NULL)  (*s != '\0')) {
-   printf(running RECOVERY according to the request\n);
+   printf(detected recovery request (environment)\n);
want_recovery = 1;
}
-
-   if (want_recovery)
+   if (want_recovery) {
+   printf(enforced start of the recovery system\n);
setenv(bootcmd, run recovery);
+   }
 
/*
 * boot the recovery system without waiting; boot the
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 2/7] ac14xx: cleanup comments in the board support

[Gerhard Sittig]

fix typos, minor rephrasing, remove obsolete notes and TODO items

Signed-off-by: Gerhard Sittig g...@denx.de
---
 board/ifm/ac14xx/ac14xx.c |   10 ++
 include/configs/ac14xx.h  |5 ++---
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index f200b45..d45b7b2 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -37,7 +37,7 @@ static void gpio_configure(void)
 
/*
 * out_be32(gpioregs-gpdir, 0xC2293020);
-* workaround for a hardware affect: configure direction in pieces,
+* workaround for a hardware effect: configure direction in pieces,
 * setting all outputs at once drops the reset line too low and
 * makes us lose the MII connection (breaks ethernet for us)
 */
@@ -330,8 +330,7 @@ int misc_init_r(void)
gpio_configure();
 
/*
-* check the GPIO keyboard,
-* enforced start of the recovery when
+* enforce the start of the recovery system when
 * - the appropriate keys were pressed
 * - a previous installation was aborted or has failed
 * - some external software told us to
@@ -339,13 +338,8 @@ int misc_init_r(void)
want_recovery = 0;
keys = gpio_querykbd();
printf(GPIO keyboard status [0x%08X]\n, keys);
-   /* XXX insist in the _exact_ combination? */
if ((keys  GPIOKEY_BITS_RECOVERY) == GPIOKEY_BITS_RECOVERY) {
printf(GPIO keyboard requested RECOVERY\n);
-   /* XXX TODO
-* refine the logic to detect the first keypress, and
-* wait to recheck IF it was the recovery combination?
-*/
want_recovery = 1;
}
s = getenv(install_in_progress);
diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index 7cb10fb..5dbcba2 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -72,7 +72,7 @@
 #define CONFIG_SYS_MAX_RAM_SIZE0x2000
 
 /*
- * DDR Controller Configuration XXX TODO
+ * DDR Controller Configuration
  *
  * SYS_CFG:
  * [31:31] MDDRC Soft Reset:   Diabled
@@ -265,7 +265,6 @@
 
 /*
  * CS related parameters
- * TODO document these
  */
 /* CS0 Flash */
 #define CONFIG_SYS_CS0_CFG 0x00031110
@@ -506,7 +505,7 @@
 
 #define CONFIG_BOOTDELAY   2   /* -1 disables auto-boot */
 
-/* XXX TODO need to specify the builtin environment */
+/* the builtin environment and standard greeting */
 #define CONFIG_PREBOOT echo; \
echo Type \\\run flash_nfs\\\ to mount root filesystem over NFS; \
echo
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 6/7] ac14xx: use the official product name everywhere

[Gerhard Sittig]

remove remaining k6 code names, switch to the official 'ac14xx' name

Signed-off-by: Gerhard Sittig g...@denx.de
---
 include/configs/ac14xx.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index e06e9ea..fcb56f4 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -507,13 +507,13 @@
 #define CONFIG_EXTRA_ENV_SETTINGS_DEVEL
\
muster_nr=00\0\
fromram=run ramargs addip addtty; \
-   tftp ${fdt_addr_r} k6m2/ac14xx.dtb-${muster_nr};  \
-   tftp ${kernel_addr_r} k6m2/uImage-${muster_nr};   \
-   tftp ${ramdisk_addr_r} k6m2/uFS-${muster_nr}; \
+   tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr};\
+   tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; \
+   tftp ${ramdisk_addr_r} ac14xx/uFS-${muster_nr};   \
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0 \
fromnfs=run nfsargs addip addtty; \
-   tftp ${fdt_addr_r} k6m2/ac14xx.dtb-${muster_nr};  \
-   tftp ${kernel_addr_r} k6m2/uImage-${muster_nr};   \
+   tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr};\
+   tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; \
bootm ${kernel_addr_r} - ${fdt_addr_r}\0  \
fromflash=run nfsargs addip addtty;   \
bootm fc02 - fc00\0   \
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 4/7] ac14xx: re-order the recovery condition checks

[Gerhard Sittig]

re-order the conditions which make the recovery system startup: combine
those conditions which were explicitly initiated (key press, software
request) and those which post-process error conditions (installer issues)

Signed-off-by: Gerhard Sittig g...@denx.de
---
 board/ifm/ac14xx/ac14xx.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index c8e88cc..dc2aff0 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -336,8 +336,8 @@ int misc_init_r(void)
/*
 * enforce the start of the recovery system when
 * - the appropriate keys were pressed
-* - a previous installation was aborted or has failed
 * - some external software told us to
+* - a previous installation was aborted or has failed
 */
want_recovery = 0;
keys = gpio_querykbd();
@@ -347,6 +347,11 @@ int misc_init_r(void)
printf(detected recovery request (keyboard)\n);
want_recovery = 1;
}
+   s = getenv(want_recovery);
+   if ((s != NULL)  (*s != '\0')) {
+   printf(detected recovery request (environment)\n);
+   want_recovery = 1;
+   }
s = getenv(install_in_progress);
if ((s != NULL)  (*s != '\0')) {
printf(previous installation has not completed\n);
@@ -357,11 +362,6 @@ int misc_init_r(void)
printf(previous installation has failed\n);
want_recovery = 1;
}
-   s = getenv(want_recovery);
-   if ((s != NULL)  (*s != '\0')) {
-   printf(detected recovery request (environment)\n);
-   want_recovery = 1;
-   }
if (want_recovery) {
printf(enforced start of the recovery system\n);
setenv(bootcmd, run recovery);
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 7/7] ac14xx: rephrase network boot config for development

[Gerhard Sittig]

- remove the builtin 'rootpath' spec (according to U-Boot project
  policy) and require user provided environments to contain these
- rephrase the evaluation of the 'muster_nr' approach which allows to
  quickly switch among several network boot setups (make the setting
  transparent when empty, resulting in default DULG behaviour)
- reduce the ARP timeout for faster network boot

Signed-off-by: Gerhard Sittig g...@denx.de
---
 include/configs/ac14xx.h |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index fcb56f4..381bcdd 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -505,15 +505,15 @@
echo
 
 #define CONFIG_EXTRA_ENV_SETTINGS_DEVEL
\
-   muster_nr=00\0\
+   muster_nr=-00\0   \
fromram=run ramargs addip addtty; \
-   tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr};\
-   tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; \
-   tftp ${ramdisk_addr_r} ac14xx/uFS-${muster_nr};   \
+   tftp ${fdt_addr_r} ac14xx/ac14xx.dtb${muster_nr}; \
+   tftp ${kernel_addr_r} ac14xx/uImage${muster_nr};  \
+   tftp ${ramdisk_addr_r} ac14xx/uFS${muster_nr};\
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0 \
fromnfs=run nfsargs addip addtty; \
-   tftp ${fdt_addr_r} ac14xx/ac14xx.dtb-${muster_nr};\
-   tftp ${kernel_addr_r} ac14xx/uImage-${muster_nr}; \
+   tftp ${fdt_addr_r} ac14xx/ac14xx.dtb${muster_nr}; \
+   tftp ${kernel_addr_r} ac14xx/uImage${muster_nr};  \
bootm ${kernel_addr_r} - ${fdt_addr_r}\0  \
fromflash=run nfsargs addip addtty;   \
bootm fc02 - fc00\0   \
@@ -541,12 +541,11 @@
u-boot=ac14xx/u-boot.bin\0\
bootfile=ac14xx/uImage\0  \
fdtfile=ac14xx/ac14xx.dtb\0   \
-   rootpath=/opt/eldk/ppc_6xx\n  \
netdev=eth0\0 \
consdev=ttyPSC0\0 \
hostname=ac14xx\0 \
nfsargs=setenv bootargs root=/dev/nfs rw  \
-   nfsroot=${serverip}:${rootpath}-${muster_nr}\0\
+   nfsroot=${serverip}:${rootpath}${muster_nr}\0 \
ramargs=setenv bootargs root=/dev/ram rw\0\
addip=setenv bootargs ${bootargs} \
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}  \
@@ -576,6 +575,8 @@
 
 #define CONFIG_BOOTCOMMAND run production
 
+#define CONFIG_ARP_TIMEOUT 200UL
+
 #define CONFIG_FIT 1
 #define CONFIG_OF_LIBFDT   1
 #define CONFIG_OF_BOARD_SETUP  1
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 5/7] ac14xx: remove obsolete board config items

[Gerhard Sittig]

- use the default baudrate table for serial communication
- remove hostname/boofile/rootpath defines which were not referenced elsewhere

Signed-off-by: Gerhard Sittig g...@denx.de
---
 include/configs/ac14xx.h |6 --
 1 file changed, 6 deletions(-)

diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h
index 5dbcba2..e06e9ea 100644
--- a/include/configs/ac14xx.h
+++ b/include/configs/ac14xx.h
@@ -330,8 +330,6 @@
 #endif
 
 #define CONFIG_BAUDRATE115200  /* ... at 115200 bps */
-#define CONFIG_SYS_BAUDRATE_TABLE  \
-   {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 115200}
 
 #define CONSOLE_FIFO_TX_SIZE   FIFOC_PSC3_TX_SIZE
 #define CONSOLE_FIFO_TX_ADDR   FIFOC_PSC3_TX_ADDR
@@ -496,10 +494,6 @@
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_TIMESTAMP
 
-#define CONFIG_HOSTNAMEac14xx
-#define CONFIG_BOOTFILEac14xx/uImage
-#define CONFIG_ROOTPATH/opt/eldk/ppc_6xx
-
 /* default load addr for tftp and bootm */
 #define CONFIG_LOADADDR40
 
-- 
1.7.10.4

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

Re: [U-Boot] [u-boot] spi/arm-pl022: Add support for ARM PL022 spi controller

[Armando Visconti]

On 06/03/2013 12:10 PM, Jagan Teki wrote:

I completely lost the original thread... I will re-start from V3...

Pls discard this noisy thread,


Please check the below thread for earlier v3
http://patchwork.ozlabs.org/patch/205814/




Thx Jagan,

I have a v4 ready, where I just corrected the checkpatch errors.

Nevertheless, I failed to find your comments over the v3.
Can you possibly send to me the link to the discussion thread?

Thx,
Arm



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

[U-Boot] Please pull u-boot-ti/master

[Tom Rini]

Hello,

The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:

  arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)

are available in the git repository at:

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

for you to fetch changes up to 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674:

  am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c 
(2013-06-05 08:46:49 -0400)


Tom Rini (3):
  omap-common/hwinit-common.c: Mark omap_rev_string as static
  am33xx: Correct NON_SECURE_SRAM_START/END
  am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c

 arch/arm/cpu/armv7/omap-common/boot-common.c   |   39 
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   38 +--
 arch/arm/include/asm/arch-am33xx/omap.h|4 +--
 arch/arm/include/asm/arch-am33xx/sys_proto.h   |1 +
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 board/isee/igep0033/board.c|9 ++
 board/phytec/pcm051/board.c|9 ++
 board/ti/am335x/board.c|9 ++
 board/ti/ti814x/evm.c  |9 ++
 include/configs/am335x_evm.h   |   10 --
 include/configs/igep0033.h |   10 --
 include/configs/pcm051.h   |   10 --
 13 files changed, 105 insertions(+), 45 deletions(-)

-- 
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] [U-BOOT] [PATCH] arm: da830: moved pinmux configurations to the arch tree

[Tom Rini]

On Thu, May 30, 2013 at 01:25:11PM +0530, Vishwanathrao Badarkhe, Manish wrote:

 Move pinmux configurations for the DA830 SoCs from board file
 to the arch tree so that it can be used for all da830 based devices.
 Also, avoids duplicate pinmuxing in case of NAND.
 
 Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com

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

Re: [U-Boot] arm, arm335x: add watchdog support

[Michael Trimarchi]

Hi

On Jun 4, 2013 10:55 AM, Heiko Schocher h...@denx.de wrote:

 Add TI OMAP 16xx  24xx/34xx 32KHz (non-secure) watchdog support.

 Signed-off-by: Heiko Schocher h...@denx.de
 Cc: Albert Aribaud albert.u.b...@aribaud.net
 Cc: Tom Rini tr...@ti.com
 ---
  arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
  drivers/watchdog/Makefile  |   1 +
  drivers/watchdog/omap_wdt.c| 115
+
  3 Dateien geändert, 136 Zeilen hinzugefügt(+)
  create mode 100644 drivers/watchdog/omap_wdt.c

 diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
 index 3d3a7c8..fb44654 100644
 --- a/arch/arm/include/asm/arch-am33xx/cpu.h
 +++ b/arch/arm/include/asm/arch-am33xx/cpu.h
 @@ -61,6 +61,26 @@
  #define PRM_RSTCTRL_RESET  0x01
  #define PRM_RSTST_WARM_RESET_MASK  0x232

 +/*
 + * Watchdog:
 + * Using the prescaler, the OMAP watchdog could go for many
 + * months before firing.  These limits work without scaling,
 + * with the 60 second default assumed by most tools and docs.
 + */
 +#define TIMER_MARGIN_MAX   (24 * 60 * 60)  /* 1 day */
 +#define TIMER_MARGIN_DEFAULT   60  /* 60 secs */
 +#define TIMER_MARGIN_MIN   1
 +
 +#define PTV0   /* prescale */
 +#define GET_WLDR_VAL(secs) (0x - ((secs) * (32768/(1PTV)))
+ 1)
 +#define WDT_WWPS_PEND_WCLR BIT(0)
 +#define WDT_WWPS_PEND_WLDR BIT(2)
 +#define WDT_WWPS_PEND_WTGR BIT(3)
 +#define WDT_WWPS_PEND_WSPR BIT(4)
 +
 +#define WDT_WCLR_PRE   BIT(5)
 +#define WDT_WCLR_PTV_OFF   2
 +
  #ifndef __KERNEL_STRICT_NAMES
  #ifndef __ASSEMBLY__
  struct gpmc_cs {
 diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
 index d57578d..46adc42 100644
 --- a/drivers/watchdog/Makefile
 +++ b/drivers/watchdog/Makefile
 @@ -34,6 +34,7 @@ COBJS-$(CONFIG_TNETV107X_WATCHDOG) += tnetv107x_wdt.o
  COBJS-$(CONFIG_S5P)   += s5p_wdt.o
  COBJS-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
  COBJS-$(CONFIG_BFIN_WATCHDOG)  += bfin_wdt.o
 +COBJS-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o

  COBJS  := $(COBJS-y)
  SRCS   := $(COBJS:.o=.c)
 diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
 new file mode 100644
 index 000..dc4df98
 --- /dev/null
 +++ b/drivers/watchdog/omap_wdt.c
 @@ -0,0 +1,115 @@
 +/*
 + * omap_wdt.c
 + *
 + * (C) Copyright 2013
 + * Heiko Schocher, DENX Software Engineering, h...@denx.de.
 + *
 + * Based on:
 + *
 + * Watchdog driver for the TI OMAP 16xx  24xx/34xx 32KHz (non-secure)
watchdog
 + *
 + * Author: MontaVista Software, Inc.
 + *  gda...@mvista.com or sou...@mvista.com
 + *
 + * 2003 (c) MontaVista Software, Inc. This file is licensed under the
 + * terms of the GNU General Public License version 2. This program is
 + * licensed as is without any warranty of any kind, whether express
 + * or implied.
 + *
 + * History:
 + *
 + * 20030527: George G. Davis gda...@mvista.com
 + * Initially based on
linux-2.4.19-rmk7-pxa1/drivers/char/sa1100_wdt.c
 + * (c) Copyright 2000 Oleg Drokin gr...@crimea.edu
 + * Based on SoftDog driver by Alan Cox a...@lxorguk.ukuu.org.uk
 + *
 + * Copyright (c) 2004 Texas Instruments.
 + * 1. Modified to support OMAP1610 32-KHz watchdog timer
 + * 2. Ported to 2.6 kernel
 + *
 + * Copyright (c) 2005 David Brownell
 + * Use the driver model and standard identifiers; handle bigger
timeouts.
 + */
 +
 +#include common.h
 +#include watchdog.h
 +#include asm/arch/hardware.h
 +#include asm/io.h
 +#include asm/processor.h
 +#include asm/arch/cpu.h
 +
 +/* Hardware timeout in seconds */
 +#define WDT_HW_TIMEOUT 60
 +
 +static unsigned int wdt_trgr_pattern = 0x1234;
 +
 +void hw_watchdog_reset(void)
 +{
 +   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
 +
 +   /* wait for posted write to complete */
 +   while ((readl(wdt-wdtwwps))  WDT_WWPS_PEND_WTGR)
 +   ;
 +
 +   wdt_trgr_pattern = ~wdt_trgr_pattern;
 +   writel(wdt_trgr_pattern, wdt-wdtwtgr);
 +
 +   /* wait for posted write to complete */
 +   while ((readl(wdt-wdtwwps)  WDT_WWPS_PEND_WTGR))
 +   ;
 +}
 +

I think that this patch has some problem because watchdog reset is in getc
code. Did you try to paste very long string when it is enabled? You need to
avoid reset when it is not needed

Michael

 +static int omap_wdt_set_timeout(unsigned int timeout)
 +{
 +   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
 +   u32 pre_margin = GET_WLDR_VAL(timeout);
 +
 +   /* just count up at 32 KHz */
 +   while (readl(wdt-wdtwwps)  WDT_WWPS_PEND_WLDR)
 +   ;
 +
 +   writel(pre_margin, wdt-wdtwldr);
 +   while (readl(wdt-wdtwwps)  WDT_WWPS_PEND_WLDR)
 +   ;
 +
 +   return 0;
 +}
 +
 +void hw_watchdog_init(void)
 +{
 +   struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
 +
 +   /* initialize prescaler */
 +   while (readl(wdt-wdtwwps)  

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Tom Rini]

On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote:

 Hi Tom,
 
 On 05/06/13 00:06, Tom Rini wrote:
  On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
  Hi Lokesh,
 
  Hi Lubomir,
  On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
  Hi Lokesh,
 
  On 30/05/13 16:19, Lokesh Vutla wrote:
  From: Balaji T K balaj...@ti.com
 
  add dra mmc pbias support and ldo1 power on
 
  Signed-off-by: Balaji T K balaj...@ti.com
  Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
  ---
arch/arm/include/asm/arch-omap5/omap.h |3 ++-
drivers/mmc/omap_hsmmc.c   |   26 
  ++
drivers/power/palmas.c |   25 
  -
include/configs/omap5_common.h |4 
include/configs/omap5_uevm.h   |5 -
include/palmas.h   |6 +-
6 files changed, 49 insertions(+), 20 deletions(-)
 
  [snip]
  +   /* set LDO9 TWL6035 to 3V */
  LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
  TPS659038), you should add some comment above.
  Ok ll add the comment.
 
  +   val = 0x2b; /* (3 - 0.9) * 20 + 1 */
  Why not use definitions for the voltage? You could take them from
  http://patchwork.ozlabs.org/patch/244103/ where some values are
  defined.
  Yes, Ill rebase this patch on top of your patch and use those defines.
  Please be aware that my above mentioned patch has not been reviewed/
  tested/acked/nacked/whatever by nobody (except possibly a quick look by
  Nishanth Menon, who had some objections). I wrote it when bringing up a
  custom OMAP5 board, and most probably it shall not go into mainline in
  its current form, if ever. I gave it only as an example of how things
  could be done cleaner. Feel free to use the code as you wish, but I'm
  afraid that applying it as a patch to your tree and basing upon it might
  run you into problems when you later sync with mainline.
 
  Tom, your opinion?
  
  OK, so at the time it was nothing will really use this code except test
  functions.  Looks like we have a use for mmc1_ldo9 code at least, so
  lets rework the first patch for adding that + cleanups wrt constants.
 Well, I'm not quite sure that this LDO9 function would be the only one
 used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
 set to 'Forced PWM' mode in order to reduce board noise - there sure has
 been a reason to do so and sacrifice converter efficiency. Therefore I
 added similar functionality in my patch to the Palmas driver (and am
 explicitly calling it in my board init).
 The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
 as well, if hardware is designed such that the SD card socket has a
 separate fixed 3.3 V supply which also powers the LDO9 input (the
 uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
 different and this does not apply.

OK, lets see.  That so lets keep your patch as-is, since we've now got
-ffunction-sections/-fdata-sections/--gc-sections on ARM for main
U-Boot, these small things won't hurt like they used to.

-- 
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] dfu: make data buffer size configurable

[Heiko Schocher]

Hello Tom,

Am 05.06.2013 14:43, schrieb Tom Rini:
 On Wed, Jun 05, 2013 at 06:53:53AM +0200, Heiko Schocher wrote:
 Hello Tom,

 Am 04.06.2013 22:04, schrieb Tom Rini:
 On Tue, Jun 04, 2013 at 11:22:54AM +0200, Heiko Schocher wrote:
[...]
 +  CONFIG_SYS_DFU_DATA_BUF_SIZE
 +  Dfu transfer uses a buffer before writing data to the
 +  raw storage device. Make the size (in bytes) of this buffer
 +  configurable.
 +
CONFIG_SYS_DFU_MAX_FILE_SIZE
When updating files rather than the raw storage device,
we use a static buffer to copy the file into and then write

 The point of the buffer being configurable is to allow for larger files,
 right?  We need to fix CONFIG_SYS_DFU_MAX_FILE_SIZE so that..

 In current code CONFIG_SYS_DFU_MAX_FILE_SIZE is not used in dfu_nand.c,
 
 Nor anywhere else.  As I said in the DFU + UBI thread, there's a bug
 here :)

CONFIG_SYS_DFU_MAX_FILE_SIZE is used in ./drivers/dfu/dfu_mmc.c ...

 as if buffer is full, it is immediately flushed to nand.
 Also default value from CONFIG_SYS_DFU_MAX_FILE_SIZE is smaller (4MiB)
 as default value of CONFIG_SYS_DFU_DATA_BUF_SIZE (8MiB) ...
 
 Right, and the commit that did it was about increasing the size of the
 kernel that could be sent over.

Hmm.. the CONFIG_SYS_DFU_DATA_BUF_SIZE limits not the size of
a file that could be loaded into a partition. It specifies
only the size of one chunk, that get burned into the raw nand ...

And this should be a configurable size ...

 I used on my upcoming board port a CONFIG_SYS_DFU_DATA_BUF_SIZE from
 1MiB and that worked perfectly, when transferring a file  200MB.
 The default value from 8MiB sometimes caused an error on the host:

 []# date;dfu-util -a rootfs -D 
 dxr2-org/dxr2.xx-release-image-UNKNOWN-dxr2.ubi;date
 Di 28. Mai 14:20:44 CEST 2013
 dfu-util 0.5
 [...]
 Copying data from PC to DFU device
 Starting download: 
 [#dfu_download: 
 libusb_control_transfer returned -7
 Error during download

 Why we have a buffersize from 8MiB for raw writes, but a max file size
 from 4MiB only?
 
 Then we need to poke around the code here a bit more and see what's
 going on, and fix things so that we can both do larger (say, 8MiB)
 filesystem transfers and not have dfu-util get mad sometimes.

Timeout in libusb_control_transfer while the target writes
the 8MiB into the nand ... ?

I try to find out something ...

 -#define DFU_DATA_BUF_SIZE (1024*1024*8)   /* 8 MiB */
 +#ifndef CONFIG_SYS_DFU_DATA_BUF_SIZE
 +#define CONFIG_SYS_DFU_DATA_BUF_SIZE  (1024*1024*8)   /* 8 
 MiB */
 +#endif
  #ifndef CONFIG_SYS_DFU_MAX_FILE_SIZE
  #define CONFIG_SYS_DFU_MAX_FILE_SIZE  (4  20)   /* 4 MiB */
  #endif

 We use one variable for both spots.  Or is there some case I'm missing
 where we need to buffer 8MiB at a time for raw writes?  In which case we
 still need to make CONFIG_SYS_DFU_MAX_FILE_SIZE be used :)

 I do not really know, why we have 2 defines here!
 
 File size vs buffer size?  I'm not quite certain it was the right way to
 go either.

Yeah, but why is the file size  buffer size as default?

In dfu_mmc:
If raw partition, if dfu_buf (size of CONFIG_SYS_DFU_DATA_BUF_SIZE)
full - write it to the mmc. Same for nand.

If FAT or EXT4 partition (mmc only), write the dfu_buffer through
mmc_file_buffer() to dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE] ...
this seems buggy to me, but maybe I oversee something, I could not
try it ... and if the hole file is transfered, the dfu_file_buf
gets flushed to the partition ...

The CONFIG_SYS_DFU_MAX_FILE_SIZE is only needed as we can only
write a complete image to FAT, EXT4 (also UBI) partitions, I think.

So we have in the dfu subsystem following problems:

a) we have no common API to add image types. Currently
   all dfu_{device_type} has to program it.
b) we have no possibility to write image types (FAT, EXT4 or
   UBI) in chunks - CONFIG_SYS_DFU_MAX_FILE_SIZE introduced
c) CONFIG_SYS_DFU_DATA_BUF_SIZE  CONFIG_SYS_DFU_MAX_FILE_SIZE
   which is in my eyes buggy ...
d) sporadic problems with CONFIG_SYS_DFU_DATA_BUF_SIZE = 8MiB
   Currently i get always an error ... try to find out why ...

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm, arm335x: add watchdog support

[Heiko Schocher]

Hello Michael,

Am 05.06.2013 15:31, schrieb Michael Trimarchi:
 Hi
 
 On Jun 4, 2013 10:55 AM, Heiko Schocher h...@denx.de 
 mailto:h...@denx.de wrote:

 Add TI OMAP 16xx  24xx/34xx 32KHz (non-secure) watchdog support.

 Signed-off-by: Heiko Schocher h...@denx.de mailto:h...@denx.de
 Cc: Albert Aribaud albert.u.b...@aribaud.net 
 mailto:albert.u.b...@aribaud.net
 Cc: Tom Rini tr...@ti.com mailto:tr...@ti.com
 ---
  arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
  drivers/watchdog/Makefile  |   1 +
  drivers/watchdog/omap_wdt.c| 115 
 +
  3 Dateien geändert, 136 Zeilen hinzugefügt(+)
  create mode 100644 drivers/watchdog/omap_wdt.c
[...]
 diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
 new file mode 100644
 index 000..dc4df98
 --- /dev/null
 +++ b/drivers/watchdog/omap_wdt.c
 @@ -0,0 +1,115 @@
[...]
 +   /* wait for posted write to complete */
 +   while ((readl(wdt-wdtwwps)  WDT_WWPS_PEND_WTGR))
 +   ;
 +}
 +
 
 I think that this patch has some problem because watchdog reset is in getc 
 code. Did you try to paste very long string when it is enabled? You need to
 avoid reset when it is not needed

I think, I do not understand you ... this is for all watchdogs
the case ...

I currently pasted a 500 bytes long string, seeing no problems
with the watchdog...

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT] [PATCH] arm: da830: moved pinmux configurations to the arch tree

[Christian Riesch]

On 2013-05-30 09:55, Vishwanathrao Badarkhe, Manish wrote:

Move pinmux configurations for the DA830 SoCs from board file
to the arch tree so that it can be used for all da830 based devices.
Also, avoids duplicate pinmuxing in case of NAND.

Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com


Acked-by: Christian Riesch christian.rie...@omicron.at

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

Re: [U-Boot] arm, arm335x: add watchdog support

[Michael Trimarchi]

Hi

On Jun 5, 2013 4:17 PM, Heiko Schocher h...@denx.de wrote:

 Hello Michael,

 Am 05.06.2013 15:31, schrieb Michael Trimarchi:
  Hi
 
  On Jun 4, 2013 10:55 AM, Heiko Schocher h...@denx.de 
  mailto:h...@denx.de
wrote:
 
  Add TI OMAP 16xx  24xx/34xx 32KHz (non-secure) watchdog support.
 
  Signed-off-by: Heiko Schocher h...@denx.de mailto:h...@denx.de
  Cc: Albert Aribaud albert.u.b...@aribaud.net mailto:
albert.u.b...@aribaud.net
  Cc: Tom Rini tr...@ti.com mailto:tr...@ti.com
  ---
   arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
   drivers/watchdog/Makefile  |   1 +
   drivers/watchdog/omap_wdt.c| 115
+
   3 Dateien geändert, 136 Zeilen hinzugefügt(+)
   create mode 100644 drivers/watchdog/omap_wdt.c
 [...]
  diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
  new file mode 100644
  index 000..dc4df98
  --- /dev/null
  +++ b/drivers/watchdog/omap_wdt.c
  @@ -0,0 +1,115 @@
 [...]
  +   /* wait for posted write to complete */
  +   while ((readl(wdt-wdtwwps)  WDT_WWPS_PEND_WTGR))
  +   ;
  +}
  +
 
  I think that this patch has some problem because watchdog reset is in
getc code. Did you try to paste very long string when it is enabled? You
need to
  avoid reset when it is not needed

 I think, I do not understand you ... this is for all watchdogs
 the case ...

 I currently pasted a 500 bytes long string, seeing no problems
 with the watchdog...


OK, maybe was a problem of my version. I have done the same driver 2 month
ago and tested on omap3. I optimize the watchdog reset using time delaying.
BTW if it works I have no other comments. Sorry for the noise

Michael

 bye,
 Heiko
 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm, arm335x: add watchdog support

[Heiko Schocher]

Hello Michael,

Am 05.06.2013 16:21, schrieb Michael Trimarchi:
 Hi
 
 On Jun 5, 2013 4:17 PM, Heiko Schocher h...@denx.de mailto:h...@denx.de 
 wrote:

 Hello Michael,

 Am 05.06.2013 15:31, schrieb Michael Trimarchi:
  Hi
 
  On Jun 4, 2013 10:55 AM, Heiko Schocher h...@denx.de 
  mailto:h...@denx.de mailto:h...@denx.de mailto:h...@denx.de wrote:
 
  Add TI OMAP 16xx  24xx/34xx 32KHz (non-secure) watchdog support.
 
  Signed-off-by: Heiko Schocher h...@denx.de mailto:h...@denx.de 
  mailto:h...@denx.de mailto:h...@denx.de
  Cc: Albert Aribaud albert.u.b...@aribaud.net 
  mailto:albert.u.b...@aribaud.net mailto:albert.u.b...@aribaud.net
 mailto:albert.u.b...@aribaud.net
  Cc: Tom Rini tr...@ti.com mailto:tr...@ti.com mailto:tr...@ti.com 
  mailto:tr...@ti.com
  ---
   arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
   drivers/watchdog/Makefile  |   1 +
   drivers/watchdog/omap_wdt.c| 115 
  +
   3 Dateien geändert, 136 Zeilen hinzugefügt(+)
   create mode 100644 drivers/watchdog/omap_wdt.c
 [...]
  diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
  new file mode 100644
  index 000..dc4df98
  --- /dev/null
  +++ b/drivers/watchdog/omap_wdt.c
  @@ -0,0 +1,115 @@
 [...]
  +   /* wait for posted write to complete */
  +   while ((readl(wdt-wdtwwps)  WDT_WWPS_PEND_WTGR))
  +   ;
  +}
  +
 
  I think that this patch has some problem because watchdog reset is in getc 
  code. Did you try to paste very long string when it is enabled? You need to
  avoid reset when it is not needed

 I think, I do not understand you ... this is for all watchdogs
 the case ...

 I currently pasted a 500 bytes long string, seeing no problems
 with the watchdog...

 
 OK, maybe was a problem of my version. I have done the same driver 2 month 
 ago and tested on omap3. I optimize the watchdog reset using time delaying.
 BTW if it works I have no other comments. Sorry for the noise

Maybe you have a chance to try this patch on your hw?

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] arm: dra7xx: Update the EXTRA_ENV_SETTINGS

[Dan Murphy]

Update the EXTRA_ENV_SETTING for the dra7xx.
The console needs to be set to ttyO0 and the
findfdt needs to be updated to load the
dra7xx-evm.dtb file.

Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Updated based on comments - http://patchwork.ozlabs.org/patch/248687/
v2 - Updated with side bar maintainer comments.
 include/configs/dra7xx_evm.h   |2 ++
 include/configs/omap5_common.h |8 ++--
 include/configs/omap5_uevm.h   |1 +
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 28a306b..2db0fbd 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -35,4 +35,6 @@
 #define CONFIG_DRA7XX  /* in a TI DRA7XX core */
 #define CONFIG_SYS_PROMPT  DRA752 EVM # 
 
+#define CONSOLEDEV ttyO0
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index deb5e9f..b261176 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -144,7 +144,7 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
-   console=ttyO2,115200n8\0 \
+   console= CONSOLEDEV ,115200n8\0 \
fdt_high=0x\0 \
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
@@ -174,7 +174,11 @@
bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then  \
-   setenv fdtfile omap5-uevm.dtb; fi;\0  \
+   setenv fdtfile omap5-uevm.dtb; fi;  \
+   if test $board_name = dra7xx; then  \
+   setenv fdtfile dra7-evm.dtb; fi;  \
+   if test -z ${fdtfile}; then  \
+   echo WARNING: Could not determine device tree to use; 
fi; \0 \
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
 
 #define CONFIG_BOOTCOMMAND \
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 9e0339b..f2cbb02 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -55,6 +55,7 @@
 #define CONFIG_CMD_PART
 
 #define CONFIG_SYS_PROMPT  OMAP5430 EVM # 
+#define CONSOLEDEV ttyO2
 
 #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC   16296
 #endif /* __CONFIG_OMAP5_EVM_H */
-- 
1.7.5.4

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

Re: [U-Boot] [PATCH 1/1 RESEND] NET: Fix system hanging if NET device is not installed

[Stephen Warren]

On 06/05/2013 01:07 AM, Jim Lin wrote:
 If we try to boot from NET device, NetInitLoop in net.c will be invoked.
 If NET device is not installed, eth_get_dev() function will return
 eth_current value, which is NULL.
 When NetInitLoop is called, eth_get_dev-enetaddr will access
 restricted memory area and therefore cause hanging.
 This issue is found on Tegra30 Cardhu platform after adding
 CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file.

Oh, you didn't send this patch to anyone, just the mailing list. I added
the net maintainer to Cc so he'll see this patch.

BTW, this is a critical bugfix, to avoid hangs without any USB Ethernet
device attached.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-ti/master

[Albert ARIBAUD]

Hi Tom,

On Wed, 5 Jun 2013 08:54:18 -0400, Tom Rini tr...@ti.com wrote:

 Hello,
 
 The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
 
   arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-ti.git master
 
 for you to fetch changes up to 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674:
 
   am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c 
 (2013-06-05 08:46:49 -0400)
 
 
 Tom Rini (3):
   omap-common/hwinit-common.c: Mark omap_rev_string as static
   am33xx: Correct NON_SECURE_SRAM_START/END
   am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
 
  arch/arm/cpu/armv7/omap-common/boot-common.c   |   39 
 
  arch/arm/cpu/armv7/omap-common/hwinit-common.c |   38 +--
  arch/arm/include/asm/arch-am33xx/omap.h|4 +--
  arch/arm/include/asm/arch-am33xx/sys_proto.h   |1 +
  arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
  arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
  board/isee/igep0033/board.c|9 ++
  board/phytec/pcm051/board.c|9 ++
  board/ti/am335x/board.c|9 ++
  board/ti/ti814x/evm.c  |9 ++
  include/configs/am335x_evm.h   |   10 --
  include/configs/igep0033.h |   10 --
  include/configs/pcm051.h   |   10 --
  13 files changed, 105 insertions(+), 45 deletions(-)
 

Applied to u-boot-arm/master, thanks!

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

[U-Boot] pull request: u-boot-arm/master

[Albert ARIBAUD]

Hello Tom,

The following changes since commit
3da0e5750b24a9491058df6126c7be577a276c09:

  arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)

are available in the git repository at:

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

for you to fetch changes up to 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674:

  am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
  (2013-06-05 08:46:49 -0400)


Tom Rini (3):
  omap-common/hwinit-common.c: Mark omap_rev_string as static
  am33xx: Correct NON_SECURE_SRAM_START/END
  am33xx/omap: Move save_omap_boot_params to
omap-common/boot-common.c

 arch/arm/cpu/armv7/omap-common/boot-common.c   |   39
 
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   38
 +-- arch/arm/include/asm/arch-am33xx/omap.h
 |4 +-- arch/arm/include/asm/arch-am33xx/sys_proto.h   |1 +
 arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 board/isee/igep0033/board.c|9 ++
 board/phytec/pcm051/board.c|9 ++
 board/ti/am335x/board.c|9 ++
 board/ti/ti814x/evm.c  |9 ++
 include/configs/am335x_evm.h   |   10 --
 include/configs/igep0033.h |   10 --
 include/configs/pcm051.h   |   10 -- 13 files
 changed, 105 insertions(+), 45 deletions(-)

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

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Nishanth Menon]

On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov lpo...@mm-sol.com wrote:
 Hi Tom,

 On 05/06/13 00:06, Tom Rini wrote:
 On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
 Hi Lokesh,

 Hi Lubomir,
 On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
 Hi Lokesh,

 On 30/05/13 16:19, Lokesh Vutla wrote:
 From: Balaji T K balaj...@ti.com

 add dra mmc pbias support and ldo1 power on

 Signed-off-by: Balaji T K balaj...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
   drivers/mmc/omap_hsmmc.c   |   26 
 ++
   drivers/power/palmas.c |   25 -
   include/configs/omap5_common.h |4 
   include/configs/omap5_uevm.h   |5 -
   include/palmas.h   |6 +-
   6 files changed, 49 insertions(+), 20 deletions(-)

 [snip]
 + /* set LDO9 TWL6035 to 3V */
 LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
 TPS659038), you should add some comment above.
 Ok ll add the comment.

 + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
 Why not use definitions for the voltage? You could take them from
 http://patchwork.ozlabs.org/patch/244103/ where some values are
 defined.
 Yes, Ill rebase this patch on top of your patch and use those defines.
 Please be aware that my above mentioned patch has not been reviewed/
 tested/acked/nacked/whatever by nobody (except possibly a quick look by
 Nishanth Menon, who had some objections). I wrote it when bringing up a
 custom OMAP5 board, and most probably it shall not go into mainline in
 its current form, if ever. I gave it only as an example of how things
 could be done cleaner. Feel free to use the code as you wish, but I'm
 afraid that applying it as a patch to your tree and basing upon it might
 run you into problems when you later sync with mainline.

 Tom, your opinion?

 OK, so at the time it was nothing will really use this code except test
 functions.  Looks like we have a use for mmc1_ldo9 code at least, so
 lets rework the first patch for adding that + cleanups wrt constants.
 Well, I'm not quite sure that this LDO9 function would be the only one
 used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
 set to 'Forced PWM' mode in order to reduce board noise - there sure has
 been a reason to do so and sacrifice converter efficiency. Therefore I
 added similar functionality in my patch to the Palmas driver (and am
 explicitly calling it in my board init).
 The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
 as well, if hardware is designed such that the SD card socket has a
 separate fixed 3.3 V supply which also powers the LDO9 input (the
 uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
 different and this does not apply.


I hate this code for many reasons -
a) hsmmc is used on many OMAP and DM platforms to my knowledge.
b) what is being done here is to power on the LDO supplying MMC.

The implementation *should* be board specific! not an #ifdef madness
which works only on TI platforms.

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

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lubomir Popov]

Hi Nishanth,

On 05/06/13 17:01, Nishanth Menon wrote:
 On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov lpo...@mm-sol.com wrote:
 Hi Tom,

 On 05/06/13 00:06, Tom Rini wrote:
 On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
 Hi Lokesh,

 Hi Lubomir,
 On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
 Hi Lokesh,

 On 30/05/13 16:19, Lokesh Vutla wrote:
 From: Balaji T K balaj...@ti.com

 add dra mmc pbias support and ldo1 power on

 Signed-off-by: Balaji T K balaj...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
   drivers/mmc/omap_hsmmc.c   |   26 
 ++
   drivers/power/palmas.c |   25 
 -
   include/configs/omap5_common.h |4 
   include/configs/omap5_uevm.h   |5 -
   include/palmas.h   |6 +-
   6 files changed, 49 insertions(+), 20 deletions(-)

 [snip]
 + /* set LDO9 TWL6035 to 3V */
 LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
 TPS659038), you should add some comment above.
 Ok ll add the comment.

 + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
 Why not use definitions for the voltage? You could take them from
 http://patchwork.ozlabs.org/patch/244103/ where some values are
 defined.
 Yes, Ill rebase this patch on top of your patch and use those defines.
 Please be aware that my above mentioned patch has not been reviewed/
 tested/acked/nacked/whatever by nobody (except possibly a quick look by
 Nishanth Menon, who had some objections). I wrote it when bringing up a
 custom OMAP5 board, and most probably it shall not go into mainline in
 its current form, if ever. I gave it only as an example of how things
 could be done cleaner. Feel free to use the code as you wish, but I'm
 afraid that applying it as a patch to your tree and basing upon it might
 run you into problems when you later sync with mainline.

 Tom, your opinion?

 OK, so at the time it was nothing will really use this code except test
 functions.  Looks like we have a use for mmc1_ldo9 code at least, so
 lets rework the first patch for adding that + cleanups wrt constants.
 Well, I'm not quite sure that this LDO9 function would be the only one
 used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
 set to 'Forced PWM' mode in order to reduce board noise - there sure has
 been a reason to do so and sacrifice converter efficiency. Therefore I
 added similar functionality in my patch to the Palmas driver (and am
 explicitly calling it in my board init).
 The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
 as well, if hardware is designed such that the SD card socket has a
 separate fixed 3.3 V supply which also powers the LDO9 input (the
 uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
 different and this does not apply.

 
 I hate this code for many reasons -
 a) hsmmc is used on many OMAP and DM platforms to my knowledge.
 b) what is being done here is to power on the LDO supplying MMC.
Sorry, but I can't get if hsmmc is discussed here, or power.

For OMAP5+TWL603x the LDO powering MMC (actually the removable card
interface only; eMMC is another story) is turned on automatically at
power-on by the PMIC sequencer, with a default voltage and mode --
otherwise we would not be able to boot from a card (ROM code does not
touch the PMIC at all). We are talking here about the possibility to
have additional control over this LDO, which should be board-specific,
I agree. On the OMAP5 boards, for example, the call to
palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not
turn on LDO9 - it is on at this moment anyway. The call just makes
it switch from the default bypass mode (with Vout = Vin = 3.3 V) to
regulation mode and Vout = 3.0 V. Why is this done is yet another
question; to me it seems useless (and possibly wrong) when the card
is powered with a fixed voltage of 3.3 V.
Therefore it seems reasonable to count on the PMIC defaults and
remove this call from omap_hsmmc altogether, thus disengaging the
PMIC driver from hsmmc, at least for OMAP5.

For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers
both the OMAP interface and the card socket, and in addition can
automatically power off the MMC LDO upon detecting card removal.
ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V
(it starts by default at 1.8 V), but only if booting from a card.
So here the call to PMIC driver should stay.

Other OMAPs and derivatives - other scenarios.

Anyway, omap_hsmmc.c is built for TI platforms only. If you mean
the #ifdefs here, yes, things could be cleaned up by moving the SoC-
specific pbias stuff to the corresponding board files (with the
expense of redundancy), but this is quite an amount of work... I'm
not volunteering... ;) Moreover, this 

Re: [U-Boot] TPM patches to pull if you wish

[Tom Rini]

On Mon, Jun 03, 2013 at 06:08:23PM -0700, Simon Glass wrote:

 Hi Tom,
 
 I pushed the TPM patches to a branch for you if you want to pick them up.
 
 I ended up squashing the config patch into the others - since otherwise
 snow will not build for one commit. Does that seem acceptable or should I
 resend the whole series again?
 
 Here are the original patches:
 
 http://patchwork.ozlabs.org/bundle/sjg/tpm/
 
 
 The following changes since commit d6639d10dbfa42dc888f8917012550b632a88959:
 
   Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2013-05-31
 18:28:47 -0400)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-x86.git tpm
 
 for you to fetch changes up to 1b393db5870927d68c42a46e6c5877c8d0d83910:
 
   tpm: Reorganize the I2C TPM driver (2013-06-03 01:31:23 -0700)
 
 
 Che-liang Chiou (1):
   tpm: Rename generic_lpc_tpm to tpm_tis_lpc
 
 Tom Wai-Hong Tam (2):
   x86: config: Reflect the name changes of LPC TPM configs
   tpm: Reorganize the I2C TPM driver
 
 Vincent Palatin (1):
   tpm: Add support for new Infineon I2C TPM (SLB 9645 TT 1.2 I2C)
 
  README   |  18 +++-
  drivers/tpm/Makefile |   7 +-
  drivers/tpm/slb9635_i2c/compatibility.h  |  51 -
  drivers/tpm/tis_i2c.c|   4 +
  drivers/tpm/{slb9635_i2c = }/tpm.c  | 280
 ++-
  drivers/tpm/{slb9635_i2c/tpm.h = tpm_private.h} |  46 ++--
  drivers/tpm/{slb9635_i2c = }/tpm_tis_i2c.c  | 354
 
  drivers/tpm/{generic_lpc_tpm.c = tpm_tis_lpc.c} |   0
  include/configs/coreboot.h   |   3 +-
  include/configs/exynos5250-dt.h  |   6 +-
  include/fdtdec.h |   1 +
  lib/fdtdec.c |   1 +
  12 files changed, 486 insertions(+), 285 deletions(-)
  delete mode 100644 drivers/tpm/slb9635_i2c/compatibility.h
  rename drivers/tpm/{slb9635_i2c = }/tpm.c (63%)
  rename drivers/tpm/{slb9635_i2c/tpm.h = tpm_private.h} (71%)
  rename drivers/tpm/{slb9635_i2c = }/tpm_tis_i2c.c (59%)
  rename drivers/tpm/{generic_lpc_tpm.c = tpm_tis_lpc.c} (100%)

Applied to u-boot/master, thanks!

-- 
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 V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Nishanth Menon]

On Wed, Jun 5, 2013 at 11:35 AM, Lubomir Popov lpo...@mm-sol.com wrote:
 Hi Nishanth,

 On 05/06/13 17:01, Nishanth Menon wrote:
 On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov lpo...@mm-sol.com wrote:
 Hi Tom,

 On 05/06/13 00:06, Tom Rini wrote:
 On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
 Hi Lokesh,

 Hi Lubomir,
 On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
 Hi Lokesh,

 On 30/05/13 16:19, Lokesh Vutla wrote:
 From: Balaji T K balaj...@ti.com

 add dra mmc pbias support and ldo1 power on

 Signed-off-by: Balaji T K balaj...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
   drivers/mmc/omap_hsmmc.c   |   26 
 ++
   drivers/power/palmas.c |   25 
 -
   include/configs/omap5_common.h |4 
   include/configs/omap5_uevm.h   |5 -
   include/palmas.h   |6 +-
   6 files changed, 49 insertions(+), 20 deletions(-)

 [snip]
 + /* set LDO9 TWL6035 to 3V */
 LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
 TPS659038), you should add some comment above.
 Ok ll add the comment.

 + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
 Why not use definitions for the voltage? You could take them from
 http://patchwork.ozlabs.org/patch/244103/ where some values are
 defined.
 Yes, Ill rebase this patch on top of your patch and use those defines.
 Please be aware that my above mentioned patch has not been reviewed/
 tested/acked/nacked/whatever by nobody (except possibly a quick look by
 Nishanth Menon, who had some objections). I wrote it when bringing up a
 custom OMAP5 board, and most probably it shall not go into mainline in
 its current form, if ever. I gave it only as an example of how things
 could be done cleaner. Feel free to use the code as you wish, but I'm
 afraid that applying it as a patch to your tree and basing upon it might
 run you into problems when you later sync with mainline.

 Tom, your opinion?

 OK, so at the time it was nothing will really use this code except test
 functions.  Looks like we have a use for mmc1_ldo9 code at least, so
 lets rework the first patch for adding that + cleanups wrt constants.
 Well, I'm not quite sure that this LDO9 function would be the only one
 used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
 set to 'Forced PWM' mode in order to reduce board noise - there sure has
 been a reason to do so and sacrifice converter efficiency. Therefore I
 added similar functionality in my patch to the Palmas driver (and am
 explicitly calling it in my board init).
 The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
 as well, if hardware is designed such that the SD card socket has a
 separate fixed 3.3 V supply which also powers the LDO9 input (the
 uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
 different and this does not apply.


 I hate this code for many reasons -
 a) hsmmc is used on many OMAP and DM platforms to my knowledge.
 b) what is being done here is to power on the LDO supplying MMC.
 Sorry, but I can't get if hsmmc is discussed here, or power.

 For OMAP5+TWL603x the LDO powering MMC (actually the removable card
 interface only; eMMC is another story) is turned on automatically at
 power-on by the PMIC sequencer, with a default voltage and mode --
 otherwise we would not be able to boot from a card (ROM code does not
 touch the PMIC at all). We are talking here about the possibility to
 have additional control over this LDO, which should be board-specific,
 I agree. On the OMAP5 boards, for example, the call to
 palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not
 turn on LDO9 - it is on at this moment anyway. The call just makes
 it switch from the default bypass mode (with Vout = Vin = 3.3 V) to
 regulation mode and Vout = 3.0 V. Why is this done is yet another
 question; to me it seems useless (and possibly wrong) when the card
 is powered with a fixed voltage of 3.3 V.
 Therefore it seems reasonable to count on the PMIC defaults and
 remove this call from omap_hsmmc altogether, thus disengaging the
 PMIC driver from hsmmc, at least for OMAP5.

 For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers
 both the OMAP interface and the card socket, and in addition can
 automatically power off the MMC LDO upon detecting card removal.
 ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V
 (it starts by default at 1.8 V), but only if booting from a card.
 So here the call to PMIC driver should stay.

 Other OMAPs and derivatives - other scenarios.

 Anyway, omap_hsmmc.c is built for TI platforms only. If you mean
 the #ifdefs here, yes, things could be cleaned up by moving the SoC-
 specific pbias stuff to the corresponding board files (with the
 expense of 

Re: [U-Boot] [PATCH] powerpc/mpc85xx:Add iprot input arg in create_TLB0/1_entry

[Scott Wood]

On 06/04/2013 10:20:38 PM, Prabhakar Kushwaha wrote:

On 06/04/2013 10:07 PM, Scott Wood wrote:

On 06/04/2013 11:36:17 AM, Scott Wood wrote:

On 06/04/2013 05:24:41 AM, Prabhakar Kushwaha wrote:
create_tlb1_entry and create_tlb0_entry creates TLB entries with  
IPROT
bit set by default. Any TLB entries with IPROT = 1 can not be  
invalidated.


Add IPROT as input argument for TLB entry creation APIs.

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 Based upon git://git.denx.de/u-boot.git branch master


NACK as discussed in the thread where you suggested this.


Sigh, didn't notice this was the external list, so I'll elaborate.   
We never want to create a non-IPROT entry, as we don't have a TLB  
miss handler that will replace entries that have been invalidated.   
This will be especially important if we ever run U-Boot inside a  
virtual machine.  And yes, this means that the current TLB0 usage  
should go away as well.


oh..

this means function like invalidate_tlb(1) should not be used u-boot?


Pretty much, yes.

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

Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1

[Lubomir Popov]

Hi Nishanth,

 On Wed, Jun 5, 2013 at 11:35 AM, Lubomir Popov lpo...@mm-sol.com wrote:
 Hi Nishanth,

 On 05/06/13 17:01, Nishanth Menon wrote:
 On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov lpo...@mm-sol.com wrote:
 Hi Tom,

 On 05/06/13 00:06, Tom Rini wrote:
 On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
 Hi Lokesh,

 Hi Lubomir,
 On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
 Hi Lokesh,

 On 30/05/13 16:19, Lokesh Vutla wrote:
 From: Balaji T K balaj...@ti.com

 add dra mmc pbias support and ldo1 power on

 Signed-off-by: Balaji T K balaj...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
   arch/arm/include/asm/arch-omap5/omap.h |3 ++-
   drivers/mmc/omap_hsmmc.c   |   26 
 ++
   drivers/power/palmas.c |   25 
 -
   include/configs/omap5_common.h |4 
   include/configs/omap5_uevm.h   |5 -
   include/palmas.h   |6 +-
   6 files changed, 49 insertions(+), 20 deletions(-)

 [snip]
 + /* set LDO9 TWL6035 to 3V */
 LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
 TPS659038), you should add some comment above.
 Ok ll add the comment.

 + val = 0x2b; /* (3 - 0.9) * 20 + 1 */
 Why not use definitions for the voltage? You could take them from
 http://patchwork.ozlabs.org/patch/244103/ where some values are
 defined.
 Yes, Ill rebase this patch on top of your patch and use those defines.
 Please be aware that my above mentioned patch has not been reviewed/
 tested/acked/nacked/whatever by nobody (except possibly a quick look by
 Nishanth Menon, who had some objections). I wrote it when bringing up a
 custom OMAP5 board, and most probably it shall not go into mainline in
 its current form, if ever. I gave it only as an example of how things
 could be done cleaner. Feel free to use the code as you wish, but I'm
 afraid that applying it as a patch to your tree and basing upon it might
 run you into problems when you later sync with mainline.

 Tom, your opinion?

 OK, so at the time it was nothing will really use this code except test
 functions.  Looks like we have a use for mmc1_ldo9 code at least, so
 lets rework the first patch for adding that + cleanups wrt constants.
 Well, I'm not quite sure that this LDO9 function would be the only one
 used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5
 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is
 set to 'Forced PWM' mode in order to reduce board noise - there sure has
 been a reason to do so and sacrifice converter efficiency. Therefore I
 added similar functionality in my patch to the Palmas driver (and am
 explicitly calling it in my board init).
 The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory
 as well, if hardware is designed such that the SD card socket has a
 separate fixed 3.3 V supply which also powers the LDO9 input (the
 uEVM for example). On the DRA7xx+TPS659038 board the power scheme is
 different and this does not apply.


 I hate this code for many reasons -
 a) hsmmc is used on many OMAP and DM platforms to my knowledge.
 b) what is being done here is to power on the LDO supplying MMC.
 Sorry, but I can't get if hsmmc is discussed here, or power.

 For OMAP5+TWL603x the LDO powering MMC (actually the removable card
 interface only; eMMC is another story) is turned on automatically at
 power-on by the PMIC sequencer, with a default voltage and mode --
 otherwise we would not be able to boot from a card (ROM code does not
 touch the PMIC at all). We are talking here about the possibility to
 have additional control over this LDO, which should be board-specific,
 I agree. On the OMAP5 boards, for example, the call to
 palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not
 turn on LDO9 - it is on at this moment anyway. The call just makes
 it switch from the default bypass mode (with Vout = Vin = 3.3 V) to
 regulation mode and Vout = 3.0 V. Why is this done is yet another
 question; to me it seems useless (and possibly wrong) when the card
 is powered with a fixed voltage of 3.3 V.
 Therefore it seems reasonable to count on the PMIC defaults and
 remove this call from omap_hsmmc altogether, thus disengaging the
 PMIC driver from hsmmc, at least for OMAP5.

 For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers
 both the OMAP interface and the card socket, and in addition can
 automatically power off the MMC LDO upon detecting card removal.
 ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V
 (it starts by default at 1.8 V), but only if booting from a card.
 So here the call to PMIC driver should stay.

 Other OMAPs and derivatives - other scenarios.

 Anyway, omap_hsmmc.c is built for TI platforms only. If you mean
 the #ifdefs here, yes, things could be cleaned up by moving the SoC-
 specific pbias stuff to the corresponding board files (with 

Re: [U-Boot] arm, arm335x: add watchdog support

[Michael Trimarchi]

Hi

On Jun 5, 2013 4:27 PM, Heiko Schocher h...@denx.de wrote:

 Hello Michael,

 Am 05.06.2013 16:21, schrieb Michael Trimarchi:
  Hi
 
  On Jun 5, 2013 4:17 PM, Heiko Schocher h...@denx.de 
  mailto:h...@denx.de
wrote:
 
  Hello Michael,
 
  Am 05.06.2013 15:31, schrieb Michael Trimarchi:
   Hi
  
   On Jun 4, 2013 10:55 AM, Heiko Schocher h...@denx.de mailto:
h...@denx.de mailto:h...@denx.de mailto:h...@denx.de wrote:
  
   Add TI OMAP 16xx  24xx/34xx 32KHz (non-secure) watchdog support.
  
   Signed-off-by: Heiko Schocher h...@denx.de mailto:h...@denx.de
mailto:h...@denx.de mailto:h...@denx.de
   Cc: Albert Aribaud albert.u.b...@aribaud.net mailto:
albert.u.b...@aribaud.net mailto:albert.u.b...@aribaud.net
  mailto:albert.u.b...@aribaud.net
   Cc: Tom Rini tr...@ti.com mailto:tr...@ti.com mailto:
tr...@ti.com mailto:tr...@ti.com
   ---
arch/arm/include/asm/arch-am33xx/cpu.h |  20 ++
drivers/watchdog/Makefile  |   1 +
drivers/watchdog/omap_wdt.c| 115
+
3 Dateien geändert, 136 Zeilen hinzugefügt(+)
create mode 100644 drivers/watchdog/omap_wdt.c
  [...]
   diff --git a/drivers/watchdog/omap_wdt.c
b/drivers/watchdog/omap_wdt.c
   new file mode 100644
   index 000..dc4df98
   --- /dev/null
   +++ b/drivers/watchdog/omap_wdt.c
   @@ -0,0 +1,115 @@
  [...]
   +   /* wait for posted write to complete */
   +   while ((readl(wdt-wdtwwps)  WDT_WWPS_PEND_WTGR))
   +   ;
   +}
   +
  
   I think that this patch has some problem because watchdog reset is
in getc code. Did you try to paste very long string when it is enabled? You
need to
   avoid reset when it is not needed
 
  I think, I do not understand you ... this is for all watchdogs
  the case ...
 
  I currently pasted a 500 bytes long string, seeing no problems
  with the watchdog...
 
 
  OK, maybe was a problem of my version. I have done the same driver 2
month ago and tested on omap3. I optimize the watchdog reset using time
delaying.
  BTW if it works I have no other comments. Sorry for the noise

 Maybe you have a chance to try this patch on your hw?


Yes I can or I can ask.

Michael

 bye,
 Heiko
 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] imx: Vybrid VF610 mac address issue

[Andy Voltz]

I recently tried booting the VF610 support on the Tower board, but the mac
address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
in u-boot.

I'm booting this kernel:
https://github.com/Timesys/linux-timesys/
ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca

I haven't yet seen how the address is passed to the kernel, but our previous
u-boot support does not have this issue with the same kernel. That u-boot
branch is also on our github.

Any ideas?

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

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Fabio Estevam]

Hi Andy,

On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz andy.vo...@timesys.com wrote:
 I recently tried booting the VF610 support on the Tower board, but the mac
 address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
 in u-boot.

 I'm booting this kernel:
 https://github.com/Timesys/linux-timesys/
 ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca

 I haven't yet seen how the address is passed to the kernel, but our previous
 u-boot support does not have this issue with the same kernel. That u-boot
 branch is also on our github.

The MAC address is read in the imx_get_mac_from_fuse() function in
arch/arm/cpu/armv7/vf610/generic.c

Try printing all the elements of mac[] array in this function and
check if the logic is correct there.

Regards,

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

[U-Boot] [PATCH] vf610twr: Drop unneeded 'or' operator

[Fabio Estevam]

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

No need to use the or operator, so just remove it.

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

diff --git a/board/freescale/vf610twr/vf610twr.c 
b/board/freescale/vf610twr/vf610twr.c
index 04fa882..1156194 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -308,7 +308,7 @@ int board_mmc_init(bd_t *bis)
imx_iomux_v3_setup_multiple_pads(
esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
 
-   status |= fsl_esdhc_initialize(bis, esdhc_cfg[0]);
+   status = fsl_esdhc_initialize(bis, esdhc_cfg[0]);
 
return status;
 }
-- 
1.8.1.2

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

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Benoît Thébaudeau]

Hi Andy, Fabio,

On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
 Hi Andy,
 
 On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz andy.vo...@timesys.com wrote:
  I recently tried booting the VF610 support on the Tower board, but the mac
  address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
  in u-boot.
 
  I'm booting this kernel:
  https://github.com/Timesys/linux-timesys/
  ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
 
  I haven't yet seen how the address is passed to the kernel, but our
  previous
  u-boot support does not have this issue with the same kernel. That u-boot
  branch is also on our github.
 
 The MAC address is read in the imx_get_mac_from_fuse() function in
 arch/arm/cpu/armv7/vf610/generic.c
 
 Try printing all the elements of mac[] array in this function and
 check if the logic is correct there.

You probably had programmed the fuses with a MAC address on your board, and then
replaced the existing U-Boot with the mainline version. These 2 U-Boot-s may
interpret the MAC fuses in a different way. Especially, note that VF610
interprets the MAC fuses with reversed endianness compared to i.MX6 in mainline
U-Boot. This is documented in doc/README.SoC. There may be the same difference
between VF610 in mainline U-Boot and the other version of U-Boot that you used
first.

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

Re: [U-Boot] [PATCH] vf610twr: Drop unneeded 'or' operator

[Benoît Thébaudeau]

Hi Fabio,

On Wednesday, June 5, 2013 11:17:45 PM, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 No need to use the or operator, so just remove it.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
  board/freescale/vf610twr/vf610twr.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/board/freescale/vf610twr/vf610twr.c
 b/board/freescale/vf610twr/vf610twr.c
 index 04fa882..1156194 100644
 --- a/board/freescale/vf610twr/vf610twr.c
 +++ b/board/freescale/vf610twr/vf610twr.c
 @@ -308,7 +308,7 @@ int board_mmc_init(bd_t *bis)
   imx_iomux_v3_setup_multiple_pads(
   esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
  
 - status |= fsl_esdhc_initialize(bis, esdhc_cfg[0]);
 + status = fsl_esdhc_initialize(bis, esdhc_cfg[0]);
  
   return status;
  }
 --
 1.8.1.2

Or even better, completely drop status and use
return fsl_esdhc_initialize(bis, esdhc_cfg[0]);.

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

Re: [U-Boot] [PATCH V2 REPOST 1/2] lcd: add functions to set up simplefb device tree

[Anatolij Gustschin]

On Tue, 04 Jun 2013 21:38:19 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
...
 Anatolij, do these patches look good? Are you waiting for Albert to ack
 patch 2 in order to take it through the LCD tree? Thanks.

these patches look good, I'll queue them. Sorry for delay.

Thanks,

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

[U-Boot] [PATCH v2] vf610twr: Drop unneeded 'status' variable

[Fabio Estevam]

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

No need to use the 'status' variable, so just remove it.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Drop status variable

 board/freescale/vf610twr/vf610twr.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/board/freescale/vf610twr/vf610twr.c 
b/board/freescale/vf610twr/vf610twr.c
index 04fa882..f14df8b 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -301,16 +301,13 @@ int board_mmc_init(bd_t *bis)
NEW_PAD_CTRL(VF610_PAD_PTA28__ESDHC1_DAT2, ESDHC_PAD_CTRL),
NEW_PAD_CTRL(VF610_PAD_PTA29__ESDHC1_DAT3, ESDHC_PAD_CTRL),
};
-   s32 status = 0;
 
esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
 
imx_iomux_v3_setup_multiple_pads(
esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
 
-   status |= fsl_esdhc_initialize(bis, esdhc_cfg[0]);
-
-   return status;
+   return fsl_esdhc_initialize(bis, esdhc_cfg[0]);
 }
 #endif
 
-- 
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 REPOST 1/2] lcd: add functions to set up simplefb device tree

[Anatolij Gustschin]

On Mon, 27 May 2013 22:31:17 -0600
Stephen Warren swar...@wwwdotorg.org wrote:

 simple-framebuffer is a new device tree binding that describes a pre-
 configured frame-buffer memory region and its format. The Linux kernel
 contains a driver that supports this binding. Implement functions to
 create a DT node (or fill in an existing node) with parameters that
 describe the framebuffer format that U-Boot is using.
 
 This will be immediately used by the Raspberry Pi board in U-Boot, and
 likely will be used by the Samsung ARM ChromeBook support soon too. It
 could well be used by many other boards (e.g. Tegra boards with built-in
 LCD panels, which aren't yet supported by the Linux kernel).
 
 Signed-off-by: Stephen Warren swar...@wwwdotorg.org
 Acked-by: Simon Glass s...@chromium.org
 ---
 v2: Add binding doc, remove ifdefs from lcd.h
 ---
  common/lcd.c   |   87 
 
  .../video/simple-framebuffer.txt   |   25 ++
  include/lcd.h  |3 +
  3 files changed, 115 insertions(+)
  create mode 100644 doc/device-tree-bindings/video/simple-framebuffer.txt

Applied to u-boot-video/master. Thanks!

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

Re: [U-Boot] [PATCH V2 REPOST 2/2] ARM: bcm2835: add simplefb DT node during bootz/m

[Anatolij Gustschin]

On Mon, 27 May 2013 22:31:18 -0600
Stephen Warren swar...@wwwdotorg.org wrote:

 Add a DT simple-framebuffer node to DT when booting the Linux kernel.
 This will allow the kernel to inherit the framebuffer configuration from
 U-Boot, and display a graphical boot console, and even run a full SW-
 rendered X server.
 
 Signed-off-by: Stephen Warren swar...@wwwdotorg.org
 Acked-by: Simon Glass s...@chromium.org
 ---
  board/raspberrypi/rpi_b/rpi_b.c |   14 +-
  include/configs/rpi_b.h |2 ++
  2 files changed, 15 insertions(+), 1 deletion(-)

Applied to u-boot-video/master. Thanks!

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

Re: [U-Boot] [PATCH] vf610twr: Drop unneeded 'or' operator

[Otavio Salvador]

On Wed, Jun 5, 2013 at 6:24 PM, Benoît Thébaudeau 
benoit.thebaud...@advansee.com wrote:

 Hi Fabio,

 On Wednesday, June 5, 2013 11:17:45 PM, Fabio Estevam wrote:
  From: Fabio Estevam fabio.este...@freescale.com
 
  No need to use the or operator, so just remove it.
 
  Signed-off-by: Fabio Estevam fabio.este...@freescale.com
  ---
   board/freescale/vf610twr/vf610twr.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/board/freescale/vf610twr/vf610twr.c
  b/board/freescale/vf610twr/vf610twr.c
  index 04fa882..1156194 100644
  --- a/board/freescale/vf610twr/vf610twr.c
  +++ b/board/freescale/vf610twr/vf610twr.c
  @@ -308,7 +308,7 @@ int board_mmc_init(bd_t *bis)
imx_iomux_v3_setup_multiple_pads(
esdhc1_pads, ARRAY_SIZE(esdhc1_pads));
 
  - status |= fsl_esdhc_initialize(bis, esdhc_cfg[0]);
  + status = fsl_esdhc_initialize(bis, esdhc_cfg[0]);
 
return status;
   }
  --
  1.8.1.2

 Or even better, completely drop status and use
 return fsl_esdhc_initialize(bis, esdhc_cfg[0]);.


+1 :)

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] vf610twr: Drop unneeded 'status' variable

[Otavio Salvador]

On Wed, Jun 5, 2013 at 6:34 PM, Fabio Estevam feste...@gmail.com wrote:

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

 No need to use the 'status' variable, so just remove it.

 Signed-off-by: Fabio Estevam fabio.este...@freescale.com


Reviewed-by: Otavio Salvador ota...@ossystems.com.br

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Benoît Thébaudeau]

On Wednesday, June 5, 2013 11:16:17 PM, Benoît Thébaudeau wrote:
 Hi Andy, Fabio,
 
 On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
  Hi Andy,
  
  On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz andy.vo...@timesys.com wrote:
   I recently tried booting the VF610 support on the Tower board, but the
   mac
   address is reversed in Linux userspace. DHCP/BOOTP seems to work properly
   in u-boot.
  
   I'm booting this kernel:
   https://github.com/Timesys/linux-timesys/
   ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
  
   I haven't yet seen how the address is passed to the kernel, but our
   previous
   u-boot support does not have this issue with the same kernel. That u-boot
   branch is also on our github.
  
  The MAC address is read in the imx_get_mac_from_fuse() function in
  arch/arm/cpu/armv7/vf610/generic.c
  
  Try printing all the elements of mac[] array in this function and
  check if the logic is correct there.
 
 You probably had programmed the fuses with a MAC address on your board, and
 then
 replaced the existing U-Boot with the mainline version. These 2 U-Boot-s may
 interpret the MAC fuses in a different way. Especially, note that VF610
 interprets the MAC fuses with reversed endianness compared to i.MX6 in
 mainline
 U-Boot. This is documented in doc/README.SoC. There may be the same
 difference
 between VF610 in mainline U-Boot and the other version of U-Boot that you
 used
 first.

But if there is such a difference between U-Boot editions, it might be worth
considering to make mainline U-Boot more consistent with Freescale's or others'
before it is too much widespread. It is especially important if people change
the U-Boot edition on their board.

Stefano, Alison, what do you think?

Alison, have you checked if your implementation in mainline is consistent with
Freescale's? There may be a difference both for which fuse word is used for
high/low parts of the MAC address (i.e. word-level endianness that I was talking
about above), and for the byte-level endianness inside each fuse word.

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

[U-Boot] [PATCH 4/4] imx: nitrogen6x: Enable filesystem generic commands

[Robert Winkler]

Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
 include/configs/nitrogen6x.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 5936e88..1d8d7e5 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -289,5 +289,6 @@
 
 #define CONFIG_CMD_BOOTZ
 #define CONFIG_SUPPORT_RAW_INITRD
+#define CONFIG_CMD_FS_GENERIC
 
 #endif/* __CONFIG_H */
-- 
1.8.3

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

[U-Boot] [PATCH 3/4] imx: nitrogen6x: Enable raw initrd

[Robert Winkler]

Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
 include/configs/nitrogen6x.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index b126940..5936e88 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -288,5 +288,6 @@
 #define CONFIG_SYS_ALT_MEMTEST
 
 #define CONFIG_CMD_BOOTZ
+#define CONFIG_SUPPORT_RAW_INITRD
 
 #endif/* __CONFIG_H */
-- 
1.8.3

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

[U-Boot] [PATCH 1/4] imx: nitrogen6x: Enabled data cache

[Robert Winkler]

Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
 include/configs/nitrogen6x.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index aea91bc..07f39e9 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -276,7 +276,7 @@
 #define CONFIG_OF_LIBFDT
 #define CONFIG_CMD_BOOTZ
 
-#define CONFIG_SYS_DCACHE_OFF
+/* #define CONFIG_SYS_DCACHE_OFF */
 
 #ifndef CONFIG_SYS_DCACHE_OFF
 #define CONFIG_CMD_CACHE
-- 
1.8.3

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

[U-Boot] [PATCH 0/4] imx: nitrogen6x: Config changes

[Robert Winkler]

These are just some config changes for nitrogen6x.


RAW_INITRD, BOOTZ, FS_GENERIC are being used by this project
http://www.eewiki.net/display/linuxonarm/i.MX6x+SABRE+Lite

DCACHE can finally be enabled because some related bugs have
been fixed.

Robert Winkler (4):
  imx: nitrogen6x: Enabled data cache
  imx: nitrogen6x: Enable bootz
  imx: nitrogen6x: Enable raw initrd
  imx: nitrogen6x: Enable filesystem generic commands

 include/configs/nitrogen6x.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
1.8.3

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

[U-Boot] [PATCH 2/4] imx: nitrogen6x: Enable bootz

[Robert Winkler]

Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
 include/configs/nitrogen6x.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 07f39e9..b126940 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -287,4 +287,6 @@
 #define CONFIG_CMD_TIME
 #define CONFIG_SYS_ALT_MEMTEST
 
+#define CONFIG_CMD_BOOTZ
+
 #endif/* __CONFIG_H */
-- 
1.8.3

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

Re: [U-Boot] Maintain U-Boot splash until application is loaded

[Anatolij Gustschin]

Hi Otavio,

On Tue, 4 Jun 2013 23:13:43 -0300
Otavio Salvador ota...@ossystems.com.br wrote:
...
 I am working in a product and we'd like to keep the U-Boot splash until the
 application has been loaded so we have a graceful initialization. This
 project uses MX23 (so mxs SoC family).
 
 I tried to check the U-Boot mailing list archive for it but I couldn't find
 anything useful. I also did look at kernel source and it seems
 CONFIG_FB_PRE_INIT_FB is available for only *one* board.
 
 Could someone advice me how to do that?

the mxs frame buffer driver in mainline linux tree looks in platform
data structure struct mxsfb_platform_data for fb_phys and fb_size
fields and uses this memory range for the frame buffer (if these are
initialized by platform code). But the platform code in
arch/arm/mach-mxs/mach-mxs.c doesn't initialize them. The platform
code could be extended to check if the display controller is
initialized by the boot loader and in this case it should read out
the frame buffer base address from the display controller registers
and calculate the frame buffer size using the resolution and depth
values from the controller registers. Then this frame buffer range
could be reserved (by reserve_bootmem()) so that the kernel doesn't
use it for other purposes, and the reserved range should be passed
in mxsfb_platform_data to the frame buffer driver.

When booting, the frame buffer could be used by frame buffer console
fbcon and in this case your splash will be overwritten. To prevent
this you could pass fbcon=map:1 on the kernel command line and if
the console on frame buffer is needed later, then map the console
to the frame buffer by appropriate ioctl (see con2fbmap utility).

Thanks,

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

[U-Boot] Pull request: u-boot-video/master

[Anatolij Gustschin]

Hey Tom,

The following changes since commit 5ed6f447af60aabd2669d913f673793c1ce48f47:

  P1022DS: Set CONFIG_SPL_MAX_SIZE directly (2013-05-03 09:19:43 -0400)

are available in the git repository at:

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

for you to fetch changes up to ea697ae7eb059d7467c6854ce562c31df510eb59:

  ARM: bcm2835: add simplefb DT node during bootz/m (2013-06-05 22:40:38 +0200)


Eric Nelson (1):
  cfb_console: flush FB cache at end of public functions

Stephen Warren (2):
  lcd: add functions to set up simplefb device tree
  ARM: bcm2835: add simplefb DT node during bootz/m

 board/raspberrypi/rpi_b/rpi_b.c|   14 +++-
 common/lcd.c   |   87 
 .../video/simple-framebuffer.txt   |   25 ++
 drivers/video/cfb_console.c|   15 ++--
 include/configs/rpi_b.h|2 +
 include/lcd.h  |3 +
 6 files changed, 139 insertions(+), 7 deletions(-)
 create mode 100644 doc/device-tree-bindings/video/simple-framebuffer.txt

Please pull. Thanks!

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

Re: [U-Boot] Vybrid VF610 mac address issue

[Wang Huan-B18965]

Hi, Andy, Fabio, Benoît,

 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
 On Behalf Of Beno?t Thébaudeau
 Sent: Thursday, June 06, 2013 5:16 AM
 To: Fabio Estevam
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] imx: Vybrid VF610 mac address issue
 
 Hi Andy, Fabio,
 
 On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
  Hi Andy,
 
  On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz andy.vo...@timesys.com
 wrote:
   I recently tried booting the VF610 support on the Tower board, but
   the mac address is reversed in Linux userspace. DHCP/BOOTP seems to
   work properly in u-boot.
  
   I'm booting this kernel:
   https://github.com/Timesys/linux-timesys/
   ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
  
   I haven't yet seen how the address is passed to the kernel, but our
   previous u-boot support does not have this issue with the same
   kernel. That u-boot branch is also on our github.
 
  The MAC address is read in the imx_get_mac_from_fuse() function in
  arch/arm/cpu/armv7/vf610/generic.c
 
  Try printing all the elements of mac[] array in this function and
  check if the logic is correct there.
 
 You probably had programmed the fuses with a MAC address on your board,
 and then replaced the existing U-Boot with the mainline version. These
 2 U-Boot-s may interpret the MAC fuses in a different way. Especially,
 note that VF610 interprets the MAC fuses with reversed endianness
 compared to i.MX6 in mainline U-Boot. This is documented in
 doc/README.SoC. There may be the same difference between VF610 in
 mainline U-Boot and the other version of U-Boot that you used first.
 
[Alison Wang] First of all, the mac address is set in include/configs/vybrid.h 
as below in Andy's previous u-boot version.
#define CONFIG_ETHADDR  00:e0:0c:bc:e5:60
#define CONFIG_IPADDR   10.81.67.175
Because no hardcoded IP addresses/MAC addresses should be set there, I change 
the codes. As Fabio said, the mac address is read in the 
imx_get_mac_from_fuse() function in arch/arm/cpu/armv7/vf610/generic.c now.

I think Andy may not program the mac address correctly in fuses on his board 
with the mainline version. On my board, the fuses are programmed like this,
The value of OTP fuse Bank4 Word2 is 0x00e0
The value of OTP fuse Bank4 Word3 is 0x0cbce560

So the mac address can be read from imx_get_mac_from_fuse() function in u-boot. 
Then we can get ethaddr=00:e0:0c:bc:e5:60 in u-boot environment variables as 
below.
Vybrid U-Boot  pri
baudrate=115200
bootdelay=3
ethact=FEC
ethaddr=00:e0:0c:bc:e5:60
stderr=serial
stdin=serial
stdout=serial

Environment size: 121/8188 bytes

Andy, did you program the fuses as above? How about the result after 
programming the fuses as above?

Best Regards,
Alison Wang

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

Re: [U-Boot] imx: Vybrid VF610 mac address issue

[Wang Huan-B18965]

Hi, Benoit,

 -Original Message-
 From: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com]
 Sent: Thursday, June 06, 2013 5:46 AM
 To: Fabio Estevam
 Cc: Andy Voltz; u-boot@lists.denx.de; Stefano Babic; Wang Huan-B18965
 Subject: Re: [U-Boot] imx: Vybrid VF610 mac address issue
 
 On Wednesday, June 5, 2013 11:16:17 PM, Benoît Thébaudeau wrote:
  Hi Andy, Fabio,
 
  On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
   Hi Andy,
  
   On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz andy.vo...@timesys.com
 wrote:
I recently tried booting the VF610 support on the Tower board,
 but
the mac address is reversed in Linux userspace. DHCP/BOOTP seems
to work properly in u-boot.
   
I'm booting this kernel:
https://github.com/Timesys/linux-timesys/
ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
   
I haven't yet seen how the address is passed to the kernel, but
our previous u-boot support does not have this issue with the
 same
kernel. That u-boot branch is also on our github.
  
   The MAC address is read in the imx_get_mac_from_fuse() function in
   arch/arm/cpu/armv7/vf610/generic.c
  
   Try printing all the elements of mac[] array in this function and
   check if the logic is correct there.
 
  You probably had programmed the fuses with a MAC address on your
  board, and then replaced the existing U-Boot with the mainline
  version. These 2 U-Boot-s may interpret the MAC fuses in a different
  way. Especially, note that VF610 interprets the MAC fuses with
  reversed endianness compared to i.MX6 in mainline U-Boot. This is
  documented in doc/README.SoC. There may be the same difference
  between VF610 in mainline U-Boot and the other version of U-Boot that
  you used first.
 
 But if there is such a difference between U-Boot editions, it might be
 worth considering to make mainline U-Boot more consistent with
 Freescale's or others'
 before it is too much widespread. It is especially important if people
 change the U-Boot edition on their board.
 
 Stefano, Alison, what do you think?
 
 Alison, have you checked if your implementation in mainline is
 consistent with Freescale's? There may be a difference both for which
 fuse word is used for high/low parts of the MAC address (i.e. word-
 level endianness that I was talking about above), and for the byte-
 level endianness inside each fuse word.
[Alison Wang] Thanks for your comments. In Vybrid's RM, there is no specific 
descriptions about
how to program the mac address in the OTP Bank4 Word2(OCOTP_MAC0) and OTP Bank4 
Word3(OCOTP_MAC1).
So I think it is not formulary which fuse word is used for high/low parts of 
the MAC address
(i.e. word-level endianness), and for the byte-level endianness inside each 
fuse word.
Through reading the doc/README.vf610, I think the user could program the fuses 
correctly.


Best Regards,
Alison Wang

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

[U-Boot] [PATCH] powerpc/mpc85xx:Disable Debug TLB entry before init_tlbs

[Prabhakar Kushwaha]

init_tlbs() initialize all the TLB entries required for the system.

So disable DEBUG TLB entry before TLB entries initialization.

Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
 arch/powerpc/cpu/mpc85xx/cpu_init_early.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
index f4403c2..3ab7748 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -180,5 +180,9 @@ void cpu_init_early_f(void)
 
invalidate_tlb(1);
 
+#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB)  !defined(CONFIG_SPL_BUILD)
+   disable_tlb(CONFIG_SYS_PPC_E500_DEBUG_TLB);
+#endif
+
init_tlbs();
 }
-- 
1.7.9.5



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

Re: [U-Boot] [PATCH V2] exynos: spl: Add a custom spi copy function

[Rajeshwari Birje]

Hi Jagan,

Simon had sent a V2 by rebasing the patch on MMC series submitted by
Amar, but there are no comments on those MMC patches and are not yet
merged. I incorporated the review comments given by Wolfgang Denk on
top of V1 and sent a V2 patch.

Regards,
Rajeshwari Shinde.

On Mon, Jun 3, 2013 at 12:36 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi,

 I think this needs to send as v3, as Simon sent v2 for this.
 http://patchwork.ozlabs.org/patch/243139/

 --
 Thanks,
 Jagan.

 On Thu, May 30, 2013 at 12:01 PM, Rajeshwari Shinde
 rajeshwar...@samsung.com wrote:
 This patch implements a custom spi_copy funtion to copy u-boot from SF
 to RAM. This is faster then iROM spi_copy funtion as this runs spi at
 50Mhz and also in WORD mode of operation.

 Changed a printf in pinmux.c to debug just to avoid the compilation
 error in SPL.
 Removed enum for boot mode from spl_boot.c as it was already define
 in spl.h

 Based on [PATCH V2] spi: exynos: Support word transfers

 Signed-off-by: Alim Akhtar alim.akh...@samsung.com
 Signed-off-by: Tom Wai-Hong Tam waih...@chromium.org
 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
 Changes in V2:
 - Corrected the commit message.
 - Added a SPI timeout check.
 - Corrected the comments.
  arch/arm/cpu/armv7/exynos/pinmux.c |2 +-
  arch/arm/include/asm/arch-exynos/spi.h |2 +
  board/samsung/smdk5250/spl_boot.c  |  136 
 ---
  include/configs/exynos5250-dt.h|3 +
  spl/Makefile   |4 +
  5 files changed, 132 insertions(+), 15 deletions(-)

 diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
 b/arch/arm/cpu/armv7/exynos/pinmux.c
 index bd499b4..c484a86 100644
 --- a/arch/arm/cpu/armv7/exynos/pinmux.c
 +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
 @@ -427,7 +427,7 @@ static int exynos4_pinmux_config(int peripheral, int 
 flags)
 case PERIPH_ID_SDMMC1:
 case PERIPH_ID_SDMMC3:
 case PERIPH_ID_SDMMC4:
 -   printf(SDMMC device %d not implemented\n, peripheral);
 +   debug(SDMMC device %d not implemented\n, peripheral);
 return -1;
 default:
 debug(%s: invalid peripheral %d, __func__, peripheral);
 diff --git a/arch/arm/include/asm/arch-exynos/spi.h 
 b/arch/arm/include/asm/arch-exynos/spi.h
 index e67ad27..3430ac1 100644
 --- a/arch/arm/include/asm/arch-exynos/spi.h
 +++ b/arch/arm/include/asm/arch-exynos/spi.h
 @@ -43,6 +43,8 @@ struct exynos_spi {

  #define SPI_TIMEOUT_MS 10

 +#define SF_READ_DATA_CMD   0x3
 +
  /* SPI_CHCFG */
  #define SPI_CH_HS_EN   (1  6)
  #define SPI_CH_RST (1  5)
 diff --git a/board/samsung/smdk5250/spl_boot.c 
 b/board/samsung/smdk5250/spl_boot.c
 index c0bcf46..85a5d68 100644
 --- a/board/samsung/smdk5250/spl_boot.c
 +++ b/board/samsung/smdk5250/spl_boot.c
 @@ -22,17 +22,13 @@

  #includecommon.h
  #includeconfig.h
 +#include asm/arch/clk.h
 +#include asm/arch/spi.h
 +#include asm/arch/pinmux.h
 +#include asm/arch/periph.h
 +#include asm/arch/spl.h

 -enum boot_mode {
 -   BOOT_MODE_MMC = 4,
 -   BOOT_MODE_SERIAL = 20,
 -   /* Boot based on Operating Mode pin settings */
 -   BOOT_MODE_OM = 32,
 -   BOOT_MODE_USB,  /* Boot using USB download */
 -};
 -
 -   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
 -   typedef u32 (*usb_copy_func_t)(void);
 +typedef u32 (*usb_copy_func_t)(void);

  /*
   * Set/clear program flow prediction and return the previous state.
 @@ -48,6 +44,119 @@ static int config_branch_prediction(int set_cr_z)
 return cr  CR_Z;
  }

 +static void spi_rx_tx(struct exynos_spi *regs, int todo,
 +   void *dinp, void const *doutp, int i)
 +{
 +   uint *rxp = (uint *)(dinp + (i * (32 * 1024)));
 +   int rx_lvl, tx_lvl;
 +   uint out_bytes, in_bytes;
 +
 +   out_bytes = todo;
 +   in_bytes = todo;
 +   setbits_le32(regs-ch_cfg, SPI_CH_RST);
 +   clrbits_le32(regs-ch_cfg, SPI_CH_RST);
 +   writel(((todo * 8) / 32) | SPI_PACKET_CNT_EN, regs-pkt_cnt);
 +
 +   while (in_bytes) {
 +   uint32_t spi_sts;
 +   int temp;
 +
 +   spi_sts = readl(regs-spi_sts);
 +   rx_lvl = ((spi_sts  15)  0x7f);
 +   tx_lvl = ((spi_sts  6)  0x7f);
 +   while (tx_lvl  32  out_bytes) {
 +   temp = 0x;
 +   writel(temp, regs-tx_data);
 +   out_bytes -= 4;
 +   tx_lvl += 4;
 +   }
 +   while (rx_lvl = 4  in_bytes) {
 +   temp = readl(regs-rx_data);
 +   if (rxp)
 +   *rxp++ = temp;
 +   in_bytes -= 4;
 +   rx_lvl -= 4;
 +   }
 +   }
 +}
 +
 +/*
 +* Copy uboot from spi flash to RAM
 +*
 +* @parma uboot_sizesize of 

Re: [U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts

[Michal Simek]

move this discussion back to mailing list.

On 06/05/2013 05:56 PM, Jagan Teki wrote:
 And are your ok with below representation for common id's parts ?
 +   .name   = W25Q80BL/W25Q80BV,
 +   .name   = W25Q16CL/W25Q16DV,
 +   .name   = W25Q32BV/W25Q32FV_SPI,
 +   .name   = W25Q64CV/W25Q64FV_SPI,
 +   .name   = W25Q128BV/W25Q128FV_SPI,
 +   .name   = W25Q32DW/W25Q32FV_QPI,
 +   .name   = W25Q64DW/W25Q64FV_QPI,
 +   .name   = W25Q128FW/W25Q128FV_QPI,

 Any comments on above representation of part names, as the id's to
 these pairs are common.
 This will enhance u-boot sf to support all parts from winbond, but
 seems like different view of names.


 what's the difference between that parts?
 
 parts were diff in terms of voltages and sone SPI and QPI configurations.
 but from the manufacture defeat, pair of parts were same ID's

ok.

 Does software care if it is W25G80BL or BV?
 Or software behaviour is the same and there is only difference in voltage
 or so.
 
 SW is same even if it 1.8 or 3.3 v.
 The only reason for giving the pair of names to support all different parts

You are supporting them but you are just not list them.

 I don't care about it so much but it is increase u-boot size.
 Why does u-boot size increase, is it because of  below representation
 on name filed
   = W25Q80BL/W25Q80BV

Just because of longer names which go probably to rodata section.

It is not a problem for me at all.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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