[U-Boot] multichannel mmc strangeness on omap
Does anyone have any experience enabling the second or third mmc
channels in u-boot on an omap3 board?
I used the feature successfully a couple of years ago on Overo, but of
course there have been many changes in the mmc code since then.
Here's what I tried for overo with the current head of tree:
diff --git a/board/overo/overo.c b/board/overo/overo.c
index f973870..51315b3 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -404,6 +404,7 @@ int board_eth_init(bd_t *bis)
int board_mmc_init(bd_t *bis)
{
omap_mmc_init(0, 0, 0);
+ omap_mmc_init(2, 0, 0);
return 0;
}
#endif
The result is a hang after printing: MMC: OMAP SD/MMC 0, SD/MMC 1
After adding a few printf's, it seems that the crash/hang is occurring
when calling env_relocate_spec in env_nand.c, which of course is
completely unrelated code!
Just for grins I tried enabling the second mmc channel instead (i.e
change omap_mmc_init(2, 0, 0) to omap_mmc_init(1, 0, 0)).
This worked as expected. I also tried enabling all three, which
resulted in the same crash. So enabling the third mmc channel seems
to be the issue.
Before I start debugging I thought I would check to see if anyone else
has seen this or has any theories as to why it is happening.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] multichannel mmc strangeness on omap
On Mon, Jul 30, 2012 at 7:27 AM, Tom Rini tr...@ti.com wrote: After adding a few printf's, it seems that the crash/hang is occurring when calling env_relocate_spec in env_nand.c, which of course is completely unrelated code! I've spent some time scratching my head against a hang in the same spot, on am335x. I only have seen it when booting from NAND (same image from MMC or UART is fine). Further, it only showed up when a change was made in another driver which isn't even entered before the hang. In order to keep making progress on hardware bringup I swapped the base register pointer setup for mmc2 and mmc3 since enabling mmc2 in the board file didn't seem to cause the hang. With this change the mmc3 port hardware worked as expected. What a strange bug! I have a feeling that this is going to be a real bear to find root cause. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] omap: am335x_evm: enable i2c1 channel
This patch sets up pinmux, enables fclk, and
defines CONFIG_I2C_MULTI_BUS
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index bbb9c13..57bec98 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -118,6 +118,11 @@ static void enable_per_clocks(void)
writel(PRCM_MOD_EN, cmwkup-wkup_i2c0ctrl);
while (readl(cmwkup-wkup_i2c0ctrl) != PRCM_MOD_EN)
;
+
+ /* i2c1 */
+ writel(PRCM_MOD_EN, cmper-i2c1clkctrl);
+ while (readl(cmper-i2c1clkctrl) != PRCM_MOD_EN)
+ ;
}
static void mpu_pll_config(void)
diff --git a/board/ti/am335x/evm.c b/board/ti/am335x/evm.c
index 33758b5..ef27694 100644
--- a/board/ti/am335x/evm.c
+++ b/board/ti/am335x/evm.c
@@ -41,6 +41,7 @@ int board_init(void)
#ifdef CONFIG_I2C
enable_i2c0_pin_mux();
+ enable_i2c1_pin_mux();
i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
#endif
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 9ccb436..c696c0f 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -280,6 +280,14 @@ static struct module_pin_mux i2c0_pin_mux[] = {
{-1},
};
+static struct module_pin_mux i2c1_pin_mux[] = {
+ {OFFSET(spi0_d1), (MODE(2) | RXACTIVE |
+ PULLUDEN | SLEWCTRL)}, /* I2C_DATA */
+ {OFFSET(spi0_cs0), (MODE(2) | RXACTIVE |
+ PULLUDEN | SLEWCTRL)}, /* I2C_SCLK */
+ {-1},
+};
+
/*
* Configure the pin mux for the module
*/
@@ -310,3 +318,8 @@ void enable_i2c0_pin_mux(void)
{
configure_module_pin_mux(i2c0_pin_mux);
}
+
+void enable_i2c1_pin_mux(void)
+{
+ configure_module_pin_mux(i2c1_pin_mux);
+}
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 89e2aa0..2b41c1c 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -108,6 +108,7 @@
#define CONFIG_HARD_I2C
#define CONFIG_SYS_I2C_SPEED 10
#define CONFIG_SYS_I2C_SLAVE 1
+#define CONFIG_I2C_MULTI_BUS
#define CONFIG_DRIVER_OMAP24XX_I2C
#define CONFIG_BAUDRATE115200
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_nand: fix crashing bug in nand read/write
Commit 418396e212b59bf907dbccad997ff50f7eb61b16 introduced a
bug that causes nand read and nand write to crash in strcmp
due to a null pointer.
Root cause is that strchr(cmd, '.') returns a null pointer when
the input string does not contain a '.'
The strcmp function does not check for null pointers, resulting
in a crash.
Signed-off-by: Steve Sakoman st...@sakoman.com
---
common/cmd_nand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index fa44295..a91ccf4 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -617,7 +617,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
s = strchr(cmd, '.');
- if (!strcmp(s, .raw)) {
+ if (s !strcmp(s, .raw)) {
raw = 1;
if (arg_off(argv[3], dev, off, size))
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap: am335x_evm: remove unused definitions
UART_RESET, UART_CLK_RUNNING_MASK, and UART_SMART_IDLE_EN are defined inn evm.c but not used. Also removes unnecessary include of serial.h PHYS_DRAM_1_SIZE is defined in am335x_evm.h but never used. Signed-off-by: Steve Sakoman st...@sakoman.com --- board/ti/am335x/evm.c|5 - include/configs/am335x_evm.h |1 - 2 files changed, 0 insertions(+), 6 deletions(-) diff --git a/board/ti/am335x/evm.c b/board/ti/am335x/evm.c index 13dc603..33758b5 100644 --- a/board/ti/am335x/evm.c +++ b/board/ti/am335x/evm.c @@ -17,15 +17,10 @@ #include asm/arch/cpu.h #include asm/arch/hardware.h #include asm/arch/common_def.h -#include serial.h #include i2c.h DECLARE_GLOBAL_DATA_PTR; -#define UART_RESET (0x1 1) -#define UART_CLK_RUNNING_MASK 0x1 -#define UART_SMART_IDLE_EN (0x1 0x3) - /* * Basic board specific setup */ diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index d0fbc88..89e2aa0 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -85,7 +85,6 @@ /* Physical Memory Map */ #define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */ #define PHYS_DRAM_10x8000 /* DRAM Bank #1 */ -#define PHYS_DRAM_1_SIZE 0x1000 /*(0x8000 / 8) 256 MB */ #define CONFIG_MAX_RAM_BANK_SIZE (1024 20)/* 1GB */ #define CONFIG_SYS_SDRAM_BASE PHYS_DRAM_1 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap: am335x_evm: enable i2c1 channel
This patch sets up pinmux, enables fclk, and
defines CONFIG_I2C_MULTI_BUS
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/cpu/armv7/am33xx/clock.c |5 +
board/ti/am335x/mux.c |8
include/configs/am335x_evm.h |1 +
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index bbb9c13..57bec98 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -118,6 +118,11 @@ static void enable_per_clocks(void)
writel(PRCM_MOD_EN, cmwkup-wkup_i2c0ctrl);
while (readl(cmwkup-wkup_i2c0ctrl) != PRCM_MOD_EN)
;
+
+ /* i2c1 */
+ writel(PRCM_MOD_EN, cmper-i2c1clkctrl);
+ while (readl(cmper-i2c1clkctrl) != PRCM_MOD_EN)
+ ;
}
static void mpu_pll_config(void)
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 9ccb436..b97cfc8 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -280,6 +280,14 @@ static struct module_pin_mux i2c0_pin_mux[] = {
{-1},
};
+static struct module_pin_mux i2c1_pin_mux[] = {
+ {OFFSET(spi0_d1), (MODE(2) | RXACTIVE |
+ PULLUDEN | SLEWCTRL)}, /* I2C_DATA */
+ {OFFSET(spi0_cs0), (MODE(2) | RXACTIVE |
+ PULLUDEN | SLEWCTRL)}, /* I2C_SCLK */
+ {-1},
+};
+
/*
* Configure the pin mux for the module
*/
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 89e2aa0..2b41c1c 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -108,6 +108,7 @@
#define CONFIG_HARD_I2C
#define CONFIG_SYS_I2C_SPEED 10
#define CONFIG_SYS_I2C_SLAVE 1
+#define CONFIG_I2C_MULTI_BUS
#define CONFIG_DRIVER_OMAP24XX_I2C
#define CONFIG_BAUDRATE115200
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap: am33xx: enable gpio support
This patch uses the code in omap-common to support gpio modules 1-3
on am33xx based boards.
It adds base address and register definitions, enables clocks to the
modules, and enables building the common gpio code for CONFIG_AM33XX
as well as CONFIG_OMAP
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/cpu/armv7/am33xx/board.c | 10 ++
arch/arm/cpu/armv7/am33xx/clock.c | 15 +++
arch/arm/cpu/armv7/omap-common/Makefile |2 +-
arch/arm/include/asm/arch-am33xx/cpu.h | 19 +++
arch/arm/include/asm/arch-am33xx/gpio.h | 29 +
5 files changed, 74 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/include/asm/arch-am33xx/gpio.h
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 6b7a494..47ed63c 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -22,6 +22,7 @@
#include asm/arch/omap.h
#include asm/arch/ddr_defs.h
#include asm/arch/clock.h
+#include asm/arch/gpio.h
#include asm/arch/mmc_host_def.h
#include asm/arch/common_def.h
#include asm/io.h
@@ -33,6 +34,15 @@ struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE;
struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+static const struct gpio_bank gpio_bank_am33xx[4] = {
+ { (void *)AM33XX_GPIO0_BASE, METHOD_GPIO_24XX },
+ { (void *)AM33XX_GPIO1_BASE, METHOD_GPIO_24XX },
+ { (void *)AM33XX_GPIO2_BASE, METHOD_GPIO_24XX },
+ { (void *)AM33XX_GPIO3_BASE, METHOD_GPIO_24XX },
+};
+
+const struct gpio_bank *const omap_gpio_bank = gpio_bank_am33xx;
+
/* UART Defines */
#ifdef CONFIG_SPL_BUILD
#define UART_RESET (0x1 1)
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index 57bec98..c1fb75c 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -123,6 +123,21 @@ static void enable_per_clocks(void)
writel(PRCM_MOD_EN, cmper-i2c1clkctrl);
while (readl(cmper-i2c1clkctrl) != PRCM_MOD_EN)
;
+
+ /* gpio1 module */
+ writel(PRCM_MOD_EN, cmper-gpio1clkctrl);
+ while (readl(cmper-gpio1clkctrl) != PRCM_MOD_EN)
+ ;
+
+ /* gpio2 module */
+ writel(PRCM_MOD_EN, cmper-gpio2clkctrl);
+ while (readl(cmper-gpio2clkctrl) != PRCM_MOD_EN)
+ ;
+
+ /* gpio3 module */
+ writel(PRCM_MOD_EN, cmper-gpio3clkctrl);
+ while (readl(cmper-gpio3clkctrl) != PRCM_MOD_EN)
+ ;
}
static void mpu_pll_config(void)
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 2a6625f..1394c3f 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -29,7 +29,7 @@ SOBJS := reset.o
COBJS := timer.o
COBJS += utils.o
-ifdef CONFIG_OMAP
+ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP),)
COBJS += gpio.o
endif
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index be903fb..6ef82dc 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -234,6 +234,25 @@ struct ctrl_stat {
unsigned int statusreg; /* ofset 0x40 */
};
+/* AM33XX GPIO registers */
+#define OMAP_GPIO_REVISION 0x
+#define OMAP_GPIO_SYSCONFIG0x0010
+#define OMAP_GPIO_SYSSTATUS0x0114
+#define OMAP_GPIO_IRQSTATUS1 0x002c
+#define OMAP_GPIO_IRQSTATUS2 0x0030
+#define OMAP_GPIO_CTRL 0x0130
+#define OMAP_GPIO_OE 0x0134
+#define OMAP_GPIO_DATAIN 0x0138
+#define OMAP_GPIO_DATAOUT 0x013c
+#define OMAP_GPIO_LEVELDETECT0 0x0140
+#define OMAP_GPIO_LEVELDETECT1 0x0144
+#define OMAP_GPIO_RISINGDETECT 0x0148
+#define OMAP_GPIO_FALLINGDETECT0x014c
+#define OMAP_GPIO_DEBOUNCE_EN 0x0150
+#define OMAP_GPIO_DEBOUNCE_VAL 0x0154
+#define OMAP_GPIO_CLEARDATAOUT 0x0190
+#define OMAP_GPIO_SETDATAOUT 0x0194
+
void init_timer(void);
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL_STRICT_NAMES */
diff --git a/arch/arm/include/asm/arch-am33xx/gpio.h
b/arch/arm/include/asm/arch-am33xx/gpio.h
new file mode 100644
index 000..1a211e9
--- /dev/null
+++ b/arch/arm/include/asm/arch-am33xx/gpio.h
@@ -0,0 +1,29 @@
+/*
+ *
+ * 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
[U-Boot] [PATCH 0/3] omap: fix bugs in automatic emif setup code
While bringing up a new OMAP4 based board I encountered a number of issues when attempting to use the automatic emif setup code. This patch series fixes a compile error and two runtime issues. Tested on the new custom OMAP4 board and Pandaboard Steve Sakoman (3): omap: fix compile error in emif-common.c omap: emif: deal with rams that return duplicate mr data on all byte lanes omap: emif: fix bug in manufacturer code test arch/arm/cpu/armv7/omap-common/emif-common.c |9 +++-- arch/arm/cpu/armv7/omap4/sdram_elpida.c |6 +++--- 2 files changed, 10 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] omap: fix compile error in emif-common.c
ext_phy_ctrl_const_base is currently only defined if
CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS is set.
If not set, the following error occurs:
In function `do_sdram_init':
| arch/arm/cpu/armv7/omap-common/emif-common.c:985: undefined reference to
`ext_phy_ctrl_const_base'
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/cpu/armv7/omap4/sdram_elpida.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
index b538960..0599aaa 100644
--- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
+++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
@@ -46,6 +46,9 @@
* - emif_get_device_timings()
*/
+/* Dummy registers for OMAP44xx */
+const u32 ext_phy_ctrl_const_base[EMIF_EXT_PHY_CTRL_CONST_REG];
+
#ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
static const struct emif_regs emif_regs_elpida_200_mhz_2cs = {
@@ -90,9 +93,6 @@ const struct emif_regs emif_regs_elpida_400_mhz_2cs = {
.emif_ddr_phy_ctlr_1= 0x049ff418
};
-/* Dummy registers for OMAP44xx */
-const u32 ext_phy_ctrl_const_base[EMIF_EXT_PHY_CTRL_CONST_REG];
-
const struct dmm_lisa_map_regs lisa_map_2G_x_1_x_2 = {
.dmm_lisa_map_0 = 0xFF020100,
.dmm_lisa_map_1 = 0,
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] omap: emif: deal with rams that return duplicate mr data on all byte lanes
Some rams (Micron for example) return duplicate mr data on all byte lanes. Users of the get_mr function currently don't deal with this duplicated data gracefully. This patch detects the duplicated data and returns only the expected 8 bit mr data. Signed-off-by: Steve Sakoman st...@sakoman.com --- arch/arm/cpu/armv7/omap-common/emif-common.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c b/arch/arm/cpu/armv7/omap-common/emif-common.c index db509c9..176520c 100644 --- a/arch/arm/cpu/armv7/omap-common/emif-common.c +++ b/arch/arm/cpu/armv7/omap-common/emif-common.c @@ -56,7 +56,12 @@ static inline u32 get_mr(u32 base, u32 cs, u32 mr_addr) mr = readl(emif-emif_lpddr2_mode_reg_data); debug(get_mr: EMIF%d cs %d mr %08x val 0x%x\n, emif_num(base), cs, mr_addr, mr); - return mr; + if (((mr 0xff00) 8) == (mr 0xff) + ((mr 0x00ff) 16) == (mr 0xff) + ((mr 0xff00) 24) == (mr 0xff)) + return mr 0xff; + else + return mr; } static inline void set_mr(u32 base, u32 cs, u32 mr_addr, u32 mr_val) -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] omap: emif: fix bug in manufacturer code test
Code currently tests for = 0xff. Micron manufacturer code is 0xff, so
Micron memory will not be detected!
Signed-off-by: Steve Sakoman st...@sakoman.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 176520c..46be4e8 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -831,7 +831,7 @@ static u8 is_lpddr2_sdram_present(u32 base, u32 cs,
}
mr = get_mr(base, cs, LPDDR2_MR5);
- if (mr = 0xFF) {
+ if (mr 0xFF) {
/* Mode register value bigger than 8 bit */
return 0;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap: am33xx: accomodate input clocks other than 24 Mhz
The PLL setup values currently assume a 24 Mhz input clock. This patch uses V_OSCK from the board config file to support boards with different input clock rates. Signed-off-by: Steve Sakoman st...@sakoman.com --- arch/arm/include/asm/arch-am33xx/clocks_am33xx.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index abc5b6b..d748dd2 100644 --- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h @@ -19,16 +19,16 @@ #ifndef _CLOCKS_AM33XX_H_ #define _CLOCKS_AM33XX_H_ -#define OSC24 +#define OSC(V_OSCK/100) /* MAIN PLL Fdll = 550 MHZ, */ #define MPUPLL_M 550 -#define MPUPLL_N 23 +#define MPUPLL_N (OSC-1) #define MPUPLL_M2 1 /* Core PLL Fdll = 1 GHZ, */ #define COREPLL_M 1000 -#define COREPLL_N 23 +#define COREPLL_N (OSC-1) #define COREPLL_M4 10 /* CORE_CLKOUTM4 = 200 MHZ */ #define COREPLL_M5 8 /* CORE_CLKOUTM5 = 250 MHZ */ @@ -40,13 +40,13 @@ * For clkout = 192 MHZ, Fdll = 960 MHZ, divider values are given below */ #define PERPLL_M 960 -#define PERPLL_N 23 +#define PERPLL_N (OSC-1) #define PERPLL_M2 5 /* DDR Freq is 266 MHZ for now */ /* Set Fdll = 400 MHZ , Fdll = M * 2 * CLKINP/ N + 1; clkout = Fdll /(2 * M2) */ #define DDRPLL_M 266 -#define DDRPLL_N 23 +#define DDRPLL_N (OSC-1) #define DDRPLL_M2 1 extern void pll_init(void); -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
On Tue, Dec 20, 2011 at 4:20 AM, Igor Grinberg grinb...@compulab.co.ilwrote: What about forging some very not optimized default DRAM settings, that suit any assembled DRAM and then when you have I2C access, reconfigure it - is it possible? The board ID is used to determine some fairly fundamental things like how the address bits are multiplexed, bank size, number of banks, and timing. Perhaps it might be possible to determine some non-optimal settings that can work with the current set of POP memories used, and also a scheme to modify the above on the fly while executing from said ram, but then one would have to revisit this every time a new vendor/type of POP was used. That seems a lot more complex than the current method. I suppose we could just drop support for the old boards in u-boot. Those folks could continue to use the current x-load solution. Or perhaps someone will come up with a more clever idea! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] overo: add SPL support
On Wed, Dec 14, 2011 at 8:27 AM, Andreas Müller schnitzelt...@gmx.de wrote:
* implemenatation based on ti beagleboard/omap3evm
* timing data taken from x-loader
* run-tested with overo release 0 and 1 / boot from NAND and SDcard
Thanks for doing this!
I took a quick look and only see one addition to Tom's comments. See below.
Signed-off-by: Andreas Müller schnitzelt...@gmx.de
---
arch/arm/include/asm/arch-omap3/mem.h | 27
board/overo/config.mk | 28
board/overo/overo.c | 41 +++-
include/configs/omap3_overo.h | 56
-
4 files changed, 122 insertions(+), 30 deletions(-)
delete mode 100644 board/overo/config.mk
diff --git a/arch/arm/include/asm/arch-omap3/mem.h
b/arch/arm/include/asm/arch-omap3/mem.h
index 5fd02d4..18998d8 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -123,6 +123,33 @@ enum {
V_MCFG_BANKALLOCATION_RBC | \
V_MCFG_B32NOT16_32 | V_MCFG_DEEPPD_EN | V_MCFG_RAMTYPE_DDR
+
+/* Hynix part of Overo (165MHz optimized) 6.06ns */
+#define HYNIX_TDAL_165 6
+#define HYNIX_TDPL_165 3
+#define HYNIX_TRRD_165 2
+#define HYNIX_TRCD_165 3
+#define HYNIX_TRP_165 3
+#define HYNIX_TRAS_165 7
+#define HYNIX_TRC_165 10
+#define HYNIX_TRFC_165 21
+#define HYNIX_V_ACTIMA_165 \
+ ACTIM_CTRLA(HYNIX_TRFC_165, HYNIX_TRC_165, \
+ HYNIX_TRAS_165, HYNIX_TRP_165, \
+ HYNIX_TRCD_165, HYNIX_TRRD_165, \
+ HYNIX_TDPL_165, HYNIX_TDAL_165)
+
+#define HYNIX_TWTR_165 1
+#define HYNIX_TCKE_165 1
+#define HYNIX_TXP_165 2
+#define HYNIX_XSR_165 24
+#define HYNIX_V_ACTIMB_165 \
+ ACTIM_CTRLB(HYNIX_TWTR_165, HYNIX_TCKE_165, \
+ HYNIX_TXP_165, HYNIX_XSR_165)
+
+#define HYNIX_RASWIDTH_165 0x2
+#define HYNIX_V_MCFG_165(size) MCFG((size), HYNIX_RASWIDTH_165)
+
/* Hynix part of AM/DM37xEVM (200MHz optimized) */
#define HYNIX_TDAL_200 6
#define HYNIX_TDPL_200 3
diff --git a/board/overo/config.mk b/board/overo/config.mk
deleted file mode 100644
index e7c471c..000
--- a/board/overo/config.mk
+++ /dev/null
@@ -1,28 +0,0 @@
-#
-# Overo uses OMAP3 (ARM-CortexA8) cpu
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# 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
-#
-# Physical Address:
-# 8000' (bank0)
-# A000/ (bank1)
-# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
-# (mem base + reserved)
-
-CONFIG_SYS_TEXT_BASE = 0x80008000
diff --git a/board/overo/overo.c b/board/overo/overo.c
index 3c60b06..dbe43ab 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -31,6 +31,7 @@
#include common.h
#include netdev.h
#include twl4030.h
+#include linux/mtd/nand.h
#include asm/io.h
#include asm/arch/mmc_host_def.h
#include asm/arch/mux.h
@@ -126,6 +127,44 @@ int get_board_revision(void)
return revision;
}
+#ifdef CONFIG_SPL_BUILD
+/*
+ * Routine: get_board_mem_timings
+ * Description: If we use SPL then there is no x-loader nor config header
+ * so we have to setup the DDR timings ourself on both banks.
+ */
+void get_board_mem_timings(u32 *mcfg, u32 *ctrla, u32 *ctrlb, u32 *rfr_ctrl,
+ u32 *mr)
+{
+ *mr = MICRON_V_MR_165;
+ switch (get_board_revision()) {
I think you will also need to update the get_board_revision function
to ensure that SPL works with very early Overo revisions.
Note this excerpt from the X-loader get_board_revision funtion:
/* board revisions = R2410 connect 4030 irq_1 to gpio112 */
/* these boards should return a revision number of 0 */
/* the code below forces a 4030 RTC irq to ensure that gpio112 is low */
#ifdef CONFIG_DRIVER_OMAP34XX_I2C
i2c_init(CFG_I2C_SPEED, CFG_I2C_SLAVE);
data = 0x01;
i2c_write(0x4B, 0x29, 1, data, 1);
data = 0x0c;
i2c_write(0x4B, 0x2b, 1, data, 1);
i2c_read(0x4B, 0x2a, 1, data, 1);
#endif
Re: [U-Boot] SPL broken for pandaboard with v2011.09?
On Thu, Oct 13, 2011 at 1:18 AM, Aneesh V ane...@ti.com wrote: Perhaps it is a board rev issue. Yes it is. SPL works on everything other than a Panda with OMAP4430 ES2.0. I could reproduce it on an ES2.0 Panda. Please note that an SDP with OMAP4430 ES2.0 works too, which is rather strange. At the outset, it looked like a memory issue so I used CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS, which removed memory check failure. However, it still fails at the same point. The fact that Lauterbach is not working on my board is not helping my investigations. Also, the only ES2.0 Panda I could find here is also being used by another person. So, I have to time-share it with him. I will try to investigate it further today as soon as I get the board. Thanks for looking at this Aneesh! I too tried both computed and precalculated timing and found that both failed. X-loader works on my board so I have begun comparing the setup between x-loader and u-boot-spl. There are definitely differences in the register setup. Will spend some more time on this tomorrow. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL broken for pandaboard with v2011.09?
On Wed, Oct 12, 2011 at 3:00 PM, John Rigby john.ri...@linaro.org wrote: Has anyone else been able to successfully use SPL on pandaboard with v2011.09? You may want to see if the spl is oversize. Sometime ago the size was pushed up to 38K but the base was not moved to accommodate the extra size so there has been the possibility of problems since then. I work around it in my own tree by moving CONFIG_SPL_TEXT_BASE down but that breaks HS devices. The patches that start with this email http://lists.denx.de/pipermail/u-boot/2011-September/102518.html set the size back to 32K. I saw those patches and have those changes incorporated too. The spl I built is less than 32K. It seems that the issue is in RAM setup -- the RAM test fails after one word (hence it reporting 4 byte RAM size). Is your tree based on v2011.09? Is it public? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL broken for pandaboard with v2011.09?
On Wed, Oct 12, 2011 at 3:23 PM, John Rigby john.ri...@linaro.org wrote: My tree has the precalculated ddr timing patch: U-Boot/SPL: omap4: Make ddr pre-calculated timings as default. All ddr configurations(geometry/timings) are done automatically by detecting the device connected at run time. Though this is a useful feature, making this as a default setting increases the code size by about 2K bytes. This is quite big, especially in the case of SPL which runs from a smaller SRAM. So do not use this feature as the default setting, instead use the precalculated tables. Signed-off-by: sricharan r.sricha...@ti.com But you probably picked that up with the spl size fix from the same author. I did, and the mmc/fat fix also makes the same change so there is an easily fixable conflict when applying all three patches. Is your tree based on v2011.09? Is it public? My tree has a bunch of extra patches on top and is based on rc2. I know it works: http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=summary OK, I will give that a try first. My -next tree has had no testing because I only just put it together. It is nearly identical to the above but rebased to v2011.09 final: http://git.linaro.org/gitweb?p=boot/u-boot-linaro-next.git;a=summary If your rc2 based branch works then I will try this one too to see if something broke subsequently. Thanks! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL broken for pandaboard with v2011.09?
On Wed, Oct 12, 2011 at 3:23 PM, John Rigby john.ri...@linaro.org wrote: My tree has a bunch of extra patches on top and is based on rc2. I know it works: http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=summary Very strange - it doesn't work for me :-( I build from the above repo, commit 5cb383736d0e26cf85336389e234b5372fb500dd I get similar results: U-Boot SPL 2011.09-rc2 (Oct 12 2011 - 15:48:01) Texas Instruments OMAP4430 ES2.0 SDRAM: identified size not same as expected size identified: 4 expected: 4000 MMC Device 0 not found spl: mmc device not found!! ### ERROR ### Please RESET the board ### X-load builds work just fine on my pandaboard, which is Rev EA1. Perhaps it is a board rev issue. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL broken for pandaboard with v2011.09?
I'm considering using SPL instead of x-load for an upcoming omap project. To begin learning about SPL I tried building and running SPL for pandaboard using v2011.09. With my initial build I got the following output: U-Boot SPL 2011.09 (Oct 11 2011 - 10:18:27) Texas Instruments OMAP4430 ES2.0 SDRAM: identified size not same as expected size identified: 4 expected: 2000 MMC Device 0 not found spl: mmc device not found!! ### ERROR ### Please RESET the board ### Searching the list to see if others were having trouble, I found this patch and applied it: [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT This eliminated the MMC error, but spl still seems broken: U-Boot SPL 2011.09 (Oct 11 2011 - 13:42:38) Texas Instruments OMAP4430 ES2.0 SDRAM: identified size not same as expected size identified: 4 expected: 4000 : 738198048, Has anyone else been able to successfully use SPL on pandaboard with v2011.09? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] OMAP3: overo : Use ttyO2 instead of ttyS2.
On Tue, Oct 11, 2011 at 2:23 PM, Philip Balister phi...@balister.org wrote: Starting with kernel 2.6.37, the serial ports on the OMAP3 are called ttyOX, not ttySX. Signed-off-by: Philip Balister phi...@opensdr.com Tested-by: Steve Sakoman st...@sakoman.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] OMAP3: overo: Move ethernet CS4 configuration to execute based on board id
On Tue, Oct 11, 2011 at 2:23 PM, Philip Balister phi...@balister.org wrote: By moving the CS4 configuration into the board specific configuration, it is left free for custom carrier boards. The USRP-E1XX series uses CS4 to control access to an FPGA, so without this patch the device driver cannot claim CS4. Signed-off-by: Philip Balister phi...@opensdr.com Tested-by: Steve Sakoman st...@sakoman.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] OMAP3: overo : Add environment variable optargs to bootargs
On Tue, Oct 11, 2011 at 2:23 PM, Philip Balister phi...@balister.org wrote: This allows the user can easily add extra kernel arguments. Very helpful for reserving memory for the DSP without rewriting the entire kernel argument line. Signed-off-by: Philip Balister phi...@opensdr.com Tested-by: Steve Sakoman st...@sakoman.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap: TWL4030 Bump VMMC1 interface voltage from 3V to 3.15V
On Wed, Sep 28, 2011 at 9:47 AM, Ash Charles a...@gumstix.com wrote: MMC interfaces are specified to be 3.3V compatible with an operating voltage range of 3.1V to 3.5V for SD cards. This change affects hardware using TWL4030 (TPS6595x) PMICs and should improve the reliability when communicating with marginally-spec'd MMC devices. 3.15V is the highest possible level for this chip. This patch has been tested on a Gumstix Overo board. Signed-off-by: Ash Charles a...@gumstix.com Tested-by: Steve Sakoman st...@sakoman.com Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] omap: overo: Configure mux for gpio10
This pad was previously configured for sysclkout_1. This patch changes
the configuration to gpio_10 to reduce radiated noise from the 26Mhz
clock, as well as make the pin more generally useful.
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/board/overo/overo.h b/board/overo/overo.h
index d394f90..42ef1b1 100644
--- a/board/overo/overo.h
+++ b/board/overo/overo.h
@@ -290,7 +290,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(SYS_BOOT5), (IEN | PTD | DIS | M4)) /*GPIO_7*/\
MUX_VAL(CP(SYS_BOOT6), (IDIS | PTD | DIS | M4)) /*GPIO_8*/\
MUX_VAL(CP(SYS_OFF_MODE), (IEN | PTD | DIS | M0))
/*SYS_OFF_MODE*/\
- MUX_VAL(CP(SYS_CLKOUT1),(IEN | PTD | DIS | M0))
/*SYS_CLKOUT1*/\
+ MUX_VAL(CP(SYS_CLKOUT1),(IEN | PTU | EN | M4)) /*GPIO_10*/\
MUX_VAL(CP(SYS_CLKOUT2),(IEN | PTU | EN | M4)) /*GPIO_186*/\
MUX_VAL(CP(ETK_CLK_ES2),(IEN | PTU | EN | M2)) /*MMC3_CLK*/\
MUX_VAL(CP(ETK_CTL_ES2),(IEN | PTU | EN | M2)) /*MMC3_CMD*/\
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] omap: overo: Disable pull-ups on camera PCLK, HS and VS signals
The level shifters used on the Caspa camera module have a 4k output
impedance. Combined with the 100uA pull-up resistors in the OMAP3,
this raises the ground level to 400mV. Adding crosstalk between the
pixel clock and the HS/VS signals on the flat cable (a ground line in
between would have been nice), logic 0 levels can raise up to 650mV.
This exceeds the camera input pins VIL maximum voltage. This change
suggested-by Laurent Pinchart
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/board/overo/overo.h b/board/overo/overo.h
index 42ef1b1..915f15b 100644
--- a/board/overo/overo.h
+++ b/board/overo/overo.h
@@ -160,10 +160,10 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(DSS_DATA22), (IDIS | PTD | DIS | M0)) /*DSS_DATA22*/\
MUX_VAL(CP(DSS_DATA23), (IDIS | PTD | DIS | M0)) /*DSS_DATA23*/\
/*CAMERA*/\
- MUX_VAL(CP(CAM_HS), (IEN | PTU | EN | M0)) /*CAM_HS */\
- MUX_VAL(CP(CAM_VS), (IEN | PTU | EN | M0)) /*CAM_VS */\
+ MUX_VAL(CP(CAM_HS), (IEN | PTU | DIS | M0)) /*CAM_HS */\
+ MUX_VAL(CP(CAM_VS), (IEN | PTU | DIS | M0)) /*CAM_VS */\
MUX_VAL(CP(CAM_XCLKA), (IDIS | PTD | DIS | M0)) /*CAM_XCLKA*/\
- MUX_VAL(CP(CAM_PCLK), (IEN | PTU | EN | M0)) /*CAM_PCLK*/\
+ MUX_VAL(CP(CAM_PCLK), (IEN | PTU | DIS | M0)) /*CAM_PCLK*/\
MUX_VAL(CP(CAM_FLD),(IDIS | PTD | DIS | M4)) /*CAM_FLD*/\
MUX_VAL(CP(CAM_D0), (IEN | PTD | DIS | M0)) /*CAM_D0*/\
MUX_VAL(CP(CAM_D1), (IEN | PTD | DIS | M0)) /*CAM_D1*/\
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/13] BeagleBoard: config: Switch console to ttyO2
On Mon, Aug 15, 2011 at 7:47 PM, Joel A Fernandes agnel.j...@gmail.com wrote: Signed-off-by: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel A Fernandes agnel.j...@gmail.com --- include/configs/omap3_beagle.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 038fb5b..6e66100 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -200,7 +200,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ loadaddr=0x8200\0 \ usbtty=cdc_acm\0 \ - console=ttyS2,115200n8\0 \ + console=ttyO2,115200n8\0 \ mpurate=auto\0 \ buddy=none \ vram=12M\0 \ Any status on this patch? It doesn't seem to have made it into v2011.09 FWIW: Tested-by: Steve Sakoman st...@sakoman.com Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] omap: overo: Use ubifs instead of jffs2 for nand
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 9a8ef06..8114194 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -164,8 +164,8 @@
mmcdev=0\0 \
mmcroot=/dev/mmcblk0p2 rw\0 \
mmcrootfstype=ext3 rootwait\0 \
- nandroot=/dev/mtdblock4 rw\0 \
- nandrootfstype=jffs2\0 \
+ nandroot=ubi0:rootfs ubi.mtd=4\0 \
+ nandrootfstype=ubifs\0 \
mmcargs=setenv bootargs console=${console} \
${optargs} \
mpurate=${mpurate} \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap: beagle: Use ubifs instead of jffs2 for nand boot
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 2c0f5a5..a92ffdf 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -227,8 +227,8 @@
mmcdev=0\0 \
mmcroot=/dev/mmcblk0p2 rw\0 \
mmcrootfstype=ext3 rootwait\0 \
- nandroot=/dev/mtdblock4 rw\0 \
- nandrootfstype=jffs2\0 \
+ nandroot=ubi0:rootfs ubi.mtd=4\0 \
+ nandrootfstype=ubifs\0 \
ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=0x8100,64M\0 \
ramrootfstype=ext2\0 \
mmcargs=setenv bootargs console=${console} \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap: beagle: Use ubifs instead of jffs2 for nand boot
On Fri, Sep 30, 2011 at 12:32 PM, Kooi, Koen k-k...@ti.com wrote: On Fri, Sep 30, 2011 at 21:29:11, Steve Sakoman wrote: Subject: [PATCH] omap: beagle: Use ubifs instead of jffs2 for nand boot Signed-off-by: Steve Sakoman st...@sakoman.com --- diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 2c0f5a5..a92ffdf 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -227,8 +227,8 @@ mmcdev=0\0 \ mmcroot=/dev/mmcblk0p2 rw\0 \ mmcrootfstype=ext3 rootwait\0 \ - nandroot=/dev/mtdblock4 rw\0 \ - nandrootfstype=jffs2\0 \ + nandroot=ubi0:rootfs ubi.mtd=4\0 \ + nandrootfstype=ubifs\0 \ IIRC all beagle builds use 'beagleboard-rootfs' as ubi name, but I need to double check. In any case, this is already a massive improvement, so: Acked-by: Koen Kooi k-k...@ti.com I do generic omap kernel rootfs builds, so it seemed better to do a non machine specific ubi name. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4: update maintainer for omap4 boards
On Thu, Sep 22, 2011 at 7:13 AM, Aneesh V ane...@ti.com wrote: Steve wants to transfer maintainership of OMAP4 boards to me as he is not working on these boards lately. CC: Steve Sakoman st...@sakoman.com CC: Sandeep Paulraj s-paul...@ti.com CC: Albert Aribaud albert.u.b...@aribaud.net CC: Wolfgang Denk w...@denx.de Signed-off-by: Aneesh V ane...@ti.com --- MAINTAINERS | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2f60a60..bee8699 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -798,6 +798,9 @@ Nomadik Linux Team stn_wmm_nomadik_li...@list.st.com Steve Sakoman sako...@gmail.com omap3_overo ARM ARMV7 (OMAP3xx SoC) + +Aneesh V ane...@ti.com + omap4_panda ARM ARMV7 (OMAP4xx SoC) omap4_sdp4430 ARM ARMV7 (OMAP4xx SoC) Of course you have my ack for this, but I suspect that Wolfgang will want you to modify the patch to preserve alphabetical ordering of names. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Overo: Update GPMC timing for ethernet chip.
On Wed, Sep 7, 2011 at 4:57 AM, Philip Balister phi...@balister.org wrote:
The existing timing does not quite meet the minimum requirements
in the LAN9221 datasheet. The timing in this patch solves problems
noticed on some parts.
Signed-off-by: Philip Balister phi...@opensdr.com
Acked-by: Steve Sakoman st...@sakoman.com
Tested-by: Steve Sakoman st...@sakoman.com
---
board/overo/overo.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/overo/overo.h b/board/overo/overo.h
index 68e1243..617c0c3 100644
--- a/board/overo/overo.h
+++ b/board/overo/overo.h
@@ -35,10 +35,10 @@ const omap3_sysinfo sysinfo = {
/* GPMC CS 5 connected to an SMSC LAN9221 ethernet controller */
#define NET_LAN9221_GPMC_CONFIG1 0x1000
-#define NET_LAN9221_GPMC_CONFIG2 0x00080701
+#define NET_LAN9221_GPMC_CONFIG2 0x00060700
#define NET_LAN9221_GPMC_CONFIG3 0x00020201
-#define NET_LAN9221_GPMC_CONFIG4 0x08030703
-#define NET_LAN9221_GPMC_CONFIG5 0x00060908
+#define NET_LAN9221_GPMC_CONFIG4 0x06000700
+#define NET_LAN9221_GPMC_CONFIG5 0x0006090A
#define NET_LAN9221_GPMC_CONFIG6 0x8703
#define NET_LAN9221_GPMC_CONFIG7 0x0f6c
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] fix break caused by new binutils
On Mon, 2011-01-24 at 19:36 +0100, Víctor Manuel Jáquez Leal wrote: According with this discussion [1] the new assemblers need -march=armv7-a+sec on command line or .arch_extension sec inline to enable use of the smc instruction. In the sakoman's u-boot repository there is branch for the omap4 [2] which uses the smc instruction with the -march=armv7-a, and it will not compile with the latest binutils (2.21) Just to clarify -- my branch has Aneesh's armv7: adapt omap4 to the new cache maintenance framework patch series in it. So this issue will arise only when Aneesh's patch series is applied. Perhaps this fix could be incorporated into Aneesh's next revision?? Steve This patch fix that problem adding conditionally the armv7-a+sec the march. In order to do this the patch adds as-instr which checks the latter to enable the correct -march in AFLAGS for files that use smc. This patch must be applied on top of git://www.sakoman.com/git/u-boot.git;branch=omap4-exp 1. https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/669912 2. http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-exp Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com --- arch/arm/cpu/armv7/omap4/Makefile |2 ++ config.mk |9 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/omap4/Makefile b/arch/arm/cpu/armv7/omap4/Makefile index 987dc9d..9dc2b64 100644 --- a/arch/arm/cpu/armv7/omap4/Makefile +++ b/arch/arm/cpu/armv7/omap4/Makefile @@ -26,6 +26,8 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(SOC).o SOBJS+= lowlevel_init.o +plus_sec := $(call as-instr,.arch_extension sec,+sec) +lowlevel_init.o: AFLAGS += -Wa,-march=armv7-a$(plus_sec) COBJS+= board.o COBJS+= mem.o diff --git a/config.mk b/config.mk index c6d6f7b..8d86860 100644 --- a/config.mk +++ b/config.mk @@ -266,3 +266,12 @@ cmd_link_o_target = $(if $(strip $1),\ rm -f $@; $(AR) rcs $@ ) # + +# Tries to compile an assembly instruction +as-instr = $(shell if echo -e $(1) | \ +$(CC) $(AFLAGS) -c -xassembler - \ + -o $(TMPOUT)astest.out /dev/null 21; \ + then rm $(TMPOUT)astest.out; echo $(2); \ + else echo $(3); fi) + +# ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP: Remove omapfb.debug=y from Beagle and Overo env settings
The kernel DSS2 code is mature now, and keeping this setting hurts performance
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 56363f7..d0ef313 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -203,7 +203,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${mmcroot} \
rootfstype=${mmcrootfstype}\0 \
@@ -211,7 +210,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 3b53796..74b2ff0 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -169,7 +169,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${mmcroot} \
rootfstype=${mmcrootfstype}\0 \
@@ -177,7 +176,6 @@
mpurate=${mpurate} \
vram=${vram} \
omapfb.mode=dvi:${dvimode} \
- omapfb.debug=y \
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] armv7: cache maintenance operations
On Wed, Dec 22, 2010 at 3:54 AM, Aneesh V ane...@ti.com wrote: With D-cache and MMU enabled for ARM in u-boot it becomes imperative to support a minimal set of cache maintenance operations and necessary initializations before enabling MMU. This series of patches attempt to do the following for armv7: * Necessary initialization sequence before enabling MMU that includes invalidation of TLB, data caches, branch predictor array etc. * Framework for supporting SOC specific outer caches in a generic manner (using a structure of function pointers - inspired by the Linux implementation) * Generic armv7 cache maintenance operations for caches known to the CPU * Support for ARM PL310 L2 cache controller used in OMAP4 * Cleanup of the cleanup_before_linux() function * Adapting all armv7 SOCs to use the new framework and removing duplicated code Testing: * Extensive testing on OMAP4430SDP and OMAP3430SDP by creating coherency issues and solving them using the maintenance routines - Eg: memfill a region of memory with a known pattern - Invalidate the region - Read back and compare the region with the original pattern - If match fails it means that invalidate is successful - Now add a flush call just before the invalidate - If match succeeds it means that flush was successful - Outer caches were tested with experiments involving making the function pointers NULL * Kernel booting on OMAP4430SDP and OMAP3430SDP I build tested for Beagle, Overo, Panda, and OMAP4430SDP - no issues. I run tested on Overo and Panda to evaluate the changes on both OMAP3 and OMAP4 - no issues. Tested-by: Steve Sakoman steve.sako...@linaro.org Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fw_printenv supports mmc device
On Wed, Dec 15, 2010 at 5:22 PM, Donghwa Lee dh09@samsung.com wrote: I modified fw_printenv tools to use /dev/mmcblk0 node. Original fw_printenv tool can be access MTD devices, but, in some cases, environment variables can be stored other memory devices, for example, mmc devices. So, I modified a few code to use /dev/mmcblk0. I submitted a similar patch series from Loïc Minier a couple of weeks ago: http://old.nabble.com/-U-Boot---RFC-0-3--Enhance-env-tools-td30373328.html I've been working a a v2 to address the comments received. Do you think a variant of that patch series will work for you? Perhaps we could combine efforts for a patch series to solve the mmc and normal file write targets? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] OMAP: Timer: Replace bss variable by gd
On Thu, Dec 9, 2010 at 11:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Dirk Behme, In message 4d01b92e.8050...@googlemail.com you wrote: Note: This is compile tested only (therefore the RFC). Please *test* on real OMAP HW, e.g. Beagle. To the custodian who has to apply this: Regarding the RFC in the subject: Now that this patch is confirmed to work, will you apply this patch as is? Or do I have to resend it without 'RFC'? If Sandeep agrees, I wil pull this directly, as this fixes a real problem for many of us. Sorry for the delay in testing, jury duty this week :-( I build tested for Beagle, Overo, Panda, and SDP4430 - no issues. Run tested on Beagle, Overo, and Panda - no issues. Tested-by: Steve Sakoman steve.sako...@linaro.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 2/3] tools/env: Support writing to files
On Sat, 2010-12-04 at 05:37 -0500, Mike Frysinger wrote:
On Friday, December 03, 2010 23:28:52 Steve Sakoman wrote:
- ioctl (fd, MEMLOCK, erase);
+ if (is_mtd) {
+ ioctl (fd, MEMLOCK, erase);
+ }
useless braces
Good catch, I will correct in the next revision.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/3] tools/env: Default to the config specified in FW_CONFIG_FILE
On Sat, 2010-12-04 at 11:59 +0100, Stefano Babic wrote: On 12/04/2010 05:28 AM, Steve Sakoman wrote: From: Loïc Minier loic.min...@linaro.org Hi, #if defined(CONFIG_FILE) + /* Default to the config file specified in FW_CONFIG_FILE */ + char *config_file = getenv(FW_CONFIG_FILE); What about to pass the configuration file on the command line instead of an environment variable ? Something like fw_env -c /etc/fw_config, for example ? IMHO it is easier to understand and we can add documentation in the help message. Good suggestion, I prefer that too. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/3] tools/env: Default to the config specified in FW_CONFIG_FILE
On Sat, 2010-12-04 at 05:34 -0500, Mike Frysinger wrote:
On Friday, December 03, 2010 23:28:51 Steve Sakoman wrote:
+ if (!config_file || !strlen(config_file)) {
strlen is a bad bad idea. if you only want to see if it's non-empty, check
the first byte.
I'll correct this in the next revision.
Thanks for reviewing the code!
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 2/3] tools/env: Support writing to files
On Sat, 2010-12-04 at 12:23 +0100, Stefano Babic wrote:
On 12/04/2010 05:28 AM, Steve Sakoman wrote:
-static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart)
+static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart,
+ int is_mtd)
You add an additional parameter to the flash function to check if it is
a real mtd, but we have already a structure to store which type of flash
we have. We could use envdevices[].mtd_type to store that we want to
write into a file and not into a mtd device. There is already a
MTD_ABSENT constant that we could reuse.
{
+ if (!is_mtd)
+ return 0;
+
Because this function does nothing with the parameter, it should be
better to check its value in the caller without calling this function.
/* This only runs once on NOR flash */
while (processed count) {
- rc = flash_bad_block (fd, mtd_type, blockstart);
+ rc = flash_bad_block (fd, mtd_type, blockstart, is_mtd);
Ditto.
rc = flash_read_buf (dev, fd, data, write_total, erase_offset,
-mtd_type);
+mtd_type, is_mtd);
See my first comment. mtd_type can already tell us if we want to write
into a file or into a real mtd device, without adding an additional
parameter.
I have an additional question: if we want to add support to prepare the
environment on the host and to transfer later on the target, should we
not to care about the endianess ? I think the crc is written without
checking the endianess of the target. Does it work for powerpc (usually
big endian) when we run on a host PC ?
Good points! I'll work with Loïc to revise the code and get a new
version submitted.
I don't have a big endian target for testing, but perhaps Loïc has
access to one. Otherwise we'll come back to the list with a request for
testing help.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_nand: Use nand_read_skip_bad instead of nand_read
The nand-read function returns an error code if correctable errors have
occurred.
This is not desirable, since the errors have been corrected!
This patch switches to the nand_read_skip_bad function which does not
return an error code if the errors are correctable.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/common/env_nand.c b/common/env_nand.c
index 4e8307a..7f6c917 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -297,7 +297,7 @@ int readenv(size_t offset, u_char * buf)
offset += blocksize;
} else {
char_ptr = buf[amount_loaded];
- if (nand_read(nand_info[0], offset, len, char_ptr))
+ if (nand_read_skip_bad(nand_info[0], offset, len,
char_ptr))
return 1;
offset += blocksize;
amount_loaded += len;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 0/3] Enhance env tools
There are circustances where it is desirable to run the environment tools on your build machine in order to create an environment image that can be written to the target machine at a later time. This patch series introduces a number of enhancements to the tools that make this possible. The first patch allows allows one to override the default location of the tool config file by setting a FW_CONFIG_FILE environment variable. The second patch allows the environment to be written to a regular file. The third patch increases the devname length to 4096 in order to support writing to normal files in addition to mtd devices. Loïc Minier (3): tools/env: Default to the config specified in FW_CONFIG_FILE tools/env: Support writing to files tools/env: Bump devname length to PATH_MAX for filenames tools/env/fw_env.c | 107 1 files changed, 74 insertions(+), 33 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/3] tools/env: Default to the config specified in FW_CONFIG_FILE
From: Loïc Minier loic.min...@linaro.org
This patch allows one to override the default location of
the config file by setting FW_CONFIG_FILE environment variable.
Signed-off-by: Loïc Minier loic.min...@linaro.org
Tested-by: Steve Sakoman st...@sakoman.com
---
tools/env/fw_env.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 8ff7052..75f6a98 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1224,8 +1224,15 @@ static int parse_config ()
struct stat st;
#if defined(CONFIG_FILE)
+ /* Default to the config file specified in FW_CONFIG_FILE */
+ char *config_file = getenv(FW_CONFIG_FILE);
+ if (!config_file || !strlen(config_file)) {
+ /* If unset or empty use the default config file */
+ config_file = CONFIG_FILE;
+ }
+
/* Fills in DEVNAME(), ENVSIZE(), DEVESIZE(). Or don't. */
- if (get_config (CONFIG_FILE)) {
+ if (get_config (config_file)) {
fprintf (stderr,
Cannot parse config file: %s\n, strerror (errno));
return -1;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 2/3] tools/env: Support writing to files
From: Loïc Minier loic.min...@linaro.org
Track st_mode and use it to skip ioctls on file-backed fds. This allows
writing to regular files transparently.
Signed-off-by: Loïc Minier loic.min...@linaro.org
Tested-by: Steve Sakoman steve.sako...@linaro.org
---
tools/env/fw_env.c | 92 ++-
1 files changed, 61 insertions(+), 31 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 75f6a98..d2f9748 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -60,6 +60,7 @@ struct envdev_s {
ulong erase_size; /* device erase size */
ulong env_sectors; /* number of environment sectors */
uint8_t mtd_type; /* type of the MTD device */
+ mode_t st_mode; /* protection / file type */
};
static struct envdev_s envdevices[2] =
@@ -78,6 +79,7 @@ static int dev_current;
#define DEVESIZE(i) envdevices[(i)].erase_size
#define ENVSECTORS(i) envdevices[(i)].env_sectors
#define DEVTYPE(i)envdevices[(i)].mtd_type
+#define STMODE(i) envdevices[(i)].st_mode
#define CONFIG_ENV_SIZE ENVSIZE(dev_current)
@@ -633,8 +635,12 @@ int fw_parse_script(char *fname)
* 0 - block is bad
* 0 - failed to test
*/
-static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart)
+static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart,
+ int is_mtd)
{
+ if (!is_mtd)
+ return 0;
+
if (mtd_type == MTD_NANDFLASH) {
int badblock = ioctl (fd, MEMGETBADBLOCK, blockstart);
@@ -661,7 +667,7 @@ static int flash_bad_block (int fd, uint8_t mtd_type,
loff_t *blockstart)
* the DEVOFFSET (dev) block. On NOR the loop is only run once.
*/
static int flash_read_buf (int dev, int fd, void *buf, size_t count,
- off_t offset, uint8_t mtd_type)
+ off_t offset, uint8_t mtd_type, int is_mtd)
{
size_t blocklen;/* erase / write length - one block on NAND,
0 on NOR */
@@ -683,7 +689,7 @@ static int flash_read_buf (int dev, int fd, void *buf,
size_t count,
/* Offset inside a block */
block_seek = offset - blockstart;
- if (mtd_type == MTD_NANDFLASH) {
+ if (!is_mtd || mtd_type == MTD_NANDFLASH) {
/*
* NAND: calculate which blocks we are reading. We have
* to read one block at a time to skip bad blocks.
@@ -707,7 +713,7 @@ static int flash_read_buf (int dev, int fd, void *buf,
size_t count,
/* This only runs once on NOR flash */
while (processed count) {
- rc = flash_bad_block (fd, mtd_type, blockstart);
+ rc = flash_bad_block (fd, mtd_type, blockstart, is_mtd);
if (rc 0) /* block test failed */
return -1;
@@ -754,7 +760,7 @@ static int flash_read_buf (int dev, int fd, void *buf,
size_t count,
* the whole data at once.
*/
static int flash_write_buf (int dev, int fd, void *buf, size_t count,
- off_t offset, uint8_t mtd_type)
+ off_t offset, uint8_t mtd_type, int is_mtd)
{
void *data;
struct erase_info_user erase;
@@ -812,7 +818,7 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
}
rc = flash_read_buf (dev, fd, data, write_total, erase_offset,
-mtd_type);
+mtd_type, is_mtd);
if (write_total != rc)
return -1;
@@ -826,7 +832,7 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
data = buf;
}
- if (mtd_type == MTD_NANDFLASH) {
+ if (!is_mtd || mtd_type == MTD_NANDFLASH) {
/*
* NAND: calculate which blocks we are writing. We have
* to write one block at a time to skip bad blocks.
@@ -840,7 +846,7 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
/* This only runs once on NOR flash */
while (processed write_total) {
- rc = flash_bad_block (fd, mtd_type, blockstart);
+ rc = flash_bad_block (fd, mtd_type, blockstart, is_mtd);
if (rc 0) /* block test failed */
return rc;
@@ -854,14 +860,16 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
continue;
}
- erase.start = blockstart;
- ioctl (fd, MEMUNLOCK, erase);
+ if (is_mtd) {
+ erase.start = blockstart;
+ ioctl (fd, MEMUNLOCK, erase);
- if (ioctl (fd, MEMERASE, erase) != 0) {
- fprintf (stderr, MTD erase
[U-Boot] [RFC 3/3] tools/env: Bump devname length to PATH_MAX for filenames
From: Loïc Minier loic.min...@linaro.org
This patch increases the devname length to 4096 in order to support writing
to normal files in addition to mtd devices.
Signed-off-by: Loïc Minier loic.min...@linaro.org
Tested-by: Steve Sakoman steve.sako...@linaro.org
---
tools/env/fw_env.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index d2f9748..a75b73b 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -53,8 +53,12 @@
(void) (_min1 == _min2); \
_min1 _min2 ? _min1 : _min2; })
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
struct envdev_s {
- char devname[16]; /* Device name */
+ char devname[PATH_MAX]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: OMAP4: twl6030 add battery charging support
From: Balaji T K balaj...@ti.com
Add battery charging support twl6030 driver.
Add support for battery voltage and current measurements.
Add command to get battery status and start/stop battery charging from USB.
Signed-off-by: Balaji T K balaj...@ti.com
Tested-by: Steve Sakoman steve.sako...@linaro.org
---
board/ti/sdp4430/Makefile |2 +-
board/ti/sdp4430/cmd_bat.c | 58 ++
board/ti/sdp4430/sdp.c |4 +
drivers/power/twl6030.c | 124 ++-
include/configs/omap4_sdp4430.h |1 +
include/twl6030.h | 45 +-
6 files changed, 229 insertions(+), 5 deletions(-)
create mode 100644 board/ti/sdp4430/cmd_bat.c
diff --git a/board/ti/sdp4430/Makefile b/board/ti/sdp4430/Makefile
index bce8534..f1ee544 100644
--- a/board/ti/sdp4430/Makefile
+++ b/board/ti/sdp4430/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := sdp.o
+COBJS := sdp.o cmd_bat.o
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/ti/sdp4430/cmd_bat.c b/board/ti/sdp4430/cmd_bat.c
new file mode 100644
index 000..fe33538
--- /dev/null
+++ b/board/ti/sdp4430/cmd_bat.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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 common.h
+#include command.h
+
+#ifdef CONFIG_CMD_BAT
+#include twl6030.h
+
+int do_vbat(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ if (argc == 2) {
+ if (strncmp(argv[1], startcharge, 12) == 0)
+ twl6030_start_usb_charging();
+ else if (strncmp(argv[1], stopcharge, 11) == 0)
+ twl6030_stop_usb_charging();
+ else if (strncmp(argv[1], status, 7) == 0) {
+ twl6030_get_battery_voltage();
+ twl6030_get_battery_current();
+ } else {
+ goto bat_cmd_usage;
+ }
+ } else {
+ goto bat_cmd_usage;
+ }
+ return 0;
+
+bat_cmd_usage:
+ return cmd_usage(cmdtp);
+}
+
+U_BOOT_CMD(
+ bat, 2, 1, do_vbat,
+ battery charging, voltage/current measurements,
+ status - display battery voltage and current\n
+ bat startcharge - start charging via USB\n
+ bat stopcharge - stop charging\n
+);
+#endif /* CONFIG_BAT_CMD */
diff --git a/board/ti/sdp4430/sdp.c b/board/ti/sdp4430/sdp.c
index 01d5ce4..b13c4c5 100644
--- a/board/ti/sdp4430/sdp.c
+++ b/board/ti/sdp4430/sdp.c
@@ -23,6 +23,7 @@
* MA 02111-1307 USA
*/
#include common.h
+#include twl6030.h
#include asm/arch/sys_proto.h
#include asm/arch/mmc_host_def.h
@@ -63,6 +64,9 @@ int board_eth_init(bd_t *bis)
*/
int misc_init_r(void)
{
+#ifdef CONFIG_TWL6030_POWER
+ twl6030_init_battery_charging();
+#endif
return 0;
}
diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
index cf1da6b..fef57b4 100644
--- a/drivers/power/twl6030.c
+++ b/drivers/power/twl6030.c
@@ -36,6 +36,54 @@ static inline int twl6030_i2c_read_u8(u8 chip_no, u8 *val,
u8 reg)
return i2c_read(chip_no, reg, 1, val, 1);
}
+static int twl6030_gpadc_read_channel(u8 channel_no)
+{
+ u8 lsb = 0;
+ u8 msb = 0;
+ int ret = 0;
+
+ ret = twl6030_i2c_read_u8(TWL6030_CHIP_ADC, lsb,
+ GPCH0_LSB + channel_no * 2);
+ if (ret)
+ return ret;
+
+ ret = twl6030_i2c_read_u8(TWL6030_CHIP_ADC, msb,
+ GPCH0_MSB + channel_no * 2);
+ if (ret)
+ return ret;
+
+ return (msb 8) | lsb;
+}
+
+static int twl6030_gpadc_sw2_trigger(void)
+{
+ u8 val;
+ int ret = 0;
+
+ ret = twl6030_i2c_write_u8(TWL6030_CHIP_ADC, CTRL_P2_SP2, CTRL_P2);
+ if (ret)
+ return ret;
+
+ /* Waiting until the SW1 conversion ends*/
+ val = CTRL_P2_BUSY;
+
+ while (!((val CTRL_P2_EOCP2) (!(val CTRL_P2_BUSY {
+ ret = twl6030_i2c_read_u8(TWL6030_CHIP_ADC, val, CTRL_P2);
+ if (ret)
+ return ret;
+ udelay(1000
Re: [U-Boot] Pull request: u-boot-arm
On Fri, Nov 26, 2010 at 11:43 PM, Dirk Behme dirk.be...@googlemail.com wrote: On 26.11.2010 21:55, Wolfgang Denk wrote: In message20101126202955.b087d11d9...@gemini.denx.de you wrote: The following changes since commit 6163f5b4c8873848ed023054bc401727301ea537: malloc: Fix issue with calloc memory possibly being non-zero (2010-11-17 22:06:40 +0100) are available in the git repository at: git://git.denx.de/u-boot-arm.git master ... Applied. Doing a './MAKEALL ARMV7' on the recent master (d4752d5d2...) doesn't look nice [2]. The following configs build fine: igep0020 mx51evk omap3_beagle omap3_overo omap3_pandora omap4_panda I have hardware for igep0020, beagle, overo, panda, and sdp4430. I build daily for these machines and submit patches when they break (there is a patch pending for omap4430 that fixes the build for it). Steve The following boards fail to build: am3517_evm board ca9x4_ct_vxp devkit8000 igep0030 omap3_evm omap3_sdp3430 omap3_zoom1 omap3_zoom2 omap4_sdp4430 s5p_goni smdkc100 I applied [1] to fix a beagle warning. Are there any other pending patches to fix the compilation of the failing boards? Thanks Dirk [1] http://patchwork.ozlabs.org/patch/72453/ [2] ./MAKEALL ARMV7 Configuring for am3517_evm board... board.c: In function '__dram_init_banksize': board.c:233: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) board.c:233: error: (Each undeclared identifier is reported only once board.c:233: error: for each function it appears in.) board.c: In function 'board_init_f': board.c:279: error: 'CONFIG_SYS_INIT_SP_ADDR' undeclared (first use in this function) board.c:312: error: 'CONFIG_SYS_SDRAM_BASE' undeclared (first use in this function) make[1]: *** [board.o] Error 1 make: *** [arch/arm/lib/libarm.o] Error 2 size: './u-boot': No such file Configuring for ca9x4_ct_vxp board... syslib.c:26:32: error: asm/arch/sys_proto.h: No such file or directory make[1]: *** No rule to build the target ».depend«, needed from »_depend«. End. syslib.c:26:32: error: asm/arch/sys_proto.h: No such file or directory make[1]: *** [syslib.o] Error 1 make: *** [arch/arm/cpu/armv7/libarmv7.o] Error 2 size: './u-boot': No such file Configuring for devkit8000 board... start.S: Assembler messages: start.S:144: Error: constant expression expected -- `ldr sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))' make[1]: *** [start.o] Error 1 make: *** [arch/arm/cpu/armv7/start.o] Error 2 size: './u-boot': No such file Configuring for igep0020 board... text data bss dec hex filename 219538 7768 214536 441842 6bdf2 ./u-boot Configuring for igep0030 board... net/libnet.o: In function `rpc_req': u-boot.git/net/nfs.c:193: undefined reference to `NetEthHdrSize' u-boot.git/net/nfs.c:202: undefined reference to `NetSendUDPPacket' u-boot.git/net/nfs.c:203: undefined reference to `NetTxPacket' u-boot.git/net/nfs.c:203: undefined reference to `NetServerEther' net/libnet.o: In function `NfsStart': u-boot.git/net/nfs.c:741: undefined reference to `NetSetTimeout' u-boot.git/net/nfs.c:742: undefined reference to `NetSetHandler' u-boot.git/net/nfs.c:754: undefined reference to `BootFile' u-boot.git/net/nfs.c:754: undefined reference to `NetServerIP' u-boot.git/net/nfs.c:754: undefined reference to `NetOurIP' u-boot.git/net/nfs.c:754: undefined reference to `NetOurGatewayIP' u-boot.git/net/nfs.c:754: undefined reference to `NetOurSubnetMask' u-boot.git/net/nfs.c:754: undefined reference to `NetBootFileSize' u-boot.git/net/nfs.c:754: undefined reference to `NetServerEther' net/libnet.o: In function `nfs_read_reply': u-boot.git/net/nfs.c:563: undefined reference to `NetBootFileXferSize' net/libnet.o: In function `NfsHandler': u-boot.git/net/nfs.c:656: undefined reference to `NetSetTimeout' u-boot.git/net/nfs.c:668: undefined reference to `NetState' net/libnet.o: In function `NfsTimeout': u-boot.git/net/nfs.c:574: undefined reference to `NetStartAgain' u-boot.git/net/nfs.c:577: undefined reference to `NetSetTimeout' arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 assertion fail /scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/obj/binutils-src-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:12273 arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 assertion fail /scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/obj/binutils-src-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:12273 arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 assertion fail /scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/obj/binutils-src-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:12273 arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 assertion fail
Re: [U-Boot] Pull request: u-boot-arm
On Sat, Nov 27, 2010 at 3:57 PM, Paulraj, Sandeep s-paul...@ti.com wrote: I have hardware for igep0020, beagle, overo, panda, and sdp4430. I build daily for these machines and submit patches when they break (there is a patch pending for omap4430 that fixes the build for it). Which patch? Can you give me the link? Fear not, you didn't miss anything! The patch just made it to mainline from the arm branch: http://git.denx.de/?p=u-boot.git;a=commit;h=8721e95b16024f0a92ccc1cd85aecf6672fe9499 Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_nand: Use nand_read_skip_bad instead of nand_read
Otherwise environment read will fail if correctable errors occur
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/common/env_nand.c b/common/env_nand.c
index 4e8307a..7f6c917 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -297,7 +297,7 @@ int readenv(size_t offset, u_char * buf)
offset += blocksize;
} else {
char_ptr = buf[amount_loaded];
- if (nand_read(nand_info[0], offset, len, char_ptr))
+ if (nand_read_skip_bad(nand_info[0], offset, len,
char_ptr))
return 1;
offset += blocksize;
amount_loaded += len;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP4: Panda: Disable CMD_NFS
This patch fixes the Panda build after commit 6d8962e814c15807dd6ac5757904be2a02d187b8 by explicitly disabling CMD_NFS From the commit message for Switch from archive libraries to partial linking: This commit reveals board configurations that exclude some features but include source files that depend these disabled features in the build, resulting in undefined symbols. Known such cases include: - disabling CMD_NET but not CMD_NFS; - enabling CONFIG_OF_LIBFDT but not CONFIG_QE. Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index e373fe0..8715ed7 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -134,6 +134,7 @@ /* Disabled commands */ #undef CONFIG_CMD_NET +#undef CONFIG_CMD_NFS #undef CONFIG_CMD_FPGA /* FPGA configuration Support */ #undef CONFIG_CMD_IMLS /* List all found images*/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv broken?
On Wed, 2010-11-17 at 16:08 -0600, Scott Wood wrote: On Wed, 17 Nov 2010 22:40:49 +0100 Wolfgang Denk w...@denx.de wrote: Dear Steve Sakoman, In message aanlktimrfq5+awfdfy_fuetmh=x=xrkazgntk8fis...@mail.gmail.com you wrote: readenv: offset = 24 readenv: nand_read failure = -117 *** Warning - readenv() failed, using default environment I then immediately tried to use the nand read command to read the same block, and it was successful! Hm... any chance that - for example - your timers are not working correctly before relocation (maybe because they try to write to the not yet available data segment) ? This could cause timeouts or delays to be too short, so the NAND driver is misbehaving? The NAND driver only works after relocation. It looks like the problem is that -EUCLEAN is a non-fatal error (indicates a correctable ECC error). The code invoked by the nand read command succeeds if nand_read() returns either 0 or -EUCLEAN, but readenv() is missing this check. Changing readenv to use nand_read_skip_bad eliminated the -117 (EUCLEAN) failures. Now I am getting just the -74 (EBADMSG) errors for fw_setenv written environments. It seems that fw_printenv can always read u-boot written environments, but 99.9% of the time I get a -74 (EBADMSG) error in u-boot for environments written by fw_setenv: NAND read from offset 24 failed -74 *** Warning - readenv() failed, using default environment If I try to read the environment using the nand read tool I get the same error. Using fw_printenv always seems to work -- whether u-boot or fw_setenv was the writer. The code generating both errors is in the nand_do_read_ops function in nand_base.c: if (mtd-ecc_stats.failed - stats.failed) return -EBADMSG; return mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; } I understand that the -EUCLEAN error indicates a correctable ECC error. What does the -EBADMSG error indicate? This condition doesn't seem to bother the linux driver, but u-boot doesn't like it at all! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv broken?
On Thu, 2010-11-18 at 18:20 -0600, Scott Wood wrote: On Thu, 18 Nov 2010 16:13:52 -0800 Steve Sakoman st...@sakoman.com wrote: The code generating both errors is in the nand_do_read_ops function in nand_base.c: if (mtd-ecc_stats.failed - stats.failed) return -EBADMSG; return mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; } I understand that the -EUCLEAN error indicates a correctable ECC error. What does the -EBADMSG error indicate? An uncorrectable ECC error (or other failure). This condition doesn't seem to bother the linux driver, but u-boot doesn't like it at all! Check whether the ECC layout and code is the same for this driver in both U-Boot and Linux. Since fw_printenv in Linux always can successfully read an environment written by U-boot (aqs well as those written by fw_setenv), wouldn't this indicate that they are using the same ECC layout? If they were different I would expect that compatibility in both directions would be broken. This is not my area of expertise, so perhaps I am just ignorant of how things work. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv broken?
On Thu, Nov 18, 2010 at 4:20 PM, Scott Wood scottw...@freescale.com wrote: On Thu, 18 Nov 2010 16:13:52 -0800 Steve Sakoman st...@sakoman.com wrote: The code generating both errors is in the nand_do_read_ops function in nand_base.c: if (mtd-ecc_stats.failed - stats.failed) return -EBADMSG; return mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; } I understand that the -EUCLEAN error indicates a correctable ECC error. What does the -EBADMSG error indicate? An uncorrectable ECC error (or other failure). This condition doesn't seem to bother the linux driver, but u-boot doesn't like it at all! Check whether the ECC layout and code is the same for this driver in both U-Boot and Linux. Well, the mystery is solved. The strange behavior was a combination of the -EUCLEAN issue in u-boot and the following bizarre bug that crept into the Linux OMAP NAND driver in 2.6.26: http://article.gmane.org/gmane.linux.ports.arm.omap/46545 I will submit a patch to deal with the u-boot issue tomorrow, and it seems that a fix is already queued for Linux 2.6.37. Thanks to Scott Wood for helping with the -EUCLEAN issue and Scott Ellis for noticing that what might be the same issue was being discussed on both the u-boot and linux lists today. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fw_setenv broken?
I'm seeing some strange behavior with the fw_setenv tools on OMAP.
Here's what I see when using the tools on OMAP (overo in this case):
1. fw_printenv prints the environment with no issues [1]
2. fw_setenv allows me to change a variable with no reported errors [2]
3. fw_printenv will print the changed environment, however the variables
are not sorted [3]
4. Since all seems well at this point, I reboot. There is an error
reading the new environment [4]
I added debug printf's to readenv() in env_nand.c and the root cause is
an error return from ret=nand_read(nand_info[0], offset, len,
char_ptr)). I get an error code of -74
Before I spend too much time on this I wanted to check to see if others
are seeing this issue, or whether it might be OMAP specific.
Regards,
Steve
[1]
r...@omap3-multi:~# fw_printenv
baudrate=115200
bootcmd=if mmc rescan ${mmcdev}; then if run loadbootscript; then run
bootscript; else if run loaduimage; then run mmcboot; else run nandboot;
fi; fi; else run nandboot; fi
bootdelay=5
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
console=ttyS2,115200n8
defaultdisplay=dvi
dieid#=1e1e000404032d460d01900b
dvimode=1024x768mr...@60
ethact=smc911x-0
loadaddr=0x8200
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
mmcargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
mmcdev=0
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext3 rootwait
mpurate=500
nandargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr}
28 40; bootm ${loadaddr}
nandroot=/dev/mtdblock4 rw
nandrootfstype=jffs2
stderr=serial
stdin=serial
stdout=serial
vram=12M
[2]
r...@omap3-multi:~# fw_setenv mpurate 720
[3]
r...@omap3-multi:~# fw_printenv
baudrate=115200
bootcmd=if mmc rescan ${mmcdev}; then if run loadbootscript; then run
bootscript; else if run loaduimage; then run mmcboot; else run nandboot;
fi; fi; else run nandboot; fi
bootdelay=5
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
console=ttyS2,115200n8
defaultdisplay=dvi
dieid#=1e1e000404032d460d01900b
dvimode=1024x768mr...@60
ethact=smc911x-0
loadaddr=0x8200
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
mmcargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
mmcdev=0
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr}
28 40; bootm ${loadaddr}
nandroot=/dev/mtdblock4 rw
nandrootfstype=jffs2
stderr=serial
stdin=serial
stdout=serial
vram=12M
mpurate=720
[4]
U-Boot 2010.12-rc1 (Nov 17 2010 - 08:04:09)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
Gumstix Overo board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv broken?
On Wed, 2010-11-17 at 18:39 +0100, Wolfgang Denk wrote: Dear Stefano Babic, In message 4ce4092b.7090...@denx.de you wrote: On 11/17/2010 05:30 PM, Steve Sakoman wrote: I'm seeing some strange behavior with the fw_setenv tools on OMAP. Here's what I see when using the tools on OMAP (overo in this case): 1. fw_printenv prints the environment with no issues [1] 2. fw_setenv allows me to change a variable with no reported errors [2] 3. fw_printenv will print the changed environment, however the variables are not sorted [3] I tested yesterday on a davinci board, I can confirm this behavior, I have not thought was an error. I do not see any code in fw_env.c to sort variables. I konow the variables are sorted in u-boot, but do we ever have this feature on the userland fw_printenv ? Indeed this behaviour is normal. fw_printenv does not sort the output (not yet - patches welcome). I added debug printf's to readenv() in env_nand.c and the root cause is an error return from ret=nand_read(nand_info[0], offset, len, char_ptr)). I get an error code of -74 Before I spend too much time on this I wanted to check to see if others are seeing this issue, or whether it might be OMAP specific. At least this should not be a general failure, because it works on my target. It could be also nand specific. Thanks for confirming this. Well, the next step should be a review of the code, where error -74 gets set and what that probably means... Well, since -74 is EBADMSG, I suspect the error occurs at the following code in nand_do_read_ops() in nand-base.c: if (mtd-ecc_stats.failed - stats.failed) return -EBADMSG; I'm not real familiar with the nand driver code, so I'll add some debug printfs and see if I can determine why this is happening. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv broken?
On Wed, Nov 17, 2010 at 9:39 AM, Wolfgang Denk w...@denx.de wrote: Dear Stefano Babic, In message 4ce4092b.7090...@denx.de you wrote: On 11/17/2010 05:30 PM, Steve Sakoman wrote: I'm seeing some strange behavior with the fw_setenv tools on OMAP. Here's what I see when using the tools on OMAP (overo in this case): 1. fw_printenv prints the environment with no issues [1] 2. fw_setenv allows me to change a variable with no reported errors [2] 3. fw_printenv will print the changed environment, however the variables are not sorted [3] I tested yesterday on a davinci board, I can confirm this behavior, I have not thought was an error. I do not see any code in fw_env.c to sort variables. I konow the variables are sorted in u-boot, but do we ever have this feature on the userland fw_printenv ? Indeed this behaviour is normal. fw_printenv does not sort the output (not yet - patches welcome). I added debug printf's to readenv() in env_nand.c and the root cause is an error return from ret=nand_read(nand_info[0], offset, len, char_ptr)). I get an error code of -74 Before I spend too much time on this I wanted to check to see if others are seeing this issue, or whether it might be OMAP specific. At least this should not be a general failure, because it works on my target. It could be also nand specific. Thanks for confirming this. Well, the next step should be a review of the code, where error -74 gets set and what that probably means... I've experimented on a couple of boards and it seems to always fail. The nand_do_read_ops function in nand_base.c ends like so: if (mtd-ecc_stats.failed - stats.failed) return -EBADMSG; return mtd-ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; } After writing the environment with fw_setenv in linux, u-boot's read of the environment on the subsequent boot always fails with either EBADMSG or EUCLEAN. I'll keep digging, but perhaps the above might mean something to someone with more knowledge of the nand driver. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv broken?
On Wed, Nov 17, 2010 at 12:47 PM, Wolfgang Denk w...@denx.de wrote:
Dear Steve Sakoman,
In message aanlktikalbzg5ed=p-_0mwolojh=kfna-p8syac=n...@mail.gmail.com you
wrote:
After writing the environment with fw_setenv in linux, u-boot's read
of the environment on the subsequent boot always fails with either
EBADMSG or EUCLEAN.
Can you read - in U-Boot - any other data written in Linux?
Ecventually there is some discrepance for example in the use of sw
versus hw ECC or such?
I just did that experiment!
As I mentioned, after writing with fw_setenv, I get an error in u-boot
(I added a couple of printf's to indicate the offset being read from
as well as any error codes returned):
U-Boot 2010.12-rc1 (Nov 17 2010 - 11:20:23)
OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
Gumstix Overo board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
readenv: offset = 24
readenv: nand_read failure = -117
*** Warning - readenv() failed, using default environment
I then immediately tried to use the nand read command to read the same
block, and it was successful!
Overo # nand read 8200 24 2
NAND read: device 0 offset 0x24, size 0x2
131072 bytes read: OK
Not only that, the data read looks correct!
Overo # md 8200 140
8200: bd8c0c16 64756162 65746172 3531313dbaudrate=115
8210: 00303032 746f6f62 3d646d63 6d206669200.bootcmd=if m
8220: 7220636d 61637365 7b24206e 64636d6dmc rescan ${mmcd
8230: 3b7d7665 65687420 6669206e 6e757220ev}; then if run
8240: 616f6c20 6f6f6264 72637374 3b747069 loadbootscript;
8250: 65687420 7572206e 6f62206e 6373746f then run bootsc
8260: 74706972 6c6d203b 69206573 75722066ript; mlse if ru
8270: 6f6c206e 69756461 6567616d 6874203bn loaduimage; th
8280: 72206e65 6d206e75 6f62636d 203b746fen run mmcboot;
8290: 65736c65 6e757220 6e616e20 6f6f6264else run nandboo
82a0: 66203b74 66203b69 65203b69 2065736ct; fi; fi; else
82b0: 206e7572 646e616e 746f6f62 6966203brun nandboot; fi
82c0: 6f6f6200 6c656474 353d7961 6f6f6200.bootdelay=5.boo
82d0: 72637374 3d747069 6f686365 6e755220tscript=echo Run
82e0: 676e696e 6f6f6220 72637374 20747069ning bootscript
82f0: 6d6f7266 636d6d20 2e2e2e20 6f73203bfrom mmc ...; so
82000100: 65637275 6c7b2420 6164616f 7d726464urce ${loadaddr}
82000110: 6e6f6300 656c6f73 7974743d 312c3253.console=ttyS2,1
82000120: 30323531 00386e30 61666564 64746c7515200n8.defaultd
82000130: 6c707369 643d7961 64006976 64696569isplay=dvi.dieid
82000140: 32363d23 30306535 62313030 30303066#=625e1bf000
82000150: 31303030 39333735 37306165 3066323000015739ea0702f0
82000160: 64006530 6f6d6976 313d6564 783432300e.dvimode=1024x
82000170: 4d383637 36312d52 00303640 61687465768mr...@60.etha
82000180: 733d7463 3139636d 302d7831 616f6c00ct=smc911x-0.loa
82000190: 64646164 78303d72 30303238 30303030daddr=0x8200
820001a0: 616f6c00 6f6f6264 72637374 3d747069.loadbootscript=
820001b0: 6c746166 2064616f 20636d6d 6d6d7b24fatload mmc ${mm
820001c0: 76656463 7b24207d 64616f6c 72646461cdev} ${loadaddr
820001d0: 6f62207d 732e746f 6c007263 7564616f} boot.scr.loadu
820001e0: 67616d69 61663d65 616f6c74 6d6d2064image=fatload mm
820001f0: 7b242063 64636d6d 207d7665 6f6c7b24c ${mmcdev} ${lo
82000200: 64616461 207d7264 616d4975 6d006567adaddr} uImage.m
82000210: 7261636d 733d7367 6e657465 6f622076mcargs=setenv bo
82000220: 7261746f 63207367 6f736e6f 243d656cotargs console=$
82000230: 6e6f637b 656c6f73 706d207d 74617275{console} mpurat
82000240: 7b243d65 7275706d 7d657461 61727620e=${mpurate} vra
82000250: 7b243d6d 6d617276 6d6f207d 62667061m=${vram} omapfb
82000260: 646f6d2e 76643d65 7b243a69 6d697664.mode=dvi:${dvim
82000270: 7d65646f 616d6f20 2e626670 75626564ode} omapfb.debu
82000280: 20793d67 70616d6f 2e737364 5f666564g=y omapdss.def_
82000290: 70736964 647b243d 75616665 6964746cdisp=${defaultdi
820002a0: 616c7073 72207d79 3d746f6f 6d6d7b24splay} root=${mm
820002b0: 6f6f7263 72207d74 66746f6f 70797473croot} rootfstyp
820002c0: 7b243d65 72636d6d 66746f6f 70797473e=${mmcrootfstyp
820002d0: 6d007d65 6f62636d 653d746f 206f6863e}.mmcboot=echo
820002e0: 746f6f42 20676e69 6d6f7266 636d6d20Booting from mmc
820002f0: 2e2e2e20 7572203b 6d6d206e 67726163 ...; run mmcarg
82000300: 62203b73 6d746f6f 6c7b2420 6164616fs; bootm ${loada
82000310: 7d726464 636d6d00 3d766564 6d6d0030ddr}.mmcdev=0.mm
82000320: 6f6f7263 642f3d74 6d2f7665 6c62636dcroot=/dev/mmcbl
82000330: 3270306b 00777220 72636d6d 66746f6fk0p2 rw.mmcrootf
82000340: 70797473 78653d65 72203374 77746f6fstype=ext3 rootw
82000350: 00746961 646e616e 73677261 7465733dait.nandargs=set
82000360: 20766e65 746f6f62 73677261 6e6f6320env bootargs con
82000370: 656c6f73 637b243d 6f736e6f 207d656csole
Re: [U-Boot] fw_setenv broken?
On Wed, Nov 17, 2010 at 1:40 PM, Wolfgang Denk w...@denx.de wrote: Dear Steve Sakoman, In message aanlktimrfq5+awfdfy_fuetmh=x=xrkazgntk8fis...@mail.gmail.com you wrote: readenv: offset = 24 readenv: nand_read failure = -117 *** Warning - readenv() failed, using default environment I then immediately tried to use the nand read command to read the same block, and it was successful! Hm... any chance that - for example - your timers are not working correctly before relocation (maybe because they try to write to the not yet available data segment) ? This could cause timeouts or delays to be too short, so the NAND driver is misbehaving? Hmm . . . I suppose that is possible, but it doesn't seem to explain why environment data written by u-boot will always be read successfully, but reads of linux written data fails. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_setenv broken?
On Wed, 2010-11-17 at 16:08 -0600, Scott Wood wrote: On Wed, 17 Nov 2010 22:40:49 +0100 Wolfgang Denk w...@denx.de wrote: Dear Steve Sakoman, In message aanlktimrfq5+awfdfy_fuetmh=x=xrkazgntk8fis...@mail.gmail.com you wrote: readenv: offset = 24 readenv: nand_read failure = -117 *** Warning - readenv() failed, using default environment I then immediately tried to use the nand read command to read the same block, and it was successful! Hm... any chance that - for example - your timers are not working correctly before relocation (maybe because they try to write to the not yet available data segment) ? This could cause timeouts or delays to be too short, so the NAND driver is misbehaving? The NAND driver only works after relocation. It looks like the problem is that -EUCLEAN is a non-fatal error (indicates a correctable ECC error). The code invoked by the nand read command succeeds if nand_read() returns either 0 or -EUCLEAN, but readenv() is missing this check. OK, we seem to be peeling back the layers of the onion now. I patched readenv to use the same nand_read_skip_bad function used in the command line nand read tool. I no longer get the -EUCLEAN errors when reading the environment after using fw_setenv to write from linux. Now I get: *** Warning - bad CRC, using default environment Checking the data with the nand read command line shows that the changes I made in linux are indeed there, so I suspect that there is also some mismatch in the CRC computation between the fw tools and the u-boot code (i.e. I'm pretty sure this error does *not* refer to the nand CRC) Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Un-initialization of hardware block prior to launching linux
Beagle currently enables musb gadget support in u-boot in order to support console communication over USB. The musb hardware remains in an active state as linux is launched. I've had complaints from those working on Linux power management -- it seems that leaving things active prevents the kernel from entering full chip retention. Is there an approved mechanism for shutting down hardware gracefully prior to launching linux? The console gadget seems somewhat of a special case since you really want it to remain active till the very last moment so error messages can be displayed. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Un-initialization of hardware block prior to launching linux
On Tue, Nov 16, 2010 at 3:40 PM, Wolfgang Denk w...@denx.de wrote: Dear Steve Sakoman, In message aanlkti==8qfve-r+nxvvcs4sjzmkv3-v1q2fxy4za...@mail.gmail.com you wrote: Beagle currently enables musb gadget support in u-boot in order to support console communication over USB. The musb hardware remains in an active state as linux is launched. Leaving USB enabled when starting an OS is calling for really serious trouble. Indeed. I sort of assumed that the gadget code would shut things down properly prior to launching linux, but it seems that isn't true. I've had complaints from those working on Linux power management -- it seems that leaving things active prevents the kernel from entering full chip retention. Power management is the least of your problems. I don't know for USB gadgets, but at least for Host Controllers you will suffer from (usually silent) memory corruption. Is there an approved mechanism for shutting down hardware gracefully prior to launching linux? The console gadget seems somewhat of a special case since you really want it to remain active till the very last moment so error messages can be displayed. I think you should shut down USB with usb_stop(); (see common/cmd_bootm.c:643). Yes, even when this precents some error messages from being displayed on the USB console. [I never understood the hw designers that omitted a real serial port.] OK, it seems I might need to make this happen when CONFIG_USB_DEVICE is enabled as well as CONFIG_CMD_USB. I'll investigate to see if it really is this simple. BTW -- there are real serial ports on OMAP silicon. It seems that lots of customers have PC's without serial ports and they want to use USB consoles, hence the inclusion of the gadget support in several of the OMAP board configs. Go figure -- personally I feel better using a serial dongle and connecting to the hw serial ports. Thanks for the pointer Wolfgang! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [WIP] tools/env: cleanup host build flags
On Tue, Nov 9, 2010 at 7:03 AM, Detlev Zundel d...@denx.de wrote: Hello Daniel, This patch makes tools/env/Makefile more similar to tools/imls: - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works. - include U-Boot headers using -idirafter to prevent picking up u-boot/include/errno.h. - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic). - use the cross compiler again (fw_printenv is intended for a hosted environment on the target). Signed-off-by: Daniel Hobi daniel.h...@schmid-telecom.ch Cc: Mike Frysinger vap...@gentoo.org Cc: Wolfgang Denk w...@denx.de As this indeed fixes the cross-compilation problem: Tested-by: Detlev Zundel d...@denx.de Agreed! Tested-by: Steve Sakoman steve.sako...@linaro.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] tools/env: use host build flags
On Mon, Nov 8, 2010 at 3:15 PM, Wolfgang Denk w...@denx.de wrote: Dear Detlev Zundel, In message m2k4knd6lx@ohwell.denx.de you wrote: Applied to next branch. Thanks It just occurred to me that this will no longer cross compile the fw_env tool - effectively rendering the tool useless for me. Argh... Indeed, that's broken. Mike, what _exactly_ was the reason to drop cross compilation? Mike, I think we should revert that commit? I ran into this issue this week too. Reverting is one option. I also tried Daniel Hobi's patch tools/env: cleanup host build flags and that worked for me. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
On Sun, Nov 7, 2010 at 6:56 AM, Nishanth Menon menon.nisha...@gmail.com wrote: Premi, Sanjeev wrote, on 11/07/2010 03:16 AM: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, November 06, 2010 8:35 AM To: Nishanth Menon Cc: u-boot@lists.denx.de; Koen Kooi Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table [snip] Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. [sp] 720MHz is not a valid frequency for 36x. It is the highest freq for OMAP35x - subject to associated bit set in the silicon. 600MHz would be be safe for all OMAP35x family processors. For 36xx, the freq should be 800MHz (if you don't want 1GHz). yep, Good catch :) , 720 is not valid either 800/1GHz :( Thanks for pointing out that I can go up to 800 Mhz. For the record, on my 3730 based system, using: Linux version 2.6.36 (st...@build.sakoman.com) (gcc version 4.3.3 (GCC) ) #1 Thu Nov 4 21:19:18 PDT 2010 The kernel reports the processor as: OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) I tried mpurate settings of 720, 800, and 1000. Though you say it is not valid, an mpurate setting of 720 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/359 MHz An mpurate setting of 800 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/800/359 MHz An mpurate setting of 1000 is not successful and yields: WARNING: at arch/arm/mach-omap2/clock.c:440 omap2_clk_switch_mpurate_at_boot+0x80/0xb4() clock: dpll1_ck: unable to set MPU rate to 1000: -22 I will resubmit the patch changing to 800 for 36XX/37XX. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
On Fri, Nov 5, 2010 at 12:56 PM, Nishanth Menon menon.nisha...@gmail.com wrote: Folks, I would like to work on the following: Cleanup mux configurations done in OMAP3 and 4 platforms. includes the following: a) have isolate mux configurations per IP configuration, e.g. for EHCI, we have a mux array definition for EHCI etc.. b) remove ALL mux configurations that are not relevant for u-boot functionality - currently we do all muxing in u-boot(including stuff like camera which obviously we dont use in u-boot). any kernel breakages as a result of assumptions of muxing already done is to be fixed in kernel itself - kernel *has* a mux framework for OMAP and platforms files *should* be using that for kernel functionality that they need. no point in carrying that burden in u-boot. I would like to post this patches so that for the next merge window we could pull this in and notify the linux-omap kernel guys to fix their stuff if they depend on u-boot for mux configurations - it is high time they stop being closely tied to U-boot and have capability to deal with other bootloaders which may or maynot have capability for doing muxing - it also saves us to add and maintain mux configurations for linux kernel booting - u-boot is supposed to support multiple operating systems (not just linux kernel). While I understand that you are frustrated with the slow movement in getting the kernel mux cleaned up, I really can't support deliberately breaking systems to force the issue. I don't think it does end users any service to have a u-boot upgrade break their systems. In the end, they are the ones who will be hurt and u-boot will get the blame for causing the breakage. I'd rather see us put the energy into helping get the kernel in shape. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: Overo: Automatically set clock rate to maximum if mpurate env variable is auto
The maximum clock rate for the OMAP3 processors on Overo depends on the
processor type and revision. This patch sets the clock rate to the
spec sheet maximum if the mpurate environment variable is set to
auto. Otherwise it passes the mpurate variable unchanged on the
kernel command line.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/board/overo/overo.c b/board/overo/overo.c
index f917e40..3c9e4a6 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -281,6 +281,22 @@ int misc_init_r(void)
dieid_num_r();
+ if (strcmp(getenv(mpurate), auto) == 0)
+ switch (get_cpu_family()) {
+ case CPU_OMAP34XX:
+ if ((get_cpu_rev() = CPU_3XX_ES31)
+ (get_sku_id() == SKUID_CLK_720MHZ))
+ setenv(mpurate, 720);
+ else
+ setenv(mpurate, 600);
+ break;
+ case CPU_OMAP36XX:
+ setenv(mpurate, 720);
+ break;
+ default:
+ setenv(mpurate, 500);
+ }
+
return 0;
}
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 79a5b85..dbdfd9a 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -156,7 +156,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
console=ttyS2,115200n8\0 \
- mpurate=500\0 \
+ mpurate=auto\0 \
vram=12M\0 \
dvimode=1024x768mr...@60\0 \
defaultdisplay=dvi\0 \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
On Fri, Nov 5, 2010 at 10:54 AM, Nishanth Menon
menon.nisha...@gmail.com wrote:
Jason Kridner wrote, on 11/05/2010 01:46 AM:
From: Koen Kooik...@dominion.thruhere.net
Patch was updated by Jason Kridnerjkrid...@beagleboard.org:
* Use tabs to match style of other board revisions
* Only include board revisions that exist
* Default to the same configuration as the latest revision, but
without setting 'beaglerev'
Signed-off-by: Jason Kridnerjkrid...@beagleboard.org
not signed-off-by: Koen?
---
board/ti/beagle/beagle.c | 20 +++-
board/ti/beagle/beagle.h | 3 ++-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 520e57d..93c452e 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -176,7 +176,7 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM:
+ case REVISION_XM_A:
printf(Beagle xM Rev A\n);
setenv(beaglerev, xMA);
setenv(mpurate, 1000);
@@ -187,8 +187,26 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
+ case REVISION_XM_B:
+ printf(Beagle xM Rev B\n);
+ setenv(beaglerev, xMB);
+ setenv(mpurate, 1000);
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
+ break;
default:
printf(Beagle unknown 0x%02x\n, get_board_revision());
+ setenv(mpurate, 1000);
It looks to me looking at the file that mpurate usage is CPU based and
NOT board based.. maybe you should use the cpu idendity to decide on
mpurate instead?
I noticed this too. I just submitted a patch for Overo that sets the
mpurate to the cpu maximum (based on cpu type and version) if the
mpurate environment variable is set to auto
This solves an additional issue: with things as they are now, it is
not possible for a user to set the mpurate to a specific value -- it
will always be overwritten. The scheme above allows the user to set a
specific value or to allow u-boot to set the maximum automatically.
Note that for 36xx my patch sets the max to 720 -- this is because
mainline/linux-omap currently does not support 1000. We can adjust
that when kernel support for 1000 appears.
My plan was to submit a similar patch for Beagle.
Steve
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
}
switch (get_expansion_id()) {
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index 7d8dee0..fa893c4 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -37,7 +37,8 @@ const omap3_sysinfo sysinfo = {
#define REVISION_AXBX 0x7
#define REVISION_CX 0x6
#define REVISION_C4 0x5
-#define REVISION_XM 0x0
+#define REVISION_XM_A 0x0
+#define REVISION_XM_B 0x1
/*
* IEN - Input Enable
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fwd: [PATCH] OMAP4: speed up booting on Pandaboard
Forgot to copy list on my reply! -- Forwarded message -- From: Steve Sakoman sako...@gmail.com Date: Thu, Nov 4, 2010 at 11:09 AM Subject: Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard To: Sergiy Kibrik sergiy.kib...@globallogic.com On Thu, Nov 4, 2010 at 2:38 AM, Sergiy Kibrik sergiy.kib...@globallogic.com wrote: Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; How much time does this save? I think shrinking to 2K might be a bit extreme, how about 4K? -USB TTY driver turned off; Not sure I agree with this. I think it might be useful to leave USB gadget support in, since there are those who might prefer a USB console over the serial port. However if others disagree, I have this comment: If you are going to turn off the gadget, why not remove the USB driver too? -tweaked blob load address to avoid image relocation (according to default uImage load address); I don't think this does what you think it does! Unless I am horribly mistaken, the loadaddr address environment variable has nothing to do with relocation! It is the address typically used to store data when you do a fatload, tftp, bootp, etc. Steve Signed-off-by: Sergiy Kibrik sergiy.kib...@globallogic.com --- include/configs/omap4_panda.h | 8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..5aba424 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -62,10 +62,10 @@ /* * Size of malloc() pool - * Total Size Environment - 256k + * Total Size Environment - 2k * Malloc - add 256k */ -#define CONFIG_ENV_SIZE (256 10) +#define CONFIG_ENV_SIZE (256 4) #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (256 10)) /* initial data */ /* Vector Base */ @@ -117,7 +117,7 @@ /* USB device configuration */ #define CONFIG_USB_DEVICE 1 -#define CONFIG_USB_TTY 1 +#undef CONFIG_USB_TTY #define CONFIG_SYS_CONSOLE_IS_IN_ENV 1 /* Flash */ @@ -146,7 +146,7 @@ #define CONFIG_ENV_OVERWRITE #define CONFIG_EXTRA_ENV_SETTINGS \ - loadaddr=0x8200\0 \ + loadaddr=0x80007FC0\0 \ console=ttyS2,115200n8\0 \ usbtty=cdc_acm\0 \ vram=16M\0 \ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4: board: change global data pointer to file scope
On Thu, Nov 4, 2010 at 8:58 AM, Menon, Nishanth n...@ti.com wrote: On Mon, Oct 25, 2010 at 16:13, Menon, Nishanth n...@ti.com wrote: DECLARE_GLOBAL_DATA_PTR is currently defined within the scope of function while it is a global pointer. Change the scope of definition to replicate it's global scope. This seems to help gcc 4.5 optimizations as well. Signed-off-by: Nishanth Menon n...@ti.com gentle ping - I dont see comments on this, is it ok to pull this in? Tested on Panda, no issues found. Tested-by: Steve Sakoman steve.sako...@linaro.org Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mmc: omap: timeout counter fix
On Tue, Oct 26, 2010 at 11:04 AM, Nishanth Menon n...@ti.com wrote: Having a loop with a counter is no timing guarentee for timing accuracy or compiler optimizations. For e.g. the same loop counter which runs when the MPU is running at 600MHz will timeout in around half the time when running at 1GHz. or the example where GCC 4.5 compiles with different optimization compared to GCC 4.4. use timer to keep track of time elapse and we use an emperical number - 1sec for a worst case timeout. This should never happen, and is adequate imaginary condition for us to fail with timeout. Signed-off-by: Nishanth Menon n...@ti.com --- V3: changed the delay logic, removed udelays which was introduced in v2 as the intent was purely to have predictable time delays. the timer logic is based on the discussion in ML using get_timer V2: http://www.mail-archive.com/u-boot@lists.denx.de/msg40972.html additional cleanups + made MAX_RETRY a macro for reuse throughout the file. tested on PandaBoard with 1GHz boot frequency and GCC4.5 on u-boot 2010.09 + mmc patches. Requesting testing on other platforms V1: http://www.mail-archive.com/u-boot@lists.denx.de/msg40969.html Tested on Overo, Beagleboard xM, and Panda. No issues found. Tested-by: Steve Sakoman steve.sako...@linaro.org Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patches added to u-boot-ti
On Thu, Nov 4, 2010 at 1:25 PM, Paulraj, Sandeep s-paul...@ti.com wrote: I have added quite a few patches to u-boot-ti but MAKEALL returns several errors. I think most boards have not been updated since the ARM relocation patch. I believe the rule is that support for boards that are not compiling will be kept in mainline till the next release. After that we will have to dump all the boards that are not compiling. I do daily builds for all the boards I have: Beagle, IGEP, Overo, Panda, and 4430SDP. These are all building and functioning with no known issues (assuming application of all the patches I've posted to date). The only known build issue is related to recent gcc/binutils. I've posted a patch that seems to work for a number of folks, but I don't think we've reached consensus yet on whether it is the final solution. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD albert.arib...@free.fr wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
Thanks for pointing this out, Steve. That'll go into V3 of my patch set I
guess, as Alexander's patch derives from mine and I most probably hit the
same size increase issue as he does.
Wolfgang: that may mean the tx25 config file patch is unneeded. Stay tuned.
I should have stated that I was using gcc 4.3.3 and binutils 2.18.50,
since indeed it does seem to be binutils related.
I have had a couple of reports that the following patch works with
recent gcc/binutils without increasing the size of the binary.
Could others check and report results?
Steve
ARMV7: Fix build issue with recent versions of gcc/binutils
---
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..e690b58 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,7 +55,7 @@ SECTIONS
}
. = ALIGN(4);
__rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
__rel_dyn_end = .;
__dynsym_start = .;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
On Wed, Oct 27, 2010 at 10:32 AM, Paulraj, Sandeep s-paul...@ti.com wrote: On Wed, 2010-10-27 at 17:11 +0200, Wolfgang Denk wrote: Dear Paulraj, Sandeep, In message 0554bef07d437848af01b9c9b5f0bc5da9d89...@dlee01.ent.ti.com you wrote: Test this patch on my beagle board, works fine: Tested-by: Heiko Schocher h...@denx.de Should I consider this a bug fix and add it to my tree? I believe the patch itself came after the merge window ended Yes, all these are bug fixes needed to get the current code working as expected. Please apply. Thanks. Sandeep, there are a couple of other pending patches that are build fixers: ARMV7: OMAP3: IGEP: Rename TEXT_BASE ARMV7: Fix build for non-OMAP3 boards They've been posted to the list for a few days now, and are also sitting in my omap4-next-upstream branch. Steve Yes I have seen them. Pull request will be sent on Saturday or Sunday. Any update on this? It would be good to get mainline in a build-able state again. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
On Tue, Nov 2, 2010 at 9:28 AM, Albert ARIBAUD albert.arib...@free.fr wrote:
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
Thanks for pointing this out, Steve. That'll go into V3 of my patch set I
guess, as Alexander's patch derives from mine and I most probably hit the
same size increase issue as he does.
Wolfgang: that may mean the tx25 config file patch is unneeded. Stay
tuned.
I should have stated that I was using gcc 4.3.3 and binutils 2.18.50,
since indeed it does seem to be binutils related.
I have had a couple of reports that the following patch works with
recent gcc/binutils without increasing the size of the binary.
Could others check and report results?
Steve
ARMV7: Fix build issue with recent versions of gcc/binutils
---
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..e690b58 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,7 +55,7 @@ SECTIONS
}
. = ALIGN(4);
__rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
__rel_dyn_end = .;
__dynsym_start = .;
Weird... This patch seems indeed more restrictive than mine, but the input
sections collected in .rel.dyn are actually the same for both.
We can gain a bit less than 60k by overlapping .bss and .rel.dyn, but
certainly not 200k!
OTOH, it happened during my 'cross-build' tests (using one chain's gcc with
another chain's ld) that the resulting u-boot was drastically reduced; but I
chalked that to my misusing of the build tools.
Steve, can you indicate which toolchain excatly exhibits the 230k-to-430k
issue, and which board I should build?
I used gcc 4.3.3 and binutils 2.18.50 and built beagle and overo.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
On Mon, Nov 1, 2010 at 8:23 PM, Alexander Holler hol...@ahsoftware.de wrote:
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
arch/arm/cpu/armv7/u-boot.lds | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..34e0a79 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -54,13 +54,6 @@ SECTIONS
*(.data.rel.ro)
}
. = ALIGN(4);
- __rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
- __rel_dyn_end = .;
-
- __dynsym_start = .;
- .dynsym : { *(.dynsym) }
-
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
@@ -74,4 +67,12 @@ SECTIONS
__bss_start = .;
.bss : { *(.bss) }
_end = .;
+
+ . = ALIGN(4);
+ __rel_dyn_start = .;
+ .rel.dyn : { *(.rel*) }
+ __rel_dyn_end = .;
+
+ __dynsym_start = .;
+ .dynsym : { *(.dynsym) }
}
--
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: IGEP: Rename TEXT_BASE
On Fri, Oct 29, 2010 at 12:20 PM, Enric Balletbò i Serra eballe...@iseebcn.com wrote: Hello, 2010/10/23 Enric Balletbò i Serra eballe...@iseebcn.com: 2010/10/21 Steve Sakoman st...@sakoman.com: Commit 14d0a02a Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE missed the IGEP boards since they were just added. Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk index b8812f9..7964621 100644 --- a/board/isee/igep0020/config.mk +++ b/board/isee/igep0020/config.mk @@ -30,4 +30,4 @@ # (mem base + reserved) # For use with external or internal boots. -TEXT_BASE = 0x80008000 +CONFIG_SYS_TEXT_BASE = 0x80008000 diff --git a/board/isee/igep0030/config.mk b/board/isee/igep0030/config.mk index 35865e0..de6384f 100644 --- a/board/isee/igep0030/config.mk +++ b/board/isee/igep0030/config.mk @@ -30,5 +30,5 @@ # (mem base + reserved) # For use with external or internal boots. -TEXT_BASE = 0x80008000 +CONFIG_SYS_TEXT_BASE = 0x80008000 Acked-by: Enric Balletbo i Serra eballe...@gmail.com Tested-by: Enric Balletbo i Serra eballe...@gmail.com Wolfgang, can this patch be applied ? Otherwise IGEP board support is broken in current mainline. Thanks. I believe that Sandeep plans to send a merge request for this patch and a couple others sometime this weekend. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARMV7: OMAP3: Add expansion board detection for Beagle
Beagle expansion boards contain an i2c eeprom to identify themselves.
This patch adds code to read and parse the eeprom contents. It prints
the expansion board name and revision and modifies environment variables
as appropriate. This patch is based on the Overo expansion board code.
Signed-off-by: Koen Kooi k-k...@ti.com
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
Change for v2:
Add GPIO 162 pinmux for TCT Trainer board
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c5d6679..d9b6f01 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -39,6 +39,27 @@
#include asm/mach-types.h
#include beagle.h
+#define TWL4030_I2C_BUS0
+#define EXPANSION_EEPROM_I2C_BUS 1
+#define EXPANSION_EEPROM_I2C_ADDRESS 0x50
+
+#define TINCANTOOLS_ZIPPY 0x01000100
+#define TINCANTOOLS_ZIPPY2 0x02000100
+#define TINCANTOOLS_TRAINER0x04000100
+#define TINCANTOOLS_SHOWDOG0x03000100
+#define KBADC_BEAGLEFPGA 0x01000600
+
+#define BEAGLE_NO_EEPROM 0x
+
+static struct {
+ unsigned int device_vendor;
+ unsigned char revision;
+ unsigned char content;
+ char fab_revision[8];
+ char env_var[16];
+ char env_setting[64];
+} expansion_config;
+
/*
* Routine: board_init
* Description: Early hardware init.
@@ -95,6 +116,31 @@ int get_board_revision(void)
}
/*
+ * Routine: get_expansion_id
+ * Description: This function checks for expansion board by checking I2C
+ * bus 1 for the availability of an AT24C01B serial EEPROM.
+ * returns the device_vendor field from the EEPROM
+ */
+unsigned int get_expansion_id(void)
+{
+ i2c_set_bus_num(EXPANSION_EEPROM_I2C_BUS);
+
+ /* return BEAGLE_NO_EEPROM if eeprom doesn't respond */
+ if (i2c_probe(EXPANSION_EEPROM_I2C_ADDRESS) == 1) {
+ i2c_set_bus_num(TWL4030_I2C_BUS);
+ return BEAGLE_NO_EEPROM;
+ }
+
+ /* read configuration data */
+ i2c_read(EXPANSION_EEPROM_I2C_ADDRESS, 0, 1, (u8 *)expansion_config,
+sizeof(expansion_config));
+
+ i2c_set_bus_num(TWL4030_I2C_BUS);
+
+ return expansion_config.device_vendor;
+}
+
+/*
* Routine: misc_init_r
* Description: Configure board specific parts
*/
@@ -141,6 +187,55 @@ int misc_init_r(void)
printf(Beagle unknown 0x%02x\n, get_board_revision());
}
+ switch (get_expansion_id()) {
+ case TINCANTOOLS_ZIPPY:
+ printf(Recognized Tincantools Zippy board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ MUX_TINCANTOOLS_ZIPPY();
+ setenv(buddy, zippy);
+ break;
+ case TINCANTOOLS_ZIPPY2:
+ printf(Recognized Tincantools Zippy2 board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ MUX_TINCANTOOLS_ZIPPY();
+ setenv(buddy, zippy2);
+ break;
+ case TINCANTOOLS_TRAINER:
+ printf(Recognized Tincantools Trainer board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ MUX_TINCANTOOLS_ZIPPY();
+ MUX_TINCANTOOLS_TRAINER();
+ setenv(buddy, trainer);
+ break;
+ case TINCANTOOLS_SHOWDOG:
+ printf(Recognized Tincantools Showdow board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ /* Place holder for DSS2 definition for showdog lcd */
+ setenv(defaultdisplay, showdoglcd);
+ setenv(buddy, showdog);
+ break;
+ case KBADC_BEAGLEFPGA:
+ printf(Recognized KBADC Beagle FPGA board\n);
+ MUX_KBADC_BEAGLEFPGA();
+ setenv(buddy, beaglefpga);
+ break;
+ case BEAGLE_NO_EEPROM:
+ printf(No EEPROM on expansion board\n);
+ setenv(buddy, none);
+ break;
+ default:
+ printf(Unrecognized expansion board: %x\n,
+ expansion_config.device_vendor);
+ setenv(buddy, unknown);
+ }
+
+ if (expansion_config.content == 1)
+ setenv(expansion_config.env_var, expansion_config.env_setting);
+
twl4030_power_init();
twl4030_led_init(TWL4030_LED_LEDEN_LEDAON | TWL4030_LED_LEDEN_LEDBON);
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index ec0da6d..b22b653 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -259,8 +259,8 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(HSUSB0_DATA7), (IEN | PTD | DIS | M0))
/*HSUSB0_DATA7
[U-Boot] [PATCH v2] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
This patch fixes the issue by defining and using CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang Denk and Heiko Schocher. Signed-off-by: Steve Sakoman steve.sako...@linaro.org Tested-by: Heiko Schocher h...@denx.de --- Version 2 of patch: - adds Heiko's Tested-by - fixes SRAM address for omap4 boards, since it was set incorrectly diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h index 16d9279..a970ad2 100644 --- a/include/configs/igep0020.h +++ b/include/configs/igep0020.h @@ -222,6 +222,10 @@ #endif /* (CONFIG_CMD_NET) */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h index d6fbec7..031de35 100644 --- a/include/configs/igep0030.h +++ b/include/configs/igep0030.h @@ -209,6 +209,10 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (128 10)) #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index e7d5bd0..076dd5a 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -346,8 +346,11 @@ extern unsigned int boot_flash_sec; extern unsigned int boot_flash_type; #endif -/* additions for new relocation code, must be added to all boards */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index 052d503..79a5b85 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -325,6 +325,10 @@ extern unsigned int boot_flash_type; #endif /* (CONFIG_CMD_NET) */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..eeab11c 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -227,6 +227,10 @@ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x8000 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4030D800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h index 26c380d..ed0bd41 100644 --- a/include/configs/omap4_sdp4430.h +++ b/include/configs/omap4_sdp4430.h @@ -232,6 +232,10 @@ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x8000 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4030D800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ ___ U-Boot mailing
[U-Boot] [PATCH RFC] mmc: Clean up generic mmc driver multi-block write functions
The current mmc write implementation is type ulong, but returns int values.
Some of the printf's are terminated with /n/r, one has none.
This patch fixes these issues and also removes some unnecessary local
variables.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index eb7bfb3..00fe867 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -82,12 +82,9 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
{
struct mmc_cmd cmd;
struct mmc_data data;
- int blklen, err;
-
- blklen = mmc-write_bl_len;
if ((start + blkcnt) mmc-block_dev.lba) {
- printf(MMC: block number 0x%lx exceeds max(0x%lx),
+ printf(MMC: block number 0x%lx exceeds max(0x%lx)\n,
start + blkcnt, mmc-block_dev.lba);
return 0;
}
@@ -100,21 +97,19 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
if (mmc-high_capacity)
cmd.cmdarg = start;
else
- cmd.cmdarg = start * blklen;
+ cmd.cmdarg = start * mmc-write_bl_len;
cmd.resp_type = MMC_RSP_R1;
cmd.flags = 0;
data.src = src;
data.blocks = blkcnt;
- data.blocksize = blklen;
+ data.blocksize = mmc-write_bl_len;
data.flags = MMC_DATA_WRITE;
- err = mmc_send_cmd(mmc, cmd, data);
-
- if (err) {
- printf(mmc write failed\n\r);
- return err;
+ if (mmc_send_cmd(mmc, cmd, data)) {
+ printf(mmc write failed\n);
+ return 0;
}
if (blkcnt 1) {
@@ -122,10 +117,9 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
cmd.cmdarg = 0;
cmd.resp_type = MMC_RSP_R1b;
cmd.flags = 0;
- err = mmc_send_cmd(mmc, cmd, NULL);
- if (err) {
- printf(mmc fail to send stop cmd\n\r);
- return err;
+ if (mmc_send_cmd(mmc, cmd, NULL)) {
+ printf(mmc fail to send stop cmd\n);
+ return 0;
}
}
@@ -135,18 +129,14 @@ mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t
blkcnt, const void*src)
static ulong
mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
{
- int err;
- struct mmc *mmc = find_mmc_device(dev_num);
lbaint_t cur, blocks_todo = blkcnt;
+ struct mmc *mmc = find_mmc_device(dev_num);
if (!mmc)
- return -1;
+ return 0;
- err = mmc_set_blocklen(mmc, mmc-write_bl_len);
- if (err) {
- printf(set write bl len failed\n\r);
- return err;
- }
+ if (mmc_set_blocklen(mmc, mmc-write_bl_len))
+ return 0;
do {
/*
@@ -155,7 +145,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const
void*src)
*/
cur = (blocks_todo 65535) ? 65535 : blocks_todo;
if(mmc_write_blocks(mmc, start, cur, src) != cur)
- return -1;
+ return 0;
blocks_todo -= cur;
start += cur;
src += cur * mmc-write_bl_len;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] mmc: Add multi-block read support to the generic mmc driver
From: Alagu Sankar alagusankar at embwise.com
This patch adds multi-block read support for the generic MMC
driver. Large reads are broken into chunks of 65535 blocks to
ensure that the code works with controllers having a 16 bit block counter.
This patch results in a significant performance improvement.
Time to read a 45 MB file went from 36 seconds to 9 seconds on Overo
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
Tested-by: Steve Sakoman steve.sako...@linaro.org
---
This is based on Alagu's original patch, but heavily modified to reflect
recent changes in the driver and to remove the CONFIG option as
requested in the earlier discussion of the patch:
http://www.mail-archive.com/u-boot@lists.denx.de/msg32319.html
It also incorporates feedback on my previously submitted RFC multi-block
read patch. I am leaving authorship with Alagu since he did the original
work, but will leave it up to him to add his Signed-off-by
---
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 00fe867..6805b33 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -154,110 +154,78 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
const void*src)
return blkcnt;
}
-int mmc_read_block(struct mmc *mmc, void *dst, uint blocknum)
+int mmc_read_blocks(struct mmc *mmc, void *dst, ulong start, lbaint_t blkcnt)
{
struct mmc_cmd cmd;
struct mmc_data data;
- cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
+ if (blkcnt 1)
+ cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
+ else
+ cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
if (mmc-high_capacity)
- cmd.cmdarg = blocknum;
+ cmd.cmdarg = start;
else
- cmd.cmdarg = blocknum * mmc-read_bl_len;
+ cmd.cmdarg = start * mmc-read_bl_len;
cmd.resp_type = MMC_RSP_R1;
cmd.flags = 0;
data.dest = dst;
- data.blocks = 1;
+ data.blocks = blkcnt;
data.blocksize = mmc-read_bl_len;
data.flags = MMC_DATA_READ;
- return mmc_send_cmd(mmc, cmd, data);
-}
-
-int mmc_read(struct mmc *mmc, u64 src, uchar *dst, int size)
-{
- char *buffer;
- int i;
- int blklen = mmc-read_bl_len;
- int startblock = lldiv(src, mmc-read_bl_len);
- int endblock = lldiv(src + size - 1, mmc-read_bl_len);
- int err = 0;
-
- /* Make a buffer big enough to hold all the blocks we might read */
- buffer = malloc(blklen);
-
- if (!buffer) {
- printf(Could not allocate buffer for MMC read!\n);
- return -1;
- }
-
- /* We always do full block reads from the card */
- err = mmc_set_blocklen(mmc, mmc-read_bl_len);
-
- if (err)
- goto free_buffer;
-
- for (i = startblock; i = endblock; i++) {
- int segment_size;
- int offset;
-
- err = mmc_read_block(mmc, buffer, i);
-
- if (err)
- goto free_buffer;
-
- /*
-* The first block may not be aligned, so we
-* copy from the desired point in the block
-*/
- offset = (src (blklen - 1));
- segment_size = MIN(blklen - offset, size);
-
- memcpy(dst, buffer + offset, segment_size);
+ if (mmc_send_cmd(mmc, cmd, data))
+ return 0;
- dst += segment_size;
- src += segment_size;
- size -= segment_size;
+ if (blkcnt 1) {
+ cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.flags = 0;
+ if (mmc_send_cmd(mmc, cmd, NULL)) {
+ printf(mmc fail to send stop cmd\n);
+ return 0;
+ }
}
-free_buffer:
- free(buffer);
-
- return err;
+ return blkcnt;
}
static ulong mmc_bread(int dev_num, ulong start, lbaint_t blkcnt, void *dst)
{
- int err;
- int i;
- struct mmc *mmc = find_mmc_device(dev_num);
+ lbaint_t cur, blocks_todo = blkcnt;
+
+ if (blkcnt == 0)
+ return 0;
+ struct mmc *mmc = find_mmc_device(dev_num);
if (!mmc)
return 0;
if ((start + blkcnt) mmc-block_dev.lba) {
- printf(MMC: block number 0x%lx exceeds max(0x%lx),
+ printf(MMC: block number 0x%lx exceeds max(0x%lx)\n,
start + blkcnt, mmc-block_dev.lba);
return 0;
}
- /* We always do full block reads from the card */
- err = mmc_set_blocklen(mmc, mmc-read_bl_len);
- if (err) {
+ if (mmc_set_blocklen(mmc, mmc-read_bl_len))
return 0;
- }
- for (i = start; i start + blkcnt; i++, dst += mmc-read_bl_len) {
- err = mmc_read_block(mmc, dst, i
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4cc7c628.70...@denx.de you wrote: CONFIG_SYS_INIT_RAM_ADDR(SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x7f0 Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? Agreed. I saw this issue last night, but didn't have enough time to prepare a fix. I'll generate and test a patch on the OMAP boards which have implemented relocation. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, omap3, beagle: initial stack pointer setup
On Wed, 2010-10-27 at 14:23 +0200, Heiko Schocher wrote: Hello Steve, Steve Sakoman wrote: On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4cc7c628.70...@denx.de you wrote: CONFIG_SYS_INIT_RAM_ADDR (SRAM_VECT_CODE) ^ 0x4020f800 CONFIG_SYS_INIT_RAM_SIZE 0x7f0 Why that? From the current settings I would expect something like CONFIG_SYS_INIT_RAM_ADDR0x4020f800 CONFIG_SYS_INIT_RAM_SIZE0x800 I see no reason to substract the top 16 bytes? Agreed. I saw this issue last night, but didn't have enough time to prepare a fix. I'll generate and test a patch on the OMAP boards which have implemented relocation. Ok, thanks! Now that I have some coffee, I think I see the actual reason that the build was broken. If you look at the error output: start.S: Assembler messages: start.S:175: Error: missing ')' start.S:175: Error: missing ')' start.S:175: Error: garbage following instruction -- `ldr sp,=((0x4020f800+0x800-#96))' It is apparent that the assembler does not like that GENERATED_GBL_DATA_SIZE is defined as #96 I tried without the # symbol and the build completes successfully. I'll prepare a patch to use CONFIG_SYS_INIT_RAM_ADDR and CONFIG_SYS_INIT_RAM_SIZE on the OMAP boards with relocation, because that is still a good idea, but we also need to deal with the prepended # symbol. I'm guessing that the PPC tools don't complain about the # symbol? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
This patch fixes the issue by defining and using CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR. Based on an email discussion with Wolfgang Denk and Heiko Schocher. Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- Tested on Overo. Will test on all available boards later today. diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h index 16d9279..a970ad2 100644 --- a/include/configs/igep0020.h +++ b/include/configs/igep0020.h @@ -222,6 +222,10 @@ #endif /* (CONFIG_CMD_NET) */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h index d6fbec7..031de35 100644 --- a/include/configs/igep0030.h +++ b/include/configs/igep0030.h @@ -209,6 +209,10 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (128 10)) #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index e7d5bd0..076dd5a 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -346,8 +346,11 @@ extern unsigned int boot_flash_sec; extern unsigned int boot_flash_type; #endif -/* additions for new relocation code, must be added to all boards */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index 052d503..79a5b85 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -325,6 +325,10 @@ extern unsigned int boot_flash_type; #endif /* (CONFIG_CMD_NET) */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 9dda2a3..76131fd 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -227,6 +227,10 @@ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x8000 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4030E000 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h index 36471ba..3d4d3a7 100644 --- a/include/configs/omap4_sdp4430.h +++ b/include/configs/omap4_sdp4430.h @@ -245,6 +245,10 @@ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x8000 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_RAM_ADDR 0x4030E000 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] mmc: seperate block number into small parts for multi-write cmd
On Wed, Oct 27, 2010 at 11:39 AM, Wolfgang Denk w...@denx.de wrote: Dear Lei Wen, In message 1287034691-26278-1-git-send-email-lei...@marvell.com you wrote: Constraint the mmc framework to only send no more than 65535 blocks in one go during the multi-write command. This constraint comes due to the limitation of 16bit width block counter register at some hardware. Signed-off-by: Lei Wen lei...@marvell.com Cc: Reinhard Meyer u-b...@emk-elektronik.de --- V4: clean patch V3: return to the V1 solution that keep the 65535 constraint, but cut the 512KiB dma limitation V2: add additional members in mmc structure drivers/mmc/mmc.c | 54 ++-- 1 files changed, 39 insertions(+), 15 deletions(-) Applied, thanks. Thanks Wolfgang! I'll get to work on a revised multi-block read implementation. A 4x speedup in large MMC reads is worth the effort! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
On Mon, 2010-10-25 at 20:10 +0530, Premi, Sanjeev wrote: -Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 6:52 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? No, it is not. [sp] I asked because I can see omap3/cache.S but not under omap-common/ (as I was expecting) - neither in omap4/ Doesn't this patch works-around the problem by using CONFIG_OMAP34XX? Yes, this is a hopefully temporary fix to allow non-OMAP3 ARMV7 boards to build. Wouldn't change in cache.S (or Makefile) be better solution/ or workaround. At least workaround will be visible to more eyes. Ideally we would have a generic ARMV7 implementation that would work for even non-OMAP ARMV7 processors. Someone who is familiar with the differences in ARMV7 cache implementations from the various silicon vendors would need to do this. This beyond my knowledge. A second best solution would be to have a cache.S that worked for both OMAP3 and OMAP4 in omap-common/ If this isn't possible, then we should add an OMAP4 specific cache.S in omap4/ But until we settle on the proper long term strategy this patch should be applied so that non-OMAP3 ARMV7 boards will build. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support
On Sat, Oct 23, 2010 at 8:14 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Friday, October 15, 2010 3:14 AM To: John Rigby Cc: u-boot@lists.denx.de; Alagu Sankar; Andy Fleming Subject: Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support On Mon, Oct 4, 2010 at 1:32 PM, John Rigby jcri...@gmail.com wrote: Alagu, This never made it into Andy's tree nor upstream. Could you submit a new patch to current upstream with the config option removed as Andy said he did back in May? Maybe we can get it commited via some other maintainer. Steve Sakoman seems to have done some MMC work lately. I've done some testing with this patch on OMAP3 and OMAP4, in the always enabled version. I compared the old legacy mmc driver vs the new generic mmc driver vs new generic mmc driver with multiblock read support added. The good news is that the generic mmc driver for OMAP is almost twice as fast as the old legacy driver. These patches should be in the next u-boot-ti pull request and so will be in mainline shortly. The bad news is that multiblock reads seem to make no difference :-( For reading a 45MB file from an ext3 partition using ext2load I get: legacy: 62 seconds generic: 35 seconds generic w/ multi: 35 seconds I'm happy to resubmit the multi-block read patch because it does seem to work properly and may even yield improvements on other architectures. Would you like me to do that? [Ghorai] would you please try with additional change? Yes! That is much better! Now multiblock reads are faster :-) The results (including the old legacy mmc driver for reference): legacy: 62 seconds generic: 35 seconds generic w/ multi: 9 seconds I will add my Acked-by and Tested-by and submit the final patch to the list later today. Steve $git diff drivers/mmc/omap_hsmmc.c diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index f8b9840..7f3f968 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -401,6 +401,7 @@ int omap_mmc_init(int dev_index) mmc-f_min = 40; mmc-f_max = 5200; + mmc-b_max = 0x; mmc_register(mmc); Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] mmc: seperate block number into small parts for multi-write cmd
On Wed, Oct 13, 2010 at 10:38 PM, Lei Wen lei...@marvell.com wrote: Constraint the mmc framework to only send no more than 65535 blocks in one go during the multi-write command. This constraint comes due to the limitation of 16bit width block counter register at some hardware. Signed-off-by: Lei Wen lei...@marvell.com Cc: Reinhard Meyer u-b...@emk-elektronik.de --- V4: clean patch V3: return to the V1 solution that keep the 65535 constraint, but cut the 512KiB dma limitation V2: add additional members in mmc structure What is the status of this patch? I would like to submit a multi-block read patch and need to know whether to assume that this patch will be pushed. Regards, Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] drivers/net/fec_mxc.c: write mac address ininit
On Thu, Oct 21, 2010 at 9:37 PM, Wolfgang Denk w...@denx.de wrote: Dear Jason Liu, In message aanlktimesozpvruutursgkxtqk0tyjgdxtck7egzm...@mail.gmail.com you wrote: Geting mac address from FUSE is the right way for mx51 and it's not difficult to add FUSE read function due to the FUSE read is simple as the memory read. I have seen that Shawn has posted the patches to Linaro-uboot git there. It's a pity that Linaro does it's development out-of-tree, but it's their decision, and we cannot help it. Hmmm . . . I'm doing OMAP3 4 u-boot work for Linaro and *all* of my work is based on current mainline! So I think that this is probably not a good blanket assumption. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] drivers/net/fec_mxc.c: write mac address ininit
On Fri, Oct 22, 2010 at 8:32 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday, October 22, 2010 11:00:37 Steve Sakoman wrote: On Thu, Oct 21, 2010 at 9:37 PM, Wolfgang Denk wrote: Jason Liu wrote: Geting mac address from FUSE is the right way for mx51 and it's not difficult to add FUSE read function due to the FUSE read is simple as the memory read. I have seen that Shawn has posted the patches to Linaro-uboot git there. It's a pity that Linaro does it's development out-of-tree, but it's their decision, and we cannot help it. Hmmm . . . I'm doing OMAP3 4 u-boot work for Linaro and *all* of my work is based on current mainline! technically speaking, *everyone* is doing work based on mainline. but if you're maintaining a fork without getting merged, then Wolfgang's statement is still pretty correct. if i cant checkout current mainline from Wolfgang and get stuff working, then something is wrong. I can't speak for others, but the lifetime of a patch in my working branch is just a few days before it gets posted to the list. Frankly I can't imagine working any closer to top of tree. I do daily merges and builds and send fix patches as soon as I have them. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: OMAP: I2C driver: Fix bug found in 37XX testing
On OMAP36/37XX the standard on chip pullups are not sufficient to
ensure proper i2c operation without external pullups or switching
to high speed mode and enabling special on chip pullups.
This is an issue for Beagle xM, which does not have external pullups
on the expansion board i2c lines.
The issue manifests itself as an AL (arbitration lost) error when
probing for a non-existent device (i.e. on a Beagle xM with no expansion
boards attached). This issue does not occur on expansion boards that
include pullups or on Overo 37XX COM's since they include pull-ups.
This patch fixes the issue by checking for the AL bit in the i2c_probe
function.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index a72d1a1..fab49fd 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -329,7 +329,7 @@ int i2c_probe (uchar chip)
while (1) {
status = wait_for_pin();
- if (status == 0) {
+ if (status == 0 || status I2C_STAT_AL) {
res = 1;
goto probe_exit;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. Tested on Beagle, Overo, Panda, and OMAP4430SDP Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c index 5715168..30686fe 100644 --- a/arch/arm/lib/cache.c +++ b/arch/arm/lib/cache.c @@ -38,7 +38,7 @@ void flush_cache (unsigned long dummy1, unsigned long dummy2) /* disable write buffer as well (page 2-22) */ asm(mcr p15, 0, %0, c7, c10, 4 : : r (0)); #endif -#ifdef CONFIG_ARMV7 +#ifdef CONFIG_OMAP34XX void v7_flush_cache_all(void); v7_flush_cache_all(); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: OMAP3: Add expansion board detection for Beagle
From: Koen Kooi k-k...@ti.com
Beagle expansion boards contain an i2c eeprom to identify themselves.
This patch adds code to read and parse the eeprom contents. It prints
the expansion board name and revision and modifies environment variables
as appropriate. This patch is based on the Overo expansion board code.
Signed-off-by: Koen Kooi k-k...@ti.com
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c5d6679..d9b6f01 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -39,6 +39,27 @@
#include asm/mach-types.h
#include beagle.h
+#define TWL4030_I2C_BUS0
+#define EXPANSION_EEPROM_I2C_BUS 1
+#define EXPANSION_EEPROM_I2C_ADDRESS 0x50
+
+#define TINCANTOOLS_ZIPPY 0x01000100
+#define TINCANTOOLS_ZIPPY2 0x02000100
+#define TINCANTOOLS_TRAINER0x04000100
+#define TINCANTOOLS_SHOWDOG0x03000100
+#define KBADC_BEAGLEFPGA 0x01000600
+
+#define BEAGLE_NO_EEPROM 0x
+
+static struct {
+ unsigned int device_vendor;
+ unsigned char revision;
+ unsigned char content;
+ char fab_revision[8];
+ char env_var[16];
+ char env_setting[64];
+} expansion_config;
+
/*
* Routine: board_init
* Description: Early hardware init.
@@ -95,6 +116,31 @@ int get_board_revision(void)
}
/*
+ * Routine: get_expansion_id
+ * Description: This function checks for expansion board by checking I2C
+ * bus 1 for the availability of an AT24C01B serial EEPROM.
+ * returns the device_vendor field from the EEPROM
+ */
+unsigned int get_expansion_id(void)
+{
+ i2c_set_bus_num(EXPANSION_EEPROM_I2C_BUS);
+
+ /* return BEAGLE_NO_EEPROM if eeprom doesn't respond */
+ if (i2c_probe(EXPANSION_EEPROM_I2C_ADDRESS) == 1) {
+ i2c_set_bus_num(TWL4030_I2C_BUS);
+ return BEAGLE_NO_EEPROM;
+ }
+
+ /* read configuration data */
+ i2c_read(EXPANSION_EEPROM_I2C_ADDRESS, 0, 1, (u8 *)expansion_config,
+sizeof(expansion_config));
+
+ i2c_set_bus_num(TWL4030_I2C_BUS);
+
+ return expansion_config.device_vendor;
+}
+
+/*
* Routine: misc_init_r
* Description: Configure board specific parts
*/
@@ -141,6 +187,55 @@ int misc_init_r(void)
printf(Beagle unknown 0x%02x\n, get_board_revision());
}
+ switch (get_expansion_id()) {
+ case TINCANTOOLS_ZIPPY:
+ printf(Recognized Tincantools Zippy board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ MUX_TINCANTOOLS_ZIPPY();
+ setenv(buddy, zippy);
+ break;
+ case TINCANTOOLS_ZIPPY2:
+ printf(Recognized Tincantools Zippy2 board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ MUX_TINCANTOOLS_ZIPPY();
+ setenv(buddy, zippy2);
+ break;
+ case TINCANTOOLS_TRAINER:
+ printf(Recognized Tincantools Trainer board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ MUX_TINCANTOOLS_ZIPPY();
+ MUX_TINCANTOOLS_TRAINER();
+ setenv(buddy, trainer);
+ break;
+ case TINCANTOOLS_SHOWDOG:
+ printf(Recognized Tincantools Showdow board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ /* Place holder for DSS2 definition for showdog lcd */
+ setenv(defaultdisplay, showdoglcd);
+ setenv(buddy, showdog);
+ break;
+ case KBADC_BEAGLEFPGA:
+ printf(Recognized KBADC Beagle FPGA board\n);
+ MUX_KBADC_BEAGLEFPGA();
+ setenv(buddy, beaglefpga);
+ break;
+ case BEAGLE_NO_EEPROM:
+ printf(No EEPROM on expansion board\n);
+ setenv(buddy, none);
+ break;
+ default:
+ printf(Unrecognized expansion board: %x\n,
+ expansion_config.device_vendor);
+ setenv(buddy, unknown);
+ }
+
+ if (expansion_config.content == 1)
+ setenv(expansion_config.env_var, expansion_config.env_setting);
+
twl4030_power_init();
twl4030_led_init(TWL4030_LED_LEDEN_LEDAON | TWL4030_LED_LEDEN_LEDBON);
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index ec0da6d..2db84b5 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -259,8 +259,8 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(HSUSB0_DATA7), (IEN | PTD | DIS | M0))
/*HSUSB0_DATA7*/\
MUX_VAL(CP(I2C1_SCL
[U-Boot] [PATCH v2] ARMV7: OMAP3: Add expansion board detection for Overo
ARMV7: OMAP3: Add expansion board detection for Overo
Overo expansion boards contain an i2c eeprom to identify themselves.
This patch adds code to read and parse the eeprom contents. It prints
the expansion board name and revision and modifies environment variables
as appropriate.
Signed-off-by: Steve Sakoman st...@sakoman.com
---
Change in v2:
set i2c_bus_num to TWL4030_I2C_BUS on error exit
diff --git a/board/overo/overo.c b/board/overo/overo.c
index 9c92693..f917e40 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -40,6 +40,32 @@
#include asm/mach-types.h
#include overo.h
+#define TWL4030_I2C_BUS0
+#define EXPANSION_EEPROM_I2C_BUS 2
+#define EXPANSION_EEPROM_I2C_ADDRESS 0x51
+
+#define GUMSTIX_SUMMIT 0x01000200
+#define GUMSTIX_TOBI 0x02000200
+#define GUMSTIX_TOBI_DUO 0x03000200
+#define GUMSTIX_PALO35 0x04000200
+#define GUMSTIX_PALO43 0x05000200
+#define GUMSTIX_CHESTNUT43 0x06000200
+#define GUMSTIX_PINTO 0x07000200
+#define GUMSTIX_GALLOP43 0x08000200
+
+#define ETTUS_USRP_E 0x01000300
+
+#define GUMSTIX_NO_EEPROM 0x
+
+static struct {
+ unsigned int device_vendor;
+ unsigned char revision;
+ unsigned char content;
+ char fab_revision[8];
+ char env_var[16];
+ char env_setting[64];
+} expansion_config;
+
#if defined(CONFIG_CMD_NET)
static void setup_net_chip(void);
#endif
@@ -137,6 +163,31 @@ int get_sdio2_config(void)
}
/*
+ * Routine: get_expansion_id
+ * Description: This function checks for expansion board by checking I2C
+ * bus 2 for the availability of an AT24C01B serial EEPROM.
+ * returns the device_vendor field from the EEPROM
+ */
+unsigned int get_expansion_id(void)
+{
+ i2c_set_bus_num(EXPANSION_EEPROM_I2C_BUS);
+
+ /* return GUMSTIX_NO_EEPROM if eeprom doesn't respond */
+ if (i2c_probe(EXPANSION_EEPROM_I2C_ADDRESS) == 1) {
+ i2c_set_bus_num(TWL4030_I2C_BUS);
+ return GUMSTIX_NO_EEPROM;
+ }
+
+ /* read configuration data */
+ i2c_read(EXPANSION_EEPROM_I2C_ADDRESS, 0, 1, (u8 *)expansion_config,
+sizeof(expansion_config));
+
+ i2c_set_bus_num(TWL4030_I2C_BUS);
+
+ return expansion_config.device_vendor;
+}
+
+/*
* Routine: misc_init_r
* Description: Configure board specific parts
*/
@@ -164,6 +215,70 @@ int misc_init_r(void)
printf(Unable to detect mmc2 connection type\n);
}
+ switch (get_expansion_id()) {
+ case GUMSTIX_SUMMIT:
+ printf(Recognized Summit expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ setenv(defaultdisplay, dvi);
+ break;
+ case GUMSTIX_TOBI:
+ printf(Recognized Tobi expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ setenv(defaultdisplay, dvi);
+ break;
+ case GUMSTIX_TOBI_DUO:
+ printf(Recognized Tobi Duo expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ break;
+ case GUMSTIX_PALO35:
+ printf(Recognized Palo35 expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ setenv(defaultdisplay, lcd35);
+ break;
+ case GUMSTIX_PALO43:
+ printf(Recognized Palo43 expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ setenv(defaultdisplay, lcd43);
+ break;
+ case GUMSTIX_CHESTNUT43:
+ printf(Recognized Chestnut43 expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ setenv(defaultdisplay, lcd43);
+ break;
+ case GUMSTIX_PINTO:
+ printf(Recognized Pinto expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ break;
+ case GUMSTIX_GALLOP43:
+ printf(Recognized Gallop43 expansion board (rev %d %s)\n,
+ expansion_config.revision,
+ expansion_config.fab_revision);
+ setenv(defaultdisplay, lcd43);
+ break;
+ case ETTUS_USRP_E:
+ printf(Recognized Ettus Research USRP-E (rev %d %s)\n,
+ expansion_config.revision
[U-Boot] [PATCH] ARMV7: OMAP3: IGEP: Rename TEXT_BASE
Commit 14d0a02a Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE missed the IGEP boards since they were just added. Signed-off-by: Steve Sakoman steve.sako...@linaro.org --- diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk index b8812f9..7964621 100644 --- a/board/isee/igep0020/config.mk +++ b/board/isee/igep0020/config.mk @@ -30,4 +30,4 @@ # (mem base + reserved) # For use with external or internal boots. -TEXT_BASE = 0x80008000 +CONFIG_SYS_TEXT_BASE = 0x80008000 diff --git a/board/isee/igep0030/config.mk b/board/isee/igep0030/config.mk index 35865e0..de6384f 100644 --- a/board/isee/igep0030/config.mk +++ b/board/isee/igep0030/config.mk @@ -30,5 +30,5 @@ # (mem base + reserved) # For use with external or internal boots. -TEXT_BASE = 0x80008000 +CONFIG_SYS_TEXT_BASE = 0x80008000 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] ARMV7: OMAP: I2C driver: Restructure code to eliminate udelay calls and improve performance
I've been preparing a patch series for Beagle and Overo that detects expansion board configuration information by reading a 128 byte I2C EEPROM on each expansion board. Using the OMAP I2C driver in its current form takes about 5-6 seconds to read this small number of bytes! Executing the i2c probe command takes close to 10 seconds. Examining the code I see that there are a large number of fairly long udelay calls throughout the driver (10 - 50 milliseconds). I looked through the linux driver and did not see equivalent delays in that code. In fact the longest delay in the linux code was one millisecond. In looking at the TRM I2C section for OMAP3 and OMAP4 I don't see any requirement for delays in the programming model description. This patch restructures the i2c driver to eliminate most of the udelay calls by monitoring state changes in the status register. The EEPROM reads and the i2c probe execution are now instantaneous. This patch series was tested on OMAP3 (Overo) and OMAP4 (Panda). I do not have access to OMAP2 hardware for testing. Steve Sakoman (4): ARMV7: OMAP: I2C driver: Use same timeout value as linux kernel driver ARMV7: OMAP: I2C driver: Restructure i2c_read_byte function ARMV7: OMAP: I2C driver: Restructure i2c_write_byte function ARMV7: OMAP: I2C driver: Restructure i2c_probe function drivers/i2c/omap24xx_i2c.c | 204 --- 1 files changed, 114 insertions(+), 90 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] ARMV7: OMAP: I2C driver: Use same timeout value as linux kernel driver
This patch matches the poll interval (1 millisecond) and timeout (1 second)
used in the linux driver. It also adds a return value of 0 in the event of
a timeout error and cleans up some formatting errors in that section of the
code.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
Tested-by: Heiko Schocher h...@denx.de
---
drivers/i2c/omap24xx_i2c.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 3febd1f..b69d051 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -27,7 +27,7 @@
#include omap24xx_i2c.h
-#define I2C_TIMEOUT10
+#define I2C_TIMEOUT1000
static void wait_for_bb (void);
static u16 wait_for_pin (void);
@@ -392,13 +392,13 @@ int i2c_write (uchar chip, uint addr, int alen, uchar *
buffer, int len)
static void wait_for_bb (void)
{
- int timeout = 10;
+ int timeout = I2C_TIMEOUT;
u16 stat;
writew(0x, i2c_base-stat); /* clear current interruts...*/
while ((stat = readw (i2c_base-stat) I2C_STAT_BB) timeout--) {
writew (stat, i2c_base-stat);
- udelay (5);
+ udelay(1000);
}
if (timeout = 0) {
@@ -411,7 +411,7 @@ static void wait_for_bb (void)
static u16 wait_for_pin (void)
{
u16 status;
- int timeout = 10;
+ int timeout = I2C_TIMEOUT;
do {
udelay (1000);
@@ -424,8 +424,10 @@ static u16 wait_for_pin (void)
if (timeout = 0) {
printf (timed out in wait_for_pin: I2C_STAT=%x\n,
readw (i2c_base-stat));
- writew(0x, i2c_base-stat);
-}
+ writew(0x, i2c_base-stat);
+ status = 0;
+ }
+
return status;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] ARMV7: OMAP: I2C driver: Restructure i2c_read_byte function
This patch removes the magic number delays and instead
monitors state changes in the status register bits.
Signed-off-by: Steve Sakoman steve.sakomanlinaro.org
Tested-by: Heiko Schocher h...@denx.de
---
drivers/i2c/omap24xx_i2c.c | 76 +--
1 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index b69d051..d176b5d 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -159,58 +159,56 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
value)
/* no stop bit needed here */
writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX,
i2c_base-con);
- status = wait_for_pin ();
-
- if (status I2C_STAT_XRDY) {
- /* Important: have to use byte access */
- writeb (regoffset, i2c_base-data);
- udelay (2);
- if (readw (i2c_base-stat) I2C_STAT_NACK) {
+ /* send register offset */
+ while (1) {
+ status = wait_for_pin();
+ if (status == 0 || status I2C_STAT_NACK) {
i2c_error = 1;
+ goto read_exit;
+ }
+ if (status I2C_STAT_XRDY) {
+ /* Important: have to use byte access */
+ writeb(regoffset, i2c_base-data);
+ writew(I2C_STAT_XRDY, i2c_base-stat);
+ }
+ if (status I2C_STAT_ARDY) {
+ writew(I2C_STAT_ARDY, i2c_base-stat);
+ break;
}
- } else {
- i2c_error = 1;
}
- if (!i2c_error) {
- writew (I2C_CON_EN, i2c_base-con);
- while (readw(i2c_base-stat)
- (I2C_STAT_XRDY | I2C_STAT_ARDY)) {
- udelay (1);
- /* Have to clear pending interrupt to clear I2C_STAT */
- writew (0x, i2c_base-stat);
+ /* set slave address */
+ writew(devaddr, i2c_base-sa);
+ /* read one byte from slave */
+ writew(1, i2c_base-cnt);
+ /* need stop bit here */
+ writew(I2C_CON_EN | I2C_CON_MST |
+ I2C_CON_STT | I2C_CON_STP,
+ i2c_base-con);
+
+ /* receive data */
+ while (1) {
+ status = wait_for_pin();
+ if (status == 0 || status I2C_STAT_NACK) {
+ i2c_error = 1;
+ goto read_exit;
}
-
- /* set slave address */
- writew (devaddr, i2c_base-sa);
- /* read one byte from slave */
- writew (1, i2c_base-cnt);
- /* need stop bit here */
- writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_STP,
- i2c_base-con);
-
- status = wait_for_pin ();
if (status I2C_STAT_RRDY) {
#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
defined(CONFIG_OMAP44XX)
- *value = readb (i2c_base-data);
+ *value = readb(i2c_base-data);
#else
- *value = readw (i2c_base-data);
+ *value = readw(i2c_base-data);
#endif
- udelay (2);
- } else {
- i2c_error = 1;
+ writew(I2C_STAT_RRDY, i2c_base-stat);
}
-
- if (!i2c_error) {
- writew (I2C_CON_EN, i2c_base-con);
- while (readw (i2c_base-stat)
- (I2C_STAT_RRDY | I2C_STAT_ARDY)) {
- udelay (1);
- writew (0x, i2c_base-stat);
- }
+ if (status I2C_STAT_ARDY) {
+ writew(I2C_STAT_ARDY, i2c_base-stat);
+ break;
}
}
+
+read_exit:
flush_fifo();
writew (0x, i2c_base-stat);
writew (0, i2c_base-cnt);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] ARMV7: OMAP: I2C driver: Restructure i2c_write_byte function
This patch removes the magic number delays and instead
monitors state changes in the status register bits.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
Tested-by: Heiko Schocher h...@denx.de
---
drivers/i2c/omap24xx_i2c.c | 78 +++
1 files changed, 42 insertions(+), 36 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index d176b5d..35201c3 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -218,7 +218,7 @@ read_exit:
static int i2c_write_byte (u8 devaddr, u8 regoffset, u8 value)
{
int i2c_error = 0;
- u16 status, stat;
+ u16 status;
/* wait until bus not busy */
wait_for_bb ();
@@ -231,49 +231,55 @@ static int i2c_write_byte (u8 devaddr, u8 regoffset, u8
value)
writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX |
I2C_CON_STP, i2c_base-con);
- /* wait until state change */
- status = wait_for_pin ();
-
- if (status I2C_STAT_XRDY) {
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
-defined(CONFIG_OMAP44XX)
- /* send out 1 byte */
- writeb (regoffset, i2c_base-data);
- writew (I2C_STAT_XRDY, i2c_base-stat);
-
- status = wait_for_pin ();
- if ((status I2C_STAT_XRDY)) {
- /* send out next 1 byte */
- writeb (value, i2c_base-data);
- writew (I2C_STAT_XRDY, i2c_base-stat);
- } else {
+ while (1) {
+ status = wait_for_pin();
+ if (status == 0 || status I2C_STAT_NACK) {
i2c_error = 1;
+ goto write_exit;
}
+ if (status I2C_STAT_XRDY) {
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+defined(CONFIG_OMAP44XX)
+ /* send register offset */
+ writeb(regoffset, i2c_base-data);
+ writew(I2C_STAT_XRDY, i2c_base-stat);
+
+ while (1) {
+ status = wait_for_pin();
+ if (status == 0 || status I2C_STAT_NACK) {
+ i2c_error = 1;
+ goto write_exit;
+ }
+ if (status I2C_STAT_XRDY) {
+ /* send data */
+ writeb(value, i2c_base-data);
+ writew(I2C_STAT_XRDY, i2c_base-stat);
+ }
+ if (status I2C_STAT_ARDY) {
+ writew(I2C_STAT_ARDY, i2c_base-stat);
+ break;
+ }
+ }
+ break;
#else
- /* send out two bytes */
- writew ((value 8) + regoffset, i2c_base-data);
+ /* send out two bytes */
+ writew((value 8) + regoffset, i2c_base-data);
+ writew(I2C_STAT_XRDY, i2c_base-stat);
#endif
- /* must have enough delay to allow BB bit to go low */
- udelay (5);
- if (readw (i2c_base-stat) I2C_STAT_NACK) {
- i2c_error = 1;
}
- } else {
- i2c_error = 1;
+ if (status I2C_STAT_ARDY) {
+ writew(I2C_STAT_ARDY, i2c_base-stat);
+ break;
+ }
}
- if (!i2c_error) {
- int eout = 200;
+ wait_for_bb();
- writew (I2C_CON_EN, i2c_base-con);
- while ((stat = readw (i2c_base-stat)) || (readw
(i2c_base-con) I2C_CON_MST)) {
- udelay (1000);
- /* have to read to clear intrrupt */
- writew (0x, i2c_base-stat);
- if(--eout == 0) /* better leave with error than hang */
- break;
- }
- }
+ status = readw(i2c_base-stat);
+ if (status I2C_STAT_NACK)
+ i2c_error = 1;
+
+write_exit:
flush_fifo();
writew (0x, i2c_base-stat);
writew (0, i2c_base-cnt);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 3/4] ARMV7: OMAP: I2C driver: Restructure i2c_write_byte function
On Wed, 2010-10-20 at 08:08 +0200, Heiko Schocher wrote:
Hello Steve,
Steve Sakoman wrote:
This patch removes the magic number delays and instead
monitors state changes in the status register bits.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
drivers/i2c/omap24xx_i2c.c | 76
+++
1 files changed, 41 insertions(+), 35 deletions(-)
After trying this for the omap3_beagle board, I get an
compiler warning:
[...@pollux u-boot]$ ./MAKEALL omap3_beagle
Configuring for omap3_beagle board...
omap24xx_i2c.c: In function 'i2c_write_byte':
omap24xx_i2c.c:221: warning: unused variable 'stat'
Hmm . . . I can swear I fixed that! Must be getting old :-)
textdata bss dec hex filename
218103 11412 202384 431899 6971b ./u-boot
- SUMMARY
Boards compiled: 1
Boards with warnings or errors: 1 ( omap3_beagle )
--
[...@pollux u-boot]$
following patch fixes it.
BTW:
Just for the record, your patchset works fine and faster
on the beagle board, for example:
before your after your
patchset patchset
i2c probe9s 0,4s
i2c md 48 0 100 17s 1s
I'm glad that you see the same speedups!
What tool do you use to measure the speedups?
would you post a v2 of this patch, and I add my
Tested-by to it, or is it OK, if I add my fix patch
to u-boot-i2c master?
I've posted v2 with your Tested-by and the warning fix.
If it helps, the patches are in my omap4-next-upstream branch:
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-next-upstream
Thanks for testing and for the comments!
Steve
From 01c6c59014c4174ad4d13944d740d3491d9cf137 Mon Sep 17 00:00:00 2001
From: Heiko Schocher h...@denx.de
Date: Wed, 20 Oct 2010 07:57:05 +0200
Subject: [PATCH] ARMV7: OMAP: I2C driver: fix compiler warning
Signed-off-by: Heiko Schocher h...@denx.de
---
drivers/i2c/omap24xx_i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index eb153fb..a72d1a1 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -218,7 +218,7 @@ read_exit:
static int i2c_write_byte (u8 devaddr, u8 regoffset, u8 value)
{
int i2c_error = 0;
- u16 status, stat;
+ u16 status;
/* wait until bus not busy */
wait_for_bb ();
bye,
Heiko
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] ARMV7: OMAP: I2C driver: Restructure i2c_probe function
This patch removes the magic number delays and instead
monitors state changes in the status register bits.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
Tested-by: Heiko Schocher h...@denx.de
---
drivers/i2c/omap24xx_i2c.c | 41 ++---
1 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 35201c3..a72d1a1 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -310,6 +310,7 @@ static void flush_fifo(void)
int i2c_probe (uchar chip)
{
+ u16 status;
int res = 1; /* default = fail */
if (chip == readw (i2c_base-oa)) {
@@ -325,19 +326,37 @@ int i2c_probe (uchar chip)
writew (chip, i2c_base-sa);
/* stop bit needed here */
writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_STP,
i2c_base-con);
- /* enough delay for the NACK bit set */
- udelay (5);
- if (!(readw (i2c_base-stat) I2C_STAT_NACK)) {
- res = 0; /* success case */
- flush_fifo();
- writew(0x, i2c_base-stat);
- } else {
- writew(0x, i2c_base-stat); /* failue, clear
sources*/
- writew (readw (i2c_base-con) | I2C_CON_STP, i2c_base-con);
/* finish up xfer */
- udelay(2);
- wait_for_bb ();
+ while (1) {
+ status = wait_for_pin();
+ if (status == 0) {
+ res = 1;
+ goto probe_exit;
+ }
+ if (status I2C_STAT_NACK) {
+ res = 1;
+ writew(0xff, i2c_base-stat);
+ writew (readw (i2c_base-con) | I2C_CON_STP,
i2c_base-con);
+ wait_for_bb ();
+ break;
+ }
+ if (status I2C_STAT_ARDY) {
+ writew(I2C_STAT_ARDY, i2c_base-stat);
+ break;
+ }
+ if (status I2C_STAT_RRDY) {
+ res = 0;
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
+defined(CONFIG_OMAP44XX)
+ readb(i2c_base-data);
+#else
+ readw(i2c_base-data);
+#endif
+ writew(I2C_STAT_RRDY, i2c_base-stat);
+ }
}
+
+probe_exit:
flush_fifo();
writew (0, i2c_base-cnt); /* don't allow any more data in...we don't
want it.*/
writew(0x, i2c_base-stat);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
