Re: [U-Boot] [PATCH 0/4] omap3: clean up gpmc config strut
which tree is the baseline for these? i think arm/next has few changes also which is yet to be merged to mainline.. its based on 2009.06-RC1. I recently compile-tested on arm/next, it works for all platforms in master, but breaks zoom2. -- Matthias Ludwig, Software Development Ultratronik Entwicklungs GmbH, Gewerbestrasse 52, 82211 Herrsching, Germany http://www.ultratronik.de Tel: +49 8152 3709-356 Fax: +49 8152 5183 Registergericht Muenchen, HRB 55584 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Gbe Controller driver support for kirkwood SOCs
Hi Prafulla, Prafulla Wadaskar wrote: Hi All Ping I didn't here any feedback from anyone, waiting for your valued comments :-( I've started reviewing this driver - it's a lot to digest (2500 lines!?!). Please think a little about what features are really needed here. For example, do you really need RMON in a bootloader? I'll try to provide more specific feedback soon. Regards.. Prafulla . . regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] omap3: remove typedef for struct gpmc
Hi Dirk, I wonder if you have the resources and like to convert all register structs used by OMAP3 code and remove the typedef? Else we would have a mixture of typedefs and struct usage (see e.g. above in sys_info.c). I would like to have it consistent, either the one or the other way ;) What do you think? sounds reasonable, so already in the making. Patchset in reply to this mail. Again: - compile-tested on beagle, evm, over, pandora, zoom1 - boot-tested on own board - based on v2009.06-rc1 - applies on u-boot-arm/next but breaks zoom2 Please test on other platforms. best regards, Matthias Matthias Ludwig (4): omap3: embedd gpmc_cs into gpmc config struct omap3: remove typedefs for configuration structs omap3: replace all instances of gpmc config struct by one global omap3: use only fixed-size types inside ctrl_structs board/omap3/beagle/beagle.c |6 +- board/omap3/evm/evm.c | 19 +- board/omap3/pandora/pandora.c |8 +- cpu/arm_cortexa8/omap3/board.c | 16 +- cpu/arm_cortexa8/omap3/clock.c | 14 +- cpu/arm_cortexa8/omap3/interrupts.c |2 +- cpu/arm_cortexa8/omap3/mem.c| 56 ++--- cpu/arm_cortexa8/omap3/sys_info.c | 13 +- drivers/mtd/nand/omap_gpmc.c| 41 ++-- include/asm-arm/arch-omap3/cpu.h| 476 ++- include/asm-arm/arch-omap3/mem.h|4 +- include/asm-arm/arch-omap3/omap3.h |8 +- include/configs/omap3_beagle.h |3 +- include/configs/omap3_evm.h |3 +- include/configs/omap3_overo.h |3 +- include/configs/omap3_pandora.h |3 +- include/configs/omap3_zoom1.h |3 +- 17 files changed, 337 insertions(+), 341 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 3/4] omap3: replace all instances of gpmc config struct by one global
Signed-off-by: Matthias Ludwig mlud...@ultratronik.de
---
board/omap3/evm/evm.c | 15 +++
cpu/arm_cortexa8/omap3/mem.c | 21 ++---
cpu/arm_cortexa8/omap3/sys_info.c |3 +--
drivers/mtd/nand/omap_gpmc.c | 33 -
4 files changed, 34 insertions(+), 38 deletions(-)
diff --git a/board/omap3/evm/evm.c b/board/omap3/evm/evm.c
index 7747986..efbb405 100644
--- a/board/omap3/evm/evm.c
+++ b/board/omap3/evm/evm.c
@@ -92,17 +92,16 @@ void set_muxconf_regs(void)
static void setup_net_chip(void)
{
struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
- struct gpmc *gpmc = (struct gpmc *)GPMC_BASE;
struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
/* Configure GPMC registers */
- writel(NET_GPMC_CONFIG1, gpmc-cs[5].config1);
- writel(NET_GPMC_CONFIG2, gpmc-cs[5].config2);
- writel(NET_GPMC_CONFIG3, gpmc-cs[5].config3);
- writel(NET_GPMC_CONFIG4, gpmc-cs[5].config4);
- writel(NET_GPMC_CONFIG5, gpmc-cs[5].config5);
- writel(NET_GPMC_CONFIG6, gpmc-cs[5].config6);
- writel(NET_GPMC_CONFIG7, gpmc-cs[5].config7);
+ writel(NET_GPMC_CONFIG1, gpmc_cfg-cs[5].config1);
+ writel(NET_GPMC_CONFIG2, gpmc_cfg-cs[5].config2);
+ writel(NET_GPMC_CONFIG3, gpmc_cfg-cs[5].config3);
+ writel(NET_GPMC_CONFIG4, gpmc_cfg-cs[5].config4);
+ writel(NET_GPMC_CONFIG5, gpmc_cfg-cs[5].config5);
+ writel(NET_GPMC_CONFIG6, gpmc_cfg-cs[5].config6);
+ writel(NET_GPMC_CONFIG7, gpmc_cfg-cs[5].config7);
/* Enable off mode for NWE in PADCONF_GPMC_NWE register */
writew(readw(ctrl_base -gpmc_nwe) | 0x0E00, ctrl_base-gpmc_nwe);
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index aa15f94..079c848 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -41,6 +41,8 @@ unsigned int boot_flash_sec;
unsigned int boot_flash_type;
volatile unsigned int boot_flash_env_addr;
+struct gpmc *gpmc_cfg;
+
#if defined(CONFIG_CMD_NAND)
static u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG1,
@@ -51,8 +53,6 @@ static u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG6, 0
};
-struct gpmc *gpmc_cfg;
-
#if defined(CONFIG_ENV_IS_IN_NAND)
#define GPMC_CS 0
#else
@@ -219,7 +219,7 @@ void gpmc_init(void)
{
/* putting a blanket check on GPMC based on ZeBu for now */
u32 *gpmc_config = NULL;
- struct gpmc *gpmc_base = (struct gpmc *)GPMC_BASE;
+ gpmc_cfg = (struct gpmc *)GPMC_BASE;
u32 base = 0;
u32 size = 0;
u32 f_off = CONFIG_SYS_MONITOR_LEN;
@@ -227,27 +227,26 @@ void gpmc_init(void)
u32 config = 0;
/* global settings */
- writel(0, gpmc_base-irqenable); /* isr's sources masked */
- writel(0, gpmc_base-timeout_control);/* timeout disable */
+ writel(0, gpmc_cfg-irqenable); /* isr's sources masked */
+ writel(0, gpmc_cfg-timeout_control);/* timeout disable */
- config = readl(gpmc_base-config);
+ config = readl(gpmc_cfg-config);
config = (~0xf00);
- writel(config, gpmc_base-config);
+ writel(config, gpmc_cfg-config);
/*
* Disable the GPMC0 config set by ROM code
* It conflicts with our MPDB (both at 0x0800)
*/
- writel(0, gpmc_base-cs[0].config7);
+ writel(0, gpmc_cfg-cs[0].config7);
sdelay(1000);
#if defined(CONFIG_CMD_NAND) /* CS 0 */
gpmc_config = gpmc_m_nand;
- gpmc_cfg = gpmc_base;
base = PISMO1_NAND_BASE;
size = PISMO1_NAND_SIZE;
- enable_gpmc_cs_config(gpmc_config, gpmc_base-cs[0], base, size);
+ enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, size);
#if defined(CONFIG_ENV_IS_IN_NAND)
f_off = SMNAND_ENV_OFFSET;
f_sec = SZ_128K;
@@ -263,7 +262,7 @@ void gpmc_init(void)
gpmc_config = gpmc_onenand;
base = PISMO1_ONEN_BASE;
size = PISMO1_ONEN_SIZE;
- enable_gpmc_cs_config(gpmc_config, gpmc_base-cs[0], base, size);
+ enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, size);
#if defined(CONFIG_ENV_IS_IN_ONENAND)
f_off = ONENAND_ENV_OFFSET;
f_sec = SZ_128K;
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index e0e5153..765aaf2 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -32,7 +32,6 @@
#include i2c.h
extern omap3_sysinfo sysinfo;
-static struct gpmc *gpmc_base = (struct gpmc *)GPMC_BASE;
static struct sdrc *sdrc_base = (struct sdrc *)OMAP34XX_SDRC_BASE;
static struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
static char *rev_s[CPU_3XX_MAX_REV] = {
@@ -160,7 +159,7 @@ u32 get_gpmc0_base(void)
{
u32 b;
- b = readl(gpmc_base-cs[0].config7);
+ b = readl(gpmc_cfg-cs[0].config7);
b = 0x1F; /* keep base
[U-Boot] [PATCHv2 2/4] omap3: remove typedefs for configuration structs
Signed-off-by: Matthias Ludwig mlud...@ultratronik.de
---
board/omap3/beagle/beagle.c |6 ++--
board/omap3/evm/evm.c |6 ++--
board/omap3/pandora/pandora.c |8 +++---
cpu/arm_cortexa8/omap3/board.c | 16 ++--
cpu/arm_cortexa8/omap3/clock.c | 14 +-
cpu/arm_cortexa8/omap3/interrupts.c |2 +-
cpu/arm_cortexa8/omap3/mem.c| 14 +-
cpu/arm_cortexa8/omap3/sys_info.c | 12 +-
drivers/mtd/nand/omap_gpmc.c|2 +-
include/asm-arm/arch-omap3/cpu.h| 42 +-
include/asm-arm/arch-omap3/mem.h|4 +-
include/asm-arm/arch-omap3/omap3.h |8 +++---
include/configs/omap3_beagle.h |2 +-
include/configs/omap3_evm.h |2 +-
include/configs/omap3_overo.h |2 +-
include/configs/omap3_pandora.h |2 +-
include/configs/omap3_zoom1.h |2 +-
17 files changed, 72 insertions(+), 72 deletions(-)
diff --git a/board/omap3/beagle/beagle.c b/board/omap3/beagle/beagle.c
index 7eb70ee..2dc11dd 100644
--- a/board/omap3/beagle/beagle.c
+++ b/board/omap3/beagle/beagle.c
@@ -74,7 +74,7 @@ int beagle_get_revision(void)
*/
void beagle_identify(void)
{
- gpio_t *gpio6_base = (gpio_t *)OMAP34XX_GPIO6_BASE;
+ struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
/* Configure GPIO 171 as input */
writel(readl(gpio6_base-oe) | GPIO11, gpio6_base-oe);
@@ -98,8 +98,8 @@ void beagle_identify(void)
*/
int misc_init_r(void)
{
- gpio_t *gpio5_base = (gpio_t *)OMAP34XX_GPIO5_BASE;
- gpio_t *gpio6_base = (gpio_t *)OMAP34XX_GPIO6_BASE;
+ struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
+ struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
power_init_r();
diff --git a/board/omap3/evm/evm.c b/board/omap3/evm/evm.c
index 032c93a..7747986 100644
--- a/board/omap3/evm/evm.c
+++ b/board/omap3/evm/evm.c
@@ -91,9 +91,9 @@ void set_muxconf_regs(void)
*/
static void setup_net_chip(void)
{
- gpio_t *gpio3_base = (gpio_t *)OMAP34XX_GPIO3_BASE;
- gpmc_t *gpmc = (gpmc_t *)GPMC_BASE;
- ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+ struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ struct gpmc *gpmc = (struct gpmc *)GPMC_BASE;
+ struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
/* Configure GPMC registers */
writel(NET_GPMC_CONFIG1, gpmc-cs[5].config1);
diff --git a/board/omap3/pandora/pandora.c b/board/omap3/pandora/pandora.c
index c2f98ea..e4b45f7 100644
--- a/board/omap3/pandora/pandora.c
+++ b/board/omap3/pandora/pandora.c
@@ -59,10 +59,10 @@ int board_init(void)
*/
int misc_init_r(void)
{
- gpio_t *gpio1_base = (gpio_t *)OMAP34XX_GPIO1_BASE;
- gpio_t *gpio4_base = (gpio_t *)OMAP34XX_GPIO4_BASE;
- gpio_t *gpio5_base = (gpio_t *)OMAP34XX_GPIO5_BASE;
- gpio_t *gpio6_base = (gpio_t *)OMAP34XX_GPIO6_BASE;
+ struct gpio *gpio1_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ struct gpio *gpio4_base = (struct gpio *)OMAP34XX_GPIO4_BASE;
+ struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
+ struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
power_init_r();
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 51d5cf6..8a79f53 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -58,11 +58,11 @@ static inline void delay(unsigned long loops)
*/
void secure_unlock_mem(void)
{
- pm_t *pm_rt_ape_base = (pm_t *)PM_RT_APE_BASE_ADDR_ARM;
- pm_t *pm_gpmc_base = (pm_t *)PM_GPMC_BASE_ADDR_ARM;
- pm_t *pm_ocm_ram_base = (pm_t *)PM_OCM_RAM_BASE_ADDR_ARM;
- pm_t *pm_iva2_base = (pm_t *)PM_IVA2_BASE_ADDR_ARM;
- sms_t *sms_base = (sms_t *)OMAP34XX_SMS_BASE;
+ struct pm *pm_rt_ape_base = (struct pm *)PM_RT_APE_BASE_ADDR_ARM;
+ struct pm *pm_gpmc_base = (struct pm *)PM_GPMC_BASE_ADDR_ARM;
+ struct pm *pm_ocm_ram_base = (struct pm *)PM_OCM_RAM_BASE_ADDR_ARM;
+ struct pm *pm_iva2_base = (struct pm *)PM_IVA2_BASE_ADDR_ARM;
+ struct sms *sms_base = (struct sms *)OMAP34XX_SMS_BASE;
/* Protection Module Register Target APE (PM_RT) */
writel(UNLOCK_1, pm_rt_ape_base-req_info_permission_1);
@@ -233,7 +233,7 @@ void s_init(void)
* Routine: wait_for_command_complete
* Description: Wait for posting to finish on watchdog
*/
-void wait_for_command_complete(watchdog_t *wd_base)
+void wait_for_command_complete(struct watchdog *wd_base)
{
int pending = 1;
do {
@@ -247,8 +247,8 @@ void wait_for_command_complete(watchdog_t *wd_base)
*/
void
[U-Boot] [PATCHv2 4/4] omap3: use only fixed-size types inside ctrl_structs
replace variable types in ctrl_structs for omap3 by those with
fixed size (u8, u16, u32).
Additional ifndef-protection is needed by examples which do not
compile when including asm/types.h
Signed-off-by: Matthias Ludwig mlud...@ultratronik.de
---
include/asm-arm/arch-omap3/cpu.h | 418 --
1 files changed, 221 insertions(+), 197 deletions(-)
diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-omap3/cpu.h
index 61a833e..b2c8498 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -25,34 +25,40 @@
#ifndef _CPU_H
#define _CPU_H
+#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
+#include asm/types.h
+#endif /* !(__KERNEL_STRICT_NAMES || __ASSEMBLY__) */
+
/* Register offsets of common modules */
/* Control */
+#ifndef __KERNEL_STRICT_NAMES
#ifndef __ASSEMBLY__
struct ctrl {
- unsigned char res1[0xC0];
- unsigned short gpmc_nadv_ale; /* 0xC0 */
- unsigned short gpmc_noe;/* 0xC2 */
- unsigned short gpmc_nwe;/* 0xC4 */
- unsigned char res2[0x22A];
- unsigned int status;/* 0x2F0 */
- unsigned int gpstatus; /* 0x2F4 */
- unsigned char res3[0x08];
- unsigned int rpubkey_0; /* 0x300 */
- unsigned int rpubkey_1; /* 0x304 */
- unsigned int rpubkey_2; /* 0x308 */
- unsigned int rpubkey_3; /* 0x30C */
- unsigned int rpubkey_4; /* 0x310 */
- unsigned char res4[0x04];
- unsigned int randkey_0; /* 0x318 */
- unsigned int randkey_1; /* 0x31C */
- unsigned int randkey_2; /* 0x320 */
- unsigned int randkey_3; /* 0x324 */
- unsigned char res5[0x124];
- unsigned int ctrl_omap_stat;/* 0x44C */
+ u8 res1[0xC0];
+ u16 gpmc_nadv_ale; /* 0xC0 */
+ u16 gpmc_noe; /* 0xC2 */
+ u16 gpmc_nwe; /* 0xC4 */
+ u8 res2[0x22A];
+ u32 status; /* 0x2F0 */
+ u32 gpstatus; /* 0x2F4 */
+ u8 res3[0x08];
+ u32 rpubkey_0; /* 0x300 */
+ u32 rpubkey_1; /* 0x304 */
+ u32 rpubkey_2; /* 0x308 */
+ u32 rpubkey_3; /* 0x30C */
+ u32 rpubkey_4; /* 0x310 */
+ u8 res4[0x04];
+ u32 randkey_0; /* 0x318 */
+ u32 randkey_1; /* 0x31C */
+ u32 randkey_2; /* 0x320 */
+ u32 randkey_3; /* 0x324 */
+ u8 res5[0x124];
+ u32 ctrl_omap_stat; /* 0x44C */
};
#else /* __ASSEMBLY__ */
#define CONTROL_STATUS 0x2F0
#endif /* __ASSEMBLY__ */
+#endif /* __KERNEL_STRICT_NAMES */
/* cpu type */
#define OMAP3503 0x5c00
@@ -60,18 +66,20 @@ struct ctrl {
#define OMAP3525 0x4c00
#define OMAP3530 0x0c00
+#ifndef __KERNEL_STRICT_NAMES
#ifndef __ASSEMBLY__
struct ctrl_id {
- unsigned char res1[0x4];
- unsigned int idcode;/* 0x04 */
- unsigned int prod_id; /* 0x08 */
- unsigned char res2[0x0C];
- unsigned int die_id_0; /* 0x18 */
- unsigned int die_id_1; /* 0x1C */
- unsigned int die_id_2; /* 0x20 */
- unsigned int die_id_3; /* 0x24 */
-} ctrl_id_t;
+ u8 res1[0x4];
+ u32 idcode; /* 0x04 */
+ u32 prod_id;/* 0x08 */
+ u8 res2[0x0C];
+ u32 die_id_0; /* 0x18 */
+ u32 die_id_1; /* 0x1C */
+ u32 die_id_2; /* 0x20 */
+ u32 die_id_3; /* 0x24 */
+};
#endif /* __ASSEMBLY__ */
+#endif /* __KERNEL_STRICT_NAMES */
/* device type */
#define DEVICE_MASK(0x7 8)
@@ -84,47 +92,48 @@ struct ctrl_id {
#define GPMC_BASE (OMAP34XX_GPMC_BASE)
#define GPMC_CONFIG_CS00x60
+#ifndef __KERNEL_STRICT_NAMES
#ifndef __ASSEMBLY__
struct gpmc_cs {
- unsigned int config1; /* 0x00 */
- unsigned int config2; /* 0x04 */
- unsigned int config3; /* 0x08 */
- unsigned int config4; /* 0x0C */
- unsigned int config5; /* 0x10 */
- unsigned int config6; /* 0x14 */
- unsigned int config7; /* 0x18 */
- unsigned int nand_cmd; /* 0x1C */
- unsigned int nand_adr; /* 0x20 */
- unsigned int nand_dat; /* 0x24 */
- unsigned char res[8]; /* blow up to 0x30 byte */
+ u32 config1;/* 0x00 */
+ u32 config2;/* 0x04 */
+ u32 config3;/* 0x08 */
+ u32 config4;/* 0x0C */
+ u32 config5;/* 0x10 */
+ u32 config6;/* 0x14 */
+ u32 config7;/* 0x18 */
+ u32 nand_cmd; /* 0x1C */
+ u32 nand_adr; /* 0x20 */
+ u32
[U-Boot] [PATCHv2 1/4] omap3: embedd gpmc_cs into gpmc config struct
Embedd chip select configuration into struct for gpmc config
instead of having it completely separated as suggested by
Wolfgang Denk on
http://lists.denx.de/pipermail/u-boot/2009-May/052247.html
Attention: this also fixes a missnaming in board/omap3/evm/evm.c
which told to use CS6 but used CS5 in reallity. More info on
http://lists.denx.de/pipermail/u-boot/2009-May/052157.html
Signed-off-by: Matthias Ludwig mlud...@ultratronik.de
---
board/omap3/evm/evm.c | 16 +++---
cpu/arm_cortexa8/omap3/mem.c | 33 --
cpu/arm_cortexa8/omap3/sys_info.c |4 +-
drivers/mtd/nand/omap_gpmc.c | 22 ++-
include/asm-arm/arch-omap3/cpu.h | 40
include/configs/omap3_beagle.h|1 -
include/configs/omap3_evm.h |1 -
include/configs/omap3_overo.h |1 -
include/configs/omap3_pandora.h |1 -
include/configs/omap3_zoom1.h |1 -
10 files changed, 48 insertions(+), 72 deletions(-)
diff --git a/board/omap3/evm/evm.c b/board/omap3/evm/evm.c
index c008c2e..032c93a 100644
--- a/board/omap3/evm/evm.c
+++ b/board/omap3/evm/evm.c
@@ -92,17 +92,17 @@ void set_muxconf_regs(void)
static void setup_net_chip(void)
{
gpio_t *gpio3_base = (gpio_t *)OMAP34XX_GPIO3_BASE;
- gpmc_csx_t *gpmc_cs6_base = (gpmc_csx_t *)GPMC_CONFIG_CS6_BASE;
+ gpmc_t *gpmc = (gpmc_t *)GPMC_BASE;
ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
/* Configure GPMC registers */
- writel(NET_GPMC_CONFIG1, gpmc_cs6_base-config1);
- writel(NET_GPMC_CONFIG2, gpmc_cs6_base-config2);
- writel(NET_GPMC_CONFIG3, gpmc_cs6_base-config3);
- writel(NET_GPMC_CONFIG4, gpmc_cs6_base-config4);
- writel(NET_GPMC_CONFIG5, gpmc_cs6_base-config5);
- writel(NET_GPMC_CONFIG6, gpmc_cs6_base-config6);
- writel(NET_GPMC_CONFIG7, gpmc_cs6_base-config7);
+ writel(NET_GPMC_CONFIG1, gpmc-cs[5].config1);
+ writel(NET_GPMC_CONFIG2, gpmc-cs[5].config2);
+ writel(NET_GPMC_CONFIG3, gpmc-cs[5].config3);
+ writel(NET_GPMC_CONFIG4, gpmc-cs[5].config4);
+ writel(NET_GPMC_CONFIG5, gpmc-cs[5].config5);
+ writel(NET_GPMC_CONFIG6, gpmc-cs[5].config6);
+ writel(NET_GPMC_CONFIG7, gpmc-cs[5].config7);
/* Enable off mode for NWE in PADCONF_GPMC_NWE register */
writew(readw(ctrl_base -gpmc_nwe) | 0x0E00, ctrl_base-gpmc_nwe);
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 3cc22c4..965de3a 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -51,7 +51,6 @@ static u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG6, 0
};
-gpmc_csx_t *nand_cs_base;
gpmc_t *gpmc_cfg_base;
#if defined(CONFIG_ENV_IS_IN_NAND)
@@ -72,8 +71,6 @@ static u32 gpmc_onenand[GPMC_MAX_REG] = {
ONENAND_GPMC_CONFIG6, 0
};
-gpmc_csx_t *onenand_cs_base;
-
#if defined(CONFIG_ENV_IS_IN_ONENAND)
#define GPMC_CS 0
#else
@@ -195,21 +192,21 @@ void do_sdrc_init(u32 cs, u32 early)
writel(0, sdrc_base-cs[cs].mcfg);
}
-void enable_gpmc_config(u32 *gpmc_config, gpmc_csx_t *gpmc_cs_base, u32 base,
+void enable_gpmc_cs_config(u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
u32 size)
{
- writel(0, gpmc_cs_base-config7);
+ writel(0, cs-config7);
sdelay(1000);
/* Delay for settling */
- writel(gpmc_config[0], gpmc_cs_base-config1);
- writel(gpmc_config[1], gpmc_cs_base-config2);
- writel(gpmc_config[2], gpmc_cs_base-config3);
- writel(gpmc_config[3], gpmc_cs_base-config4);
- writel(gpmc_config[4], gpmc_cs_base-config5);
- writel(gpmc_config[5], gpmc_cs_base-config6);
+ writel(gpmc_config[0], cs-config1);
+ writel(gpmc_config[1], cs-config2);
+ writel(gpmc_config[2], cs-config3);
+ writel(gpmc_config[3], cs-config4);
+ writel(gpmc_config[4], cs-config5);
+ writel(gpmc_config[5], cs-config6);
/* Enable the config */
writelsize 0xF) 8) | ((base 24) 0x3F) |
- (1 6)), gpmc_cs_base-config7);
+ (1 6)), cs-config7);
sdelay(2000);
}
@@ -223,7 +220,6 @@ void gpmc_init(void)
/* putting a blanket check on GPMC based on ZeBu for now */
u32 *gpmc_config = NULL;
gpmc_t *gpmc_base = (gpmc_t *)GPMC_BASE;
- gpmc_csx_t *gpmc_cs_base = (gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
u32 base = 0;
u32 size = 0;
u32 f_off = CONFIG_SYS_MONITOR_LEN;
@@ -242,17 +238,16 @@ void gpmc_init(void)
* Disable the GPMC0 config set by ROM code
* It conflicts with our MPDB (both at 0x0800)
*/
- writel(0, gpmc_cs_base-config7);
+ writel(0, gpmc_base-cs[0].config7);
sdelay(1000);
#if defined(CONFIG_CMD_NAND) /* CS 0 */
gpmc_config = gpmc_m_nand;
gpmc_cfg_base = gpmc_base;
- nand_cs_base =
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan Roese, In message 200905120639.24172...@denx.de you wrote: OK, here we go: Canyonlands (using NAND) without this patch: textdata bss dec hex filename 339324 20044 336384 695752 a9dc8 ./u-boot and with this patch: textdata bss dec hex filename 339796 20044 336384 696224 a9fa0 ./u-boot So it's 472 bytes on this platform. Thanks - that's indeed not much. Is my understanding correct that the effect on NOR-only systems is even smaller, it at all visible? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Many aligators will be slain, but the swamp will remain. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot kernel rejects filesystem
Hi All,
I am very new to u-boot.
I have kernel image, which I loaded to NOR of my board and with bootm,
control passes to kernel and it starts booting.
There is panic in kernel: since it can not find the file-system. I am
afraid, I did make trivial mistake.
I have flashed squashfs filesystem image to NOR @ address NOR1 I did not
define any partition.
I do not have MTD support.
Now I tried booting like after setting
setenv kernel_addr 0xBF06Note this has u-boot hdr generated
form mkimage
setenv ramdisk_addr 0xBF26Note this does not have u-boot hdr
generated form mkimage
setenv bootargs 'filesystem=squashfs'
I do bootm ${kernel_addr} ${ramdisk_addr}
I do get error from U_BOOT that :
*Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
*I am sure that I have done something wrong in this process:
Few Questions which I could not find the answer:
1. Can I nor-flash the image without u-boot hdr.
2. Is it necessary to have MTD partition defined.
3. Do we have any document which specify the boot arguments in context of
U_BOOT. I tried denx website. I could not figure out much. May be I do not
what to search for.
Any help would be highly appreciated.
Regards,
Bharat
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
Hi, how do set a mac for NFS Rootfs? use initramfs don't you think it's overkill to use a initramfs just for set a mac address?? no, i think it's perfectly reasonable. and considering you have no other option here that'll get merged ... Can you please explain to me, why you think it to be reasonable to demand providing an initramfs in the order of 100s of k to set an attribute of a hardware device which has its own driver? Apart from being constantly repeated, I do not understand this reasoning at all. My (old-school) belief was that an operating system deals with abstracting the hardware thus userspace does not need to (nor should) know too many hw details. Knowing that there is not a clear distinction line, I still fail to see why a mac address of a network interface should be handled by userspace. Can someone enlighten me here? Thanks Detlev -- Ftpd never switches uid and euid, it uses setfsuid(2) instead. The main reason is that uid switching has been exploited in several breakins, but the sheer ugliness of uid switching counts too. -- pure-ftpd(8) -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot kernel rejects filesystem
Hi Bharat,
I am very new to u-boot.
Welcome aboard!
I have kernel image, which I loaded to NOR of my board and with bootm,
control passes to kernel and it starts booting.
There is panic in kernel: since it can not find the file-system. I am
afraid, I did make trivial mistake.
I have flashed squashfs filesystem image to NOR @ address NOR1 I did not
define any partition.
I do not have MTD support.
Now I tried booting like after setting
setenv kernel_addr 0xBF06Note this has u-boot hdr generated
form mkimage
setenv ramdisk_addr 0xBF26Note this does not have u-boot hdr
generated form mkimage
setenv bootargs 'filesystem=squashfs'
I do bootm ${kernel_addr} ${ramdisk_addr}
This is not correct. The second argument for bootm is a real ramdisk
or initrd in Linux speak. The squashfs filesystem that you use needs
a MTD device and thus can not be passed in this way.
I do get error from U_BOOT that :
*Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
That's to be expected, because U-Boot wants the initrd to be wrapped
with mkimage also - which is irrelevant in your case though.
*I am sure that I have done something wrong in this process:
Few Questions which I could not find the answer:
1. Can I nor-flash the image without u-boot hdr.
Sure you can. You should flash it to the address of a partition defined
inside of the Linux MTD subsystem.
2. Is it necessary to have MTD partition defined.
You will of course need to define MTD partitions inside of Linux -
whereas in U-Boot this is optional.
3. Do we have any document which specify the boot arguments in context of
U_BOOT. I tried denx website. I could not figure out much. May be I do not
what to search for.
What exactly do you mean by boot arguments?
Any help would be highly appreciated.
To solve your problem, do the following:
1. Find out which MTD device (in Linux) you want to use to hold the
squashfs image. I'll assume mtd0 below.
2. If you do not want to use partitioning in U-Boot then determine the
physical address that this device maps to
3. Flash the squasfs image to that address
4. Be sure to include root=/dev/mtdblock0 on the Linux command line so
Linux knows where it finds its rootfs.
Cheers
Detlev
--
We support democracy, but that doesn't mean we have to support
governments that get elected as a result of democracy.
-- George W. Bush - March 30, 2006
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Data transfer through Ethernet in u-boot.
Wolfgang Denk wrote: Dear prathika, please do not top post / full quote. Make sure to read and understand http://www.netmeister.org/news/learn2quote.html In message 4a08080e.6030...@deeopl.com you wrote: You have mentioned to add the test code to the existing POST framework. In my hardware, I have CAN controller interfaced to SPI interface, SPI DACs, parallel ADCs, 1553B controller interfaced to EBC. I have a CPLD to generate chip selects to these ICs. If this test code will be useful, please let me to know how to add it to the POST framework. Well, study the existing code and the documentation, than add your test code. I understood that tftp command in u-boot has been coded only for receiving data from the PC and not to transmit, to PC.If this is the case should i add the transmit code to the tftp command? Yes. Even if I use this command for data transfer, what are the requirements for the application in PC side? I don't understand this question? --Here, I will be connecting my board through a GUI to a Windows PC. I will interact using this GUI. Actually if I use tftp command for file transfer, do I need some tftp client or server running on my Windows PC? Thanks Regards, Prathika R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
On Tuesday 12 May 2009 04:48:28 Detlev Zundel wrote: how do set a mac for NFS Rootfs? use initramfs don't you think it's overkill to use a initramfs just for set a mac address?? no, i think it's perfectly reasonable. and considering you have no other option here that'll get merged ... Can you please explain to me, why you think it to be reasonable to demand providing an initramfs in the order of 100s of k to set an attribute of a hardware device which has its own driver? Apart from being constantly repeated, I do not understand this reasoning at all. My (old-school) belief was that an operating system deals with abstracting the hardware thus userspace does not need to (nor should) know too many hw details. Knowing that there is not a clear distinction line, I still fail to see why a mac address of a network interface should be handled by userspace. Can someone enlighten me here? no one said it must be done in userspace, that was just one method for doing it. read the FAQ for other possibilities. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Timeout in tftp.c
Hello, The timeout for lost packages in tftp.c is defined to 5000 msecs. But when setting the timeout get_timer(0) is called in NetSetTimeout in net.c. But on AT91 the timer code returns usecs and not msecs resulting in a timeout of 5 ms instead of 5 secs, which is kind of short. I looked in the timer code of other ARM-based platforms and they seem to use usec-based timers as well. Of course I can change the defined timeout in tftp.c to one second or so, but that doesn't seem to be the right way to solve this issue. Any suggestions or ideas or do I miss something here? Kind regards Achim -- product manager email:aehrl...@taskit.de Tel.: ++49 30 611295-25 Fax: ++49 30 611295-11 -- taskit GmbH Seelenbinderstr. 33 | D-12555 Berlin web:http://www.taskit.de Amtsgericht Charlottenburg: 93HRB39014 Managing director: Thorsten Raulfs -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mtd: Add MTD concat support to concatenate multiple MTD NOR devices
This patch adds concatenation support to the U-Boot MTD infrastructure.
By enabling CONFIG_MTD_CONCAT this MTD CFI wrapper will concatenate
all found NOR devices into one single MTD device. This can be used by
e.g by UBI to access a partition that spans over multiple NOR chips.
Signed-off-by: Stefan Roese s...@denx.de
---
v2:
- Using #ifdef's instead of __attribute__((unused)) for variable
declaration.
drivers/mtd/Makefile |1 +
drivers/mtd/cfi_mtd.c | 79 +-
drivers/mtd/mtdconcat.c| 807
include/linux/mtd/compat.h | 12 +-
include/linux/mtd/concat.h | 21 ++
5 files changed, 915 insertions(+), 5 deletions(-)
create mode 100644 drivers/mtd/mtdconcat.c
create mode 100644 include/linux/mtd/concat.h
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index ed3f91e..19dc02b 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libmtd.a
COBJS-$(CONFIG_MTD_PARTITIONS) += mtdcore.o mtdpart.o
+COBJS-$(CONFIG_MTD_CONCAT) += mtdconcat.o
COBJS-$(CONFIG_HAS_DATAFLASH) += at45.o
COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o
COBJS-$(CONFIG_FLASH_CFI_MTD) += cfi_mtd.o
diff --git a/drivers/mtd/cfi_mtd.c b/drivers/mtd/cfi_mtd.c
index a0a15da..c7e357b 100644
--- a/drivers/mtd/cfi_mtd.c
+++ b/drivers/mtd/cfi_mtd.c
@@ -25,14 +25,19 @@
#include common.h
#include flash.h
+#include malloc.h
#include asm/errno.h
#include linux/mtd/mtd.h
+#include linux/mtd/concat.h
extern flash_info_t flash_info[];
static struct mtd_info cfi_mtd_info[CONFIG_SYS_MAX_FLASH_BANKS];
static char cfi_mtd_names[CONFIG_SYS_MAX_FLASH_BANKS][16];
+#ifdef CONFIG_MTD_CONCAT
+static char c_mtd_name[16];
+#endif
static int cfi_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
{
@@ -145,16 +150,68 @@ static int cfi_mtd_unlock(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
static int cfi_mtd_set_erasesize(struct mtd_info *mtd, flash_info_t *fi)
{
int sect_size = 0;
+ int sect_size_old = 0;
int sect;
+ int regions = 0;
+ int numblocks = 0;
+ ulong offset = 0;
+ ulong base_addr = fi-start[0];
/*
-* Select the largest sector size as erasesize (e.g. for UBI)
+* First detect the number of eraseregions so that we can allocate
+* the array of eraseregions correctly
*/
for (sect = 0; sect fi-sector_count; sect++) {
+ if (sect_size_old != flash_sector_size(fi, sect))
+ regions++;
+ sect_size_old = flash_sector_size(fi, sect);
+ }
+
+ mtd-eraseregions = malloc(sizeof(struct mtd_erase_region_info) *
regions);
+
+ /*
+* Now detect the largest sector and fill the eraseregions
+*/
+ sect_size_old = 0;
+ regions = 0;
+ for (sect = 0; sect fi-sector_count; sect++) {
+ if ((sect_size_old != flash_sector_size(fi, sect))
+ (sect_size_old != 0)) {
+ mtd-eraseregions[regions].offset = offset - base_addr;
+ mtd-eraseregions[regions].erasesize = sect_size_old;
+ mtd-eraseregions[regions].numblocks = numblocks;
+
+ /* Now start counting the next eraseregions */
+ numblocks = 0;
+ regions++;
+ } else {
+ numblocks++;
+ }
+
+ if (sect_size_old != flash_sector_size(fi, sect))
+ offset = fi-start[sect];
+
+ /*
+* Select the largest sector size as erasesize (e.g. for UBI)
+*/
if (flash_sector_size(fi, sect) sect_size)
sect_size = flash_sector_size(fi, sect);
+
+ sect_size_old = flash_sector_size(fi, sect);
}
+ /*
+* Set the last region
+*/
+ mtd-eraseregions[regions].offset = offset - base_addr;
+ mtd-eraseregions[regions].erasesize = sect_size_old;
+ mtd-eraseregions[regions].numblocks = numblocks + 1;
+
+ if (regions)
+ mtd-numeraseregions = regions + 1;
+ else
+ mtd-numeraseregions = 0;
+
mtd-erasesize = sect_size;
return 0;
@@ -165,6 +222,8 @@ int cfi_mtd_init(void)
struct mtd_info *mtd;
flash_info_t *fi;
int error, i;
+ int devices_found = 0;
+ struct mtd_info *mtd_list[CONFIG_SYS_MAX_FLASH_BANKS];
for (i = 0; i CONFIG_SYS_MAX_FLASH_BANKS; i++) {
fi = flash_info[i];
@@ -193,7 +252,25 @@ int cfi_mtd_init(void)
if (add_mtd_device(mtd))
return -ENOMEM;
+
+ mtd_list[devices_found++] = mtd;
+ }
+
+#ifdef CONFIG_MTD_CONCAT
+ if (devices_found 1) {
+ /*
+* We detected multiple devices.
[U-Boot] [PATCH] mtd: MTD related config header changes (mtdparts command)
By changing the cmd_mtdparts to only use the MTD infrastructure and not the direct interface to the CFI NOR FLASH driver we now need to add the MTD infrastructure to all boards using those mtdparts commands. This patch adds those components: CONFIG_MTD_DEVICE (for all FLASH types) plus CONFIG_FLASH_CFI_MTD (for NOR FLASH) To all board maintainers: Please test this on your platforms and report any problems/issues found. Thanks. Signed-off-by: Stefan Roese s...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Ron Madrid i...@sheldoninst.com Cc: Georg Schardt scha...@team-ctech.de Cc: Michal Simek mon...@monstr.eu Cc: Ladislav Michl la...@linux-mips.org Cc: Martin Krause martin.kra...@tqs.de Cc: Gary Jennejohn g...@denx.de Cc: Ricardo Ribalda ricardo.riba...@uam.es --- include/configs/BC3450.h |2 ++ include/configs/FPS850L.h|2 ++ include/configs/FPS860L.h|2 ++ include/configs/SIMPC8313.h |1 + include/configs/TB5200.h |2 ++ include/configs/TQM5200.h|2 ++ include/configs/TQM823L.h|2 ++ include/configs/TQM823M.h|2 ++ include/configs/TQM834x.h|2 ++ include/configs/TQM850L.h|2 ++ include/configs/TQM850M.h|2 ++ include/configs/TQM855L.h|2 ++ include/configs/TQM855M.h|2 ++ include/configs/TQM85xx.h|2 ++ include/configs/TQM860L.h|2 ++ include/configs/TQM860M.h|2 ++ include/configs/TQM862L.h|2 ++ include/configs/TQM862M.h|2 ++ include/configs/TQM866M.h|2 ++ include/configs/apollon.h|1 + include/configs/cm5200.h |2 ++ include/configs/fx12mm.h |2 ++ include/configs/idmr.h |2 ++ include/configs/microblaze-generic.h |2 ++ include/configs/motionpro.h |2 ++ include/configs/mx1fs2.h |2 ++ include/configs/netstar.h|2 ++ include/configs/omap3_beagle.h |1 + include/configs/qong.h |2 ++ include/configs/smmaco4.h|2 ++ include/configs/trab.h |2 ++ include/configs/vct.h|1 + include/configs/virtlab2.h |2 ++ include/configs/voiceblue.h |2 ++ include/configs/xilinx-ppc.h |2 ++ 35 files changed, 66 insertions(+), 0 deletions(-) diff --git a/include/configs/BC3450.h b/include/configs/BC3450.h index 9934f29..8c5a742 100644 --- a/include/configs/BC3450.h +++ b/include/configs/BC3450.h @@ -347,6 +347,8 @@ /* Dynamic MTD partition support */ #define CONFIG_CMD_MTDPARTS +#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ +#define CONFIG_FLASH_CFI_MTD #define MTDIDS_DEFAULT nor0=TQM5200-0 #define MTDPARTS_DEFAULT mtdparts=TQM5200-0:640k(firmware),\ 1408k(kernel),\ diff --git a/include/configs/FPS850L.h b/include/configs/FPS850L.h index f152230..aceecd8 100644 --- a/include/configs/FPS850L.h +++ b/include/configs/FPS850L.h @@ -217,6 +217,8 @@ * Dynamic MTD partition support */ #define CONFIG_CMD_MTDPARTS +#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ +#define CONFIG_FLASH_CFI_MTD #define MTDIDS_DEFAULT nor0=TQM8xxL-0 #define MTDPARTS_DEFAULT mtdparts=TQM8xxL-0:256k(u-boot), \ diff --git a/include/configs/FPS860L.h b/include/configs/FPS860L.h index 5eaed84..4a61d7c 100644 --- a/include/configs/FPS860L.h +++ b/include/configs/FPS860L.h @@ -217,6 +217,8 @@ * Dynamic MTD partition support */ #define CONFIG_CMD_MTDPARTS +#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ +#define CONFIG_FLASH_CFI_MTD #define MTDIDS_DEFAULT nor0=TQM8xxL-0 #define MTDPARTS_DEFAULT mtdparts=TQM8xxL-0:256k(u-boot), \ diff --git a/include/configs/SIMPC8313.h b/include/configs/SIMPC8313.h index 88ea7c7..8d1e95b 100644 --- a/include/configs/SIMPC8313.h +++ b/include/configs/SIMPC8313.h @@ -190,6 +190,7 @@ /* mtdparts command line support */ #define CONFIG_CMD_MTDPARTS +#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ #define MTDIDS_DEFAULT nand0=nand0 #define MTDPARTS_DEFAULT mtdparts=nand0:2M(u-boot),6M(kernel),-(jffs2) diff --git a/include/configs/TB5200.h b/include/configs/TB5200.h index 92b4fa5..3438aba 100644 --- a/include/configs/TB5200.h +++ b/include/configs/TB5200.h @@ -276,6 +276,8 @@ /* Dynamic MTD partition support */ #define CONFIG_CMD_MTDPARTS +#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ +#define CONFIG_FLASH_CFI_MTD #define MTDIDS_DEFAULT nor0=TQM5200-0 #if defined(CONFIG_TQM5200_B) #define MTDPARTS_DEFAULT mtdparts=TQM5200-0:768k(firmware),\ diff --git a/include/configs/TQM5200.h
[U-Boot] [PATCH] mtd: Introduce CONFIG_MTD_DEVICE to select compilation of mtdcore.o
This new define enables mtdcore.c compilation and with this we can select the MTD device infrastructure needed for the reworked mtdparts command. We now have the 2 MTD infrastructure defines, CONFIG_MTD_DEVICE and CONFIG_MTD_PARTITIONS. CONFIG_MTD_DEVICE is needed (as explained above) for the mtdparts command and CONFIG_MTD_PARTITIONS is needed for UBI. Signed-off-by: Stefan Roese s...@denx.de Cc: Scott Wood scottw...@freescale.com --- README | 11 +++ drivers/mtd/Makefile|3 ++- drivers/mtd/nand/nand.c |2 +- drivers/mtd/onenand/onenand_uboot.c |2 +- 4 files changed, 15 insertions(+), 3 deletions(-) diff --git a/README b/README index 75fc4b7..561c100 100644 --- a/README +++ b/README @@ -1846,6 +1846,17 @@ The following options need to be configured: These options enable and control the auto-update feature; for a more detailed description refer to doc/README.update. +- MTD Support (mtdparts command, UBI support) + CONFIG_MTD_DEVICE + + Adds the MTD device infrastructure from the Linux kernel. + Needed for mtdparts command support. + + CONFIG_MTD_PARTITIONS + + Adds the MTD partitioning infrastructure from the Linux + kernel. Needed for UBI support. + Legacy uImage format: Arg Where When diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 19dc02b..754d648 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -25,7 +25,8 @@ include $(TOPDIR)/config.mk LIB:= $(obj)libmtd.a -COBJS-$(CONFIG_MTD_PARTITIONS) += mtdcore.o mtdpart.o +COBJS-$(CONFIG_MTD_DEVICE) += mtdcore.o +COBJS-$(CONFIG_MTD_PARTITIONS) += mtdpart.o COBJS-$(CONFIG_MTD_CONCAT) += mtdconcat.o COBJS-$(CONFIG_HAS_DATAFLASH) += at45.o COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c index d369115..9065fa9 100644 --- a/drivers/mtd/nand/nand.c +++ b/drivers/mtd/nand/nand.c @@ -57,7 +57,7 @@ static void nand_init_chip(struct mtd_info *mtd, struct nand_chip *nand, else mtd-name += gd-reloc_off; -#ifdef CONFIG_MTD_PARTITIONS +#ifdef CONFIG_MTD_DEVICE /* * Add MTD device so that we can reference it later * via the mtdcore infrastructure (e.g. ubi). diff --git a/drivers/mtd/onenand/onenand_uboot.c b/drivers/mtd/onenand/onenand_uboot.c index a95b922..9823b5b 100644 --- a/drivers/mtd/onenand/onenand_uboot.c +++ b/drivers/mtd/onenand/onenand_uboot.c @@ -43,7 +43,7 @@ void onenand_init(void) puts(OneNAND: ); print_size(onenand_mtd.size, \n); -#ifdef CONFIG_MTD_PARTITIONS +#ifdef CONFIG_MTD_DEVICE /* * Add MTD device so that we can reference it later * via the mtdcore infrastructure (e.g. ubi). -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] cmd_mtdparts: Move to common handling of FLASH devices via MTD layer
This patch removes all references to the direct CFI FLASH interface
(via flash_info[]). Now that all FLASH types currently handled in
mtdparts are available (if selected, see below) via the MTD infrastructure.
This is NOR, NAND and OneNAND right now. This can be achieved by defining
the following options:
CONFIG_MTD_DEVICE (for all FLASH types)
plus
CONFIG_FLASH_CFI_MTD (for NOR FLASH)
So we need to add those defines to the board config headers currently
using the mtdparts commands. This is done via another patch, so
we shouldn't break mtdparts compatibility.
One big advantage from this solution is that the cmd_mtdparts.c is
*much* cleaner now. Lot's of #ifdef's are removed and the code itself
is smaller. Additionally the newly added MDT concatenation feature
can new be used via the mtdparts infrastructure and therefor via
UBI etc.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Ladislav Michl la...@linux-mips.org
Cc: Scott Wood scottw...@freescale.com
---
v2:
- Use CONFIG_MTD_DEVICE instead of CONFIG_MTD_PARTITIONS in commit
text.
common/cmd_mtdparts.c | 240
1 files changed, 80 insertions(+), 160 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index e7b6acc..e94ca1b 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -90,7 +90,8 @@
#include jffs2/load_kernel.h
#include linux/list.h
#include linux/ctype.h
-#include cramfs/cramfs_fs.h
+#include linux/err.h
+#include linux/mtd/mtd.h
#if defined(CONFIG_CMD_NAND)
#ifdef CONFIG_NAND_LEGACY
@@ -102,7 +103,6 @@
#endif
#if defined(CONFIG_CMD_ONENAND)
-#include linux/mtd/mtd.h
#include linux/mtd/onenand.h
#include onenand_uboot.h
#endif
@@ -303,137 +303,91 @@ static void current_save(void)
}
/**
- * Performs sanity check for supplied NOR flash partition. Table of existing
- * NOR flash devices is searched and partition device is located. Alignment
- * with the granularity of NOR flash sectors is verified.
+ * Performs sanity check for supplied flash partition.
+ * Table of existing MTD flash devices is searched and partition device
+ * is located. Alignment with the granularity of nand erasesize is verified.
*
* @param id of the parent device
* @param part partition to validate
* @return 0 if partition is valid, 1 otherwise
*/
-static int part_validate_nor(struct mtdids *id, struct part_info *part)
+static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
{
-#if defined(CONFIG_CMD_FLASH)
- /* info for FLASH chips */
- extern flash_info_t flash_info[];
- flash_info_t *flash;
- int offset_aligned;
- u32 end_offset, sector_size = 0;
- int i;
-
- flash = flash_info[id-num];
-
- /* size of last sector */
- part-sector_size = flash-size -
- (flash-start[flash-sector_count-1] - flash-start[0]);
-
- offset_aligned = 0;
- for (i = 0; i flash-sector_count; i++) {
- if ((flash-start[i] - flash-start[0]) == part-offset) {
- offset_aligned = 1;
- break;
- }
- }
- if (offset_aligned == 0) {
- printf(%s%d: partition (%s) start offset alignment
incorrect\n,
- MTD_DEV_TYPE(id-type), id-num, part-name);
+ struct mtd_info *mtd;
+ char mtd_dev[16];
+ int i, j;
+ ulong start;
+
+ sprintf(mtd_dev, %s%d, MTD_DEV_TYPE(id-type), id-num);
+ mtd = get_mtd_device_nm(mtd_dev);
+ if (IS_ERR(mtd)) {
+ printf(Partition %s not found on device %s!\n, part-name,
mtd_dev);
return 1;
}
- end_offset = part-offset + part-size;
- offset_aligned = 0;
- for (i = 0; i flash-sector_count; i++) {
- if (i) {
- sector_size = flash-start[i] - flash-start[i-1];
- if (part-sector_size sector_size)
- part-sector_size = sector_size;
- }
- if ((flash-start[i] - flash-start[0]) == end_offset)
- offset_aligned = 1;
- }
-
- if (offset_aligned || flash-size == end_offset)
- return 0;
-
- printf(%s%d: partition (%s) size alignment incorrect\n,
- MTD_DEV_TYPE(id-type), id-num, part-name);
-#endif
- return 1;
-}
-
-/**
- * Performs sanity check for supplied NAND flash partition. Table of existing
- * NAND flash devices is searched and partition device is located. Alignment
- * with the granularity of nand erasesize is verified.
- *
- * @param id of the parent device
- * @param part partition to validate
- * @return 0 if partition is valid, 1 otherwise
- */
-static int part_validate_nand(struct mtdids *id, struct part_info *part)
-{
-#if defined(CONFIG_CMD_NAND)
- /* info for NAND chips */
- nand_info_t *nand;
+ part-sector_size = mtd-erasesize;
- nand
[U-Boot] Repository with latest (mostly) MTD related changes for testing
Hi, I pushed my latest patches, mostly MTD related, to a branch in the u-boot-cfi- flash repository. This is not intended for merging into mainline, but meant for testing these changes on the affected boards. So please go ahead and pull this branch and test it on your board and let me know if there are any problems. Thanks, Stefan The following changes since commit fbe7eff021399175ef7d9d57f44145587c4e9a51: Mike Frysinger (1): tools/envcrc: add --binary option to export embedded env are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git mtd-rework Stefan Roese (8): cmd_flash updates: Remove unneeded CONFIG_CMD_JFFS2 lib_arch/board.c: Move malloc initialization before flash_init() cfi_mtd: Fix bug in last sector detection mtd: Update MTD infrastructure to support 64bit device size mtd: Add MTD concat support to concatenate multiple MTD NOR devices mtd: Introduce CONFIG_MTD_DEVICE to select compilation of mtdcore.o cmd_mtdparts: Move to common handling of FLASH devices via MTD layer mtd: MTD related config header changes (mtdparts command) README | 11 + common/cmd_flash.c | 12 +- common/cmd_mtdparts.c| 240 --- common/cmd_onenand.c |6 +- common/env_onenand.c |2 +- drivers/mtd/Makefile |4 +- drivers/mtd/cfi_mtd.c| 92 - drivers/mtd/mtdconcat.c | 807 ++ drivers/mtd/mtdpart.c| 488 +--- drivers/mtd/nand/nand.c |2 +- drivers/mtd/nand/nand_util.c | 11 +- drivers/mtd/onenand/onenand_uboot.c |2 +- include/configs/BC3450.h |2 + include/configs/FPS850L.h|2 + include/configs/FPS860L.h|2 + include/configs/SIMPC8313.h |1 + include/configs/TB5200.h |2 + include/configs/TQM5200.h|2 + include/configs/TQM823L.h|2 + include/configs/TQM823M.h|2 + include/configs/TQM834x.h|2 + include/configs/TQM850L.h|2 + include/configs/TQM850M.h|2 + include/configs/TQM855L.h|2 + include/configs/TQM855M.h|2 + include/configs/TQM85xx.h|2 + include/configs/TQM860L.h|2 + include/configs/TQM860M.h|2 + include/configs/TQM862L.h|2 + include/configs/TQM862M.h|2 + include/configs/TQM866M.h|2 + include/configs/apollon.h|1 + include/configs/cm5200.h |2 + include/configs/fx12mm.h |2 + include/configs/idmr.h |2 + include/configs/microblaze-generic.h |2 + include/configs/motionpro.h |2 + include/configs/mx1fs2.h |2 + include/configs/netstar.h|2 + include/configs/omap3_beagle.h |1 + include/configs/qong.h |2 + include/configs/smmaco4.h|2 + include/configs/trab.h |2 + include/configs/vct.h|1 + include/configs/virtlab2.h |2 + include/configs/voiceblue.h |2 + include/configs/xilinx-ppc.h |2 + include/linux/mtd/compat.h | 12 +- include/linux/mtd/concat.h | 21 + include/linux/mtd/mtd.h | 29 +- lib_arm/board.c |6 +- lib_blackfin/board.c |7 +- lib_m68k/board.c |8 +- lib_mips/board.c |8 +- lib_nios/board.c |6 +- lib_nios2/board.c|6 +- lib_ppc/board.c |8 +- lib_sh/board.c |2 +- lib_sparc/board.c|9 +- 59 files changed, 1377 insertions(+), 488 deletions(-) create mode 100644 drivers/mtd/mtdconcat.c create mode 100644 include/linux/mtd/concat.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MPC8260: fixup device tree by property instead of path
cpu/mpc8260/cpu.c used to use do_fixup_by_path_u32() to update the
clock frequencies in the device tree, using a CPU path
/cpus/OF_CPU, with OF_CPU beind defined in the board config file.
However, this does not work when one board config file (here:
MPC8260ADS.h) is intended to be used for several diffrent CPUs and
therefor contains a generic definition like c...@0, as the device
trees that will then be loaded will contain specific names like
PowerPC,8...@0.
We switch to using do_fixup_by_prop_u32() instead, so we can search
for device_type=cpu, as it is done in other architectures, too.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Heiko Schocher h...@denx.de
---
v2: Fix typo in Heiko's name.
Heiko, could you please test if this works with mgcoge, too?
cpu/mpc8260/cpu.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/cpu/mpc8260/cpu.c b/cpu/mpc8260/cpu.c
index d4622ca..17e6248 100644
--- a/cpu/mpc8260/cpu.c
+++ b/cpu/mpc8260/cpu.c
@@ -304,8 +304,6 @@ void watchdog_reset (void)
#if defined(CONFIG_OF_LIBFDT) defined (CONFIG_OF_BOARD_SETUP)
void ft_cpu_setup (void *blob, bd_t *bd)
{
- char * cpu_path = /cpus/ OF_CPU;
-
#if defined(CONFIG_HAS_ETH0) || defined(CONFIG_HAS_ETH1) ||\
defined(CONFIG_HAS_ETH2) || defined(CONFIG_HAS_ETH3)
fdt_fixup_ethernet(blob);
@@ -314,9 +312,12 @@ void ft_cpu_setup (void *blob, bd_t *bd)
do_fixup_by_compat_u32(blob, fsl,cpm2-brg,
clock-frequency, bd-bi_brgfreq, 1);
- do_fixup_by_path_u32(blob, cpu_path, bus-frequency, bd-bi_busfreq,
1);
- do_fixup_by_path_u32(blob, cpu_path, timebase-frequency, OF_TBCLK, 1);
- do_fixup_by_path_u32(blob, cpu_path, clock-frequency, bd-bi_intfreq,
1);
+ do_fixup_by_prop_u32(blob, device_type, cpu, 4,
+ bus-frequency, bd-bi_busfreq, 1);
+ do_fixup_by_prop_u32(blob, device_type, cpu, 4,
+ timebase-frequency, OF_TBCLK, 1);
+ do_fixup_by_prop_u32(blob, device_type, cpu, 4,
+ clock-frequency, bd-bi_intfreq, 1);
}
#endif /* CONFIG_OF_LIBFDT */
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
Hi Mike, On Tuesday 12 May 2009 04:48:28 Detlev Zundel wrote: how do set a mac for NFS Rootfs? use initramfs don't you think it's overkill to use a initramfs just for set a mac address?? no, i think it's perfectly reasonable. and considering you have no other option here that'll get merged ... Can you please explain to me, why you think it to be reasonable to demand providing an initramfs in the order of 100s of k to set an attribute of a hardware device which has its own driver? Apart from being constantly repeated, I do not understand this reasoning at all. My (old-school) belief was that an operating system deals with abstracting the hardware thus userspace does not need to (nor should) know too many hw details. Knowing that there is not a clear distinction line, I still fail to see why a mac address of a network interface should be handled by userspace. Can someone enlighten me here? no one said it must be done in userspace, that was just one method for doing it. read the FAQ for other possibilities. No you lost me completely. The question cited above was whether you find it plausible to use initramfs - and thus userspace - to set a mac address. You answered that you find this plausible. This is what I do not understand. I never ran across this outside of linux arm where people seriously repeat the statement over and over that a whole initramfs with an initial userspace and a pivot_root is plausible for nfs root whilst patches of a few lines float around doing the same in the kernel. Now proof by repetition is not my preferred form of understanding a problem, so I was asking for an explanation from someone arguing along the same lines. Cheers Detlev -- We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely. --- Oscar Wilde -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: MTD related config header changes (mtdparts command)
Hi Stefan, By changing the cmd_mtdparts to only use the MTD infrastructure and not the direct interface to the CFI NOR FLASH driver we now need to add the MTD infrastructure to all boards using those mtdparts commands. This patch adds those components: CONFIG_MTD_DEVICE (for all FLASH types) plus CONFIG_FLASH_CFI_MTD (for NOR FLASH) To all board maintainers: Please test this on your platforms and report any problems/issues found. Thanks. Signed-off-by: Stefan Roese s...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Ron Madrid i...@sheldoninst.com Cc: Georg Schardt scha...@team-ctech.de Cc: Michal Simek mon...@monstr.eu Cc: Ladislav Michl la...@linux-mips.org Cc: Martin Krause martin.kra...@tqs.de Cc: Gary Jennejohn g...@denx.de There is a typo here, you meant ga...@denx.de. Cheers Detlev -- Programming X-Windows is like trying to find the square root of pi using roman numerals. -- The UNIX Haters Handbook -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] start.s file
Hi Deepak, In the quest of finding the code for relocation i have reached the start.s file present in u-boot-1.1.6\cpu\mpc83xx\ folder. This is old code you're looking at. Best would be to look at current code although this doesn't help here. Even its in assembly language (i dont know assembly language beyond movlw) i tried to understand that using the descriptions of the commands given in this site: http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.aixassem/doc/alangref/mfmsr.htm but im not able to proceed much. Is there any better way to understand this. The algorithm is implemented in assembler (at the relocate_code label), so understanding assembler a little bit will be a preliminary to understanding unless you have access to a device which we in german call a Nürnberger Trichter [its a mythical mechanical learning device] ;) Cheers Detlev -- I haven't lost my mind, I know exactly where I left it. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] omap3: remove typedef for struct gpmc
Matthias Ludwig wrote: Hi Dirk, I wonder if you have the resources and like to convert all register structs used by OMAP3 code and remove the typedef? Else we would have a mixture of typedefs and struct usage (see e.g. above in sys_info.c). I would like to have it consistent, either the one or the other way ;) What do you think? sounds reasonable, so already in the making. Patchset in reply to this mail. Again: - compile-tested on beagle, evm, over, pandora, zoom1 - boot-tested on own board - based on v2009.06-rc1 - applies on u-boot-arm/next but breaks zoom2 Please test on other platforms. Compile tested with recent mainline: Ok. Boot tested on BeagleBoard: Ok. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot kernel rejects filesystem
Hi Bharat, [re-adding the mailing list as others may also profit from the discussion] Thank you for the prompt reply. Unfortunately in linux tree, my board specific MTD partition info is not preset. Is there any quick way round. Yep - thinking some more, I see two possible (quick) solutions. M/M Layout: 0xBF00 : U-BOOT 0xBF04 : u_boot_config_area 0xBF06: vm_linux_image (with u-boot header : created by mkimage and LZMA) 0xBF26: root_fs area... Here I have flashed squashfs (without u-boot hdr) Should I? 0xBFFC: root_fs_data .. JFFS RW filesystem Just as a sidenote - are you able to use the JFFS (really JFFS, not JFFS2?) image? If so, then you _do_ have an MTD partition in Linux which you only need to tweak. I do following on u-boot prompt boardbootm 0xBF06 0xBF26 This command only makes sense, if the image at 0xbf26 is wrapped with mkimage. This is exactly the first solution that you can try, i.e. use mkimage with -T ramdisk to wrap your image and use the it with the two argument bootm version like you tried. Maybe you will need to specify rootfstype=squashfs on the command line also, you will have to check this. Having said this, if you are on an ARM platform, the above will very likely not work, so you will have to turn to the other solution I have in mind: NO SUCCESS again I try: with modification to include/configs/my_board.h file as #define MTDIDS_DEFAULT nor0=app #define MTDPARTS_DEFAULT \ mtdparts=app:64k(u-boot),64k(boot_config),64k(board_config),2048k (kernel),13696(rootfs),256kb(roots_data) #define CONFIG_BOOTARGS root=/dev/mtdblock4 rootfstype=squashfs console= ttyS1,115200 boardbootm 0xbf06 The mtdparts variable in U-Boot has no automagic connection to the Linux kernel. It was designed however with connecting in Linux by using the following Linux config: drivers/mtd/Kconfig:106 Device Drivers config MTD_CMDLINE_PARTS bool Command line partition table parsing depends on MTD_PARTITIONS = y MTD = y ---help--- Allow generic configuration of the MTD partition tables via the kernel command line. Multiple flash resources are supported for hardware where different kinds of flash memory are available. So if you have this support in your Linux configuration, you can pass the whole mtdpart=.. through the linux commandline. A nasty part here is the beginning (you chose app) of the configuration - as you will need to find what your kernel thinks the name of the flash chip is. I think in second case it does make sense to pass mtdblock4 since my kernel (;;) does not recognize it. Is there any work around like adding mtd table in linux kernel from uboot via bootargs. Yes, like I stated above. Please try either method - if you are trying via MTD, be sure to include the contents of /proc/mtd and the relevant section of the Linux bootlog where the MTD layer registers in your next mail. Thanks Detlev PS: And please stop quoting the full text of the whole e-mail thread as this is considered to be impolite on mailing lists. -- Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it. -- The Tao of Programming -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] DaVinci Network Driver Updates
Different flavours of DaVinci SOC's have differences in their EMAC IP
This patch does the following
1) Updates base addresses for DM365
2) Updates MDIO frequencies for DM365 and DM646x
3) Update EMAC wrapper registers for DM365 and DM646x
Patch applies to u-boot-net git. the EMAC driver itself
will be updated shortly to add support for DM365 and DM646x
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
include/asm-arm/arch-davinci/emac_defs.h | 32 +-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/include/asm-arm/arch-davinci/emac_defs.h
b/include/asm-arm/arch-davinci/emac_defs.h
index c11161f..ae75f84 100644
--- a/include/asm-arm/arch-davinci/emac_defs.h
+++ b/include/asm-arm/arch-davinci/emac_defs.h
@@ -38,15 +38,38 @@
#include asm/arch/hardware.h
+#ifdef CONFIG_SOC_DM365
+#define EMAC_BASE_ADDR (0x01d07000)
+#define EMAC_WRAPPER_BASE_ADDR (0x01d0a000)
+#define EMAC_WRAPPER_RAM_ADDR (0x01d08000)
+#define EMAC_MDIO_BASE_ADDR(0x01d0b000)
+#else
#define EMAC_BASE_ADDR (0x01c8)
#define EMAC_WRAPPER_BASE_ADDR (0x01c81000)
#define EMAC_WRAPPER_RAM_ADDR (0x01c82000)
#define EMAC_MDIO_BASE_ADDR(0x01c84000)
+#endif
+#ifdef CONFIG_SOC_DM646x
+/* MDIO module input frequency */
+#define EMAC_MDIO_BUS_FREQ 7650
+/* MDIO clock output frequency */
+#define EMAC_MDIO_CLOCK_FREQ 250 /* 2.5 MHz */
+#elif defined(CONFIG_SOC_DM365)
+/* MDIO module input frequency */
+#define EMAC_MDIO_BUS_FREQ 12150
+/* MDIO clock output frequency */
+#define EMAC_MDIO_CLOCK_FREQ 220 /* 2.2 MHz */
+#else
/* MDIO module input frequency */
#define EMAC_MDIO_BUS_FREQ 9900/* PLL/6 - 99 MHz */
/* MDIO clock output frequency */
#define EMAC_MDIO_CLOCK_FREQ 200 /* 2.0 MHz */
+#endif
+
+/* PHY mask - set only those phy number bits where phy is/can be connected */
+#define EMAC_MDIO_PHY_NUM 1
+#define EMAC_MDIO_PHY_MASK (1 EMAC_MDIO_PHY_NUM)
/* Ethernet Min/Max packet size */
#define EMAC_MIN_ETHERNET_PKT_SIZE 60
@@ -103,6 +126,8 @@ typedef volatile struct _emac_desc
#define EMAC_MACCONTROL_MIIEN_ENABLE (0x20)
#define EMAC_MACCONTROL_FULLDUPLEX_ENABLE (0x1)
+#define EMAC_MACCONTROL_GIGABIT_ENABLE (1 7)
+#define EMAC_MACCONTROL_GIGFORCE (1 17)
#define EMAC_RXMBPENABLE_RXCAFEN_ENABLE(0x20)
#define EMAC_RXMBPENABLE_RXBROADEN (0x2000)
@@ -258,12 +283,17 @@ typedef struct {
/* EMAC Wrapper Registers Structure */
typedef struct {
+#if defined(CONFIG_SOC_DM646x) || defined(CONFIG_SOC_DM365)
+ dv_reg IDVER;
+ dv_reg SOFTRST;
+ dv_reg EMCTRL;
+#else
u_int8_tRSVD0[4100];
dv_reg EWCTL;
dv_reg EWINTTCNT;
+#endif
} ewrap_regs;
-
/* EMAC MDIO Registers Structure */
typedef struct {
dv_reg VERSION;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
On Tue, 12 May 2009, Detlev Zundel wrote: I never ran across this outside of linux arm where people seriously repeat the statement over and over that a whole initramfs with an initial userspace and a pivot_root is plausible for nfs root whilst patches of a few lines float around doing the same in the kernel. Now proof by repetition is not my preferred form of understanding a problem, so I was asking for an explanation from someone arguing along the same lines. The wiki page that explains the problem and provides the suggested solutions does not repeat that same mantra. It mentions the initramfs method as one way out of several - I don't think it mentions that solution as particularly better in any way. Wolfgang also repeated (most of) them here just a few mails ago in this thread. -- / daniel.haxx.se ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX31: Add NAND SPL for i.MX31.
On Tue, May 12, 2009 at 06:03:29AM +0200, Magnus Lilja wrote: As I said in another email: The main purpose of CONFIG_ONENAND_IPL and NAND_SPL in start.S is to change the behaviour a bit, not so much to save some space. Given that those CONFIG_s are used in other places as well to indicate the type of boot I don't think it's good to create a new CONFIG_ that one has to specify in addition to one of the above. Better to define one more in order to test only one... and use the new one for things that are generally applicable to pre-loaders regardless of type. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
On Tue, May 12, 2009 at 10:48:28AM +0200, Detlev Zundel wrote: Can you please explain to me, why you think it to be reasonable to demand providing an initramfs in the order of 100s of k to set an attribute of a hardware device which has its own driver? Kind of defeats any space-usage argument against putting device trees in ARM instead... Apart from being constantly repeated, I do not understand this reasoning at all. My (old-school) belief was that an operating system deals with abstracting the hardware thus userspace does not need to (nor should) know too many hw details. There's more to the operating system than the kernel. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
On Tue, May 12, 2009 at 02:04:46AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: i dont know why you're emphasizing mainline. if it's your board and if you implement the change correctly, submit it to mainline. because I already known RMK answer NACK So go to RMK and say you need device trees because you got NACKed in u-boot. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Data transfer through Ethernet in u-boot.
prathika ha scritto: Even if I use this command for data transfer, what are the requirements for the application in PC side? I don't understand this question? --Here, I will be connecting my board through a GUI to a Windows PC. I will interact using this GUI. Actually if I use tftp command for file transfer, do I need some tftp client or server running on my Windows PC? Yes, you need a tftp server on your PC. Marco ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Introduce CONFIG option for power code
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: [some unanswered questions removed here?] as davinci which is starting to be clean Sorry, but I can't find any board/ti which would be board/vendor you mention above. Even not for davinci. I looked into u-boot-arm-master and -next. and the code is start to be moved Sorry, but this confuses me because I can't find this start anywhere. So for me this sounds like I have some (undiscussed) changes in mind or in my local tree, nobody does know about, but every new patch has to care about this (publically unknown) changes (i.e. this is 'supposed' to be used to use your wording). If this understanding is right, no, this way of dealing with patches and NACKing (?) them doesn't work. If this understanding is wrong, sorry, please correct. But what I can find in both trees are board/davinci/common board/davinci/dvevm board/davinci/schmoogie board/davinci/all other Davinci boards This is 100% the same layout we use for OMAP3 boards. Looks fine to me. not to me Then, as the easiest way of dealing with directory/file moves is doing it directly in your git, the best would be if you do this re-sorting directly. NACKing a quite trivial patch (this one) because of an existing directory/file layout you don't like, while you requested yourself this change we talk about, and making it a show stopper for adding additional boards [1] like e.g. Matthias' one, sounds somehow strange to me, btw. [1] http://lists.denx.de/pipermail/u-boot/2009-April/051383.html We talk about *board* specific code here, it is totally unrelated to arch or the soc we use. This board specific code configures an OMAP3 (SoC) external companion chip which is on the board (or not). Some boards which share the basic layout have this companion chip, some not. Please note that original config options (we remove with this patch) were the *board* config options (e.g. CONFIG_OMAP3_BEAGLE) to enable the compilation of power.c, too. as show now the power.c code is shared by a lot's of omap3 boards and as you said it's a power companion for the omap3 so 2 choices move the code to cpu/omap3 as it's omap3 specific No and no. Above I mentioned why cpu/ is wrong (because it's board related code) and that it's not OMAP3 (SoC) specific. It's (OMAP3) *board* specific. or to drivers/ Driver makes no sense either, because it's not a driver. Power.c *uses* drivers e.g. I2C (like the board code) to access board components. no I2C is the communication bus, but you write a i2c drivers to manage the power chips so it's a drivers No. I don't write a driver. I just use a driver. If you want to name code that uses a driver a driver again, then you wouldn't need the board directory any more. Unfortunately, you removed my argumentation regarding this from the previous mail: -- cut -- access board components. If you would move power.c to drivers, it would be similar if you would move everything in board/* to drivers. Please have a look to code in board/davinci/common. These are no drivers, too. It's board code, which normally is in board/davinci/board/board.c file, but is moved to /common to avoid copy paste. Same is with OMAP3 power.c code. It was originally in board/omap3/board/board.c file, but you (correctly) asked to move it to a common place to avoid copy paste. If you like, we can move it back into board.c files -- cut -- Additionally, if you don't like the Davinci example, let's take an other one randomly chosen: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=board/freescale/mpc8568mds/mpc8568mds.c;h=8f991e537df10d8ff48d7783e00bb4aeaa231c79;hb=HEAD Following your argumentation, for pib_init() you would need an IO expander driver. For pci_init_board() you would need a PCI driver. Both functions are larger than what we talk about here, btw. If you go on with this, you have to create a LED driver for a one liner which enables/disables a LED using a gpio driver. And at the end you will have an empty board directory. Yes, I can do this. Unfortunately, you can't imagine how clever TI is with selling mainly the same functionality (chips) with different chip names. So most probably there is more than on chip name, and I'm not sure if I will get them right. Most probably only TI marketing department will get this right ;) why not start with the chip name I think I mentioned above that there are different chip names. But anyway ... or the familly name if they can be manage by the same driver (no 'driver' btw) ... as mentioned above I will have a look if I can find some matching naming and send an updated patch with this. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3][Net][ARM] Davinci Ethernet driver cleanup
Hi Sandeep, Paulraj, Sandeep wrote: Ben, DID anybody volunteer to test this or has it already been tested. HAS the patch been applied to any branch yet. I still see the files in the /cpu/arm926ejs/davinci folder in the u-boot-net git. I ask because I will need to add support for other DaVinci's to that driver. And this patch that I submitted today [PATCH] DaVinci Network Driver Updates Is a precursor to that. Thanks, Sandeep David Brownell tested the driver successfully. There has been a bunch of churn regarding the file structure of the Davinci code, and I'm waiting from arm/next to be pulled into main/next before re-basing these patches. Maybe J-C can give us an idea of when we can expect such a thing... regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3][Net][ARM] Davinci Ethernet driver cleanup
On 10:43 Tue 12 May , Ben Warren wrote: Hi Sandeep, Paulraj, Sandeep wrote: Ben, DID anybody volunteer to test this or has it already been tested. HAS the patch been applied to any branch yet. I still see the files in the /cpu/arm926ejs/davinci folder in the u-boot-net git. I ask because I will need to add support for other DaVinci's to that driver. And this patch that I submitted today [PATCH] DaVinci Network Driver Updates Is a precursor to that. Thanks, Sandeep David Brownell tested the driver successfully. There has been a bunch of churn regarding the file structure of the Davinci code, and I'm waiting from arm/next to be pulled into main/next before re-basing these patches. Maybe J-C can give us an idea of when we can expect such a thing... It's plan for this WE Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Canyonlands SATA harddisk driver
Dear Kazuaki Ichinohe, In message 4a0947cd.6050...@fsi.co.jp you wrote: I re-send the patch source. The following three points were corrected. 1.--- was adjusted to add git history. 2.The following lines of /drivers/block/Makefile were matched to sorting. You really don't get it. All such comments like the lines above must go *BELOW* the --- line. Only the commit message, and nothing elase, is allowed above the ---. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Minds are like parachutes - they only function when open. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timeout in tftp.c
On 14:22 Tue 12 May , Achim Ehrlich wrote: Hello, The timeout for lost packages in tftp.c is defined to 5000 msecs. But when setting the timeout get_timer(0) is called in NetSetTimeout in net.c. But on AT91 the timer code returns usecs and not msecs resulting in a timeout of 5 ms instead of 5 secs, which is kind of short. I looked in the timer code of other ARM-based platforms and they seem to use usec-based timers as well. Of course I can change the defined timeout in tftp.c to one second or so, but that doesn't seem to be the right way to solve this issue. Any suggestions or ideas or do I miss something here? could you be more precise against which version your test was done? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timeout in tftp.c
Dear Achim Ehrlich, In message 4a0969fc.2060...@taskit.de you wrote: The timeout for lost packages in tftp.c is defined to 5000 msecs. But when setting the timeout get_timer(0) is called in NetSetTimeout in net.c. But on AT91 the timer code returns usecs and not msecs resulting in a timeout of 5 ms instead of 5 secs, which is kind of short. I looked in the timer code of other ARM-based platforms and they seem to use usec-based timers as well. Of course I can change the defined timeout in tftp.c to one second or so, but that doesn't seem to be the right way to solve this issue. Any suggestions or ideas or do I miss something here? Any chance that you are using an old version of U-Boot? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Comparing information and knowledge is like asking whether the fatness of a pig is more or less green than the designated hitter rule. - David Guaspari ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove inline qualifier from show_boot_progress()
The 'inline' is conflicting with the semantic of 'weak' attribute and with the
way the show_boot_progress() function is used.
Also gcc 4.4 is complaining about it:
main.c:51: error: inline function 'show_boot_progress' cannot be declared weak
Signed-off-by: Emil Medve emilian.me...@freescale.com
---
common/main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/main.c b/common/main.c
index 905d40f..026edd1 100644
--- a/common/main.c
+++ b/common/main.c
@@ -48,7 +48,7 @@ DECLARE_GLOBAL_DATA_PTR;
* Board-specific Platform code can reimplement show_boot_progress () if needed
*/
void inline __show_boot_progress (int val) {}
-void inline show_boot_progress (int val) __attribute__((weak,
alias(__show_boot_progress)));
+void show_boot_progress (int val) __attribute__((weak,
alias(__show_boot_progress)));
#if defined(CONFIG_BOOT_RETRY_TIME) defined(CONFIG_RESET_TO_RETRY)
extern int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
/* for do_reset() prototype */
--
1.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help with driver for a ethernet switch
Hello all, Could anyone help me with this? Which change should I do on http://git.denx.de/u-boot/drivers/net/ks8695eth.c to make it work with the ks8995m ? Have anyone done this before? thanks, Raphael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/29] Rename ads5121 board into mpc5121ads
On Sat, 9 May 2009 21:50:44 +0200 Wolfgang Denk w...@denx.de wrote: MAKEALL |2 +- Makefile|6 +- board/ads5121/Makefile | 53 --- board/ads5121/README|7 - board/ads5121/ads5121.c | 432 board/ads5121/config.mk | 23 -- board/freescale/mpc5121ads/Makefile | 53 +++ board/freescale/mpc5121ads/README |7 + board/freescale/mpc5121ads/config.mk| 23 ++ board/freescale/mpc5121ads/mpc5121ads.c | 432 include/configs/ads5121.h | 551 --- include/configs/mpc5121ads.h| 551 +++ 12 files changed, 1070 insertions(+), 1070 deletions(-) delete mode 100644 board/ads5121/Makefile delete mode 100644 board/ads5121/README delete mode 100644 board/ads5121/ads5121.c delete mode 100644 board/ads5121/config.mk create mode 100644 board/freescale/mpc5121ads/Makefile create mode 100644 board/freescale/mpc5121ads/README create mode 100644 board/freescale/mpc5121ads/config.mk create mode 100644 board/freescale/mpc5121ads/mpc5121ads.c delete mode 100644 include/configs/ads5121.h create mode 100644 include/configs/mpc5121ads.h can git format-patch's -M and -B options be used to submit mass rename patches such as these please? Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/29] Rework MPC512x Support
On Sat, 9 May 2009 21:50:39 +0200 Wolfgang Denk w...@denx.de wrote: The following patch series includes a heavy rework of the existing code for MPC512x processors. The changes include especially: - move common files from mpc5121ads (so far ads5121) board to common directory so they can be reused by other boards based on the same CPU - rename ads5121 into freescale/mpc5121ads so thesame board name as in Linux is used, and the vendor directory is correct - rework the whole MPC512x related code to use I/O acessors (i. e. in_*() and out_*() functions) instead of deprecated pointer accesses - Don't #define register offsets, but use the offset from the respective C structs instead [1] - remove include/mpc512x.h to avoid duplication of the same information in include/asm-ppc/immap_512x.h - add support for the ARIA board, a MPC5121e based COM Express module [1] Note: It was not possible to get completely rid of #define'd register offsets yet, as some are used in cpu/mpc512x/start.S, and in assembly the available options are limited. In Linux, the required header files with the respective #define's are auto-generated from the C struct definitions. We intend to do the same, but this needs co-ordinations across architectures - for example, Blackfin already uses such an approach. For now, we created cpu/mpc512x/asm-offsets.h; this file will be removed again as soon as auto-generation works. Note: It might seem a good idea to squash related patches (like all I/O accessors patches into one, and all mpc512x.h removal patches into another one) to reduce the number of commits. I decided against doing this, as the amount of changes carries the risk that, inspite of pretty careful testing, some errors have not been discovered yet. The current one-step-at-a-time approach is more git-bisect friendly. Patches are agains v2009.06-rc1; they have been tested on the mpc5121ads and the aria boards. Patch overview: [PATCH 01/29] mpc512x: change cpu/mpc512x/Makefile to use Kconfig style [PATCH 02/29] mpc512x: Move common files to share them by several boards [PATCH 03/29] cpu/mpc512x/pci.c: minor coding style cleanup [PATCH 04/29] cpu/mpc512x/diu.c: fix warning: assignment from incompatible pointer type [PATCH 05/29] Rename ads5121 board into mpc5121ads [PATCH 06/29] MPC512x: add more hardware description to immap_512x.h [PATCH 07/29] mpc5121ads: use I/O accessors instead of pointer accesses [PATCH 08/29] MPC512x: add support for ARIA board [PATCH 09/29] cpu/mpc512x/iopin.c: convert to use I/O acessors. [PATCH 10/29] cpu/mpc512x/iopin.c: remove redundant include of asm/immap_512x.h [PATCH 11/29] MPC512x: prepare removal of include/mpc512x.h [PATCH 12/29] include/configs/mpc5121ads.h: prepare removal of include/mpc512x.h [PATCH 13/29] include/configs/aria.h: prepare removal of include/mpc512x.h [PATCH 14/29] common/cmd_ide.c: prepare removal of include/mpc512x.h [PATCH 15/29] cpu/mpc512x/cpu.c: prepare removal of include/mpc512x.h [PATCH 16/29] cpu/mpc512x/cpu_init.c: prepare removal of include/mpc512x.h [PATCH 17/29] cpu/mpc512x/cpu_init.c: use I/O accessors instead of pointer accesses [PATCH 18/29] cpu/mpc512x/speed.c: prepare removal of include/mpc512x.h [PATCH 19/29] cpu/mpc512x/speed.c: use I/O accessors instead of pointer accesses [PATCH 20/29] cpu/mpc512x/serial.c: use I/O accessors instead of pointer accesses [PATCH 21/29] cpu/mpc512x/i2c.c: prepare removal of include/mpc512x.h [PATCH 22/29] cpu/mpc512x/i2c.c: use immr offsets from C struct instead of #define [PATCH 23/29] cpu/mpc512x/i2c.c: use I/O accessors instead of pointer accesses [PATCH 24/29] cpu/mpc512x/pci.c: use I/O accessors instead of pointer accesses [PATCH 25/29] drivers/net/mpc512x_fec.c: prepare removal of include/mpc512x.h [PATCH 26/29] MPC512x FEC: remove duplicated code and data types [PATCH 27/29] drivers/net/mpc512x_fec.c: use I/O accessors instead of pointer accesses [PATCH 28/29] MPC512x FEC: get rid of duplicated struct ethernet_regs [PATCH 29/29] Remove include/mpc512x.h there seem to be recurring themes among these patches - this patchseries would be better grouped into theme based content instead of on a file by file basis. Eg., Removal of mpc512x.h shouldn't need 10 prepare to remove patches - it should be a single patch that removes all #include references, plus the file removal itself. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help with driver for a ethernet switch
Hi Raphael, Raphael Amorim wrote: Hello all, Could anyone help me with this? Which change should I do on http://git.denx.de/u-boot/drivers/net/ks8695eth.c to make it work with the ks8995m ? Have anyone done this before? thanks, Raphael First, read the data sheets for both chips to find out how similar/different they are. If similar, modify or copy the ks8695 driver. If they're significantly different, you might find a better match for a template. No matter what, you need to understand your hardware. Please note that the KS8695 driver will be changing soon because the API that it uses is deprecated. There are plenty of examples of drivers that use the preferred methods. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib_arch/board.c: Move malloc initialization before flash_init()
On Mon, 11 May 2009 15:50:12 +0200 Stefan Roese s...@denx.de wrote: This patch moves the malloc initialization before calling flash_init(). Upcoming changes to the NOR FLASH common CFI driver with optional MTD infrastructure and MTD concatenation support will call malloc(). And nothing really speaks against enabling malloc just a little earlier in the boot stage. Some architectures already enable malloc before calling flash_init() so they don't need any changes here. Signed-off-by: Stefan Roese s...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Mike Frysinger vap...@gentoo.org Cc: Scott McNutt smcn...@psyent.com Cc: Shinya Kuribayashi shinya.kuribaya...@necel.com Cc: Nobuhiro Iwamatsu iwama...@nigauri.org Cc: Daniel Hellstrom dan...@gaisler.com Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: John Rigby jcri...@gmail.com --- If nobody from the platforms custodians objects against this patch then I suggest that Wolfgang pulls it directly into next. fyi, you've only cc:d Scott McNutt and John Rigby on this mail, yet you indicate otherwise... Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] MX31: Add NAND SPL boot support to i.MX31 PDK board.
On 22:49 Tue 12 May , Magnus Lilja wrote: diff --git a/board/freescale/mx31pdk/config.mk b/board/freescale/mx31pdk/config.mk index d34dc02..dcaa09f 100644 --- a/board/freescale/mx31pdk/config.mk +++ b/board/freescale/mx31pdk/config.mk @@ -1 +1,5 @@ +ifdef CONFIG_NAND_SPL +TEXT_BASE = 0x87ec +else TEXT_BASE = 0x87f0 +endif + +.macro DELAY loops + ldr r2, =\loops +1: + subs r2, r2, #1 + nop + bcs 1b +.endm NACK as already reply to the kirwood patch we must have common macro please use the attached file as based work I don't see any file attached to you e-mail, so which attached file? Can you point to the relevant kirkwood patch? Is the patch in some git-tree? no not yet so I've forget to re-attached it There's a minor problem in the timer macro, fixed by replacing sub with subs. Are you OK with me posting the file as a separate patch with your From+signed-off as part of my patch series or will you add the file to arm-next yourself? ok please do tks Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/29] Rename ads5121 board into mpc5121ads
Dear Kim, In message 20090512150147.63002c4b.kim.phill...@freescale.com you wrote: can git format-patch's -M and -B options be used to submit mass rename patches such as these please? Sorry - yes, of course. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de An optimist believes we live in the best world possible; a pessimist fears this is true. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/29] Rework MPC512x Support
Dear Kim Phillips, In message 20090512150139.a110609b.kim.phill...@freescale.com you wrote: there seem to be recurring themes among these patches - this patchseries would be better grouped into theme based content instead of on a file by file basis. Eg., Removal of mpc512x.h shouldn't need 10 prepare to remove patches - it should be a single patch that removes all #include references, plus the file removal itself. You are right, there should be just a single patch. But that patch would be big, and if it later turns out that I missed something during my testing, it will be a nightmare to debug. Been there before. I already had such a patch stack, which I then collapsed into a small number of handy commits. Until it turned out that there was a nasty bug somewhere. And there is no unsquash option to git-besect -i yet ;-) In the end, I had to restore the previous version from backup tape. I really thought about this, and I came to the conclusion that it's better to keep the commits separate, step by step. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Ill-chosen abstraction is particularly evident in the design of the ADA runtime system. The interface to the ADA runtime system is so opaque that it is impossible to model or predict its performance, making it effectively useless for real-time systems. - Marc D. Donner and David H. Jameson. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/imx31_phycore: Fix bi_arch_number
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090512011419.gm18...@game.jcrosoft.org you wrote: On 13:08 Thu 07 May , Detlev Zundel wrote: Signed-off-by: Detlev Zundel d...@denx.de Cc: Sascha Hauer s.ha...@pengutronix.de --- Sascha ping? What are you waiting for? Isn't the patch obvious? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Carelessly planned projects take three times longer to complete than expected. Carefully planned projects take four times longer to complete than expected, mostly because the planners expect their planning to reduce the time it takes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
On Tuesday 12 May 2009 10:18:25 Detlev Zundel wrote: Hi Mike, On Tuesday 12 May 2009 04:48:28 Detlev Zundel wrote: how do set a mac for NFS Rootfs? use initramfs don't you think it's overkill to use a initramfs just for set a mac address?? no, i think it's perfectly reasonable. and considering you have no other option here that'll get merged ... Can you please explain to me, why you think it to be reasonable to demand providing an initramfs in the order of 100s of k to set an attribute of a hardware device which has its own driver? Apart from being constantly repeated, I do not understand this reasoning at all. My (old-school) belief was that an operating system deals with abstracting the hardware thus userspace does not need to (nor should) know too many hw details. Knowing that there is not a clear distinction line, I still fail to see why a mac address of a network interface should be handled by userspace. Can someone enlighten me here? no one said it must be done in userspace, that was just one method for doing it. read the FAQ for other possibilities. No you lost me completely. The question cited above was whether you find it plausible to use initramfs - and thus userspace - to set a mac address. You answered that you find this plausible. This is what I do not understand. I never ran across this outside of linux arm where people seriously repeat the statement over and over that a whole initramfs with an initial userspace and a pivot_root is plausible for nfs root whilst patches of a few lines float around doing the same in the kernel. i never said that a completely populated initramfs was needed. it can be accomplished pretty easily with very little code. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/29] Rework MPC512x Support
On Tue, 12 May 2009 23:21:53 +0200 Wolfgang Denk w...@denx.de wrote: Dear Kim Phillips, In message 20090512150139.a110609b.kim.phill...@freescale.com you wrote: there seem to be recurring themes among these patches - this patchseries would be better grouped into theme based content instead of on a file by file basis. Eg., Removal of mpc512x.h shouldn't need 10 prepare to remove patches - it should be a single patch that removes all #include references, plus the file removal itself. You are right, there should be just a single patch. But that patch would be big, and if it later turns out that I missed something ? wouldn't it be approximately the size of the file plus ten single-line hunks removing the #include lines in the rest of the code, i.e, a tad larger than patch 29/29? Plus it would significantly reduce the intimidating denominator number of this patchseries (making it approx. 10 commits less, and that's only on the subject of the removal of this mpc512x file). during my testing, it will be a nightmare to debug. Been there before. I already had such a patch stack, which I then collapsed into a small number of handy commits. Until it turned out that there was a nasty bug somewhere. And there is no unsquash option to git-besect -i yet ;-) In the end, I had to restore the previous version from backup tape. I really thought about this, and I came to the conclusion that it's better to keep the commits separate, step by step. I'm not going to tell you how to do your development, but you don't have to expose artefacts of your personal debugging cycles to reviewers nor unnecessarily clutter git bisect with unnecessary commits. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Introduce CONFIG option for power code
On 19:41 Tue 12 May , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: [some unanswered questions removed here?] as davinci which is starting to be clean Sorry, but I can't find any board/ti which would be board/vendor you mention above. Even not for davinci. I looked into u-boot-arm-master and -next. and the code is start to be moved Sorry, but this confuses me because I can't find this start anywhere. davinci: display correct clock info http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=5516e87d057c13fce05b6fc6e56cf3f4ddfc36b4 davinci: move psc support board--cpu http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=20bb2384e2b81e77880993134c8f268d59fdfe07 But what I can find in both trees are board/davinci/common board/davinci/dvevm board/davinci/schmoogie board/davinci/all other Davinci boards This is 100% the same layout we use for OMAP3 boards. Looks fine to me. not to me Then, as the easiest way of dealing with directory/file moves is doing it directly in your git, the best would be if you do this re-sorting directly. NACKing a quite trivial patch (this one) because of an existing directory/file layout you don't like, while you requested yourself this change we talk about, and making it a show stopper for adding additional boards [1] like e.g. Matthias' one, sounds somehow strange to me, btw. [1] http://lists.denx.de/pipermail/u-boot/2009-April/051383.html We talk about *board* specific code here, it is totally unrelated to arch or the soc we use. This board specific code configures an OMAP3 (SoC) external companion chip which is on the board (or not). Some boards which share the basic layout have this companion chip, some not. Please note that original config options (we remove with this patch) were the *board* config options (e.g. CONFIG_OMAP3_BEAGLE) to enable the compilation of power.c, too. as show now the power.c code is shared by a lot's of omap3 boards and as you said it's a power companion for the omap3 so 2 choices move the code to cpu/omap3 as it's omap3 specific No and no. Above I mentioned why cpu/ is wrong (because it's board related code) and that it's not OMAP3 (SoC) specific. It's (OMAP3) *board* specific. or to drivers/ Driver makes no sense either, because it's not a driver. Power.c *uses* drivers e.g. I2C (like the board code) to access board components. no I2C is the communication bus, but you write a i2c drivers to manage the power chips so it's a drivers No. I don't write a driver. I just use a driver. If you want to name code that uses a driver a driver again, then you wouldn't need the board directory any more. Unfortunately, you removed my argumentation regarding this from the previous mail: -- cut -- access board components. If you would move power.c to drivers, it would be similar if you would move everything in board/* to drivers. Please have a look to code in board/davinci/common. These are no drivers, too. in correct as recently the soc code as device init was move to cpu/arm926ejs/davinci this only remaining code is the trivial dram_init and the EEProm Mac address management If you go on with this, you have to create a LED driver for a one liner which enables/disables a LED using a gpio driver. And at the end you will have an empty board directory. it's done for the at91 led drivers to avoid copypaste and it's in cpu/arm926ejs/at91 Yes, I can do this. Unfortunately, you can't imagine how clever TI is with selling mainly the same functionality (chips) with different chip names. So most probably there is more than on chip name, and I'm not sure if I will get them right. Most probably only TI marketing department will get this right ;) why not start with the chip name I think I mentioned above that there are different chip names. But anyway ... I agree but to simplify it why not use at the beggening the current supported or use chip or the familly name if they can be manage by the same driver (no 'driver' btw) we disagree on the term driver is this chip is useable for other board than omap3? if yes (which I suspect correct me if I'm wrong) then it's use is not omap3 specific at all ... as mentioned above I will have a look if I can find some matching naming and send an updated patch with this. ok Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] omap3: remove typedef for struct gpmc
-typedef struct gpmc {
+struct gpmc {
unsigned char res1[0x10];
unsigned int sysconfig; /* 0x10 */
unsigned char res2[0x4];
@@ -125,7 +125,7 @@ typedef struct gpmc {
unsigned int ecc7_result; /* 0x218 */
unsigned int ecc8_result; /* 0x21C */
unsigned int ecc9_result; /* 0x220 */
-} gpmc_t;
+};
I wonder if you have the resources and like to convert all register
structs used by OMAP3 code and remove the typedef?
Else we would have a mixture of typedefs and struct usage (see e.g.
above in sys_info.c). I would like to have it consistent, either the
one or the other way ;) What do you think?
Fully agree
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 2/4] omap3: remove typedefs for configuration structs
#define BURSTCOMPLETE_GROUP7 (0x1 31)
/* SDRC */
#ifndef __ASSEMBLY__
-typedef struct sdrc_cs {
+struct sdrc_cs {
unsigned int mcfg; /* 0x80 || 0xB0 */
unsigned int mr;/* 0x84 || 0xB4 */
unsigned char res1[0x4];
@@ -176,12 +176,12 @@ typedef struct sdrc_cs {
unsigned char res3[0x4];
} sdrc_cs_t;
please remove too
-typedef struct sdrc_actim {
+struct sdrc_actim {
unsigned int ctrla; /* 0x9C || 0xC4 */
unsigned int ctrlb; /* 0xA0 || 0xC8 */
} sdrc_actim_t;
please remove too
-typedef struct sdrc {
+struct sdrc {
unsigned char res1[0x10];
unsigned int sysconfig; /* 0x10 */
unsigned int status;/* 0x14 */
@@ -196,7 +196,7 @@ typedef struct sdrc {
unsigned int power; /* 0x70 */
unsigned char res4[0xC];
sdrc_cs_t cs[2];/* 0x80 || 0xB0 */
-} sdrc_t;
+};
#endif /* __ASSEMBLY__ */
#define DLLPHASE_90 (0x1 1)
@@ -240,7 +240,7 @@ typedef struct sdrc {
/* timer regs offsets (32 bit regs) */
#ifndef __ASSEMBLY__
-typedef struct gptimer {
+struct gptimer {
unsigned int tidr; /* 0x00 r */
unsigned char res[0xc];
unsigned int tiocp_cfg; /* 0x10 rw */
@@ -257,7 +257,7 @@ typedef struct gptimer {
unsigned int tcar1; /* 0x3c r */
unsigned int tcicr; /* 0x40 rw */
unsigned int tcar2; /* 0x44 r */
-} gptimer_t;
+};
#endif /* __ASSEMBLY__ */
/* enable sys_clk NO-prescale /1 */
@@ -265,12 +265,12 @@ typedef struct gptimer {
/* Watchdog */
#ifndef __ASSEMBLY__
-typedef struct watchdog {
+struct watchdog {
unsigned char res1[0x34];
unsigned int wwps; /* 0x34 r */
unsigned char res2[0x10];
unsigned int wspr; /* 0x48 rw */
-} watchdog_t;
+};
#endif /* __ASSEMBLY__ */
#define WD_UNLOCK1 0x
@@ -280,7 +280,7 @@ typedef struct watchdog {
#define PRCM_BASE0x48004000
#ifndef __ASSEMBLY__
-typedef struct prcm {
+struct prcm {
unsigned int fclken_iva2; /* 0x00 */
unsigned int clken_pll_iva2;/* 0x04 */
unsigned char res1[0x1c];
@@ -344,7 +344,7 @@ typedef struct prcm {
unsigned int clksel_per;/* 0x1040 */
unsigned char res28[0xfc];
unsigned int clksel1_emu; /* 0x1140 */
-} prcm_t;
+};
#else /* __ASSEMBLY__ */
#define CM_CLKSEL_CORE 0x48004a40
#define CM_CLKSEL_GFX0x48004b40
@@ -357,14 +357,14 @@ typedef struct prcm {
#define PRM_BASE 0x48306000
#ifndef __ASSEMBLY__
-typedef struct prm {
+struct prm {
unsigned char res1[0xd40];
unsigned int clksel;/* 0xd40 */
unsigned char res2[0x50c];
unsigned int rstctrl; /* 0x1250 */
unsigned char res3[0x1c];
unsigned int clksrc_ctrl; /* 0x1270 */
-} prm_t;
+};
#else /* __ASSEMBLY__ */
#define PRM_RSTCTRL 0x48307250
#endif /* __ASSEMBLY__ */
@@ -400,7 +400,7 @@ typedef struct prm {
#define PM_IVA2_BASE_ADDR_ARM(SMX_APE_BASE + 0x14000)
#ifndef __ASSEMBLY__
-typedef struct pm {
+struct pm {
unsigned char res1[0x48];
unsigned int req_info_permission_0; /* 0x48 */
unsigned char res2[0x4];
@@ -413,7 +413,7 @@ typedef struct pm {
unsigned int req_info_permission_1; /* 0x68 */
unsigned char res6[0x14];
unsigned int addr_match_2; /* 0x80 */
-} pm_t;
+};
#endif /*__ASSEMBLY__ */
/* Permission values for registers -Full fledged permissions to all */
diff --git a/include/asm-arm/arch-omap3/mem.h
b/include/asm-arm/arch-omap3/mem.h
index 6f0f90b..5b9ac75 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -29,12 +29,12 @@
#define CS1 0x1 /* mirror CS1 regs appear offset 0x30 from CS0 */
#ifndef __ASSEMBLY__
-typedef enum {
+enum {
STACKED = 0,
IP_DDR = 1,
COMBO_DDR = 2,
IP_SDR = 3,
-} mem_t;
+};
it will be better to use the enum type so it will be check at the compiling
time by gcc
#endif /* __ASSEMBLY__ */
#define EARLY_INIT 1
diff --git a/include/asm-arm/arch-omap3/omap3.h
b/include/asm-arm/arch-omap3/omap3.h
index 7c11019..d9d243f 100644
--- a/include/asm-arm/arch-omap3/omap3.h
+++ b/include/asm-arm/arch-omap3/omap3.h
@@ -79,10 +79,10 @@
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 3/4] omap3: replace all instances of gpmc config struct by one global
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index aa15f94..079c848 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -41,6 +41,8 @@ unsigned int boot_flash_sec;
unsigned int boot_flash_type;
volatile unsigned int boot_flash_env_addr;
+struct gpmc *gpmc_cfg;
please do not expose it directly
please use a function to get it
+
#if defined(CONFIG_CMD_NAND)
static u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG1,
@@ -51,8 +53,6 @@ static u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG6, 0
};
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 4/4] omap3: use only fixed-size types inside ctrl_structs
On 10:12 Tue 12 May , Matthias Ludwig wrote: replace variable types in ctrl_structs for omap3 by those with fixed size (u8, u16, u32). Additional ifndef-protection is needed by examples which do not compile when including asm/types.h could explain why and in which case we need it? Signed-off-by: Matthias Ludwig mlud...@ultratronik.de --- include/asm-arm/arch-omap3/cpu.h | 418 -- 1 files changed, 221 insertions(+), 197 deletions(-) diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-omap3/cpu.h index 61a833e..b2c8498 100644 --- a/include/asm-arm/arch-omap3/cpu.h +++ b/include/asm-arm/arch-omap3/cpu.h @@ -25,34 +25,40 @@ #ifndef _CPU_H #define _CPU_H +#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__)) +#include asm/types.h +#endif /* !(__KERNEL_STRICT_NAMES || __ASSEMBLY__) */ + Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/imx31_phycore: Fix bi_arch_number
On 23:37 Tue 12 May , Wolfgang Denk wrote: Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090512011419.gm18...@game.jcrosoft.org you wrote: On 13:08 Thu 07 May , Detlev Zundel wrote: Signed-off-by: Detlev Zundel d...@denx.de Cc: Sascha Hauer s.ha...@pengutronix.de --- Sascha ping? What are you waiting for? Isn't the patch obvious? the ack from the board Maintainer which is Sascha Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch arm/next] dm355 evm support (v3)
On 19:58 Mon 11 May , David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Initial U-Boot support for the DaVinci DM355 EVM. This is a board from Spectrum Digital. Board docs include schematic and firmware for its microcontroller: http://c6000.spectrumdigital.com/evmdm355/revd/ Most of the DM355 chip is fully documented by TI, the most notable exception being the MPEG/JPEG coprocessor (programmable using codecs available at no cost from TI), which is omitted from its DM335 sibling: http://focus.ti.com/docs/prod/folders/print/tms320dm355.html This version can boot from the on-board DM9000 Ethernet chip, after being loaded (from NAND, MMC/SD, or UART). In the near future, NAND and USB support could be added ... NAND support is being held back until the support for the 4-bit ECC hardware is ready. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- Applied to arm/next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB EHCI driver
Francesco, Could you send what you have done so far to the list. Someone else might be able to pick it up and figure out what might be wrong. Thanks John On Mon, Mar 23, 2009 at 2:44 AM, Rendine Francesco francesco.rend...@valueteam.com wrote: Hi, I've already tried that define, but nothing is changed... What can I see in the USB driver to resolve issue? Thanks. -Original Message- From: Michael Trimarchi [mailto:trimar...@gandalf.sssup.it] Sent: Fri 3/20/2009 9:36 AM To: Rendine Francesco Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] USB EHCI driver Hi, FrancescoVT wrote: usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 dev=1ffebb08, pipe=8883, buffer=1f9a671a, length=64, req=1ffea214 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI fail timeout STD_ASS reset usb_new_device: usb_get_descriptor() failed #define CONFIG_LEGACY_USB_INIT_SEQ Michael ___ 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] lib_arch/board.c: Move malloc initialization before flash_init()
On Tuesday 12 May 2009 22:09:11 Kim Phillips wrote: Signed-off-by: Stefan Roese s...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Mike Frysinger vap...@gentoo.org Cc: Scott McNutt smcn...@psyent.com Cc: Shinya Kuribayashi shinya.kuribaya...@necel.com Cc: Nobuhiro Iwamatsu iwama...@nigauri.org Cc: Daniel Hellstrom dan...@gaisler.com Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: John Rigby jcri...@gmail.com --- If nobody from the platforms custodians objects against this patch then I suggest that Wolfgang pulls it directly into next. fyi, you've only cc:d Scott McNutt and John Rigby on this mail, yet you indicate otherwise... Hmmm. I used git send-email for sending and I'm pretty sure that I saw all those email addresses added by this command. Perhaps the mailing list server removed some? I've seen this happen on other lists as well. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib_arch/board.c: Move malloc initialization before flash_init()
On Wednesday 13 May 2009 00:20:52 Stefan Roese wrote: On Tuesday 12 May 2009 22:09:11 Kim Phillips wrote: Signed-off-by: Stefan Roese s...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Mike Frysinger vap...@gentoo.org Cc: Scott McNutt smcn...@psyent.com Cc: Shinya Kuribayashi shinya.kuribaya...@necel.com Cc: Nobuhiro Iwamatsu iwama...@nigauri.org Cc: Daniel Hellstrom dan...@gaisler.com Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: John Rigby jcri...@gmail.com --- If nobody from the platforms custodians objects against this patch then I suggest that Wolfgang pulls it directly into next. fyi, you've only cc:d Scott McNutt and John Rigby on this mail, yet you indicate otherwise... Hmmm. I used git send-email for sending and I'm pretty sure that I saw all those email addresses added by this command. Perhaps the mailing list server removed some? I've seen this happen on other lists as well. full CC list looks fine on the e-mail i received -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timeout in tftp.c
Wolfgang Denk schrieb: Dear Achim Ehrlich, In message 4a0969fc.2060...@taskit.de you wrote: The timeout for lost packages in tftp.c is defined to 5000 msecs. But when setting the timeout get_timer(0) is called in NetSetTimeout in net.c. But on AT91 the timer code returns usecs and not msecs resulting in a timeout of 5 ms instead of 5 secs, which is kind of short. I looked in the timer code of other ARM-based platforms and they seem to use usec-based timers as well. Of course I can change the defined timeout in tftp.c to one second or so, but that doesn't seem to be the right way to solve this issue. Any suggestions or ideas or do I miss something here? Any chance that you are using an old version of U-Boot? Hi Achim, I'm interested in this, too. I observed timeouts on ARM11 (MX31), but couldn't do any investigation due to other projects. Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 3/4] omap3: replace all instances of gpmc config struct by one global
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090512230224.gl...@game.jcrosoft.org you wrote: diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c index aa15f94..079c848 100644 --- a/cpu/arm_cortexa8/omap3/mem.c +++ b/cpu/arm_cortexa8/omap3/mem.c @@ -41,6 +41,8 @@ unsigned int boot_flash_sec; unsigned int boot_flash_type; volatile unsigned int boot_flash_env_addr; +struct gpmc *gpmc_cfg; please do not expose it directly please use a function to get it Isn't this just adding to the memory footprint for little or no benefit? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/imx31_phycore: Fix bi_arch_number
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090512231236.gn...@game.jcrosoft.org you wrote: Sascha ping? What are you waiting for? Isn't the patch obvious? the ack from the board Maintainer which is Sascha For such trivial patches you can decide this yourself. That's better than delaying things. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A weak mind is like a microscope, which magnifies trifling things, but cannot receive great ones. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
