[U-Boot] [PATCH V4 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
From: Balaji T K
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K
Signed-off-by: Lokesh Vutla
---
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
@@ -39,11 +39,
[U-Boot] [PATCH V4] lcd: align bmp header when uncopmressing image
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
Signed-off-by: Kyungmin Park
CC: Anatolij Gustschin
CC: Wolfgang Denk
---
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 a/include/lcd.h b/include/lcd.h
index c6e7fc5..4
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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 add dra mmc pbias support and ldo1 power on Signed-off-by: Balaji T K Signed-off-by: Lokesh Vutla --- 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 v2] arm, am33xx: add defines for gmii_sel_register bits
move gmii_sel register defines from board code to common place.
Signed-off-by: Heiko Schocher
Cc: Chandan Nath
Cc: Sandeep Paulraj
Cc: Tom Rini
Cc: Lars Poeschel
Cc: Enric Balletbo i Serra
---
- 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
[U-Boot] [PATCH v2] arm, am33xx: move rtc32k_enable() to common place
move rtc32k_enable() to common place so all am33xx boards can use it.
Signed-off-by: Heiko Schocher
Cc: Matt Porter
Cc: Lars Poeschel
Cc: Tom Rini
Cc: Enric Balletbo i Serra
---
- changes for v2:
remove ifdef around prototype, as Tom Rini suggested
arch/arm/cpu/armv7/am33xx/board.c| 18 ++
arch/arm/include/asm/arch-am33xx/sys_proto.h | 2 ++
board/isee/igep0033/board.c | 16
board/phytec/pcm051/board.c | 16
board/ti/am335x/board.c | 16
board/ti/ti814x/evm.c| 16
6 Dateien geändert, 20 Zeilen hinzugefügt(+), 64 Zeilen entfernt(-)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 885fb2d..d3b3612 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -149,3 +149,21 @@ int arch_misc_init(void)
#endif
return 0;
}
+
+#ifdef CONFIG_SPL_BUILD
+void rtc32k_enable(void)
+{
+ struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
+
+ /*
+* Unlock the RTC's registers. For more details please see the
+* RTC_SS section of the TRM. In order to unlock we need to
+* write these specific values (keys) in this order.
+*/
+ writel(0x83e70b13, &rtc->kick0r);
+ writel(0x95a4f1e0, &rtc->kick1r);
+
+ /* Enable the RTC 32K OSC by setting bits 3 and 6. */
+ writel((1 << 3) | (1 << 6), &rtc->osc);
+}
+#endif
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index c913b5f..f76b17c 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -40,4 +40,6 @@ void gpmc_init(void);
void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size);
void omap_nand_switch_ecc(uint32_t, uint32_t);
+
+void rtc32k_enable(void);
#endif
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index d315516..e82d722 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -51,22 +51,6 @@ static struct ctrl_dev *cdev = (struct ctrl_dev
*)CTRL_DEVICE_BASE;
#define UART_CLK_RUNNING_MASK 0x1
#define UART_SMART_IDLE_EN (0x1 << 0x3)
-static void rtc32k_enable(void)
-{
- struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
-
- /*
-* Unlock the RTC's registers. For more details please see the
-* RTC_SS section of the TRM. In order to unlock we need to
-* write these specific values (keys) in this order.
-*/
- writel(0x83e70b13, &rtc->kick0r);
- writel(0x95a4f1e0, &rtc->kick1r);
-
- /* Enable the RTC 32K OSC by setting bits 3 and 6. */
- writel((1 << 3) | (1 << 6), &rtc->osc);
-}
-
static const struct ddr_data ddr3_data = {
.datardsratio0 = K4B2G1646EBIH9_RD_DQS,
.datawdsratio0 = K4B2G1646EBIH9_WR_DQS,
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 9ea50e1..6c0993a 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -59,22 +59,6 @@ static struct ctrl_dev *cdev = (struct ctrl_dev
*)CTRL_DEVICE_BASE;
/* DDR RAM defines */
#define DDR_CLK_MHZ303 /* DDR_DPLL_MULT value */
-static void rtc32k_enable(void)
-{
- struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
-
- /*
-* Unlock the RTC's registers. For more details please see the
-* RTC_SS section of the TRM. In order to unlock we need to
-* write these specific values (keys) in this order.
-*/
- writel(0x83e70b13, &rtc->kick0r);
- writel(0x95a4f1e0, &rtc->kick1r);
-
- /* Enable the RTC 32K OSC by setting bits 3 and 6. */
- writel((1 << 3) | (1 << 6), &rtc->osc);
-}
-
static const struct ddr_data ddr3_data = {
.datardsratio0 = MT41J256M8HX15E_RD_DQS,
.datawdsratio0 = MT41J256M8HX15E_WR_DQS,
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index e52b009..bf25878 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -132,22 +132,6 @@ static int read_eeprom(void)
#define UART_CLK_RUNNING_MASK 0x1
#define UART_SMART_IDLE_EN (0x1 << 0x3)
-static void rtc32k_enable(void)
-{
- struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
-
- /*
-* Unlock the RTC's registers. For more details please see the
-* RTC_SS section of the TRM. In order to unlock we need to
-* write these specific values (keys) in this order.
-*/
- writel(0x83e70b13, &rtc->kick0r);
- writel(0x95a4f1e0, &rtc->kick1r);
-
- /* Enable the RTC 32K OSC by setting bits 3 and 6. */
- writel((1 << 3) | (1 << 6), &rtc->osc);
-}
-
static const struct ddr_data ddr2_data = {
.datardsratio0 = ((MT47H128M16RT25E_RD_DQS<<30) |
(MT47H128M16RT25E_RD_D
Re: [U-Boot] arm, am33xx: add defines for gmii_sel_register bits
Hello Tom, Am 04.06.2013 23:30, schrieb Tom Rini: > On Tue, Jun 04, 2013 at 11:03:18AM +0200, Heiko Schocher wrote: > >> move gmii_sel register defines from board code to common place. > [snip] >> /* MII mode defines */ >> -#define RMII_MODE_ENABLE0x4D >> +#define RMII_MODE_P1_ENABLE 0x4D > [snip] >> /* MII mode defines */ >> -#define MII_MODE_ENABLE 0x0 >> -#define RGMII_MODE_ENABLE 0xA >> #define RMII_RGMII2_MODE_ENABLE 0x49 > > Looks like there's a few bits you're leaving in the board files still, > please move them all over since they come from the TRM, right? Thanks! Done. 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, am335x: make mpu pll config configurable
Hello Tom, Am 04.06.2013 23:29, schrieb Tom Rini: > On Tue, Jun 04, 2013 at 11:01:06AM +0200, Heiko Schocher wrote: > >> upcoming support for siemens boards switches mpu pll clk in board >> code. So make this configurable. >> >> Signed-off-by: Heiko Schocher >> Cc: Tom Rini > > Wait, didn't we already something like this posted? Hmm.. did not found something like that, but maybe I missed it. 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
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 >> Cc: Albert Aribaud >> Cc: Tom Rini > > Reviewed-by: Tom Rini > > 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? 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, am33xx: move rtc32k_enable() to common place
Hello Tom, Am 04.06.2013 23:14, schrieb Tom Rini: > On Tue, Jun 04, 2013 at 11:00:50AM +0200, Heiko Schocher wrote: > >> move rtc32k_enable() to common place so all am33xx boards can use it. > [snip] >> +#ifdef CONFIG_SPL_BUILD >> +void rtc32k_enable(void); >> +#endif > > No need for ifdef on prototypes. Yep, fixed. 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] dfu: make data buffer size configurable
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, 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) ... 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? >> -#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! 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] [PATCH] Add SPI Flash STMicro's N25Q512A & add flag status check during SPI Flash write
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, IS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts
Jagan, Yes, it is OK. Of course, the 3V QPI IDs of W25Q32FV/64FV/128FV are identical to that of the 1.8V devices (W25Q32DW/64DW/128FW). It may not be a good idea but it's too late for us to change. Best Regards, Mike Chen Technical Marketing Winbond Electronics Corp. America (408)544-2667 -Original Message- From: Jagan Teki [mailto:jagannadh.t...@gmail.com] Sent: Tuesday, June 04, 2013 10:26 AM To: US20 Hui (Mike) Chen Cc: US30 Syed Hussain; u-boot@lists.denx.de; Michal Simek; Tom Rini; Simon Glass; Jagannadha Sutradharudu Teki Subject: Re: [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts On Tue, Jun 4, 2013 at 10:49 PM, mch...@winbond.com wrote: > Jagan, > > So far, our major customer request is to have the same ID for backward > compatibility. Therefore the IDs are the same for W25Q16C and W25Q16D. As for > the 2.5V parts (W25Q80BL/W25Q16CL), they are the same die as the 3V > (W25Q80BV/W25Q16CV), so the IDs are the same as well. > > The differences between the pairs are not that significant. We consider them > as drop-in compatible. Ok, thanks for your response. 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", -- Thanks, Jagan. The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: remove unaligned access in fdt_fixup_ethernet()
On 05/27/2013 10:01 PM, Stephen Warren wrote: > Some ARM compilers may emit code that makes unaligned accesses when > faced with constructs such as: > > char mac[16] = "ethaddr"; > > Replace this with a strcpy() call instead to avoid this. strcpy() is > used here, rather than replacing all usage of the mac variable with the > string itself, since the loop itself sprintf()s to the variable each > iteration, so strcpy() is doing basically the same thing. Jerry, does this patch look good? This fixes a problem that prevents U-Boot from booting a Linux kernel for some people. Thanks. ___ 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
On 05/27/2013 10:31 PM, Stephen Warren 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). 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patches never reviewed
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Angelo Dureghello > Sent: Tuesday, June 04, 2013 4:52 AM > To: u-boot@lists.denx.de > Subject: [U-Boot] patches never reviewed > > Dear All, > > i worked hardly through v6 for approval of this AMCORE Coldfire board > support. > > Waited patiently for review of this patches: > > http://patchwork.ozlabs.org/patch/215904/ > http://patchwork.ozlabs.org/patch/214686/ > > then asked again later for the review: > > http://marc.info/?l=u-boot&m=136059580219228&w=2 > > still, at today, i had no feedbacks. > > Unfortunately (i can be wrong) but i have the impression at freescale no- > one have time to spend for following this board addition. > There are still some general issues in the patches, Please send the patch with text by git-send-email instead of the attached .txt file. So everybody can review it and setup a review chain. Thanks. Best Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx:Add iprot input arg in create_TLB0/1_entry
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 --- 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? Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Maintain U-Boot splash until application is loaded
Hello, 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? Regards, -- 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 v3] ARM: imx: Fix incorrect usage of CONFIG_SYS_MMC_ENV_PART
>-Original Message-
>From: Fabio Estevam [mailto:feste...@gmail.com]
>Sent: Wednesday, June 05, 2013 9:06 AM
>To: sba...@denx.de
>Cc: Fleming Andy-AFLEMING; swar...@nvidia.com; Liu Hui-R64343; u-
>b...@lists.denx.de; Estevam Fabio-R49496
>Subject: [PATCH v3] ARM: imx: Fix incorrect usage of
>CONFIG_SYS_MMC_ENV_PART
>
>From: Fabio Estevam
>
>When running the "save" command several times on a mx6qsabresd we see:
>
>U-Boot > save
>Saving Environment to MMC...
>Writing to MMC(1)... done
>U-Boot > save
>Saving Environment to MMC...
>MMC partition switch failed
>U-Boot > save
>Saving Environment to MMC...
>Writing to MMC(1)... done
>U-Boot > save
>Saving Environment to MMC...
>MMC partition switch failed
>U-Boot > save
>Saving Environment to MMC...
>Writing to MMC(1)... done
>U-Boot > save
>Saving Environment to MMC...
>MMC partition switch failed
>
>This issue is caused by the incorrect usage of CONFIG_SYS_MMC_ENV_PART.
>
>CONFIG_SYS_MMC_ENV_PART should be used to specify the mmc partition that
>stores the environment variables.
>
>On some imx boards it is been incorrectly used to pass the partition of
>kernel and dtb files for the 'mmcpart' script variable.
>
>Remove the CONFIG_SYS_MMC_ENV_PART usage and configure the 'mmcpart'
>variable directly.
>
>Reported-by: Jason Liu
>Signed-off-by: Fabio Estevam
>---
Acked-by: Jason Liu
>Changes since v2:
>- Fix in the config files by removing CONFIG_SYS_MMC_ENV_PART Changes
>since v1:
>- Do the change inside the mmc core
> include/configs/mx53ard.h | 3 +--
> include/configs/mx6qsabre_common.h | 2 +-
> include/configs/mx6qsabreauto.h| 1 -
> include/configs/mx6qsabresd.h | 1 -
> include/configs/wandboard.h| 3 +--
> 5 files changed, 3 insertions(+), 7 deletions(-)
>
>diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h index
>41974b1..b0a965f 100644
>--- a/include/configs/mx53ard.h
>+++ b/include/configs/mx53ard.h
>@@ -118,7 +118,7 @@
> "boot_fdt=try\0" \
> "ip_dyn=yes\0" \
> "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
>- "mmcpart=" __stringify(CONFIG_SYS_MMC_ENV_PART) "\0" \
>+ "mmcpart=2\0" \
> "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
> "update_sd_firmware_filename=u-boot.imx\0" \
> "update_sd_firmware=" \
>@@ -240,7 +240,6 @@
> #define CONFIG_ENV_SIZE(8 * 1024)
> #define CONFIG_ENV_IS_IN_MMC
> #define CONFIG_SYS_MMC_ENV_DEV0
>-#define CONFIG_SYS_MMC_ENV_PART 2
>
> #define CONFIG_OF_LIBFDT
>
>diff --git a/include/configs/mx6qsabre_common.h
>b/include/configs/mx6qsabre_common.h
>index 7298a76..bfaa420 100644
>--- a/include/configs/mx6qsabre_common.h
>+++ b/include/configs/mx6qsabre_common.h
>@@ -97,7 +97,7 @@
> "fdt_high=0x\0" \
> "initrd_high=0x\0" \
> "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
>- "mmcpart=" __stringify(CONFIG_SYS_MMC_ENV_PART) "\0" \
>+ "mmcpart=1\0" \
> "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
> "update_sd_firmware=" \
> "if test ${ip_dyn} = yes; then " \
>diff --git a/include/configs/mx6qsabreauto.h
>b/include/configs/mx6qsabreauto.h index 1583c11..f2ff3e1 100644
>--- a/include/configs/mx6qsabreauto.h
>+++ b/include/configs/mx6qsabreauto.h
>@@ -35,7 +35,6 @@
> #define CONFIG_SYS_FSL_USDHC_NUM 2
> #if defined(CONFIG_ENV_IS_IN_MMC)
> #define CONFIG_SYS_MMC_ENV_DEV0
>-#define CONFIG_SYS_MMC_ENV_PART 1 /* Boot partition 1 */
> #endif
>
> #endif /* __MX6QSABREAUTO_CONFIG_H */
>diff --git a/include/configs/mx6qsabresd.h
>b/include/configs/mx6qsabresd.h index 3b8d752..44f07cb 100644
>--- a/include/configs/mx6qsabresd.h
>+++ b/include/configs/mx6qsabresd.h
>@@ -29,7 +29,6 @@
> #define CONFIG_SYS_FSL_USDHC_NUM 3
> #if defined(CONFIG_ENV_IS_IN_MMC)
> #define CONFIG_SYS_MMC_ENV_DEV1 /* SDHC3 */
>-#define CONFIG_SYS_MMC_ENV_PART 1 /* Boot partition 1 */
> #endif
>
> #endif /* __MX6QSABRESD_CONFIG_H */
>diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
>index d4ac086..34a8f15 100644
>--- a/include/configs/wandboard.h
>+++ b/include/configs/wandboard.h
>@@ -116,7 +116,7 @@
> "boot_fdt=try\0" \
> "ip_dyn=yes\0" \
> "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
>- "mmcpart=" __stringify(CONFIG_SYS_MMC_ENV_PART) "\0" \
>+ "mmcpart=2\0" \
> "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
> "update_sd_firmware_filename=u-boot.imx\0" \
> "update_sd_firmware=" \
>@@ -230,7 +230,6 @@
> #define CONFIG_ENV_IS_IN_MMC
> #define CONFIG_ENV_OFFSET (6 * 64 * 1024)
> #define CONFIG_SYS_MMC_ENV_DEV0
>-#define CONFIG_SYS_MMC_ENV_PART 2
>
> #define CONFIG_OF_LIBFDT
> #define CONFIG_CMD_BOOTZ
>--
>1.8.1.2
>ts
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/l
Re: [U-Boot] [PATCH] video: exynos: Change mipi dsi write function parameters correctly
Dear Donghwa, On 08/05/13 13:14, Donghwa Lee wrote: > This patch have changed mipi dsi write functions' parameters correctly. > > - exynos_mipi_dsi_wr_data()'s 3rd parameter is changed to > 'const unsigned char' type. > - exynos_mipi_dsi_wr_tx_header()'s 3rd and 4th parameters were changed to > 'const unsigned char' type. > - s6e8ax0 panel driver does not use type cast operations to write mipi dsi > commands anymore. > - mipi dsi payload is composed with array of panel commands to improve > readability. > > Signed-off-by: Donghwa Lee > --- > arch/arm/include/asm/arch-exynos/mipi_dsim.h |2 +- > drivers/video/exynos_mipi_dsi_common.c | 60 > -- > drivers/video/exynos_mipi_dsi_common.h |2 +- > drivers/video/exynos_mipi_dsi_lowlevel.c |2 +- > drivers/video/exynos_mipi_dsi_lowlevel.h |2 +- > drivers/video/s6e8ax0.c | 59 ++--- > 6 files changed, 65 insertions(+), 62 deletions(-) > your patch seems broken. Please check and resend. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] ARM: imx: Fix incorrect usage of CONFIG_SYS_MMC_ENV_PART
From: Fabio Estevam
When running the "save" command several times on a mx6qsabresd we see:
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
This issue is caused by the incorrect usage of CONFIG_SYS_MMC_ENV_PART.
CONFIG_SYS_MMC_ENV_PART should be used to specify the mmc partition that stores
the environment variables.
On some imx boards it is been incorrectly used to pass the partition of kernel
and dtb files for the 'mmcpart' script variable.
Remove the CONFIG_SYS_MMC_ENV_PART usage and configure the 'mmcpart' variable
directly.
Reported-by: Jason Liu
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Fix in the config files by removing CONFIG_SYS_MMC_ENV_PART
Changes since v1:
- Do the change inside the mmc core
include/configs/mx53ard.h | 3 +--
include/configs/mx6qsabre_common.h | 2 +-
include/configs/mx6qsabreauto.h| 1 -
include/configs/mx6qsabresd.h | 1 -
include/configs/wandboard.h| 3 +--
5 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/configs/mx53ard.h b/include/configs/mx53ard.h
index 41974b1..b0a965f 100644
--- a/include/configs/mx53ard.h
+++ b/include/configs/mx53ard.h
@@ -118,7 +118,7 @@
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
- "mmcpart=" __stringify(CONFIG_SYS_MMC_ENV_PART) "\0" \
+ "mmcpart=2\0" \
"mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
"update_sd_firmware_filename=u-boot.imx\0" \
"update_sd_firmware=" \
@@ -240,7 +240,6 @@
#define CONFIG_ENV_SIZE(8 * 1024)
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 0
-#define CONFIG_SYS_MMC_ENV_PART2
#define CONFIG_OF_LIBFDT
diff --git a/include/configs/mx6qsabre_common.h
b/include/configs/mx6qsabre_common.h
index 7298a76..bfaa420 100644
--- a/include/configs/mx6qsabre_common.h
+++ b/include/configs/mx6qsabre_common.h
@@ -97,7 +97,7 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
- "mmcpart=" __stringify(CONFIG_SYS_MMC_ENV_PART) "\0" \
+ "mmcpart=1\0" \
"mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
"update_sd_firmware=" \
"if test ${ip_dyn} = yes; then " \
diff --git a/include/configs/mx6qsabreauto.h b/include/configs/mx6qsabreauto.h
index 1583c11..f2ff3e1 100644
--- a/include/configs/mx6qsabreauto.h
+++ b/include/configs/mx6qsabreauto.h
@@ -35,7 +35,6 @@
#define CONFIG_SYS_FSL_USDHC_NUM 2
#if defined(CONFIG_ENV_IS_IN_MMC)
#define CONFIG_SYS_MMC_ENV_DEV 0
-#define CONFIG_SYS_MMC_ENV_PART1 /* Boot partition 1 */
#endif
#endif /* __MX6QSABREAUTO_CONFIG_H */
diff --git a/include/configs/mx6qsabresd.h b/include/configs/mx6qsabresd.h
index 3b8d752..44f07cb 100644
--- a/include/configs/mx6qsabresd.h
+++ b/include/configs/mx6qsabresd.h
@@ -29,7 +29,6 @@
#define CONFIG_SYS_FSL_USDHC_NUM 3
#if defined(CONFIG_ENV_IS_IN_MMC)
#define CONFIG_SYS_MMC_ENV_DEV 1 /* SDHC3 */
-#define CONFIG_SYS_MMC_ENV_PART1 /* Boot partition 1 */
#endif
#endif /* __MX6QSABRESD_CONFIG_H */
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index d4ac086..34a8f15 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -116,7 +116,7 @@
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
- "mmcpart=" __stringify(CONFIG_SYS_MMC_ENV_PART) "\0" \
+ "mmcpart=2\0" \
"mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
"update_sd_firmware_filename=u-boot.imx\0" \
"update_sd_firmware=" \
@@ -230,7 +230,6 @@
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_ENV_OFFSET (6 * 64 * 1024)
#define CONFIG_SYS_MMC_ENV_DEV 0
-#define CONFIG_SYS_MMC_ENV_PART2
#define CONFIG_OF_LIBFDT
#define CONFIG_CMD_BOOTZ
--
1.8.1.2
ts
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On Tue, Jun 4, 2013 at 8:30 PM, Stephen Warren wrote: > Do you have CONFIG_SYS_MMC_ENV_PART set? I wasn't aware anyone else used > it, besides Tegra. Yes, this is the issue. CONFIG_SYS_MMC_ENV_PART is used incorrectly on this board. Will update its config file. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On 06/04/2013 05:16 PM, Fabio Estevam wrote:
> On Tue, Jun 4, 2013 at 7:12 PM, Stephen Warren wrote:
>
>> static void fini_mmc_for_env(struct mmc *mmc)
>> {
>> #ifdef CONFIG_SYS_MMC_ENV_PART
>> - if (CONFIG_SYS_MMC_ENV_PART != mmc->part_num)
>> + if (mmc->part_num != orig_part_num)
>> mmc_switch_part(CONFIG_SYS_MMC_ENV_DEV,
>> - mmc->part_num);
>> + orig_part_num);
>
> If I keep the original 'mmc->part_num' here, then it works.
It doesn't "work", it just hides the problem. By passing mmc->part_num
here, you're passing the partition that's already/currently selected
rather than restoring the original value. Selecting it again is a no-op;
IIRC the MMC core explicitly checks for this condition and immediately
returns without touching the HW.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On 06/04/2013 05:09 PM, Fabio Estevam wrote: > On Tue, Jun 4, 2013 at 7:12 PM, Stephen Warren wrote: > >> In env_mmc.c, you'll want something like: > > Thanks for the patch, but when I add these changes on top of my patch > it results in the original error: Of course; with that patch applied, there is no effective difference in the code - you've just cleaned it up to have the MMC core manage mmc->part_num, rather than requiring all callers to update it themselves. > U-Boot > save > Saving Environment to MMC... > Writing to MMC(1)... done > U-Boot > save > Saving Environment to MMC... > MMC partition switch failed > U-Boot > I have no idea why that happens. You'll simply have to debug the code. Do you have CONFIG_SYS_MMC_ENV_PART set? I wasn't aware anyone else used it, besides Tegra. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On Tue, Jun 4, 2013 at 7:12 PM, Stephen Warren wrote:
> static void fini_mmc_for_env(struct mmc *mmc)
> {
> #ifdef CONFIG_SYS_MMC_ENV_PART
> - if (CONFIG_SYS_MMC_ENV_PART != mmc->part_num)
> + if (mmc->part_num != orig_part_num)
> mmc_switch_part(CONFIG_SYS_MMC_ENV_DEV,
> - mmc->part_num);
> + orig_part_num);
If I keep the original 'mmc->part_num' here, then it works.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On Tue, Jun 4, 2013 at 7:12 PM, Stephen Warren wrote: > In env_mmc.c, you'll want something like: Thanks for the patch, but when I add these changes on top of my patch it results in the original error: U-Boot > save Saving Environment to MMC... Writing to MMC(1)... done U-Boot > save Saving Environment to MMC... MMC partition switch failed U-Boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On 06/04/2013 02:45 PM, Fabio Estevam wrote:
> Hi Stephen,
>
> On Tue, Jun 4, 2013 at 4:36 PM, Stephen Warren wrote:
>
>> That seems like a reasonable way for the code to work. However, you'd
>> need to modify common/env_mmc.c:init_mmc_for_env() so that it saves off
>> mmc->part_num before switching MMC partitions, so that
>> fini_mmc_for_env() knows which partition to switch back to. Right now,
>> it relies on the fact that mmc_switch_part() does not update
>> mmc->part_num, and hence uses that value to save the previously selected
>> partition ID.
>>
>> Also, if you make this change, I think you can update
>> common/cmd_mmc.c:do_mmcops(), since it will no longer need to update
>> mmc->part_num after a successful switch.
>
> I understood your second suggestion and did the changes below, but I
> am not sure on the first one regarding the change you proposed inside
> init_mmc_for_env().
In env_mmc.c, you'll want something like:
+#ifdef CONFIG_SYS_MMC_ENV_PART
+static char orig_part_num;
+#ifdef CONFIG_SYS_MMC_ENV_PART
static int init_mmc_for_env(struct mmc *mmc)
...
#ifdef CONFIG_SYS_MMC_ENV_PART
+ orig_part_num = mmc->part_num;
if (CONFIG_SYS_MMC_ENV_PART != mmc->part_num) {
if (mmc_switch_part(CONFIG_SYS_MMC_ENV_DEV,
CONFIG_SYS_MMC_ENV_PART)) {
puts("MMC partition switch failed\n");
return -1;
}
}
#endif
...
static void fini_mmc_for_env(struct mmc *mmc)
{
#ifdef CONFIG_SYS_MMC_ENV_PART
- if (CONFIG_SYS_MMC_ENV_PART != mmc->part_num)
+ if (mmc->part_num != orig_part_num)
mmc_switch_part(CONFIG_SYS_MMC_ENV_DEV,
- mmc->part_num);
+ orig_part_num);
#endif
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
On Tue, Jun 04, 2013 at 09:03:12AM +0200, Heiko Schocher wrote: > Hello Lubomir, > > Am 04.06.2013 08:49, schrieb Lubomir Popov: > > Hi Heiko, > > > > On 04/06/13 07:26, Heiko Schocher wrote: > >> Hello Lubomir, > >> > >> Am 03.06.2013 07:13, schrieb Heiko Schocher: > >>> Hello Lubomir, > >>> > >>> Am 02.06.2013 13:42, schrieb Lubomir Popov: > > Hello Lubomir, > > > > Am 01.06.2013 18:44, schrieb Lubomir Popov: > >> New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4 > >> (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older > >> OMAPs and derivatives as well. The only anticipated exception would > >> be the OMAP2420, which shall require driver modification. > >>> [...] > >> drivers/i2c/omap24xx_i2c.c | 490 > >> +++-- > >> 1 file changed, 299 insertions(+), 191 deletions(-) > > > > Tested on 3 arm335x based boards, which one uses i2c in SPL > > code for getting ram parameters, so: > > > > Tested-by: Heiko Schocher > Many thanks for testing, to Tom as well (he did it on the > Beagleboards, but for one of the older versions, V3 I believe, > right?). > When it comes to versions, I see that V1 and V2 are still listed > in patchwork, probably because of slightly different wording of > the subject: > http://patchwork.ozlabs.org/patch/233823/ > http://patchwork.ozlabs.org/patch/246204/ > Could you or Tom clean this up, please? Thanks. > >>> > >>> Cleared the v3 v4 version, but missed the v2 and v1, Done. > >> > >> just doing a "MAKEALL arm" with your patch applied and get this error: > >> > >> Configuring for omap2420h4 board... > >> omap24xx_i2c.c:497:17: error: 'struct i2c' has no member named > >> 'irqstatus_raw' > >> omap24xx_i2c.c:528:12: error: 'struct i2c' has no member named > >> 'irqstatus_raw' > >> arm-linux-gnueabi-size: './u-boot': No such file > >> omap24xx_i2c.c: In function 'wait_for_bb': > >> omap24xx_i2c.c:497:17: error: 'struct i2c' has no member named > >> 'irqstatus_raw' > >> omap24xx_i2c.c: In function 'wait_for_event': > >> omap24xx_i2c.c:528:12: error: 'struct i2c' has no member named > >> 'irqstatus_raw' > >> make[1]: *** [omap24xx_i2c.o] Fehler 1 > >> make: *** [drivers/i2c/libi2c.o] Fehler 2 > >> make: *** Warte auf noch nicht beendete Prozesse... > >> > >> Please fix this and run a "MAKEALL arm" before repost, thanks! > > We have agreed upon this breakage with Tom - the OMAP2420 shall not > > be supported anymore in the next release. At least I understood it > > that way (and have noted it accordingly in the comments). > > Ah, ok ... so affected boards should fixed too ... > > @Tom: Could you than pick up this patch? Yes, I just need to post the patch removing omap2420h2 support. -- 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
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
> ---
> 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" \
> @@ -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!
--
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, am33xx: add defines for gmii_sel_register bits
On Tue, Jun 04, 2013 at 11:03:18AM +0200, Heiko Schocher wrote: > move gmii_sel register defines from board code to common place. [snip] > /* MII mode defines */ > -#define RMII_MODE_ENABLE 0x4D > +#define RMII_MODE_P1_ENABLE 0x4D [snip] > /* MII mode defines */ > -#define MII_MODE_ENABLE 0x0 > -#define RGMII_MODE_ENABLE0xA > #define RMII_RGMII2_MODE_ENABLE 0x49 Looks like there's a few bits you're leaving in the board files still, please move them all over since they come from the TRM, right? 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] arm, am335x: make mpu pll config configurable
On Tue, Jun 04, 2013 at 11:01:06AM +0200, Heiko Schocher wrote: > upcoming support for siemens boards switches mpu pll clk in board > code. So make this configurable. > > Signed-off-by: Heiko Schocher > Cc: Tom Rini Wait, didn't we already something like this posted? -- 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, am33xx: move uart soft reset code to common place
On Tue, Jun 04, 2013 at 11:00:57AM +0200, Heiko Schocher wrote: > move uart soft reset code to common place and call > this function from board code, instead of copy and paste > this code for every board. > > Signed-off-by: Heiko Schocher > Cc: Matt Porter > Cc: Lars Poeschel > Cc: Tom Rini > Cc: Enric Balletbo i Serra Acked-by: Tom Rini -- 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
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 > Cc: Albert Aribaud > Cc: Tom Rini Reviewed-by: Tom Rini 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. -- 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, spl: add watchdog library to SPL
On Tue, Jun 04, 2013 at 10:55:10AM +0200, Heiko Schocher wrote: > Signed-off-by: Heiko Schocher > Cc: Tom Rini Reviewed-by: Tom Rini -- 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, am33xx: move rtc32k_enable() to common place
On Tue, Jun 04, 2013 at 11:00:50AM +0200, Heiko Schocher wrote: > move rtc32k_enable() to common place so all am33xx boards can use it. [snip] > +#ifdef CONFIG_SPL_BUILD > +void rtc32k_enable(void); > +#endif No need for ifdef on prototypes. Otherwise, good cleanup, 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
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 > >>> > >>> add dra mmc pbias support and ldo1 power on > >>> > >>> Signed-off-by: Balaji T K > >>> Signed-off-by: Lokesh Vutla > >>> --- > >>> 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. -- 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] mmc: Update "mmc->part_num" when performing a partition switch
Hi Stephen,
On Tue, Jun 4, 2013 at 4:36 PM, Stephen Warren wrote:
> That seems like a reasonable way for the code to work. However, you'd
> need to modify common/env_mmc.c:init_mmc_for_env() so that it saves off
> mmc->part_num before switching MMC partitions, so that
> fini_mmc_for_env() knows which partition to switch back to. Right now,
> it relies on the fact that mmc_switch_part() does not update
> mmc->part_num, and hence uses that value to save the previously selected
> partition ID.
>
> Also, if you make this change, I think you can update
> common/cmd_mmc.c:do_mmcops(), since it will no longer need to update
> mmc->part_num after a successful switch.
I understood your second suggestion and did the changes below, but I
am not sure on the first one regarding the change you proposed inside
init_mmc_for_env().
Here is what I did so far:
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 7d82469..20a2792 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -243,8 +243,6 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
if (part != mmc->part_num) {
ret = mmc_switch_part(dev, part);
- if (!ret)
- mmc->part_num = part;
printf("switch to partions #%d, %s\n",
part, (!ret) ? "OK" : "ERROR");
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 0a2f535..e8d2ea6 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -702,14 +702,20 @@ static int mmc_change_freq(struct mmc *mmc)
int mmc_switch_part(int dev_num, unsigned int part_num)
{
+ int ret;
struct mmc *mmc = find_mmc_device(dev_num);
if (!mmc)
return -1;
- return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
+ ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
(mmc->part_config & ~PART_ACCESS_MASK)
| (part_num & PART_ACCESS_MASK));
+
+ if (!ret)
+ mmc->part_num = part_num;
+
+ return ret;
}
int mmc_getcd(struct mmc *mmc)
--
1.8.1.2
Could you please explain the change you proposed for saving
mmc->part_num inside init_mmc_for_env() ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC
I'll take them. It's on my todo list for this week On Jun 4, 2013, at 14:31, "Stephen Warren" wrote: > On 05/23/2013 02:51 PM, Stephen Warren wrote: >> From: Stephen Warren >> >> Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that >> must or can be set when using that option. > > Andy, do you intend to take these patches for the upcoming release, or > defer them until the next one? Thanks. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: only enable SCU on Tegra20
Sorry, my BW is being used up by internal projects. I'll pull it down, apply/build/test in u-boot-tegra/next, and then I can send a PR to Albert if you think it needs to move higher up right away. Tom > -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Tuesday, June 04, 2013 12:34 PM > To: Tom Warren > Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren > Subject: Re: [U-Boot] [PATCH] ARM: tegra: only enable SCU on Tegra20 > > On 05/23/2013 04:26 PM, Stephen Warren wrote: > > From: Tom Warren > > > > The non-SPL build of U-Boot on Tegra only runs on a single CPU, and > > hence there is no need to enable the SCU when running U-Boot. If an > > SMP OS is booted, and it needs the SCU enabled, it will enable the SCU > > itself. U-Boot doing so is redundant. > > > > The one exception is Tegra20, where an enabled SCU is required for > > some aspects of PCIe to work correctly. > > > > Some Tegra SoCs contain CPUs without a software-controlled SCU. In > > this case, attempting to turn it on actively causes problems. This is > > the case for Tegra114. For example, when running Linux, the first (or > > at least some very early) user-space process will trigger the > > following kernel > > message: > > > > Unhandled fault: imprecise external abort (0x406) at 0x > > > > This is typically accompanied by that process receving a fatal signal, > > and exiting. Since this process is usually pid 1, this causes total > > system boot failure. > > Tom, is this patch OK? It's a rather critical bug-fix for Tegra114, so I'd > like to > make sure it gets into the upcoming release. Thanks. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: make data buffer size configurable
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.. > -#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 :) -- 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] mmc: Update "mmc->part_num" when performing a partition switch
On 06/04/2013 01:30 PM, Fabio Estevam wrote: > On Tue, Jun 4, 2013 at 4:21 PM, Stephen Warren wrote: > >> This surely has exactly the same issue as the previous version, where >> the update of part_num was done inside common/env_mmc.c? > > My understading is that the mmc core should update mmc->part_num and I > don't see such update, or am I missing something? That seems like a reasonable way for the code to work. However, you'd need to modify common/env_mmc.c:init_mmc_for_env() so that it saves off mmc->part_num before switching MMC partitions, so that fini_mmc_for_env() knows which partition to switch back to. Right now, it relies on the fact that mmc_switch_part() does not update mmc->part_num, and hence uses that value to save the previously selected partition ID. Also, if you make this change, I think you can update common/cmd_mmc.c:do_mmcops(), since it will no longer need to update mmc->part_num after a successful switch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: only enable SCU on Tegra20
On 05/23/2013 04:26 PM, Stephen Warren wrote: > From: Tom Warren > > The non-SPL build of U-Boot on Tegra only runs on a single CPU, and > hence there is no need to enable the SCU when running U-Boot. If an > SMP OS is booted, and it needs the SCU enabled, it will enable the SCU > itself. U-Boot doing so is redundant. > > The one exception is Tegra20, where an enabled SCU is required for some > aspects of PCIe to work correctly. > > Some Tegra SoCs contain CPUs without a software-controlled SCU. In this > case, attempting to turn it on actively causes problems. This is the case > for Tegra114. For example, when running Linux, the first (or at least > some very early) user-space process will trigger the following kernel > message: > > Unhandled fault: imprecise external abort (0x406) at 0x > > This is typically accompanied by that process receving a fatal signal, > and exiting. Since this process is usually pid 1, this causes total > system boot failure. Tom, is this patch OK? It's a rather critical bug-fix for Tegra114, so I'd like to make sure it gets into the upcoming release. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC
On 05/23/2013 02:51 PM, Stephen Warren wrote: > From: Stephen Warren > > Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that > must or can be set when using that option. Andy, do you intend to take these patches for the upcoming release, or defer them until the next one? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On Tue, Jun 4, 2013 at 4:21 PM, Stephen Warren wrote: > This surely has exactly the same issue as the previous version, where > the update of part_num was done inside common/env_mmc.c? My understading is that the mmc core should update mmc->part_num and I don't see such update, or am I missing something? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] input: simplify key_matrix_decode_fdt()
On 05/23/2013 04:09 PM, Stephen Warren wrote: > From: Stephen Warren > > 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. Tom, is this likely to be applied for the upcoming release, or would it be deferred until the next? Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] input: fix unaligned access in key_matrix_decode_fdt()
On 05/22/2013 12:48 PM, Stephen Warren wrote: > From: Stephen Warren > > 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. Tom, does this patch look good? The discussion following it was unrelated to this patch, but rather related to pre-processing of device-trees, so I don't think should prevent this patch being merged. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
On 06/04/2013 01:17 PM, Fabio Estevam wrote: > When running the "save" command several times on a mx6qsabresd we see: > > U-Boot > save > Saving Environment to MMC... > Writing to MMC(1)... done > U-Boot > save > Saving Environment to MMC... > MMC partition switch failed > U-Boot > save > Saving Environment to MMC... > Writing to MMC(1)... done > U-Boot > save > Saving Environment to MMC... > MMC partition switch failed > U-Boot > save > Saving Environment to MMC... > Writing to MMC(1)... done > U-Boot > save > Saving Environment to MMC... > MMC partition switch failed > > Fix this by updating mmc->part_num inside mmc_switch_part() after a succesful > mmc partition switch. This surely has exactly the same issue as the previous version, where the update of part_num was done inside common/env_mmc.c? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mmc: Update "mmc->part_num" when performing a partition switch
When running the "save" command several times on a mx6qsabresd we see:
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
Fix this by updating mmc->part_num inside mmc_switch_part() after a succesful
mmc partition switch.
After this fix, we no longer see the error after the "save" command on a
mx6qsabresd. Also tested on a mx53loco.
Reported-by: Jason Liu
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Do the change inside the mmc core
drivers/mmc/mmc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 2590f1b..7f568ed 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -680,14 +680,20 @@ static int mmc_change_freq(struct mmc *mmc)
int mmc_switch_part(int dev_num, unsigned int part_num)
{
+ int ret;
struct mmc *mmc = find_mmc_device(dev_num);
if (!mmc)
return -1;
- return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
+ ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
(mmc->part_config & ~PART_ACCESS_MASK)
| (part_num & PART_ACCESS_MASK));
+
+ if (!ret)
+ mmc->part_num = part_num;
+
+ return ret;
}
int mmc_getcd(struct mmc *mmc)
--
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 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts
Jagan,
So far, our major customer request is to have the same ID for backward
compatibility. Therefore the IDs are the same for W25Q16C and W25Q16D. As for
the 2.5V parts (W25Q80BL/W25Q16CL), they are the same die as the 3V
(W25Q80BV/W25Q16CV), so the IDs are the same as well.
The differences between the pairs are not that significant. We consider them as
drop-in compatible.
Best Regards,
Mike Chen
Technical Marketing
Winbond Electronics Corp. America
(408)544-2667
-Original Message-
From: US30 Syed Hussain
Sent: Tuesday, June 04, 2013 10:12 AM
To: Jagan Teki; US20 Hui (Mike) Chen
Cc: u-boot@lists.denx.de; Michal Simek; Tom Rini; Simon Glass; Jagannadha
Sutradharudu Teki
Subject: RE: [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's
flash parts
Copying Mike, Technical Marketing Director
-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: Monday, June 03, 2013 11:03 PM
To: US30 Syed Hussain
Cc: u-boot@lists.denx.de; Michal Simek; Tom Rini; Simon Glass; Jagannadha
Sutradharudu Teki
Subject: Re: [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's
flash parts
Hi Syed,
On Mon, Jun 3, 2013 at 12:53 AM, Jagan Teki wrote:
> Hi,
>
> On Thu, May 30, 2013 at 7:19 PM, Jagannadha Sutradharudu Teki
> wrote:
>> Use the exact names for W25Q 0x40XX ID's flash parts, as the same
>> sizes of flashes comes with different ID's. so-that the distinguishes
>> becomes easy with this change.
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki
>> ---
>> Changes for v2:
>> - none
>>
>> drivers/mtd/spi/winbond.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
>> index 8457808..3c0ca88 100644
>> --- a/drivers/mtd/spi/winbond.c
>> +++ b/drivers/mtd/spi/winbond.c
>> @@ -55,27 +55,27 @@ static const struct winbond_spi_flash_params
>> winbond_spi_flash_table[] = {
>> {
>> .id = 0x4014,
>> .nr_blocks = 16,
>> - .name = "W25Q80BL",
>> + .name = "W25Q80BL/W25Q80BV",
>> },
>> {
>> .id = 0x4015,
>> .nr_blocks = 32,
>> - .name = "W25Q16",
>> + .name = "W25Q16CL/W25Q16DV",
>
> The id codes were same for these two parts, I think there is no way to
> detect the separately.
> Any idea?
Any comments on this.
--
Thanks,
Jagan.
The privileged confidential information contained in this email is intended for
use only by the addressees as indicated by the original sender of this email.
If you are not the addressee indicated in this email or are not responsible for
delivery of the email to such a person, please kindly reply to the sender
indicating this fact and delete all copies of it from your computer and network
server immediately. Your cooperation is highly appreciated. It is advised that
any unauthorized use of confidential information of Winbond is strictly
prohibited; and any information in this email irrelevant to the official
business of Winbond shall be deemed as neither given nor endorsed by Winbond.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common: env_mmc: Make mmc->part_num in sync after a partition switch
On 06/04/2013 12:23 PM, Fabio Estevam wrote: > When running the "save" command several times on a mx6qsabresd we see: > > U-Boot > save > Saving Environment to MMC... > Writing to MMC(1)... done > U-Boot > save > Saving Environment to MMC... > MMC partition switch failed ... > Fix this by making mmc->part_num to be in sync with CONFIG_SYS_MMC_ENV_PART > after the partition has been changed in mmc_switch_part(). I deliberately didn't do this, because fini_mmc_for_env() passes the value of mmc->part_num to call mmc_switch_part() in order to put things back the way they were. This fix would break that. Can you investigate why you're seeing the "MMC partition switch failed" message? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common: env_mmc: Make mmc->part_num in sync after a partition switch
When running the "save" command several times on a mx6qsabresd we see:
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
U-Boot > save
Saving Environment to MMC...
Writing to MMC(1)... done
U-Boot > save
Saving Environment to MMC...
MMC partition switch failed
Fix this by making mmc->part_num to be in sync with CONFIG_SYS_MMC_ENV_PART
after the partition has been changed in mmc_switch_part().
After this fix, we no longer see the error after the "save" command on a
mx6qsabresd. Also tested on a mx53loco.
Reported-by: Jason Liu
Signed-off-by: Fabio Estevam
---
common/env_mmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/env_mmc.c b/common/env_mmc.c
index 9ca098f..8020fc5 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -89,6 +89,7 @@ static int init_mmc_for_env(struct mmc *mmc)
puts("MMC partition switch failed\n");
return -1;
}
+ mmc->part_num = CONFIG_SYS_MMC_ENV_PART;
}
#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] video:lcd:cfb_console: cm_t35: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
Adding Anatolij to the CC list.
On Tue, Jun 4, 2013 at 8:10 AM, Robert Winkler
wrote:
> Hi Igor,
>
> On Mon, Jun 3, 2013 at 11:10 PM, Igor Grinberg
> 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
>
> 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.
>
>
>>>
>>> Signed-off-by: Robert Winkler
>>> ---
>>> 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?
>
>>
>>> +
>>> addr = simple_strtoul(s, NULL, 16);
>>>
>>>
>>>
>>
>> --
>> Regards,
>> Igor.
>
> Robert Winkler
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patches never reviewed
On 06/04/2013 12:47:47 PM, Scott Wood wrote: On 06/03/2013 03:51:48 PM, Angelo Dureghello wrote: Dear All, i worked hardly through v6 for approval of this AMCORE Coldfire board support. Waited patiently for review of this patches: http://patchwork.ozlabs.org/patch/215904/ http://patchwork.ozlabs.org/patch/214686/ then asked again later for the review: http://marc.info/?l=u-boot&m=136059580219228&w=2 still, at today, i had no feedbacks. Unfortunately (i can be wrong) but i have the impression at freescale no-one have time to spend for following this board addition. Jason Jin is the Coldfire custodian. I've added him on CC here; please be sure to put him on CC when you send Coldfire patches or inquiries. Sigh, and of course the list ate the CC. So for all I know maybe you had him on CC to begin with... Another thing that can help is using better subject lines. "patches review" isn't going to let people know what sort of patches they are and if it's their responsibility or not. Likewise, "board: add support for amcore board" doesn't have m68k or coldfire in the title (whereas "board:" is redundant). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patches never reviewed
On 06/03/2013 03:51:48 PM, Angelo Dureghello wrote: Dear All, i worked hardly through v6 for approval of this AMCORE Coldfire board support. Waited patiently for review of this patches: http://patchwork.ozlabs.org/patch/215904/ http://patchwork.ozlabs.org/patch/214686/ then asked again later for the review: http://marc.info/?l=u-boot&m=136059580219228&w=2 still, at today, i had no feedbacks. Unfortunately (i can be wrong) but i have the impression at freescale no-one have time to spend for following this board addition. Jason Jin is the Coldfire custodian. I've added him on CC here; please be sure to put him on CC when you send Coldfire patches or inquiries. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts
On Tue, Jun 4, 2013 at 10:49 PM, mch...@winbond.com wrote: > Jagan, > > So far, our major customer request is to have the same ID for backward > compatibility. Therefore the IDs are the same for W25Q16C and W25Q16D. As for > the 2.5V parts (W25Q80BL/W25Q16CL), they are the same die as the 3V > (W25Q80BV/W25Q16CV), so the IDs are the same as well. > > The differences between the pairs are not that significant. We consider them > as drop-in compatible. Ok, thanks for your response. 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", -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's flash parts
Copying Mike, Technical Marketing Director
-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: Monday, June 03, 2013 11:03 PM
To: US30 Syed Hussain
Cc: u-boot@lists.denx.de; Michal Simek; Tom Rini; Simon Glass; Jagannadha
Sutradharudu Teki
Subject: Re: [PATCH v2 5/8] sf: winbond: Update the names for W25Q 0x40XX ID's
flash parts
Hi Syed,
On Mon, Jun 3, 2013 at 12:53 AM, Jagan Teki wrote:
> Hi,
>
> On Thu, May 30, 2013 at 7:19 PM, Jagannadha Sutradharudu Teki
> wrote:
>> Use the exact names for W25Q 0x40XX ID's flash parts, as the same
>> sizes of flashes comes with different ID's. so-that the distinguishes
>> becomes easy with this change.
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki
>> ---
>> Changes for v2:
>> - none
>>
>> drivers/mtd/spi/winbond.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
>> index 8457808..3c0ca88 100644
>> --- a/drivers/mtd/spi/winbond.c
>> +++ b/drivers/mtd/spi/winbond.c
>> @@ -55,27 +55,27 @@ static const struct winbond_spi_flash_params
>> winbond_spi_flash_table[] = {
>> {
>> .id = 0x4014,
>> .nr_blocks = 16,
>> - .name = "W25Q80BL",
>> + .name = "W25Q80BL/W25Q80BV",
>> },
>> {
>> .id = 0x4015,
>> .nr_blocks = 32,
>> - .name = "W25Q16",
>> + .name = "W25Q16CL/W25Q16DV",
>
> The id codes were same for these two parts, I think there is no way to
> detect the separately.
> Any idea?
Any comments on this.
--
Thanks,
Jagan.
The privileged confidential information contained in this email is intended for
use only by the addressees as indicated by the original sender of this email.
If you are not the addressee indicated in this email or are not responsible for
delivery of the email to such a person, please kindly reply to the sender
indicating this fact and delete all copies of it from your computer and network
server immediately. Your cooperation is highly appreciated. It is advised that
any unauthorized use of confidential information of Winbond is strictly
prohibited; and any information in this email irrelevant to the official
business of Winbond shall be deemed as neither given nor endorsed by Winbond.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bug, nand, am33xx: nand->ecc.strength not set in board_nand_init()
On 06/04/2013 03:52:32 AM, Heiko Schocher wrote: commit dfe64e2c89731a3f9950d7acd8681b68df2bae03 Author: Sergey Lapin Date: Mon Jan 14 03:46:50 2013 + mtd: resync with Linux-3.7.1 Introduced runtime bug: U-Boot 2013.04-00499-g46567df-dirty (Jun 04 2013 - 08:17:08) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: BUG: failure at nand_base.c:3214/nand_scan_tail()! BUG! resetting ... on boards using drivers/mtd/nand/omap_gpmc.c as in board_nand_init() nand->ecc.strength is not set. Fix this! Thanks, applied to u-boot-nand-flash. We did try to update all the existing drivers to do this. Omap_gpmc did get updated, but it was incomplete, as unlike most drivers, it has two different places where this stuff gets initialized (the actual init, and the ecc switch command). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx:Add iprot input arg in create_TLB0/1_entry
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 --- 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. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx:Add iprot input arg in create_TLB0/1_entry
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 --- Based upon git://git.denx.de/u-boot.git branch master NACK as discussed in the thread where you suggested this. -Scott ___ 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
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.
Regards
Mugunthan V N
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
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
---
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" \
"fdt_high=0x\0" \
"fdtaddr=0x80f8\0" \
"bootpart=0:2\0" \
@@ -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 " \
"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
#define CONFIG_BOOTCOMMAND \
--
1.7.5.4
___
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
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) ?
Indeed. Anyway, I have to check, if this patch is necessary, as Tom
noted ...
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] [PATCH v7] Add support for Congatec Conga-QEVAl board
Dear "SARTRE Leo", In message <3465d313fdfb824f9a9c8cd24fa4f6bc0108c...@frontmail.adetel.com> you wrote: > Add minimal support (only boot from mmc device) for the Congatec > Conga-QEVAl Evaluation Carrier Board with conga-Qmx6q (i.MX6 Quad > processor) module. Checkpatch complains about two too long lines. COuld you please fix these? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Roses are red Violets are blue Some poems rhyme ___ 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
Hi Igor,
On Mon, Jun 3, 2013 at 11:10 PM, Igor Grinberg 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
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.
>>
>> Signed-off-by: Robert Winkler
>> ---
>> 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?
>
>> +
>> addr = simple_strtoul(s, NULL, 16);
>>
>>
>>
>
> --
> Regards,
> Igor.
Robert Winkler
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Hi Robert, On 04/06/2013 16:57, Robert Winkler wrote: > Yes, as Eric mentioned I submitted a patch yesterday which fixes > splash screen prepare not working > with CONFIG_VIDEO and will submit a separate patch to add the function > to nitrogen6x.c once that goes through. Ok, understood. > > The only difference is that we won't call it in board_video_skip in > nitrogen6x.c, it'll be called in > drv_video_init similar to the way it is called in lcd_logo from drv_lcd_init. > > Another thing that Eric pointed out that is a difference between > PREBOOT and SPLASH_SCREEN_PREPARE > is the former will always run but the latter will only run if there's > a display which is preferable. > > If I had submitted the fix first instead of just working around the > bug I would probably have saved > some confusion. Sorry about that. No worry - thanks for explanation, now we have better understood the issue. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] lcd: align bmp header when uncopmressing image
Dear Piotr Wilczek, In message <1370343625-16596-1-git-send-email-p.wilc...@samsung.com> you wrote: > When compressed image is loaded, it must be decompressed > to an aligned address + 2 to avoid unaligned access exception > on some ARM platforms. ... > + /* align to 32-bit-aligned-address + 2 */ > + if ((unsigned int)bmp % 4 != 2) > + bmp = (bmp_image_t *)unsigned int)dst + 1) & ~3) + 2); Please drop the "if()" - it is not necessary and just adds to the code size. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never underestimate the bandwidth of a station wagon full of tapes. -- Dr. Warren Jackson, Director, UTCS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Hi Eric, On 04/06/2013 16:30, Eric Nelson wrote: > Gotcha. This method doesn't involve splash_screen_prepare() though. > > It also will blink the display since the splash screen will paint > after the the compiled-in logo case. > http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=common/lcd.c#l1085 Right, this methods has drawbacks in your case. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net, cpsw: disable gigabit support through plattform data
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) ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Systems programmers are the high priests of a low cult.
-- R.S. Barton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Stefano
On Tue, Jun 4, 2013 at 7:30 AM, Eric Nelson
wrote:
> Hi Stefano,
>
>
> On 06/04/2013 07:15 AM, Stefano Babic wrote:
>>
>> Hi Eric,
>>
>> On 04/06/2013 15:55, Eric Nelson wrote:
>>>
>>> Hi Stefano,
>>>
>>> On 06/04/2013 06:44 AM, Stefano Babic wrote:
Hi Robert,
On 03/06/2013 18:34, Robert Winkler wrote:
>> Which is the advantage instead of using the "preboot" variable setting
>> CONFIG_PREBOOT ? It does pretty the same and you can move the whole
>> script outside of board code.
>
>
> The preboot command is run too late. It looks like it is run in
> main_loop but U-Boot looks for the splash image
> at the address in the splashimage variable in board_init_r ->
> stdio_init -> drv_lcd_init or drv_video_init (depending on
> whether you have CONFIG_LCD or CONFIG_VIDEO).
You are describing a bug - then it should be fixed globally, not only
for this board.
>>>
>>> What's the bug?
>>> - preboot being called too late, or
>>
>>
>> preboot is not called too late. The behavior is correct and wanted, as
>> the name says, and the variable is evaluated during the main loop before
>> booting. My suggestion comes because it is possible to implement a
>> splashscreen (even if the name can be misleading..), setting preboot to
>> something like "nand read ;bmp display ".
>> In your case (with a bmp image), it could be:
>> "preboot=if sf probe ; then " \
>> "sf read ${splashimage} c2000 ${splashsize} ; bmp display
>> ${splashimage}; fi\0"
>>
>> The behavior is exactly as the subject in the patch, the delay is from
>> power-on until main loop is called. It can be on some boards acceptable,
>> sometimes not.
>>
>
> Gotcha. This method doesn't involve splash_screen_prepare() though.
>
> It also will blink the display since the splash screen will paint
> after the the compiled-in logo case.
>
> http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=common/lcd.c#l1085
>
>
>>> - splash_screen_prepare() being called too early
>>>
>>> It seems that having splash_screen_prepare() called early
>>> makes sense, because stdout could be set to include VGA
>>> and having access to stdout is very useful in preboot
>>> commands.
>>
>>
>> You mention that it does not work, and then I assume that it is a bug,
>> because an image should be displayed. But again, if it does not work,
>> the issue is related to the video subsystem and should be fixed there
>> and not in board code - this is my point.
>>
Yes, as Eric mentioned I submitted a patch yesterday which fixes
splash screen prepare not working
with CONFIG_VIDEO and will submit a separate patch to add the function
to nitrogen6x.c once that goes through.
The only difference is that we won't call it in board_video_skip in
nitrogen6x.c, it'll be called in
drv_video_init similar to the way it is called in lcd_logo from drv_lcd_init.
Another thing that Eric pointed out that is a difference between
PREBOOT and SPLASH_SCREEN_PREPARE
is the former will always run but the latter will only run if there's
a display which is preferable.
If I had submitted the fix first instead of just working around the
bug I would probably have saved
some confusion. Sorry about that.
>
> This works with Robert's latest patch, which implements
> splash_screen_prepare() for boards that use cfb_console.
>
> It just wasn't implemented there.
>
> Regards,
>
>
> Eric
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Hi Stefano,
On 06/04/2013 07:15 AM, Stefano Babic wrote:
Hi Eric,
On 04/06/2013 15:55, Eric Nelson wrote:
Hi Stefano,
On 06/04/2013 06:44 AM, Stefano Babic wrote:
Hi Robert,
On 03/06/2013 18:34, Robert Winkler wrote:
Which is the advantage instead of using the "preboot" variable setting
CONFIG_PREBOOT ? It does pretty the same and you can move the whole
script outside of board code.
The preboot command is run too late. It looks like it is run in
main_loop but U-Boot looks for the splash image
at the address in the splashimage variable in board_init_r ->
stdio_init -> drv_lcd_init or drv_video_init (depending on
whether you have CONFIG_LCD or CONFIG_VIDEO).
You are describing a bug - then it should be fixed globally, not only
for this board.
What's the bug?
- preboot being called too late, or
preboot is not called too late. The behavior is correct and wanted, as
the name says, and the variable is evaluated during the main loop before
booting. My suggestion comes because it is possible to implement a
splashscreen (even if the name can be misleading..), setting preboot to
something like "nand read ;bmp display ".
In your case (with a bmp image), it could be:
"preboot=if sf probe ; then " \
"sf read ${splashimage} c2000 ${splashsize} ; bmp display
${splashimage}; fi\0"
The behavior is exactly as the subject in the patch, the delay is from
power-on until main loop is called. It can be on some boards acceptable,
sometimes not.
Gotcha. This method doesn't involve splash_screen_prepare() though.
It also will blink the display since the splash screen will paint
after the the compiled-in logo case.
http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=common/lcd.c#l1085
- splash_screen_prepare() being called too early
It seems that having splash_screen_prepare() called early
makes sense, because stdout could be set to include VGA
and having access to stdout is very useful in preboot
commands.
You mention that it does not work, and then I assume that it is a bug,
because an image should be displayed. But again, if it does not work,
the issue is related to the video subsystem and should be fixed there
and not in board code - this is my point.
This works with Robert's latest patch, which implements
splash_screen_prepare() for boards that use cfb_console.
It just wasn't implemented there.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
Over ride 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
---
include/configs/dra7xx_evm.h | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 28a306b..48c1b84 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -35,4 +35,41 @@
#define CONFIG_DRA7XX /* in a TI DRA7XX core */
#define CONFIG_SYS_PROMPT "DRA752 EVM # "
+/* Undefine the ENV_SETTINGS to redefine here */
+#undef CONFIG_EXTRA_ENV_SETTINGS
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ "loadaddr=0x8200\0" \
+ "console=ttyO0,115200n8\0" \
+ "fdt_high=0x\0" \
+ "fdtaddr=0x80f8\0" \
+ "bootpart=0:2\0" \
+ "bootdir=/boot\0" \
+ "bootfile=zImage\0" \
+ "usbtty=cdc_acm\0" \
+ "vram=16M\0" \
+ "partitions=" PARTS_DEFAULT "\0" \
+ "optargs=\0" \
+ "mmcdev=0\0" \
+ "mmcroot=/dev/mmcblk0p2 rw\0" \
+ "mmcrootfstype=ext4 rootwait\0" \
+ "mmcargs=setenv bootargs console=${console} " \
+ "${optargs} " \
+ "vram=${vram} " \
+ "root=${mmcroot} " \
+ "rootfstype=${mmcrootfstype}\0" \
+ "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+ "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
+ "source ${loadaddr}\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+ "env import -t ${loadaddr} ${filesize}\0" \
+ "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
+ "mmcboot=echo Booting from mmc${mmcdev} ...; " \
+ "run mmcargs; " \
+ "bootz ${loadaddr} - ${fdtaddr}\0" \
+ "findfdt="\
+ "if test $board_name = dra7xx; then " \
+ "setenv fdtfile dra7-evm.dtb; fi;\0 " \
+ "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
+
#endif /* __CONFIG_DRA7XX_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] Add splash screen support via loading from flash
Hi Eric,
On 04/06/2013 15:55, Eric Nelson wrote:
> Hi Stefano,
>
> On 06/04/2013 06:44 AM, Stefano Babic wrote:
>> Hi Robert,
>>
>> On 03/06/2013 18:34, Robert Winkler wrote:
>>
Which is the advantage instead of using the "preboot" variable setting
CONFIG_PREBOOT ? It does pretty the same and you can move the whole
script outside of board code.
>>>
>>> The preboot command is run too late. It looks like it is run in
>>> main_loop but U-Boot looks for the splash image
>>> at the address in the splashimage variable in board_init_r ->
>>> stdio_init -> drv_lcd_init or drv_video_init (depending on
>>> whether you have CONFIG_LCD or CONFIG_VIDEO).
>>
>> You are describing a bug - then it should be fixed globally, not only
>> for this board.
>>
>
> What's the bug?
> - preboot being called too late, or
preboot is not called too late. The behavior is correct and wanted, as
the name says, and the variable is evaluated during the main loop before
booting. My suggestion comes because it is possible to implement a
splashscreen (even if the name can be misleading..), setting preboot to
something like "nand read ;bmp display ".
In your case (with a bmp image), it could be:
"preboot=if sf probe ; then " \
"sf read ${splashimage} c2000 ${splashsize} ; bmp display
${splashimage}; fi\0"
The behavior is exactly as the subject in the patch, the delay is from
power-on until main loop is called. It can be on some boards acceptable,
sometimes not.
> - splash_screen_prepare() being called too early
>
> It seems that having splash_screen_prepare() called early
> makes sense, because stdout could be set to include VGA
> and having access to stdout is very useful in preboot
> commands.
You mention that it does not work, and then I assume that it is a bug,
because an image should be displayed. But again, if it does not work,
the issue is related to the video subsystem and should be fixed there
and not in board code - this is my point.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net, cpsw: disable gigabit support through plattform data
On Tue, Jun 04, 2013 at 10:51:54AM +0200, Heiko Schocher wrote: > add possibility to disable gigabit support through > plattform data. Current boards should not be affected > through this patch. > > Signed-off-by: Heiko Schocher Why? Based on some of your later patches, you're working with a customer that was sampled very early in am335x, but has newer silicon now. This looks like the work-around for very early parts where indeed, gigabit had to be disabled. We removed this from mainline (or from what was submitted to mainline, I forget which now) intentionally. NAK, without some new information coming to light. 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] Add splash screen support via loading from flash
Hi Stefano, On 06/04/2013 06:44 AM, Stefano Babic wrote: Hi Robert, On 03/06/2013 18:34, Robert Winkler wrote: Which is the advantage instead of using the "preboot" variable setting CONFIG_PREBOOT ? It does pretty the same and you can move the whole script outside of board code. The preboot command is run too late. It looks like it is run in main_loop but U-Boot looks for the splash image at the address in the splashimage variable in board_init_r -> stdio_init -> drv_lcd_init or drv_video_init (depending on whether you have CONFIG_LCD or CONFIG_VIDEO). You are describing a bug - then it should be fixed globally, not only for this board. What's the bug? - preboot being called too late, or - splash_screen_prepare() being called too early It seems that having splash_screen_prepare() called early makes sense, because stdout could be set to include VGA and having access to stdout is very useful in preboot commands. Please advise, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Hi Robert, On 03/06/2013 18:34, Robert Winkler wrote: >> Which is the advantage instead of using the "preboot" variable setting >> CONFIG_PREBOOT ? It does pretty the same and you can move the whole >> script outside of board code. > > The preboot command is run too late. It looks like it is run in > main_loop but U-Boot looks for the splash image > at the address in the splashimage variable in board_init_r -> > stdio_init -> drv_lcd_init or drv_video_init (depending on > whether you have CONFIG_LCD or CONFIG_VIDEO). You are describing a bug - then it should be fixed globally, not only for this board. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] lcd: align bmp header when uncopmressing image
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
Signed-off-by: Kyungmin Park
CC: Anatolij Gustschin
CC: Wolfgang Denk
---
Changes for V3:
- add comment on why extra space is allocated for 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 | 43 +--
include/lcd.h|3 ++-
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index 5a52edd..1c1e2a9 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,20 @@ 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 */
+ if ((unsigned int)bmp % 4 != 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 +81,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 +92,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 +202,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 +219,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 +239,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 +259,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 a/include/lcd.h b/include/lcd.h
index c
Re: [U-Boot] [PATCH v7] Add support for Congatec Conga-QEVAl board
On 04/06/2013 11:30, SARTRE Leo wrote: > Add minimal support (only boot from mmc device) for the Congatec > Conga-QEVAl Evaluation Carrier Board with conga-Qmx6q (i.MX6 Quad > processor) module. > > Signed-off-by: Leo Sartre > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dfu: make data buffer size configurable
Heiko, On Jun 4, 2013, at 1:31 PM, Heiko Schocher wrote: > Hello Pantelis, > > Am 04.06.2013 12:08, schrieb Pantelis Antoniou: >> Hi Heiko, >> >> Just thinking out loud here. Can we have an extra option that >> allocates the buffer dynamically based on an env variable? > > Hmm.. also a possibility... I have here no preferences ... > > Name: "dfu_data_buf_size" if not defined, or env invalid, use > default CONFIG_SYS_DFU_DATA_BUF_SIZE size? > > But this can be done in a second step, right? > Yes, only as a second step please. > bye, > Heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Regards -- Pantelis ___ 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
Hello Pantelis, Am 04.06.2013 12:08, schrieb Pantelis Antoniou: > Hi Heiko, > > Just thinking out loud here. Can we have an extra option that > allocates the buffer dynamically based on an env variable? Hmm.. also a possibility... I have here no preferences ... Name: "dfu_data_buf_size" if not defined, or env invalid, use default CONFIG_SYS_DFU_DATA_BUF_SIZE size? But this can be done in a second step, right? 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] powerpc/mpc85xx:Add iprot input arg in create_TLB0/1_entry
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 --- Based upon git://git.denx.de/u-boot.git branch master arch/powerpc/cpu/mpc85xx/start.S | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 4f0480b..cbe166d 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -174,11 +174,11 @@ l2_disabled: mtspr DBSR,r1 /* Clear all valid bits */ - .macro create_tlb1_entry esel ts tsize epn wimg rpn perm phy_high scratch + .macro create_tlb1_entry esel iprot ts tsize epn wimg rpn perm phy_high scratch lis \scratch, FSL_BOOKE_MAS0(1, \esel, 0)@h ori \scratch, \scratch, FSL_BOOKE_MAS0(1, \esel, 0)@l mtspr MAS0, \scratch - lis \scratch, FSL_BOOKE_MAS1(1, 1, 0, \ts, \tsize)@h + lis \scratch, FSL_BOOKE_MAS1(1, \iprot, 0, \ts, \tsize)@h ori \scratch, \scratch, FSL_BOOKE_MAS1(1, 1, 0, \ts, \tsize)@l mtspr MAS1, \scratch lis \scratch, FSL_BOOKE_MAS2(\epn, \wimg)@h @@ -196,11 +196,11 @@ l2_disabled: isync .endm - .macro create_tlb0_entry esel ts tsize epn wimg rpn perm phy_high scratch + .macro create_tlb0_entry esel iprot ts tsize epn wimg rpn perm phy_high scratch lis \scratch, FSL_BOOKE_MAS0(0, \esel, 0)@h ori \scratch, \scratch, FSL_BOOKE_MAS0(0, \esel, 0)@l mtspr MAS0, \scratch - lis \scratch, FSL_BOOKE_MAS1(1, 0, 0, \ts, \tsize)@h + lis \scratch, FSL_BOOKE_MAS1(1, \iprot, 0, \ts, \tsize)@h ori \scratch, \scratch, FSL_BOOKE_MAS1(1, 0, 0, \ts, \tsize)@l mtspr MAS1, \scratch lis \scratch, FSL_BOOKE_MAS2(\epn, \wimg)@h @@ -357,7 +357,7 @@ l2_disabled: */ /* create a temp mapping TLB0[0] for LBCR */ - create_tlb0_entry 0, \ + create_tlb0_entry 0, 1,\ 0, BOOKE_PAGESZ_4K, \ CONFIG_SYS_LBC_ADDR, MAS2_I|MAS2_G, \ CONFIG_SYS_LBC_ADDR, MAS3_SW|MAS3_SR, \ @@ -484,14 +484,14 @@ nexti:mflrr1 /* R1 = our PC */ * bacause flash's virtual address maps to 0xff80 - 0x. * and this window is outside of 4K boot window. */ - create_tlb1_entry CONFIG_SYS_PPC_E500_DEBUG_TLB, \ + create_tlb1_entry CONFIG_SYS_PPC_E500_DEBUG_TLB, 0,\ 0, BOOKE_PAGESZ_4M, \ CONFIG_SYS_MONITOR_BASE & 0xffc0, MAS2_I|MAS2_G, \ 0xffc0, MAS3_SX|MAS3_SW|MAS3_SR, \ 0, r6 #elif !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) - create_tlb1_entry CONFIG_SYS_PPC_E500_DEBUG_TLB, \ + create_tlb1_entry CONFIG_SYS_PPC_E500_DEBUG_TLB, 0,\ 0, BOOKE_PAGESZ_1M, \ CONFIG_SYS_MONITOR_BASE, MAS2_I|MAS2_G, \ CONFIG_SYS_PBI_FLASH_WINDOW, MAS3_SX|MAS3_SW|MAS3_SR, \ @@ -501,7 +501,7 @@ nexti: mflrr1 /* R1 = our PC */ * TLB entry is created for IVPR + IVOR15 to map on valid OP code address * because "nexti" will resize TLB to 4K */ - create_tlb1_entry CONFIG_SYS_PPC_E500_DEBUG_TLB, \ + create_tlb1_entry CONFIG_SYS_PPC_E500_DEBUG_TLB, 0,\ 0, BOOKE_PAGESZ_256K, \ CONFIG_SYS_MONITOR_BASE & 0xfffc, MAS2_I, \ CONFIG_SYS_MONITOR_BASE & 0xfffc, MAS3_SX|MAS3_SW|MAS3_SR, \ @@ -536,7 +536,7 @@ create_ccsr_new_tlb: ori r8, r8, CONFIG_SYS_CCSRBAR@l lis r9, (CONFIG_SYS_CCSRBAR + 0x1000)@h ori r9, r9, (CONFIG_SYS_CCSRBAR + 0x1000)@l - create_tlb0_entry 0, \ + create_tlb0_entry 0, 1,\ 0, BOOKE_PAGESZ_4K, \ CONFIG_SYS_CCSRBAR, MAS2_I|MAS2_G, \ CONFIG_SYS_CCSRBAR_PHYS_LOW, MAS3_SW|MAS3_SR, \ @@ -546,7 +546,7 @@ create_ccsr_new_tlb: * for the virtual address of this TLB (CONFIG_SYS_CCSRBAR + 0x1000). */ create_ccsr_old_tlb: - create_tlb0_entry 1, \ + create_tlb0_entry 1, 1,\ 0, BOOKE_PAGESZ_4K, \ CONFIG_SYS_CCSRBAR + 0x1000, MAS2_I|MAS2_G, \ CONFIG_SYS_CCSRBAR_DEFAULT, MAS3_SW|MAS3_SR, \ @@ -712,7 +712,7 @@ create_ccsr_l2_tlb: * Create a TLB for the MMR location of CCSR * to access L2CSR0 register */ - create_tlb0_entry 0, \ + create_tlb0_entry 0, 1\ 0, BOOKE_PAGESZ_4K, \ CONFIG_SYS_CCSRBAR + 0xC2, MAS2_I|MAS2_G, \ CONFIG_SYS_CCSRBAR_PHYS_LOW + 0xC2, MAS3_SW|MAS3_SR, \ @@ -1041,7 +1041,7 @@ create_init_ram_area: #ifdef NOR_BOOT /* create a temp mapping in AS=1 to the 4M boot win
Re: [U-Boot] dfu: make data buffer size configurable
Hi Heiko,
> Dfu transfer uses a buffer before writing data to the
> raw storage device. Make the size (in bytes) of this buffer
> configurable.
>
Acked-by: Lukasz Majewski
> Signed-off-by: Heiko Schocher
> Cc: Pantelis Antoniou
> Cc: Tom Rini
> Cc: Lukasz Majewski
> Cc: Kyungmin Park
> Cc: Marek Vasut
> ---
> README| 5 +
> drivers/dfu/dfu.c | 2 +-
> include/dfu.h | 4 +++-
> 3 Dateien geändert, 9 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
>
> diff --git a/README b/README
> index b1b3e17..8550f34 100644
> --- a/README
> +++ b/README
> @@ -1360,6 +1360,11 @@ The following options need to be configured:
> CONFIG_DFU_NAND
> This enables support for exposing NAND devices via
> DFU.
> + 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
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index 6af6890..fe3a36e 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -42,7 +42,7 @@ static int dfu_find_alt_num(const char *s)
> }
>
> static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
> - dfu_buf[DFU_DATA_BUF_SIZE];
> +
> dfu_buf[CONFIG_SYS_DFU_DATA_BUF_SIZE];
> static int dfu_write_buffer_drain(struct dfu_entity *dfu)
> {
> diff --git a/include/dfu.h b/include/dfu.h
> index a107f4b..124653c 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -68,7 +68,9 @@ static inline unsigned int get_mmc_blk_size(int dev)
>
> #define DFU_NAME_SIZE32
> #define DFU_CMD_BUF_SIZE 128
> -#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
--
Best regards,
Lukasz Majewski
Samsung R&D Poland Institute (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb, composite: after unregister gadget driver set composite to NULL
Hi Heiko, > Without this, second usb_composite_register() call fails always > with -EINVAL. > > Signed-off-by: Heiko Schocher > Cc: Lukasz Majewski > Cc: Kyungmin Park > Cc: Marek Vasut > --- > drivers/usb/gadget/composite.c | 1 + > 1 Datei geändert, 1 Zeile hinzugefügt(+) > > diff --git a/drivers/usb/gadget/composite.c > b/drivers/usb/gadget/composite.c index 0716e52..f867793 100644 > --- a/drivers/usb/gadget/composite.c > +++ b/drivers/usb/gadget/composite.c > @@ -1099,4 +1099,5 @@ void usb_composite_unregister(struct > usb_composite_driver *driver) if (composite != driver) > return; > usb_gadget_unregister_driver(&composite_driver); > + composite = NULL; Thanks for spotting. > } Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Poland Institute (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb, g_dnl: make possibility to fixup the device_desc board specific
Hi Heiko,
> add a weak dummy function g_dnl_fixup to add the possibility to update
> the device_desc board specific. Used on the upcoming siemens board
> support, where idVendor and idProduct is stored in an eeprom.
>
Reviewed-by: Lukasz Majewski
> Signed-off-by: Heiko Schocher
> Cc: Marek Vasut
> Cc: Lukasz Majewski
> Cc: Kyungmin Park
> ---
> drivers/usb/gadget/g_dnl.c | 7 +++
> include/g_dnl.h| 2 +-
> 2 Dateien geändert, 8 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
>
> diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
> index cc3f344..8a3777b 100644
> --- a/drivers/usb/gadget/g_dnl.c
> +++ b/drivers/usb/gadget/g_dnl.c
> @@ -125,6 +125,12 @@ static int g_dnl_config_register(struct
> usb_composite_dev *cdev) return usb_add_config(cdev, &config);
> }
>
> +__weak
> +int g_dnl_bind_fixup(struct usb_device_descriptor *dev)
> +{
> + return 0;
> +}
> +
> static int g_dnl_bind(struct usb_composite_dev *cdev)
> {
> struct usb_gadget *gadget = cdev->gadget;
> @@ -147,6 +153,7 @@ static int g_dnl_bind(struct usb_composite_dev
> *cdev) g_dnl_string_defs[1].id = id;
> device_desc.iProduct = id;
>
> + g_dnl_bind_fixup(&device_desc);
> ret = g_dnl_config_register(cdev);
> if (ret)
> goto error;
> diff --git a/include/g_dnl.h b/include/g_dnl.h
> index f47395f..f8affd8 100644
> --- a/include/g_dnl.h
> +++ b/include/g_dnl.h
> @@ -23,7 +23,7 @@
>
> #include
> #include
> -
> +int g_dnl_bind_fixup(struct usb_device_descriptor *);
> int g_dnl_register(const char *s);
> void g_dnl_unregister(void);
>
--
Best regards,
Lukasz Majewski
Samsung R&D Poland Institute (SRPOL) | Linux Platform Group
___
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
Hi Heiko,
Just thinking out loud here. Can we have an extra option that
allocates the buffer dynamically based on an env variable?
Regards
-- Pantelis
On Jun 4, 2013, at 12:22 PM, 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.
>
> Signed-off-by: Heiko Schocher
> Cc: Pantelis Antoniou
> Cc: Tom Rini
> Cc: Lukasz Majewski
> Cc: Kyungmin Park
> Cc: Marek Vasut
> ---
> README| 5 +
> drivers/dfu/dfu.c | 2 +-
> include/dfu.h | 4 +++-
> 3 Dateien geändert, 9 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
>
> diff --git a/README b/README
> index b1b3e17..8550f34 100644
> --- a/README
> +++ b/README
> @@ -1360,6 +1360,11 @@ The following options need to be configured:
> CONFIG_DFU_NAND
> This enables support for exposing NAND devices via DFU.
>
> + 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
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index 6af6890..fe3a36e 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -42,7 +42,7 @@ static int dfu_find_alt_num(const char *s)
> }
>
> static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
> - dfu_buf[DFU_DATA_BUF_SIZE];
> + dfu_buf[CONFIG_SYS_DFU_DATA_BUF_SIZE];
>
> static int dfu_write_buffer_drain(struct dfu_entity *dfu)
> {
> diff --git a/include/dfu.h b/include/dfu.h
> index a107f4b..124653c 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -68,7 +68,9 @@ static inline unsigned int get_mmc_blk_size(int dev)
>
> #define DFU_NAME_SIZE 32
> #define DFU_CMD_BUF_SIZE 128
> -#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
> --
> 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 v7] Add support for Congatec Conga-QEVAl board
Hi Leo, On 04/06/2013 11:30, SARTRE Leo wrote: > Add minimal support (only boot from mmc device) for the Congatec > Conga-QEVAl Evaluation Carrier Board with conga-Qmx6q (i.MX6 Quad > processor) module. > > Signed-off-by: Leo Sartre > --- > > Changes in v7: > -cgtqmx6eval.c : remove unused code in board_init. > > MAINTAINERS |4 + > board/congatec/cgtqmx6eval/Makefile | 42 +++ > board/congatec/cgtqmx6eval/README| 29 + > board/congatec/cgtqmx6eval/cgtqmx6eval.c | 167 ++ > boards.cfg |1 + > include/configs/cgtqmx6eval.h| 192 > ++ > 6 files changed, 435 insertions(+) > create mode 100644 board/congatec/cgtqmx6eval/Makefile > create mode 100644 board/congatec/cgtqmx6eval/README > create mode 100644 board/congatec/cgtqmx6eval/cgtqmx6eval.c > create mode 100644 include/configs/cgtqmx6eval.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 14075af..d803293 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -897,6 +897,10 @@ Steve Sakoman > > omap3_overo ARM ARMV7 (OMAP3xx SoC) > > +Leo Sartre > + > + cgtqmx6qevali.MX6Q > + > Jens Scharsig > > eb_cpux9k2 ARM920T (AT91RM9200 SoC) > diff --git a/board/congatec/cgtqmx6eval/Makefile > b/board/congatec/cgtqmx6eval/Makefile > new file mode 100644 > index 000..ac16c1f > --- /dev/null > +++ b/board/congatec/cgtqmx6eval/Makefile > @@ -0,0 +1,42 @@ > +# > +# Copyright (C) 2007, Guennadi Liakhovetski > +# > +# (C) Copyright 2011 Freescale Semiconductor, Inc. > +# (C) Copyright 2013 Adeneo Embedded > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB= $(obj)lib$(BOARD).o > + > +COBJS := cgtqmx6eval.o > + > +SRCS := $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > + > +$(LIB):$(obj).depend $(OBJS) > + $(call cmd_link_o_target, $(OBJS)) > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/congatec/cgtqmx6eval/README > b/board/congatec/cgtqmx6eval/README > new file mode 100644 > index 000..bbf0f75 > --- /dev/null > +++ b/board/congatec/cgtqmx6eval/README > @@ -0,0 +1,29 @@ > +U-Boot for the Congatec Conga-QEVAl Evaluation Carrier board with > +qmx6 quad module. > + > +This file contains information for the port of U-Boot to the Congatec > +Conga-QEVAl Evaluation Carrier board with qmx6 quad module. > + > +1. Boot source, boot from SD card > +- > + > +This version of u-boot works only on the SD card. By default, the > +Congatec board can boot only from the SPI-NOR. > +But, with the u-boot version provided with the board you can write boot > +registers to force the board to reboot and boot from the SD slot. If > +"bmode" command is not available from your pre-installed u-boot, these > +instruction will produce the same effect: > + > +conga-QMX6 U-Boot > mw.l 0x20d8040 0x3850 > +conga-QMX6 U-Boot > mw.l 0x020d8044 0x1000 > +conga-QMX6 U-Boot > reset > +resetting ... > + > +The the board will reboot and, if you have written your SD correctly > +the board will use u-boot that live into the SD > + > +To copy the resulting u-boot.imx to the SD card: > + > + dd if=u-boot.imx of=/dev/xxx bs=512 seek=2 > + > +Note: Replace xxx with the device representing the SD card in your system. > diff --git a/board/congatec/cgtqmx6eval/cgtqmx6eval.c > b/board/congatec/cgtqmx6eval/cgtqmx6eval.c > new file mode 100644 > index 000..20a004f > --- /dev/null > +++ b/board/congatec/cgtqmx6eval/cgtqmx6eval.c > @@ -0,0 +1,167 @@ > +/* > + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. > + * Based on mx6qsabrelite.c file > + * Copyright (C) 2013, Adeneo Embedded > + * Leo Sartre, > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) an
[U-Boot] [PATCH v7] Add support for Congatec Conga-QEVAl board
Add minimal support (only boot from mmc device) for the Congatec Conga-QEVAl Evaluation Carrier Board with conga-Qmx6q (i.MX6 Quad processor) module. Signed-off-by: Leo Sartre --- Changes in v7: -cgtqmx6eval.c : remove unused code in board_init. MAINTAINERS |4 + board/congatec/cgtqmx6eval/Makefile | 42 +++ board/congatec/cgtqmx6eval/README| 29 + board/congatec/cgtqmx6eval/cgtqmx6eval.c | 167 ++ boards.cfg |1 + include/configs/cgtqmx6eval.h| 192 ++ 6 files changed, 435 insertions(+) create mode 100644 board/congatec/cgtqmx6eval/Makefile create mode 100644 board/congatec/cgtqmx6eval/README create mode 100644 board/congatec/cgtqmx6eval/cgtqmx6eval.c create mode 100644 include/configs/cgtqmx6eval.h diff --git a/MAINTAINERS b/MAINTAINERS index 14075af..d803293 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -897,6 +897,10 @@ Steve Sakoman omap3_overo ARM ARMV7 (OMAP3xx SoC) +Leo Sartre + + cgtqmx6qevali.MX6Q + Jens Scharsig eb_cpux9k2 ARM920T (AT91RM9200 SoC) diff --git a/board/congatec/cgtqmx6eval/Makefile b/board/congatec/cgtqmx6eval/Makefile new file mode 100644 index 000..ac16c1f --- /dev/null +++ b/board/congatec/cgtqmx6eval/Makefile @@ -0,0 +1,42 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# (C) Copyright 2013 Adeneo Embedded +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := cgtqmx6eval.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/congatec/cgtqmx6eval/README b/board/congatec/cgtqmx6eval/README new file mode 100644 index 000..bbf0f75 --- /dev/null +++ b/board/congatec/cgtqmx6eval/README @@ -0,0 +1,29 @@ +U-Boot for the Congatec Conga-QEVAl Evaluation Carrier board with +qmx6 quad module. + +This file contains information for the port of U-Boot to the Congatec +Conga-QEVAl Evaluation Carrier board with qmx6 quad module. + +1. Boot source, boot from SD card +- + +This version of u-boot works only on the SD card. By default, the +Congatec board can boot only from the SPI-NOR. +But, with the u-boot version provided with the board you can write boot +registers to force the board to reboot and boot from the SD slot. If +"bmode" command is not available from your pre-installed u-boot, these +instruction will produce the same effect: + +conga-QMX6 U-Boot > mw.l 0x20d8040 0x3850 +conga-QMX6 U-Boot > mw.l 0x020d8044 0x1000 +conga-QMX6 U-Boot > reset +resetting ... + +The the board will reboot and, if you have written your SD correctly +the board will use u-boot that live into the SD + +To copy the resulting u-boot.imx to the SD card: + + dd if=u-boot.imx of=/dev/xxx bs=512 seek=2 + +Note: Replace xxx with the device representing the SD card in your system. diff --git a/board/congatec/cgtqmx6eval/cgtqmx6eval.c b/board/congatec/cgtqmx6eval/cgtqmx6eval.c new file mode 100644 index 000..20a004f --- /dev/null +++ b/board/congatec/cgtqmx6eval/cgtqmx6eval.c @@ -0,0 +1,167 @@ +/* + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. + * Based on mx6qsabrelite.c file + * Copyright (C) 2013, Adeneo Embedded + * Leo Sartre, + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of
[U-Boot] dfu: make data buffer size configurable
Dfu transfer uses a buffer before writing data to the
raw storage device. Make the size (in bytes) of this buffer
configurable.
Signed-off-by: Heiko Schocher
Cc: Pantelis Antoniou
Cc: Tom Rini
Cc: Lukasz Majewski
Cc: Kyungmin Park
Cc: Marek Vasut
---
README| 5 +
drivers/dfu/dfu.c | 2 +-
include/dfu.h | 4 +++-
3 Dateien geändert, 9 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/README b/README
index b1b3e17..8550f34 100644
--- a/README
+++ b/README
@@ -1360,6 +1360,11 @@ The following options need to be configured:
CONFIG_DFU_NAND
This enables support for exposing NAND devices via DFU.
+ 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
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 6af6890..fe3a36e 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -42,7 +42,7 @@ static int dfu_find_alt_num(const char *s)
}
static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
-dfu_buf[DFU_DATA_BUF_SIZE];
+dfu_buf[CONFIG_SYS_DFU_DATA_BUF_SIZE];
static int dfu_write_buffer_drain(struct dfu_entity *dfu)
{
diff --git a/include/dfu.h b/include/dfu.h
index a107f4b..124653c 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -68,7 +68,9 @@ static inline unsigned int get_mmc_blk_size(int dev)
#define DFU_NAME_SIZE 32
#define DFU_CMD_BUF_SIZE 128
-#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
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] usb, composite: after unregister gadget driver set composite to NULL
Without this, second usb_composite_register() call fails always with -EINVAL. Signed-off-by: Heiko Schocher Cc: Lukasz Majewski Cc: Kyungmin Park Cc: Marek Vasut --- drivers/usb/gadget/composite.c | 1 + 1 Datei geändert, 1 Zeile hinzugefügt(+) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index 0716e52..f867793 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -1099,4 +1099,5 @@ void usb_composite_unregister(struct usb_composite_driver *driver) if (composite != driver) return; usb_gadget_unregister_driver(&composite_driver); + composite = NULL; } -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] usb, g_dnl: make possibility to fixup the device_desc board specific
add a weak dummy function g_dnl_fixup to add the possibility to update
the device_desc board specific. Used on the upcoming siemens board
support, where idVendor and idProduct is stored in an eeprom.
Signed-off-by: Heiko Schocher
Cc: Marek Vasut
Cc: Lukasz Majewski
Cc: Kyungmin Park
---
drivers/usb/gadget/g_dnl.c | 7 +++
include/g_dnl.h| 2 +-
2 Dateien geändert, 8 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index cc3f344..8a3777b 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -125,6 +125,12 @@ static int g_dnl_config_register(struct usb_composite_dev
*cdev)
return usb_add_config(cdev, &config);
}
+__weak
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev)
+{
+ return 0;
+}
+
static int g_dnl_bind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev->gadget;
@@ -147,6 +153,7 @@ static int g_dnl_bind(struct usb_composite_dev *cdev)
g_dnl_string_defs[1].id = id;
device_desc.iProduct = id;
+ g_dnl_bind_fixup(&device_desc);
ret = g_dnl_config_register(cdev);
if (ret)
goto error;
diff --git a/include/g_dnl.h b/include/g_dnl.h
index f47395f..f8affd8 100644
--- a/include/g_dnl.h
+++ b/include/g_dnl.h
@@ -23,7 +23,7 @@
#include
#include
-
+int g_dnl_bind_fixup(struct usb_device_descriptor *);
int g_dnl_register(const char *s);
void g_dnl_unregister(void);
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] usb, musb-new: add wdt trigger
Signed-off-by: Heiko Schocher
Cc: Marek Vasut
Cc: Ilya Yanok
---
drivers/usb/musb-new/musb_uboot.c | 2 ++
1 Datei geändert, 2 Zeilen hinzugefügt(+)
diff --git a/drivers/usb/musb-new/musb_uboot.c
b/drivers/usb/musb-new/musb_uboot.c
index 15d2ec0..c240032 100644
--- a/drivers/usb/musb-new/musb_uboot.c
+++ b/drivers/usb/musb-new/musb_uboot.c
@@ -1,4 +1,5 @@
#include
+#include
#include
#include
#include
@@ -164,6 +165,7 @@ static struct musb *gadget;
int usb_gadget_handle_interrupts(void)
{
+ WATCHDOG_RESET();
if (!gadget || !gadget->isr)
return -EINVAL;
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/mpc8xxx failed to compile: operand out of range
Binutils 2.23.1 and the patch(es) for 2.23.2 work well. Thank you for your help. Jérôme On 05/31/2013 08:20:00 PM, Scott Wood wrote: > > On 05/23/2013 04:52:26 AM, Jérôme Arzel wrote: > > Hi all, > > > > I have an issue when I compile U-Boot for my target machine > > (P1022DS, > > 36-bit). > > Here is the error message: > > > > release.S: Assembler messages: > > release.S:154: Error: operand out of range (0xf144 is not > > between > > 0x and 0x) > > release.S:286: Error: operand out of range (0xf144 is not > > between > > 0x and 0x) > > release.S:311: Error: operand out of range (0xf140 is not > > between > > 0x and 0x) > > > > (release.S is located to arch/powerpc/cpu/mpc85xx/release.S) > > > > And here is the code for the first error (line 150): > > > > #define toreset(x) (x - __secondary_start_page + 0xf000) > > > > /* get our PIR to figure out our table entry */ > > lis r3,toreset(__spin_table_addr)@h > > ori r3,r3,toreset(__spin_table_addr)@l > > > > I don't really know why it doesn't work, but I think > > that "ori" is inappropried, the immediate value must be a 16-bit > > value. > > > > I use GCC 4.7.3, compiled in x86_64 for target > > powerpc-none-linux-gnuspe. > > My U-Boot come from the repository, but older versions fail too. > > This appears to be a binutils bug, introduced in 2.23.2. The > attached > test program gives a similar error on 2.23.2, but 2.23.1 is OK. > > I've filed it here: > http://sourceware.org/bugzilla/show_bug.cgi?id=15557 > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm, am33xx: add defines for gmii_sel_register bits
move gmii_sel register defines from board code to common place.
Signed-off-by: Heiko Schocher
Cc: Chandan Nath
Cc: Sandeep Paulraj
Cc: Tom Rini
Cc: Lars Poeschel
Cc: Enric Balletbo i Serra
---
arch/arm/include/asm/arch-am33xx/cpu.h | 8
board/isee/igep0033/board.c| 4 ++--
board/phytec/pcm051/board.c| 2 --
board/ti/am335x/board.c| 6 +-
4 Dateien geändert, 11 Zeilen hinzugefügt(+), 9 Zeilen entfernt(-)
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index fb44654..6dd3b0a 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -364,6 +364,14 @@ struct ctrl_dev {
unsigned int resv4[4];
unsigned int miisel;/* offset 0x50 */
};
+
+/* miisel defines */
+#define MII_MODE_ENABLE0x0
+#define RMII_MODE_ENABLE0x5
+#define RGMII_MODE_ENABLE 0xA
+#define RGMII_INT_DELAY0x30
+#define RMII_CHIPCKL_ENABLE 0xC0
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL_STRICT_NAMES */
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index 842051f..7ea22be 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -38,7 +38,7 @@ DECLARE_GLOBAL_DATA_PTR;
static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
/* MII mode defines */
-#define RMII_MODE_ENABLE 0x4D
+#define RMII_MODE_P1_ENABLE0x4D
static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
@@ -182,7 +182,7 @@ int board_eth_init(bd_t *bis)
eth_setenv_enetaddr("ethaddr", mac_addr);
}
- writel(RMII_MODE_ENABLE, &cdev->miisel);
+ writel(RMII_MODE_P1_ENABLE, &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
[U-Boot] arm, am33xx: move uart soft reset code to common place
move uart soft reset code to common place and call
this function from board code, instead of copy and paste
this code for every board.
Signed-off-by: Heiko Schocher
Cc: Matt Porter
Cc: Lars Poeschel
Cc: Tom Rini
Cc: Enric Balletbo i Serra
---
arch/arm/cpu/armv7/am33xx/board.c| 22 ++
arch/arm/include/asm/arch-am33xx/sys_proto.h | 1 +
board/isee/igep0033/board.c | 22 +-
board/phytec/pcm051/board.c | 20 +---
board/ti/am335x/board.c | 23 +--
board/ti/ti814x/evm.c| 19 +--
6 Dateien geändert, 27 Zeilen hinzugefügt(+), 80 Zeilen entfernt(-)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index d3b3612..b935a29 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -166,4 +166,26 @@ void rtc32k_enable(void)
/* Enable the RTC 32K OSC by setting bits 3 and 6. */
writel((1 << 3) | (1 << 6), &rtc->osc);
}
+
+#define UART_RESET (0x1 << 1)
+#define UART_CLK_RUNNING_MASK 0x1
+#define UART_SMART_IDLE_EN (0x1 << 0x3)
+
+void uart_soft_reset(void)
+{
+ struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+ u32 regval;
+
+ regval = readl(&uart_base->uartsyscfg);
+ regval |= UART_RESET;
+ writel(regval, &uart_base->uartsyscfg);
+ while ((readl(&uart_base->uartsyssts) &
+ UART_CLK_RUNNING_MASK) != UART_CLK_RUNNING_MASK)
+ ;
+
+ /* Disable smart idle */
+ regval = readl(&uart_base->uartsyscfg);
+ regval |= UART_SMART_IDLE_EN;
+ writel(regval, &uart_base->uartsyscfg);
+}
#endif
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 71a1677..2422924 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -43,5 +43,6 @@ void omap_nand_switch_ecc(uint32_t, uint32_t);
#ifdef CONFIG_SPL_BUILD
void rtc32k_enable(void);
+void uart_soft_reset(void);
#endif
#endif
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index e82d722..842051f 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -36,21 +36,12 @@
DECLARE_GLOBAL_DATA_PTR;
static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
-#ifdef CONFIG_SPL_BUILD
-static struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
-#endif
/* MII mode defines */
#define RMII_MODE_ENABLE 0x4D
static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
-/* UART Defines */
-#ifdef CONFIG_SPL_BUILD
-#define UART_RESET (0x1 << 1)
-#define UART_CLK_RUNNING_MASK 0x1
-#define UART_SMART_IDLE_EN (0x1 << 0x3)
-
static const struct ddr_data ddr3_data = {
.datardsratio0 = K4B2G1646EBIH9_RD_DQS,
.datawdsratio0 = K4B2G1646EBIH9_WR_DQS,
@@ -111,18 +102,7 @@ void s_init(void)
enable_uart0_pin_mux();
- regval = readl(&uart_base->uartsyscfg);
- regval |= UART_RESET;
- writel(regval, &uart_base->uartsyscfg);
- while ((readl(&uart_base->uartsyssts) &
- UART_CLK_RUNNING_MASK) != UART_CLK_RUNNING_MASK)
- ;
-
- /* Disable smart idle */
- regval = readl(&uart_base->uartsyscfg);
- regval |= UART_SMART_IDLE_EN;
- writel(regval, &uart_base->uartsyscfg);
-
+ uart_soft_reset();
gd = &gdata;
preloader_console_init();
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 6c0993a..72c5612 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -39,9 +39,6 @@
DECLARE_GLOBAL_DATA_PTR;
static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
-#ifdef CONFIG_SPL_BUILD
-static struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
-#endif
/* MII mode defines */
#define MII_MODE_ENABLE0x0
@@ -50,11 +47,7 @@ static struct uart_sys *uart_base = (struct uart_sys
*)DEFAULT_UART_BASE;
static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
-/* UART defines */
#ifdef CONFIG_SPL_BUILD
-#define UART_RESET (0x1 << 1)
-#define UART_CLK_RUNNING_MASK 0x1
-#define UART_SMART_IDLE_EN (0x1 << 0x3)
/* DDR RAM defines */
#define DDR_CLK_MHZ303 /* DDR_DPLL_MULT value */
@@ -120,18 +113,7 @@ void s_init(void)
u32 regval;
enable_uart0_pin_mux();
-
- regval = readl(&uart_base->uartsyscfg);
- regval |= UART_RESET;
- writel(regval, &uart_base->uartsyscfg);
- while ((readl(&uart_base->uartsyssts) & UART_CLK_RUNNING_MASK)
- != UART_CLK_RUNNING_MASK)
- ;
-
- /* Disable smart idle */
- regval = readl(&uart_base->uartsyscfg);
- regval |= UART_SMART_IDLE_EN;
- writel(regval, &uart_base->ua
[U-Boot] arm, am33xx: move rtc32k_enable() to common place
move rtc32k_enable() to common place so all am33xx boards can use it.
Signed-off-by: Heiko Schocher
Cc: Matt Porter
Cc: Lars Poeschel
Cc: Tom Rini
Cc: Enric Balletbo i Serra
---
arch/arm/cpu/armv7/am33xx/board.c| 18 ++
arch/arm/include/asm/arch-am33xx/sys_proto.h | 4
board/isee/igep0033/board.c | 16
board/phytec/pcm051/board.c | 16
board/ti/am335x/board.c | 16
board/ti/ti814x/evm.c| 16
6 Dateien geändert, 22 Zeilen hinzugefügt(+), 64 Zeilen entfernt(-)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 885fb2d..d3b3612 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -149,3 +149,21 @@ int arch_misc_init(void)
#endif
return 0;
}
+
+#ifdef CONFIG_SPL_BUILD
+void rtc32k_enable(void)
+{
+ struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
+
+ /*
+* Unlock the RTC's registers. For more details please see the
+* RTC_SS section of the TRM. In order to unlock we need to
+* write these specific values (keys) in this order.
+*/
+ writel(0x83e70b13, &rtc->kick0r);
+ writel(0x95a4f1e0, &rtc->kick1r);
+
+ /* Enable the RTC 32K OSC by setting bits 3 and 6. */
+ writel((1 << 3) | (1 << 6), &rtc->osc);
+}
+#endif
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index c913b5f..71a1677 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -40,4 +40,8 @@ void gpmc_init(void);
void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size);
void omap_nand_switch_ecc(uint32_t, uint32_t);
+
+#ifdef CONFIG_SPL_BUILD
+void rtc32k_enable(void);
+#endif
#endif
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index d315516..e82d722 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -51,22 +51,6 @@ static struct ctrl_dev *cdev = (struct ctrl_dev
*)CTRL_DEVICE_BASE;
#define UART_CLK_RUNNING_MASK 0x1
#define UART_SMART_IDLE_EN (0x1 << 0x3)
-static void rtc32k_enable(void)
-{
- struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
-
- /*
-* Unlock the RTC's registers. For more details please see the
-* RTC_SS section of the TRM. In order to unlock we need to
-* write these specific values (keys) in this order.
-*/
- writel(0x83e70b13, &rtc->kick0r);
- writel(0x95a4f1e0, &rtc->kick1r);
-
- /* Enable the RTC 32K OSC by setting bits 3 and 6. */
- writel((1 << 3) | (1 << 6), &rtc->osc);
-}
-
static const struct ddr_data ddr3_data = {
.datardsratio0 = K4B2G1646EBIH9_RD_DQS,
.datawdsratio0 = K4B2G1646EBIH9_WR_DQS,
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 9ea50e1..6c0993a 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -59,22 +59,6 @@ static struct ctrl_dev *cdev = (struct ctrl_dev
*)CTRL_DEVICE_BASE;
/* DDR RAM defines */
#define DDR_CLK_MHZ303 /* DDR_DPLL_MULT value */
-static void rtc32k_enable(void)
-{
- struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
-
- /*
-* Unlock the RTC's registers. For more details please see the
-* RTC_SS section of the TRM. In order to unlock we need to
-* write these specific values (keys) in this order.
-*/
- writel(0x83e70b13, &rtc->kick0r);
- writel(0x95a4f1e0, &rtc->kick1r);
-
- /* Enable the RTC 32K OSC by setting bits 3 and 6. */
- writel((1 << 3) | (1 << 6), &rtc->osc);
-}
-
static const struct ddr_data ddr3_data = {
.datardsratio0 = MT41J256M8HX15E_RD_DQS,
.datawdsratio0 = MT41J256M8HX15E_WR_DQS,
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index e52b009..bf25878 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -132,22 +132,6 @@ static int read_eeprom(void)
#define UART_CLK_RUNNING_MASK 0x1
#define UART_SMART_IDLE_EN (0x1 << 0x3)
-static void rtc32k_enable(void)
-{
- struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
-
- /*
-* Unlock the RTC's registers. For more details please see the
-* RTC_SS section of the TRM. In order to unlock we need to
-* write these specific values (keys) in this order.
-*/
- writel(0x83e70b13, &rtc->kick0r);
- writel(0x95a4f1e0, &rtc->kick1r);
-
- /* Enable the RTC 32K OSC by setting bits 3 and 6. */
- writel((1 << 3) | (1 << 6), &rtc->osc);
-}
-
static const struct ddr_data ddr2_data = {
.datardsratio0 = ((MT47H128M16RT25E_RD_DQS<<30) |
(MT47H128M16RT25E_RD_DQS<<20) |
diff --git a/board/ti/ti814x/e
[U-Boot] arm, am335x: make mpu pll config configurable
upcoming support for siemens boards switches mpu pll clk in board
code. So make this configurable.
Signed-off-by: Heiko Schocher
Cc: Tom Rini
---
arch/arm/cpu/armv7/am33xx/clock_am33xx.c | 9 +++--
arch/arm/include/asm/arch-am33xx/sys_proto.h | 1 +
2 Dateien geändert, 8 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
index a1efc75..9c4d0b4 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c
@@ -246,7 +246,7 @@ static void enable_per_clocks(void)
;
}
-static void mpu_pll_config(void)
+void mpu_pll_config_val(int mpull_m)
{
u32 clkmode, clksel, div_m2;
@@ -260,7 +260,7 @@ static void mpu_pll_config(void)
;
clksel = clksel & (~CLK_SEL_MASK);
- clksel = clksel | ((MPUPLL_M << CLK_SEL_SHIFT) | MPUPLL_N);
+ clksel = clksel | ((mpull_m << CLK_SEL_SHIFT) | MPUPLL_N);
writel(clksel, &cmwkup->clkseldpllmpu);
div_m2 = div_m2 & ~CLK_DIV_MASK;
@@ -274,6 +274,11 @@ static void mpu_pll_config(void)
;
}
+static void mpu_pll_config(void)
+{
+ mpu_pll_config_val(CONFIG_SYS_MPUCLK);
+}
+
static void core_pll_config(void)
{
u32 clkmode, clksel, div_m4, div_m5, div_m6;
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 2422924..fbeff1a 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -31,6 +31,7 @@ int print_cpuinfo(void);
extern struct ctrl_stat *cstat;
u32 get_device_type(void);
void setup_clocks_for_console(void);
+void mpu_pll_config_val(int mpull_m);
void ddr_pll_config(unsigned int ddrpll_M);
void sdelay(unsigned long);
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] phylib: add atheros ar803x phy
add atheros ar803x phy, used on the upcoming siemens boards.
Signed-off-by: Heiko Schocher
Cc: Andy Fleming
Cc: Joe Hershberger
---
drivers/net/phy/atheros.c | 11 +++
1 Datei geändert, 11 Zeilen hinzugefügt(+)
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
index 9b3808b..297e671 100644
--- a/drivers/net/phy/atheros.c
+++ b/drivers/net/phy/atheros.c
@@ -40,9 +40,20 @@ static struct phy_driver AR8021_driver = {
.shutdown = genphy_shutdown,
};
+static struct phy_driver AR8031_driver = {
+ .name = "AR8031",
+ .uid = 0x4dd074,
+ .mask = 0xf0,
+ .features = PHY_GBIT_FEATURES,
+ .config = genphy_config,
+ .startup = genphy_startup,
+ .shutdown = genphy_shutdown,
+};
+
int phy_atheros_init(void)
{
phy_register(&AR8021_driver);
+ phy_register(&AR8031_driver);
return 0;
}
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] phylib: add natsemi dp83630 phy
add natsemi dp83630 phy, used on the upcoming siemens boards.
Signed-off-by: Heiko Schocher
Cc: Andy Fleming
Cc: Joe Hershberger
---
drivers/net/phy/natsemi.c | 37 +
1 Datei geändert, 37 Zeilen hinzugefügt(+)
diff --git a/drivers/net/phy/natsemi.c b/drivers/net/phy/natsemi.c
index ea60ac1..6dc7ed5 100644
--- a/drivers/net/phy/natsemi.c
+++ b/drivers/net/phy/natsemi.c
@@ -22,6 +22,42 @@
*/
#include
+/* NatSemi DP83630 */
+
+#define DP83630_PHY_PAGESEL_REG0x13
+#define DP83630_PHY_PTP_COC_REG0x14
+#define DP83630_PHY_PTP_CLKOUT_EN (1<<15)
+#define DP83630_PHY_RBR_REG0x17
+
+static int dp83630_config(struct phy_device *phydev)
+{
+ int ptp_coc_reg;
+
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
+ phy_write(phydev, MDIO_DEVAD_NONE, DP83630_PHY_PAGESEL_REG, 0x6);
+ ptp_coc_reg = phy_read(phydev, MDIO_DEVAD_NONE,
+ DP83630_PHY_PTP_COC_REG);
+ ptp_coc_reg &= ~DP83630_PHY_PTP_CLKOUT_EN;
+ phy_write(phydev, MDIO_DEVAD_NONE, DP83630_PHY_PTP_COC_REG,
+ ptp_coc_reg);
+ phy_write(phydev, MDIO_DEVAD_NONE, DP83630_PHY_PAGESEL_REG, 0);
+
+ genphy_config_aneg(phydev);
+
+ return 0;
+}
+
+static struct phy_driver DP83630_driver = {
+ .name = "NatSemi DP83630",
+ .uid = 0x20005ce1,
+ .mask = 0xfff0,
+ .features = PHY_BASIC_FEATURES,
+ .config = &dp83630_config,
+ .startup = &genphy_startup,
+ .shutdown = &genphy_shutdown,
+};
+
+
/* DP83865 Link and Auto-Neg Status Register */
#define MIIM_DP83865_LANR 0x11
#define MIIM_DP83865_SPD_MASK 0x0018
@@ -90,6 +126,7 @@ static struct phy_driver DP83865_driver = {
int phy_natsemi_init(void)
{
+ phy_register(&DP83630_driver);
phy_register(&DP83865_driver);
return 0;
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm, arm335x: add watchdog support
Add TI OMAP 16xx & 24xx/34xx 32KHz (non-secure) watchdog support.
Signed-off-by: Heiko Schocher
Cc: Albert Aribaud
Cc: Tom Rini
---
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/(1< or
+ *
+ * 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
+ * Initially based on linux-2.4.19-rmk7-pxa1/drivers/char/sa1100_wdt.c
+ * (c) Copyright 2000 Oleg Drokin
+ * Based on SoftDog driver by Alan Cox
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+
+/* 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))
+ ;
+}
+
+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) & WDT_WWPS_PEND_WCLR)
+ ;
+
+ writel(WDT_WCLR_PRE | (PTV << WDT_WCLR_PTV_OFF), &wdt->wdtwclr);
+ while (readl(&wdt->wdtwwps) & WDT_WWPS_PEND_WCLR)
+ ;
+
+ omap_wdt_set_timeout(WDT_HW_TIMEOUT);
+
+ /* Sequence to enable the watchdog */
+ writel(0x, &wdt->wdtwspr);
+ while ((readl(&wdt->wdtwwps)) & WDT_WWPS_PEND_WSPR)
+ ;
+
+ writel(0x, &wdt->wdtwspr);
+ while ((readl(&wdt->wdtwwps)) & WDT_WWPS_PEND_WSPR)
+ ;
+}
+
+void hw_watchdog_disable(void)
+{
+ struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
+
+ /*
+* Disable watchdog
+*/
+ writel(0x, &wdt->wdtwspr);
+ while (readl(&wdt->wdtwwps) != 0x0)
+ ;
+ writel(0x, &wdt->wdtwspr);
+ while (readl(&wdt->wdtwwps) != 0x0)
+ ;
+}
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm, spl: add watchdog library to SPL
Signed-off-by: Heiko Schocher Cc: Tom Rini --- doc/README.SPL | 2 +- spl/Makefile | 1 + 2 Dateien geändert, 2 Zeilen hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/doc/README.SPL b/doc/README.SPL index 4e1cb28..64977e0 100644 --- a/doc/README.SPL +++ b/doc/README.SPL @@ -67,7 +67,7 @@ CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o) CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/nand_spl_load.o) CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o) CONFIG_SPL_RAM_DEVICE (common/spl/spl.c) - +CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o) Normally CPU is assumed to be the same between the SPL and normal u-boot build. However it is possible to specify a different CPU for diff --git a/spl/Makefile b/spl/Makefile index 8b655c4..94f763e 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -83,6 +83,7 @@ LIBS-$(CONFIG_SPL_ETH_SUPPORT) += drivers/net/libnet.o LIBS-$(CONFIG_SPL_ETH_SUPPORT) += drivers/net/phy/libphy.o LIBS-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += drivers/usb/musb-new/libusb_musb-new.o LIBS-$(CONFIG_SPL_USBETH_SUPPORT) += drivers/usb/gadget/libusb_gadget.o +LIBS-$(CONFIG_SPL_WATCHDOG_SUPPORT) += drivers/watchdog/libwatchdog.o ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] bug, nand, am33xx: nand->ecc.strength not set in board_nand_init()
commit dfe64e2c89731a3f9950d7acd8681b68df2bae03 Author: Sergey Lapin Date: Mon Jan 14 03:46:50 2013 + mtd: resync with Linux-3.7.1 Introduced runtime bug: U-Boot 2013.04-00499-g46567df-dirty (Jun 04 2013 - 08:17:08) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: BUG: failure at nand_base.c:3214/nand_scan_tail()! BUG! resetting ... on boards using drivers/mtd/nand/omap_gpmc.c as in board_nand_init() nand->ecc.strength is not set. Fix this! Signed-off-by: Heiko Schocher Cc: Sergey Lapin Cc: Scott Wood Cc: Tom Rini --- drivers/mtd/nand/omap_gpmc.c | 2 ++ 1 Datei geändert, 2 Zeilen hinzugefügt(+) diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c index d5f3248..5d08822 100644 --- a/drivers/mtd/nand/omap_gpmc.c +++ b/drivers/mtd/nand/omap_gpmc.c @@ -936,6 +936,7 @@ int board_nand_init(struct nand_chip *nand) nand->ecc.layout = &hw_bch8_nand_oob; nand->ecc.size = CONFIG_SYS_NAND_ECCSIZE; nand->ecc.bytes = CONFIG_SYS_NAND_ECCBYTES; + nand->ecc.strength = 8; nand->ecc.hwctl = omap_enable_ecc_bch; nand->ecc.correct = omap_correct_data_bch; nand->ecc.calculate = omap_calculate_ecc_bch; @@ -954,6 +955,7 @@ int board_nand_init(struct nand_chip *nand) nand->ecc.hwctl = omap_enable_hwecc; nand->ecc.correct = omap_correct_data; nand->ecc.calculate = omap_calculate_ecc; + nand->ecc.strength = 1; omap_hwecc_init(nand); #endif #endif -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] net, cpsw: disable gigabit support through plattform data
add possibility to disable gigabit support through
plattform data. Current boards should not be affected
through this patch.
Signed-off-by: Heiko Schocher
Cc: Cyril Chemparathy
Cc: Chandan Nath
Cc: Satyanarayana, Sandhya
Cc: Ilya Yanok
Cc: Yegor Yefremov
Cc: Mugunthan V N
Cc: Tom Rini
Cc: Joe Hershberger
---
board/phytec/pcm051/board.c | 1 +
board/ti/am335x/board.c | 1 +
drivers/net/cpsw.c | 14 --
include/cpsw.h | 1 +
4 Dateien geändert, 15 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 43d7b6e..9ea50e1 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -213,6 +213,7 @@ static struct cpsw_platform_data cpsw_data = {
.hw_stats_reg_ofs = 0x900,
.mac_control= (1 << 5),
.control= cpsw_control,
+ .gigabit_en = 1,
.host_port_num = 0,
.version= CPSW_CTRL_VERSION_2,
};
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index b371376..e52b009 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -464,6 +464,7 @@ static struct cpsw_platform_data cpsw_data = {
.hw_stats_reg_ofs = 0x900,
.mac_control= (1 << 5),
.control= cpsw_control,
+ .gigabit_en = 1,
.host_port_num = 0,
.version= CPSW_CTRL_VERSION_2,
};
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 379b679..10b8aeb 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -578,8 +578,15 @@ static void cpsw_slave_update_link(struct cpsw_slave
*slave,
if (*link) { /* link up */
mac_control = priv->data.mac_control;
- if (phy->speed == 1000)
- mac_control |= GIGABITEN;
+ 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;
+ }
+ }
if (phy->duplex == DUPLEX_FULL)
mac_control |= FULLDUPLEXEN;
if (phy->speed == 100)
@@ -943,6 +950,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct
cpsw_slave *slave)
SUPPORTED_100baseT_Full |
SUPPORTED_1000baseT_Full);
+ if (!priv->data.gigabit_en)
+ supported &= ~SUPPORTED_1000baseT_Full;
+
phydev = phy_connect(priv->bus,
CONFIG_PHY_ADDR,
dev,
diff --git a/include/cpsw.h b/include/cpsw.h
index 296b0e5..fa217f4 100644
--- a/include/cpsw.h
+++ b/include/cpsw.h
@@ -41,6 +41,7 @@ struct cpsw_platform_data {
u32 hw_stats_reg_ofs; /* cpsw hw stats counters */
u32 mac_control;
struct cpsw_slave_data *slave_data;
+ u32 gigabit_en; /* gigabit capable AND enabled */
void(*control)(int enabled);
u32 host_port_num;
u8 version;
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
