[U-Boot] [PATCH] ARM: MX5: Remove broken leftover TO-2 errata workaround
This check is broken. r3 does not contain the silicon revision. Signed-off-by: David Jander da...@protonic.nl --- arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..f17d200 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,11 +39,6 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ - - /* disable write combine for TO 2 and lower revs */ - orrls r0, r0, #(1 25) - mcr 15, 1, r0, c9, c0, 2 .endm /* init_l2cc */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: MX51: PLL errata workaround
This is a port of the official PLL errata workaround from Freescale to mainline u-boot. The PLL's in the i.MX51 processor can go out of lock due to a metastable condition in an analog flip-flop when used at high frequencies. This workaround implements an undocumented feature in the PLL (dither mode), which causes the effect of this failure to be much lower (in terms of frequency deviation), avoiding system failure, or at least decreasing the likelihood of system failure. Signed-off-by: David Jander da...@protonic.nl --- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 38 ++ arch/arm/include/asm/arch-mx5/imx-regs.h |5 doc/README.imx5 | 18 ++ 3 files changed, 61 insertions(+), 0 deletions(-) create mode 100644 doc/README.imx5 diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 96ebfe2..ee4150d 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -117,6 +117,35 @@ beq 1b .endm +.macro setup_pll_errata pll, freq + ldr r2, =\pll + mov r1, #0x0 + str r1, [r2, #PLL_DP_CONFIG] /* Disable auto-restart AREN bit */ + ldr r1, =0x1236 + str r1, [r2, #PLL_DP_CTL]/* Restart PLL with PLM=1 */ +1: ldr r1, [r2, #PLL_DP_CTL]/* Wait for lock */ + ands r1, r1, #0x1 + beq 1b + + ldr r5, \freq + str r5, [r2, #PLL_DP_MFN]/* Modify MFN value */ + str r5, [r2, #PLL_DP_HFS_MFN] + + mov r1, #0x1 + str r1, [r2, #PLL_DP_CONFIG] /* Reload MFN value */ + +2: ldr r1, [r2, #PLL_DP_CONFIG] + tst r1, #1 + bne 2b + + ldr r1, =100 /* Wait at least 4 us */ +3: subs r1, r1, #1 + bge 3b + + mov r1, #0x2 + str r1, [r2, #PLL_DP_CONFIG] /* Enable auto-restart AREN bit */ +.endm + .macro init_clock ldr r0, =CCM_BASE_ADDR @@ -153,7 +182,12 @@ mov r1, #0x4 str r1, [r0, #CLKCTL_CCSR] +#if defined(CONFIG_MX51_PLL_ERRATA) + setup_pll PLL1_BASE_ADDR, 864 + setup_pll_errata PLL1_BASE_ADDR, W_DP_MFN_800_DIT +#else setup_pll PLL1_BASE_ADDR, 800 +#endif #if defined(CONFIG_MX51) setup_pll PLL3_BASE_ADDR, 665 @@ -283,6 +317,10 @@ lowlevel_init: mov pc,lr /* Board level setting value */ +W_DP_OP_864: .word DP_OP_864 +W_DP_MFD_864: .word DP_MFD_864 +W_DP_MFN_864: .word DP_MFN_864 +W_DP_MFN_800_DIT: .word DP_MFN_800_DIT W_DP_OP_800: .word DP_OP_800 W_DP_MFD_800: .word DP_MFD_800 W_DP_MFN_800: .word DP_MFN_800 diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h index d7f83c5..0b1caf0 100644 --- a/arch/arm/include/asm/arch-mx5/imx-regs.h +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h @@ -235,6 +235,11 @@ /* Assuming 24MHz input clock with doubler ON */ /*MFI PDF */ +#define DP_OP_864 ((8 4) + ((1 - 1) 0)) +#define DP_MFD_864 (180 - 1) /* PL Dither mode */ +#define DP_MFN_864 180 +#define DP_MFN_800_DIT 60 /* PL Dither mode */ + #define DP_OP_850 ((8 4) + ((1 - 1) 0)) #define DP_MFD_850 (48 - 1) #define DP_MFN_850 41 diff --git a/doc/README.imx5 b/doc/README.imx5 new file mode 100644 index 000..e9b2c88 --- /dev/null +++ b/doc/README.imx5 @@ -0,0 +1,18 @@ +U-Boot for Freescale i.MX5x + +This file contains information for the port of U-Boot to the Freescale +i.MX5x SoCs. + +1. CONFIGURATION OPTIONS/SETTINGS +- + +1.1 CONFIG_MX51_PLL_ERRATA: Workaround for i.MX51 PLL errata. +This option should be enabled by all boards using the i.MX51 silicon +version up until (including) 3.0 running at 800MHz. +The PLL's in the i.MX51 processor can go out of lock due to a metastable +condition in an analog flip-flop when used at high frequencies. +This workaround implements an undocumented feature in the PLL (dither +mode), which causes the effect of this failure to be much lower (in terms +of frequency deviation), avoiding system failure, or at least decreasing +the likelihood of system failure. + -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: MX5: Remove broken leftover TO-2 errata workaround
On 07/14/2011 09:13 AM, David Jander wrote: This check is broken. r3 does not contain the silicon revision. Signed-off-by: David Jander da...@protonic.nl --- Hi David, arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..f17d200 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,11 +39,6 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ You are right. Nobody sets the r3 register, the test can be wrong. - - /* disable write combine for TO 2 and lower revs */ - orrls r0, r0, #(1 25) However, you also remove the setup for TO2. To fix the TO2 issue, we should read correctly the revision number (from IIM or from a fixed address, I do not remember now), and then apply the compare to the read value. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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
[U-Boot] [PATCH V2] MX31: Cleanup clock function
The patch provide the same API used with other i.MX
processors and get rid of mx31_ functions.
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes since V1:
- remove unneeded initialization for enum (Fabio Estevam)
arch/arm/cpu/arm1136/mx31/generic.c| 21 -
arch/arm/include/asm/arch-mx31/clock.h | 11 +--
drivers/spi/mxc_spi.c |2 --
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx31/generic.c
b/arch/arm/cpu/arm1136/mx31/generic.c
index 4ebf38d..248431b 100644
--- a/arch/arm/cpu/arm1136/mx31/generic.c
+++ b/arch/arm/cpu/arm1136/mx31/generic.c
@@ -23,6 +23,7 @@
#include common.h
#include asm/arch/imx-regs.h
+#include asm/arch/clock.h
#include asm/io.h
static u32 mx31_decode_pll(u32 reg, u32 infreq)
@@ -60,7 +61,7 @@ static u32 mx31_get_mcu_main_clk(void)
return mx31_get_mpl_dpdgck_clk();
}
-u32 mx31_get_ipg_clk(void)
+static u32 mx31_get_ipg_clk(void)
{
u32 freq = mx31_get_mcu_main_clk();
u32 pdr0 = __REG(CCM_PDR0);
@@ -78,6 +79,24 @@ void mx31_dump_clocks(void)
printf(ipg clock : %dHz\n, mx31_get_ipg_clk());
}
+unsigned int mxc_get_clock(enum mxc_clock clk)
+{
+ switch (clk) {
+ case MXC_ARM_CLK:
+ return mx31_get_mcu_main_clk();
+ case MXC_IPG_CLK:
+ case MXC_CSPI_CLK:
+ case MXC_UART_CLK:
+ return mx31_get_ipg_clk();
+ }
+ return -1;
+}
+
+u32 imx_get_uartclk(void)
+{
+ return mxc_get_clock(MXC_UART_CLK);
+}
+
void mx31_gpio_mux(unsigned long mode)
{
unsigned long reg, shift, tmp;
diff --git a/arch/arm/include/asm/arch-mx31/clock.h
b/arch/arm/include/asm/arch-mx31/clock.h
index 9f7ae80..fb035c4 100644
--- a/arch/arm/include/asm/arch-mx31/clock.h
+++ b/arch/arm/include/asm/arch-mx31/clock.h
@@ -24,8 +24,15 @@
#ifndef __ASM_ARCH_CLOCK_H
#define __ASM_ARCH_CLOCK_H
-extern u32 mx31_get_ipg_clk(void);
-#define imx_get_uartclk mx31_get_ipg_clk
+enum mxc_clock {
+ MXC_ARM_CLK,
+ MXC_IPG_CLK,
+ MXC_CSPI_CLK,
+ MXC_UART_CLK,
+};
+
+unsigned int mxc_get_clock(enum mxc_clock clk);
+extern u32 imx_get_uartclk();
extern void mx31_gpio_mux(unsigned long mode);
extern void mx31_set_pad(enum iomux_pins pin, u32 config);
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 698e726..81381d9 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -60,8 +60,6 @@ static unsigned long spi_bases[] = {
0x53f84000,
};
-#define mxc_get_clock(x) mx31_get_ipg_clk()
-
#elif defined(CONFIG_MX51)
#define MXC_CSPICTRL_EN(1 0)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] I2C: mxc_i2c rework
Hello Stefano,
Stefano Babic wrote:
On 07/13/2011 11:53 AM, Marek Vasut wrote:
Rewrite the mxc_i2c driver.
* This version is much closer to Linux implementation.
* Fixes IPG_PERCLK being incorrectly used as clock source
* Fixes behaviour of the driver on iMX51
* Clean up coding style a bit ;-)
Signed-off-by: Marek Vasut marek.va...@gmail.com
---
Hi Marek,
I have added Heiko in CC. He is the Maintainer for I2C.
Thanks! ;-)
[...]
+/*
+ * Write register address
+ */
+int i2c_imx_set_reg_addr(uint addr, int alen)
{
-int i, retry = 0;
-for (retry = 0; retry 3; retry++) {
-if (wait_idle())
+int ret;
+int i;
+
mmmhh...it seems to me you change completely the logic here. Heiko, waht
do you think about ?
I think this is OK, because of calling i2c_imx_trx_complete() later,
which do this ...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3+] I2C: mxc_i2c rework
Hello Marek,
Marek Vasut wrote:
Rewrite the mxc_i2c driver.
* This version is much closer to Linux implementation.
* Fixes IPG_PERCLK being incorrectly used as clock source
* Fixes behaviour of the driver on iMX51
* Clean up coding style a bit ;-)
Based on commit: e39428d53d080ad2615b772d7f99d2a70c2aaab2
Date: Mon Jun 21 09:27:05 2010 +0200
i2c-imx: do not allow interruptions when waiting for I2C to complete
Signed-off-by: Marek Vasut marek.va...@gmail.com
---
drivers/i2c/mxc_i2c.c | 424
+
1 files changed, 290 insertions(+), 134 deletions(-)
V2: Convert register access to struct mxc_i2c_regs.
V3: Update licensing info
V3+: Add commit ID into commit message
checkpatch says:
ERROR: trailing statements should be on next line
#143: FILE: drivers/i2c/mxc_i2c.c:130:
+ for (i = 0; i2c_clk_div[i][0] div; i++);
total: 1 errors, 0 warnings, 526 lines checked
Can you fix this?
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 89d1973..03e2448 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
[...]
@@ -68,218 +78,364 @@
#endif
#define I2C_MAX_TIMEOUT 1
-#define I2C_MAX_RETRIES 3
-static u16 div[] = { 30, 32, 36, 42, 48, 52, 60, 72, 80, 88, 104, 128, 144,
- 160, 192, 240, 288, 320, 384, 480, 576, 640, 768, 960,
- 1152, 1280, 1536, 1920, 2304, 2560, 3072, 3840};
+static u16 i2c_clk_div[50][2] = {
+ { 22, 0x20 }, { 24, 0x21 }, { 26, 0x22 }, { 28, 0x23 },
+ { 30, 0x00 }, { 32, 0x24 }, { 36, 0x25 }, { 40, 0x26 },
+ { 42, 0x03 }, { 44, 0x27 }, { 48, 0x28 }, { 52, 0x05 },
+ { 56, 0x29 }, { 60, 0x06 }, { 64, 0x2A }, { 72, 0x2B },
+ { 80, 0x2C }, { 88, 0x09 }, { 96, 0x2D }, { 104, 0x0A },
+ { 112, 0x2E }, { 128, 0x2F }, { 144, 0x0C }, { 160, 0x30 },
+ { 192, 0x31 }, { 224, 0x32 }, { 240, 0x0F }, { 256, 0x33 },
+ { 288, 0x10 }, { 320, 0x34 }, { 384, 0x35 }, { 448, 0x36 },
+ { 480, 0x13 }, { 512, 0x37 }, { 576, 0x14 }, { 640, 0x38 },
+ { 768, 0x39 }, { 896, 0x3A }, { 960, 0x17 }, { 1024, 0x3B },
+ { 1152, 0x18 }, { 1280, 0x3C }, { 1536, 0x3D }, { 1792, 0x3E },
+ { 1920, 0x1B }, { 2048, 0x3F }, { 2304, 0x1C }, { 2560, 0x1D },
+ { 3072, 0x1E }, { 3840, 0x1F }
+};
+
+static u8 clk_idx;
-static inline void i2c_reset(void)
-{
- writew(0, I2C_BASE + I2CR); /* Reset module */
- writew(0, I2C_BASE + I2SR);
- writew(I2CR_IEN, I2C_BASE + I2CR);
-}
-
-void i2c_init(int speed, int unused)
+/*
+ * Calculate and set proper clock divider
+ *
+ * FIXME: remove #ifdefs !
+ */
As Stefano just posted a patch for this, see here:
http://patchwork.ozlabs.org/patch/104642/
Can you fix this please?
Thanks!
+static void i2c_imx_set_clk(unsigned int rate)
{
- int freq;
+ struct mxc_i2c_regs *i2c_regs = (struct mxc_i2c_regs *)I2C_BASE;
+ unsigned int i2c_clk_rate;
+ unsigned int div;
int i;
+ /* Divider value calculation */
#if defined(CONFIG_MX31)
struct clock_control_regs *sc_regs =
(struct clock_control_regs *)CCM_BASE;
- freq = mx31_get_ipg_clk();
+ i2c_clk_rate = mx31_get_ipg_clk();
/* start the required I2C clock */
writel(readl(sc_regs-cgr0) | (3 I2C_CLK_OFFSET),
sc_regs-cgr0);
#else
- freq = mxc_get_clock(MXC_IPG_PERCLK);
+ i2c_clk_rate = mxc_get_clock(MXC_IPG_CLK);
#endif
[...]
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On 07/13/2011 01:46 PM, Detlev Zundel wrote: The NDEBUG approach however, as Mike suggested, was what I was looking for in the first place. Great! Detlev Again, not so great. U-boot uses all kinds of assert(), BUG_ON(), ASSERT() all over the place. This probably needs a project wide effort, which is why I simply threw in my NULL pointer check. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] handling of NAND blocks which go bad
Dear tkoka, In message 1310616218.8257.10.camel@localhost you wrote: I have a question about how u-boot handles NAND blocks going bad over time, for example when uncorrectable ECC errors or erase failures are encountered for blocks which are not already in the Bad Block Table. I know that u-boot properly skips already known bad blocks, but I can't seem to find where new bad blocks are recorded in the BBT. Can anyone point me in the right direction? Or confirm that this is not supported in u-boot? I am using a BSP from Freescale on a custom mx25 board, but I cannot find this handling in the latest u-boot git either. If you are looking into reliable systems based on NAND technology, you want to use UBI / UBIFS - even to the extent that you load the U-Boot image from a (static) UBI volume. 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 consultant is a person who borrows your watch, tells you what time it is, pockets the watch, and sends you a bill for it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 3/9] Extend build-system for SPL framework
Dear Aneesh, In message 4e1e8096.2000...@ti.com you wrote: We were not sure whether to globally enable --gc-sections unconditionally for SPL or not. My opinion is that these flags should be globally enabled for all SPLs for the following reasons: ... As such I propose that the above shall be made un-conditional after taking care not to duplicate it if it's already defined in the platform config.mk for the u-boot. I agree - we should enable these optimizations unconditionally. [Would duplication of these options be a problem? I don't think so - it's just bad for esthetic reasons.] 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 Bei genauerem Hinsehen ist die Arbeit weniger langweilig als das Vergnügen. -- Charles Baudelaire ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 3/9] Extend build-system for SPL framework
On Thursday 14 July 2011 03:15 PM, Wolfgang Denk wrote: Dear Aneesh, In message4e1e8096.2000...@ti.com you wrote: We were not sure whether to globally enable --gc-sections unconditionally for SPL or not. My opinion is that these flags should be globally enabled for all SPLs for the following reasons: ... As such I propose that the above shall be made un-conditional after taking care not to duplicate it if it's already defined in the platform config.mk for the u-boot. I agree - we should enable these optimizations unconditionally. [Would duplication of these options be a problem? I don't think so - it's just bad for esthetic reasons.] Yes, duplication will only make command line look ugly. I don't think it will result in any compilation issue. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: MX5: Remove broken leftover TO-2 errata workaround
On Thu, 14 Jul 2011 10:16:51 +0200 Stefano Babic sba...@denx.de wrote: On 07/14/2011 09:13 AM, David Jander wrote: This check is broken. r3 does not contain the silicon revision. Signed-off-by: David Jander da...@protonic.nl --- Hi David, arch/arm/cpu/armv7/mx5/lowlevel_init.S |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..f17d200 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,11 +39,6 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ You are right. Nobody sets the r3 register, the test can be wrong. - - /* disable write combine for TO 2 and lower revs */ - orrls r0, r0, #(1 25) However, you also remove the setup for TO2. To fix the TO2 issue, we should read correctly the revision number (from IIM or from a fixed address, I do not remember now), and then apply the compare to the read value. Yes, you are right. But I don't know how to do it correctly. OTOH, it is broken now for all platforms. My patch fixes it for TO3 and newer. L2 write-combine has a significant performance impact, and I wonder how many boards there are still that use such an old (prototype silicon) processor. IMHO, the vast majority of MX51 users will benefit from this patch, and the rest shouldn't have any more problems than they have already, so can we just apply this, please? Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: MX51: PLL errata workaround
On Thu, 14 Jul 2011 10:30:11 +0200 Stefano Babic sba...@denx.de wrote: On 07/14/2011 09:11 AM, David Jander wrote: This is a port of the official PLL errata workaround from Freescale to mainline u-boot. The PLL's in the i.MX51 processor can go out of lock due to a metastable condition in an analog flip-flop when used at high frequencies. This workaround implements an undocumented feature in the PLL (dither mode), which causes the effect of this failure to be much lower (in terms of frequency deviation), avoiding system failure, or at least decreasing the likelihood of system failure. Signed-off-by: David Jander da...@protonic.nl Hi David, do you have now also an official Errata number from Freescale to be added to your documentation ? Needless to say that this supersedes my patch sent back in May, 26th... which btw did not help much, since _all_ PLL's are affected by this problem. Not only PLL1. Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] integratorap: remove hardcoded 32MB memory cmdline
The default configuration for the Integrator AP forces memory to be 32 MB on the command line to the kernel, while we have perfect information and detection of the actual memory size in the ATAGs. Delete the confusion. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- include/configs/integratorap.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index d724c91..7b8aea6 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -94,7 +94,7 @@ #define CONFIG_BOOTDELAY 2 -#define CONFIG_BOOTARGSroot=/dev/mtdblock0 mem=32M console=ttyAM0 console=tty +#define CONFIG_BOOTARGSroot=/dev/mtdblock0 console=ttyAM0 console=tty #define CONFIG_BOOTCOMMAND /* -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: MX51: PLL errata workaround
On 07/14/2011 12:13 PM, David Jander wrote: Hi David, Freescale promised an official errata a week ago, but released the errata just yesterday (hadn't seen it until now). The number is ENGcm12051. Do you mind including it in the commit yourself, or do you want me to re-post? Well, it is enough - I can include it in the commit message, if there will be no further comments. From my point of view the patch is ok. The fact that the patch can be disabled will probably increase the number of testers. Acked-by : Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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] ARM: MX51: PLL errata workaround
On 07/14/2011 12:23 PM, David Jander wrote: Hi David, do you have now also an official Errata number from Freescale to be added to your documentation ? Needless to say that this supersedes my patch sent back in May, 26th... which btw did not help much, since _all_ PLL's are affected by this problem. Not only PLL1. Yes. I have set the old patch as superseeded in patchwork Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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] ARM: MX51: PLL errata workaround
Hi Stefano, On Thu, 14 Jul 2011 10:30:11 +0200 Stefano Babic sba...@denx.de wrote: On 07/14/2011 09:11 AM, David Jander wrote: This is a port of the official PLL errata workaround from Freescale to mainline u-boot. The PLL's in the i.MX51 processor can go out of lock due to a metastable condition in an analog flip-flop when used at high frequencies. This workaround implements an undocumented feature in the PLL (dither mode), which causes the effect of this failure to be much lower (in terms of frequency deviation), avoiding system failure, or at least decreasing the likelihood of system failure. Signed-off-by: David Jander da...@protonic.nl Hi David, do you have now also an official Errata number from Freescale to be added to your documentation ? Freescale promised an official errata a week ago, but released the errata just yesterday (hadn't seen it until now). The number is ENGcm12051. Do you mind including it in the commit yourself, or do you want me to re-post? Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: MX5: Remove broken leftover TO-2 errata workaround
On 07/14/2011 12:20 PM, David Jander wrote: However, you also remove the setup for TO2. To fix the TO2 issue, we should read correctly the revision number (from IIM or from a fixed address, I do not remember now), and then apply the compare to the read value. Yes, you are right. But I don't know how to do it correctly. There is a similar code always in lowlevel_init.S 189 ldr r1, =0x0 190 ldr r3, [r1, #ROM_SI_REV] 191 cmp r3, #0x10 As we can suppose this is correct, the same code can be used in the macro. OTOH, it is broken now for all platforms. Agree we have to fix it. I only dislike to break some boards. As far as I know, there is many mx51evk boards sold by Freescale with the TO2 chip. My patch fixes it for TO3 and newer. L2 write-combine has a significant performance impact, and I wonder how many boards there are still that use such an old (prototype silicon) processor. I think only on the evaluation boards, but they were sold and delivered. IMHO, the vast majority of MX51 users will benefit from this patch, and the rest shouldn't have any more problems than they have already, so can we just apply this, please? Not as it is - I prefer we fix the test. Can you resubmit with the proposed changes ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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] ARM: MX5: Remove broken leftover TO-2 errata workaround
On Thu, 14 Jul 2011 12:49:15 +0200 Stefano Babic sba...@denx.de wrote: On 07/14/2011 12:20 PM, David Jander wrote: However, you also remove the setup for TO2. To fix the TO2 issue, we should read correctly the revision number (from IIM or from a fixed address, I do not remember now), and then apply the compare to the read value. Yes, you are right. But I don't know how to do it correctly. There is a similar code always in lowlevel_init.S 189 ldr r1, =0x0 190 ldr r3, [r1, #ROM_SI_REV] 191 cmp r3, #0x10 As we can suppose this is correct, the same code can be used in the macro. Hmmm. Hadn't seen that part. Can we trust this?... because I have no means of testing for the TO2 case. OTOH, it is broken now for all platforms. Agree we have to fix it. I only dislike to break some boards. As far as I know, there is many mx51evk boards sold by Freescale with the TO2 chip. Ah, ok. AFAICR, our EVK has a TO3, but I agree there might be low quantities of EVKs with TO2 still in use somewhere. My patch fixes it for TO3 and newer. L2 write-combine has a significant performance impact, and I wonder how many boards there are still that use such an old (prototype silicon) processor. I think only on the evaluation boards, but they were sold and delivered. Ok. IMHO, the vast majority of MX51 users will benefit from this patch, and the rest shouldn't have any more problems than they have already, so can we just apply this, please? Not as it is - I prefer we fix the test. Can you resubmit with the proposed changes ? Ok, thanks for pointing out the missing code. I will fix and re-submit. Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] integratorap: disable dcache
Dear Linus Walleij, In message 1310598267-9711-1-git-send-email-linus.wall...@linaro.org you wrote: The Integrator AP with CM920T (ARM920T) does not boot without D-cache disabled throughout, the actual problem comes at bootm, at this point U-Boot tries to disable D-cache which doesn't work on this machine for some reason. The result is usually an illegal instruction trap or similar as the PC goes astray in memory and crash something like this: undefined instruction pc : [01ff1c44] lr : [01fd8430] sp : 01fa7e08 ip : 01fa7dc0 fp : r10: 01fef318 r9 : 0015 r8 : 01fa7f70 r7 : 0015 r6 : 8000 r5 : 01fa7fe8 r4 : r3 : 01fef380 r2 : 01fef8b0 r1 : r0 : fffe Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ... Disabling D-cache brings the board support to a working state that can boot the Linux kernel. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- include/configs/integratorap.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Sorry, but again I have to point out that I really dislike papering over existing bugs. If the disable D-cache in bootm does not work, _this_ should be analyzed and fixed instead of globally disabling he data cache. NAK. 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 In accord with UNIX philosophy, Perl gives you enough rope to hang yourself. - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] integratorap: fixup SDRAM memory size detection
Dear Linus Walleij, In message 1310598276-9741-1-git-send-email-linus.wall...@linaro.org you wrote: This fixes up the SDRAM memory detection code to work with the latest relocation code, moves it all into dram_init() and activates memory size detection for the Integrator AP. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- board/armltd/integrator/integrator.c | 17 +++-- include/configs/integratorap.h |2 +- 2 files changed, 8 insertions(+), 11 deletions(-) ... @@ -120,8 +112,13 @@ extern void dram_query(void); */ sdram_shift = ((cm_reg_sdram 0x001C)/4)%4; gd-bd-bi_dram[0].size = 0x0100 sdram_shift; - + gd-ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE, + 0x0100 sdram_shift); } +#else +gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE; + gd-ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE, + PHYS_SDRAM_1_SIZE); Indentation by TAB only, please. diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index acdb37c..d724c91 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -47,7 +47,7 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_CM_INIT 1 #define CONFIG_CM_REMAP 1 -#undef CONFIG_CM_SPD_DETECT +#define CONFIG_CM_SPD_DETECT #define CONFIG_SYS_DCACHE_OFF Are you sure this works for all affected boards? Please also put the board maintainer on Cc: for all patches that affedt specific boards like here. 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 I find this a nice feature but it is not according to the documen- tation. Or is it a BUG? Let's call it an accidental feature. :-) - Larry Wall in 6...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] integratorap: remove hardcoded 32MB memory cmdline
Dear Linus Walleij, In message 1310639329-9677-1-git-send-email-linus.wall...@linaro.org you wrote: The default configuration for the Integrator AP forces memory to be 32 MB on the command line to the kernel, while we have perfect information and detection of the actual memory size in the ATAGs. Delete the confusion. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- include/configs/integratorap.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index d724c91..7b8aea6 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -94,7 +94,7 @@ #define CONFIG_BOOTDELAY 2 -#define CONFIG_BOOTARGS root=/dev/mtdblock0 mem=32M console=ttyAM0 console=tty +#define CONFIG_BOOTARGS root=/dev/mtdblock0 console=ttyAM0 console=tty #define CONFIG_BOOTCOMMAND Please make sure to Cc: the board maintainer! 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 To be awake is to be alive.- Henry David Thoreau, in Walden ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] integratorap: fixup SDRAM memory size detection
Hello.
On 14-07-2011 3:04, Linus Walleij wrote:
This fixes up the SDRAM memory detection code to work with the
latest relocation code, moves it all into dram_init() and
activates memory size detection for the Integrator AP.
Signed-off-by: Linus Walleijlinus.wall...@linaro.org
---
board/armltd/integrator/integrator.c | 17 +++--
include/configs/integratorap.h |2 +-
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/board/armltd/integrator/integrator.c
b/board/armltd/integrator/integrator.c
index a0d8de7..931a916 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -86,17 +86,9 @@ int misc_init_r (void)
return (0);
}
-void dram_init_banksize(void)
-{
- gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
-gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
-}
-
int dram_init (void)
{
- gd-ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
- PHYS_SDRAM_1_SIZE);
-
+ gd-bd-bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
#ifdef CONFIG_CM_SPD_DETECT
{
extern void dram_query(void);
@@ -120,8 +112,13 @@ extern void dram_query(void);
*/
sdram_shift = ((cm_reg_sdram 0x001C)/4)%4;
gd-bd-bi_dram[0].size = 0x0100 sdram_shift;
-
+ gd-ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
+ 0x0100 sdram_shift);
}
+#else
+gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
How about fixing the indentation here to use tab?
+ gd-ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
+ PHYS_SDRAM_1_SIZE);
#endif /* CM_SPD_DETECT */
return 0;
WBR, Sergei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: MX5: Fix broken leftover TO-2 errata workaround
This check was broken. r3 does not contain the silicon revision anymore, so we need to reload it. Signed-off-by: David Jander da...@protonic.nl --- arch/arm/cpu/armv7/mx5/lowlevel_init.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..6bb398f 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,7 +39,9 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ + ldr r1, =0x0 + ldr r3, [r1, #ROM_SI_REV] + cmp r3, #0x10 /* disable write combine for TO 2 and lower revs */ orrls r0, r0, #(1 25) -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Let target 'cscope' follow symbolic links
Without telling 'find' to follow symbolic links, files under include/asm and arch/$(ARCH)/include/asm/arch are not added to the cscope file list. Signed-off-by: Horst Kronstorfer hkron...@frequentis.com --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index e56fa02..deff642 100644 --- a/Makefile +++ b/Makefile @@ -479,7 +479,7 @@ etags: etags -a -o $(obj)etags `find $(TAG_SUBDIRS) \ -name '*.[chS]' -print` cscope: - find $(TAG_SUBDIRS) -name '*.[chS]' -print cscope.files + find -L $(TAG_SUBDIRS) -name '*.[chS]' -print cscope.files cscope -b -q -k SYSTEM_MAP = \ -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: MX5: Fix broken leftover TO-2 errata workaround
On 07/14/2011 01:56 PM, David Jander wrote: This check was broken. r3 does not contain the silicon revision anymore, so we need to reload it. Signed-off-by: David Jander da...@protonic.nl --- Hi David, arch/arm/cpu/armv7/mx5/lowlevel_init.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..6bb398f 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,7 +39,9 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ + ldr r1, =0x0 + ldr r3, [r1, #ROM_SI_REV] + cmp r3, #0x10 You have to protect the code related to TO2 with CONFIG_MX51. As I can see, the macro is called for MX.53, too, and the test produces wrong results. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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] ARM: MX5: Fix broken leftover TO-2 errata workaround
On Thu, 14 Jul 2011 14:14:52 +0200 Stefano Babic sba...@denx.de wrote: On 07/14/2011 01:56 PM, David Jander wrote: This check was broken. r3 does not contain the silicon revision anymore, so we need to reload it. Signed-off-by: David Jander da...@protonic.nl --- Hi David, arch/arm/cpu/armv7/mx5/lowlevel_init.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..6bb398f 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,7 +39,9 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ + ldr r1, =0x0 + ldr r3, [r1, #ROM_SI_REV] + cmp r3, #0x10 You have to protect the code related to TO2 with CONFIG_MX51. As I can see, the macro is called for MX.53, too, and the test produces wrong results. Wow, you are right! So this code was actually broken in more ways than I initially thought :-) Ok, will fix it (again). Btw, may I congratulate you for your good work in improving u-boot code quality? It is starting to get to a level only known from LKML ;-) Clearly the code was not reviewed as well when this was initially submitted. Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: MX5: Fix broken leftover TO-2 errata workaround
On 07/14/2011 02:30 PM, David Jander wrote: You have to protect the code related to TO2 with CONFIG_MX51. As I can see, the macro is called for MX.53, too, and the test produces wrong results. Wow, you are right! So this code was actually broken in more ways than I initially thought :-) Yes, with one shot you hit more bugs... Ok, will fix it (again). Btw, may I congratulate you for your good work in improving u-boot code quality? It is starting to get to a level only known from LKML ;-) Congratulations go to all participants and reviewers of this ML, who are helping to improve the quality of the code ;-) Clearly the code was not reviewed as well when this was initially submitted. That is right - some issues was not seen and not fixed in time. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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
[U-Boot] [PATCH] miiphy: use strcpy() not sprintf()
In miiphy_register() the new device's name was initialised by passing a string parameter as the format string to sprintf(). As this would cause problems if it ever contained a '%' symbol, switch to using strcpy() instead. Signed-off-by: Laurence Withers lwith...@guralp.com Cc: Andy Fleming aflem...@freescale.com --- common/miiphyutil.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/miiphyutil.c b/common/miiphyutil.c index bcab74e..0ddf88e 100644 --- a/common/miiphyutil.c +++ b/common/miiphyutil.c @@ -141,7 +141,7 @@ void miiphy_register(const char *name, /* initalize mii_dev struct fields */ new_dev-read = legacy_miiphy_read; new_dev-write = legacy_miiphy_write; - sprintf(new_dev-name, name); + strcpy(new_dev-name, name); ldev-read = read; ldev-write = write; new_dev-priv = ldev; -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] ARM: MX5: Fix broken leftover TO-2 errata workaround
This check was broken. r3 does not contain the silicon revision anymore, so we need to reload it. Also, this errata only applies to i.MX51. Changed in this version: - Added #ifdef CONFIG_MX51 around the workaround Signed-off-by: David Jander da...@protonic.nl --- arch/arm/cpu/armv7/mx5/lowlevel_init.S |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..6c66b42 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,10 +39,14 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ +#if defined(CONFIG_MX51) + ldr r1, =0x0 + ldr r3, [r1, #ROM_SI_REV] + cmp r3, #0x10 /* disable write combine for TO 2 and lower revs */ orrls r0, r0, #(1 25) +#endif mcr 15, 1, r0, c9, c0, 2 .endm /* init_l2cc */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: MX5: Fix broken leftover TO-2 errata workaround
On 07/14/2011 02:54 PM, David Jander wrote: This check was broken. r3 does not contain the silicon revision anymore, so we need to reload it. Also, this errata only applies to i.MX51. Changed in this version: - Added #ifdef CONFIG_MX51 around the workaround Signed-off-by: David Jander da...@protonic.nl --- arch/arm/cpu/armv7/mx5/lowlevel_init.S |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..6c66b42 100644 Acked-by : Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-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] [uboot PATCH v2] Add uboot fdt_high enviroment variable
Hi Dave,
This looks reasonable, with one minor nit...
On 07/09/2011 04:40 PM, David A. Long wrote:
From: David A. Longdave.l...@linaro.org
Add a new fdt_high enviroment variable. This can be used to control (or
prevent) the
relocation of the flattened device tree on boot. It can be used to prevent
relocation
of the fdt into highmem. The variable behaves similarly to the existing
initrd_high
variable.
Signed-off-by: David A. Longdave.l...@linaro.org
---
README |9
common/image.c | 60
++--
2 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/README b/README
index 8bb9c8d..5b95246 100644
--- a/README
+++ b/README
@@ -3281,6 +3281,15 @@ List of environment variables (most likely not
complete):
[snip]
diff --git a/common/image.c b/common/image.c
index e542a57..7853de0 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1234,8 +1234,10 @@ int boot_relocate_fdt (struct lmb *lmb, char
**of_flat_tree, ulong *of_size)
{
void*fdt_blob = *of_flat_tree;
void*of_start = 0;
+ char*fdt_high;
ulong of_len = 0;
int err;
+ int disable_relocation=0;
Need spaces around the =
I will add the spaces before applying the patch unless you send an
updated patch.
Thanks,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: enanle USB2 gadget mode for corenet ds board
1. fix commit message 'enanle' - enable
2. add some details about how this change addresses the issue in commit message
- k
On Jul 13, 2011, at 9:42 PM, Shaohui Xie wrote:
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
arch/powerpc/cpu/mpc8xxx/fdt.c |3 ++-
board/freescale/corenet_ds/corenet_ds.c |1 +
include/configs/corenet_ds.h|2 ++
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index d9e3e7e..60cb210 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -164,7 +164,8 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
if (mode_idx 0 phy_idx 0)
printf(WARNING: invalid phy or mode\n);
} else {
- break;
+ if (i CONFIG_SYS_USB_DEVICE)
+ break;
}
I'm not sure that CONFIG_SYS_USB_DEVICE is the right way / #define to use for
this purpose.
Do we need the 'else' clause at all?
}
if (!usb1_defined) {
diff --git a/board/freescale/corenet_ds/corenet_ds.c
b/board/freescale/corenet_ds/corenet_ds.c
index cf9b7b8..b1e7823 100644
--- a/board/freescale/corenet_ds/corenet_ds.c
+++ b/board/freescale/corenet_ds/corenet_ds.c
@@ -236,6 +236,7 @@ void ft_board_setup(void *blob, bd_t *bd)
#endif
fdt_fixup_liodn(blob);
+ fdt_fixup_dr_usb(blob, bd);
}
int board_eth_init(bd_t *bis)
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index c9cc22a..2c86ba3 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -580,6 +580,8 @@
#define CONFIG_USB_EHCI_FSL
#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
#define CONFIG_CMD_EXT2
+#define CONFIG_HAS_FSL_DR_USB
+#define CONFIG_SYS_USB_DEVICE2
#define CONFIG_MMC
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM POST Tests.
Hello , I am new to u-boot code. I had a requirement for running memory, cpu and cache tests as part of diagnostics, on an ARM based platform. After going through the code, I found that only PPC variants are available for cpu and cache post tests. 1) Is that a limitation, or Is it some sort of misunderstanding on my side? 2) If NO, Is there a branch or patch I can pickup which will have ARM POST tests for cache and cpu? Your advice will be of great help. Thanks, Sreekumar Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 2011-07-14 at 09:10 -0400, Jerry Van Baren wrote: Hi Dave, This looks reasonable, with one minor nit... Need spaces around the = I will add the spaces before applying the patch unless you send an updated patch. OK, thanks much. Someone else recently pointed that out to me too. I can generate another update if you wish, but I'll let you handle that unless you say otherwise. FYI: In case it wasn't clear, this all came about because: 1) the Pandaboard has 1GB of RAM; 2) the presence of an fdt causes u-boot to relocate the fdt and ramdisk to the end of ram by default; 3) and the Linux kernel does not like having to access memory beyond about 3/4G (HIGHMEM) during early boot. Thanks again, -dl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: Fix device tree padding associated with ramdisk
On Jul 6, 2011, at 8:16 PM, Kumar Gala wrote:
When booting with a ramdisk we bump the amount of memory reserved for
the device tree by FDT_RAMDISK_OVERHEAD. However we did not increase
the actual size in the device tree blob to match.
Its possible on boundary cases that we dont have enough memory according
to the device tree blob and get errors like:
WARNING: could not set linux,initrd-end FDT_ERR_NOSPACE
We can easily fix this by setting the device tree size at the same time
we bump the amount of memory reserved for the device tree.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/lib/bootm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
Jerry,
Any comments on this.
- k
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index e01787d..4e0cb8f 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -288,8 +288,10 @@ static int boot_body_linux(bootm_headers_t *images)
return ret;
of_size = ret;
- if (*initrd_start *initrd_end)
+ if (*initrd_start *initrd_end) {
of_size += FDT_RAMDISK_OVERHEAD;
+ fdt_set_totalsize(*of_flat_tree, of_size);
+ }
/* Create a new LMB reservation */
lmb_reserve(lmb, (ulong)*of_flat_tree, of_size);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fdt: introduce fdt_create_phandle()
On May 10, 2011, at 3:14 PM, Timur Tabi wrote:
The ePAPR specification says that phandle properties should be called
phandle, and not linux,phandle. To facilitate the migration from
linux,phandle to phandle, introduce function fdt_create_phandle(), which
creates a phandle in a given node. For now, we create both the phandle and
linux,phandle properties. A later version of this function will remove
support for linux,phandle.
Signed-off-by: Timur Tabi ti...@freescale.com
---
common/fdt_support.c | 40
include/fdt_support.h |1 +
2 files changed, 41 insertions(+), 0 deletions(-)
Jerry,
Any comments on this?
- k
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 85715ff..dd9deaf 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1201,6 +1201,46 @@ int fdt_alloc_phandle(void *blob)
return phandle + 1;
}
+/*
+ * fdt_create_phandle: Create a phandle property for the given node
+ *
+ * @fdt: ptr to device tree
+ * @nodeoffset: node to update
+ * @phandle: phandle value to set (must be unique)
+*/
+int fdt_create_phandle(void *fdt, int nodeoffset, uint32_t phandle)
+{
+ int ret;
+
+#ifdef DEBUG
+ int off = fdt_node_offset_by_phandle(fdt, phandle);
+
+ if ((off = 0) (off != nodeoffset)) {
+ char buf[64];
+
+ fdt_get_path(fdt, nodeoffset, buf, sizeof(buf));
+ printf(Trying to update node %s with phandle %u ,
+buf, phandle);
+
+ fdt_get_path(fdt, off, buf, sizeof(buf));
+ printf(that already exists in node %s.\n, buf);
+ return -FDT_ERR_BADPHANDLE;
+ }
+#endif
+
+ ret = fdt_setprop_cell(fdt, nodeoffset, phandle, phandle);
+ if (ret 0)
+ return ret;
+
+ /*
+ * For now, also set the deprecated linux,phandle property, so that we
+ * don't break older kernels.
+ */
+ ret = fdt_setprop_cell(fdt, nodeoffset, linux,phandle, phandle);
+
+ return ret;
+}
+
#if defined(CONFIG_VIDEO)
int fdt_add_edid(void *blob, const char *compat, unsigned char *edid_buf)
{
diff --git a/include/fdt_support.h b/include/fdt_support.h
index ce6817b..366062f 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -88,6 +88,7 @@ u64 fdt_translate_address(void *blob, int node_offset,
const u32 *in_addr);
int fdt_node_offset_by_compat_reg(void *blob, const char *compat,
phys_addr_t compat_off);
int fdt_alloc_phandle(void *blob);
+int fdt_create_phandle(void *fdt, int nodeoffset, uint32_t phandle);
int fdt_add_edid(void *blob, const char *compat, unsigned char *buf);
#endif /* ifdef CONFIG_OF_LIBFDT */
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fdt: add prototype for fdt_increase_size()
On May 3, 2011, at 1:35 PM, Timur Tabi wrote: Add a prototype for fdt_increase_size() so that anyone can call it. Signed-off-by: Timur Tabi ti...@freescale.com --- include/fdt_support.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Jerry, Any comments on this? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano, Le 13/07/2011 16:25, Stefano Babic a écrit : Hi Albert, please pull from u-boot-imx. The following changes since commit 79642098a8345e2506ab0ff02e8c7ac4da405d0c: Add support for Network Space v2 and parents (2011-07-04 10:55:28 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Fabio Estevam (2): mx31pdk: cosmetic: Fix line over 80 characters mx27: Make the UART port number explicit Jana Rapava (2): EfikaMX: Use correct imximage.cfg EfikaMX: Add missing CONFIG_SYS_TEXT_BASE Marek Vasut (1): EfikaMX: Enable EXT2 booting Matthias Weisser (7): build: Add targets for auto gen of asm-offsets.h and use it in imx35 imx: Add get_tbclk() function for imx25 imx: Use correct imx25 reset.c imx: Add support for USB EHCI on imx25 imx: Add auto generation of asm-offsets.h for imx25 imx: Make imx25 compatible to mxc_gpio driver and fix in tx25 imx: Add support for zmx25 board Stefano Babic (2): MX5: Update to autogenerated asm-offsets.h MX27: Update to autogenerated asm-offsets.h Torsten Koschorrek (1): ARM: Update maintainer of board scb9328 MAINTAINERS |7 +- arch/arm/cpu/arm1136/mx35/Makefile | 11 -- arch/arm/cpu/arm926ejs/mx25/Makefile |8 +- arch/arm/cpu/arm926ejs/mx25/asm-offsets.c| 60 arch/arm/cpu/arm926ejs/mx25/timer.c | 12 ++ arch/arm/cpu/arm926ejs/mx27/Makefile |2 + arch/arm/cpu/arm926ejs/mx27/asm-offsets.c| 45 ++ arch/arm/cpu/arm926ejs/mx27/generic.c|2 +- arch/arm/cpu/armv7/mx5/Makefile |2 + arch/arm/cpu/armv7/mx5/asm-offsets.c | 76 ++ arch/arm/include/asm/arch-mx25/imx-regs.h| 49 ++- arch/arm/include/asm/arch-mx25/macro.h | 64 arch/arm/include/asm/arch-mx27/asm-offsets.h | 16 -- arch/arm/include/asm/arch-mx27/imx-regs.h|2 +- arch/arm/include/asm/arch-mx31/imx-regs.h|2 +- arch/arm/include/asm/arch-mx5/asm-offsets.h | 55 --- arch/arm/include/asm/arch-mx5/imx-regs.h | 18 +++ board/karo/tx25/tx25.c | 26 ++-- board/logicpd/imx27lite/imx27lite.c |2 +- board/syteco/zmx25/Makefile | 51 +++ board/syteco/zmx25/lowlevel_init.S | 110 ++ board/syteco/zmx25/zmx25.c | 203 ++ boards.cfg |3 +- drivers/usb/host/ehci-mxc.c | 33 +++- include/configs/efikamx.h|3 + include/configs/mx31pdk.h|6 +- include/configs/zmx25.h | 180 +++ include/mxc_gpio.h |5 + rules.mk | 10 ++ 29 files changed, 944 insertions(+), 119 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx25/asm-offsets.c create mode 100644 arch/arm/cpu/arm926ejs/mx27/asm-offsets.c create mode 100644 arch/arm/cpu/armv7/mx5/asm-offsets.c create mode 100644 arch/arm/include/asm/arch-mx25/macro.h delete mode 100644 arch/arm/include/asm/arch-mx27/asm-offsets.h delete mode 100644 arch/arm/include/asm/arch-mx5/asm-offsets.h create mode 100644 board/syteco/zmx25/Makefile create mode 100644 board/syteco/zmx25/lowlevel_init.S create mode 100644 board/syteco/zmx25/zmx25.c create mode 100644 include/configs/zmx25.h Applied to u-boot-arm/master, thanks. Best regards, Stefano Babic Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: MX5: Fix broken leftover TO-2 errata workaround
Hi David, Le 14/07/2011 14:54, David Jander a écrit : This check was broken. r3 does not contain the silicon revision anymore, so we need to reload it. Also, this errata only applies to i.MX51. Changed in this version: - Added #ifdef CONFIG_MX51 around the workaround Please keep patch history below the commit message line '---' so that the history does not appear in the Git tree. Signed-off-by: David Janderda...@protonic.nl --- Put history here. (please post a V3 for fixing this, not an amended V2!) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fdt: add prototype for fdt_increase_size()
Hi Kumar, Timur, On 07/14/2011 09:32 AM, Kumar Gala wrote: On May 3, 2011, at 1:35 PM, Timur Tabi wrote: Add a prototype for fdt_increase_size() so that anyone can call it. Signed-off-by: Timur Tabiti...@freescale.com --- include/fdt_support.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Jerry, Any comments on this? - k I put it in my todo list on patchworks. gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
Hi Helmut, Le 11/07/2011 12:10, Helmut Raiger a écrit : On 07/07/2011 06:46 PM, Albert ARIBAUD wrote: Hi Helmut, Le 04/07/2011 12:29, helmut.rai...@hale.at a écrit : From: Helmut Raigerhelmut.rai...@hale.at Seems like your git send-email config does not have your name along with your e-mail address, causing this From: to appear in the patch body (and the mail itself to lack your name) -- git can handle this, I think, but I'd be grateful if you fixed your config. Amicalement, Hi Albert, I just checked my config, user and e-mail were fine, but I had the from configured in the sendemail section which obviously generates the 'From:' line. Do you like me to resend the patches? Not needed for this patch (if that From: is ok with patchwork and Git) but if you send a V2 patch or for future patches, please do avoid the added From. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3+] I2C: mxc_i2c rework
Hi Marek, Le 13/07/2011 23:58, Marek Vasut a écrit : V3+: Add commit ID into commit message What prevents a simple V4 here? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] miiphy: use strcpy() not sprintf()
Hi Laurence, Le 14/07/2011 14:31, Laurence Withers a écrit : In miiphy_register() the new device's name was initialised by passing a string parameter as the format string to sprintf(). As this would cause problems if it ever contained a '%' symbol, switch to using strcpy() instead. Please use strncpy() which will also guard against overflows. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] ARM: MX5: Fix broken leftover TO-2 errata workaround
This check was broken. r3 does not contain the silicon revision anymore, so we need to reload it. Also, this errata only applies to i.MX51. Signed-off-by: David Jander da...@protonic.nl --- Changed in this version: - Move patch changelog below '---' line. arch/arm/cpu/armv7/mx5/lowlevel_init.S |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index ee4150d..6c66b42 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -39,10 +39,14 @@ orr r0, r0, #(1 23) /* disable write allocate combine */ orr r0, r0, #(1 22) /* disable write allocate */ - cmp r3, #0x10/* r3 contains the silicon rev */ +#if defined(CONFIG_MX51) + ldr r1, =0x0 + ldr r3, [r1, #ROM_SI_REV] + cmp r3, #0x10 /* disable write combine for TO 2 and lower revs */ orrls r0, r0, #(1 25) +#endif mcr 15, 1, r0, c9, c0, 2 .endm /* init_l2cc */ -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv7: fix: Disable D cache for goni target (s5p)
Hi Lukasz, Le 11/07/2011 09:41, Lukasz Majewski a écrit : Signed-off-by: Lukasz Majewskil.majew...@samsung.com Cc: Minkyu Kangmk7.k...@samsung.com Cc: Aneesh Vane...@ti.com --- Can you please submit a V2 patch in which the commit message provides a rationale for turning the data cache off? People who want to turn it on later will benefit from the info. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fdt: introduce fdt_create_phandle()
On 07/14/2011 09:31 AM, Kumar Gala wrote: On May 10, 2011, at 3:14 PM, Timur Tabi wrote: The ePAPR specification says that phandle properties should be called phandle, and not linux,phandle. To facilitate the migration from linux,phandle to phandle, introduce function fdt_create_phandle(), which creates a phandle in a given node. For now, we create both the phandle and linux,phandle properties. A later version of this function will remove support for linux,phandle. Signed-off-by: Timur Tabiti...@freescale.com --- common/fdt_support.c | 40 include/fdt_support.h |1 + 2 files changed, 41 insertions(+), 0 deletions(-) Jerry, Any comments on this? - k I put it in my todo list on patchworks. What I have queued are two patches from upstream 0329-Support-ePAPR-compliant-phandle-properties.patch 0344-libfdt-Implement-property-iteration-functions.patch and... [U-Boot,v2] Add uboot fdt_high enviroment variable2011-07-09 David A. Long gvb New [U-Boot,2/2,v3] powerpc/85xx: add support the ePAPR phandle property 2011-05-10 Timur Tabi gvb New [U-Boot,1/2] fdt: introduce fdt_create_phandle()2011-05-10 Timur Tabigvb New [U-Boot,1/2] fdt: add prototype for fdt_increase_size() 2011-05-03 Timur Tabi gvb New [U-Boot,1/2,v2] fdt: introduce fdt_verify_alias_address() and fdt_get_base_address() 2011-05-03 Timur Tabi gvb New Hollor if I'm missing something. Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] miiphy: use strncpy() not sprintf()
In miiphy_register() the new device's name was initialised by passing a string parameter as the format string to sprintf(). As this would cause problems if it ever contained a '%' symbol, switch to using strncpy() instead. Signed-off-by: Laurence Withers lwith...@guralp.com Cc: Andy Fleming aflem...@freescale.com --- Changes for v2: - Use strncpy() rather than plain strcpy() for extra safety. --- common/miiphyutil.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/common/miiphyutil.c b/common/miiphyutil.c index bcab74e..bc9896e 100644 --- a/common/miiphyutil.c +++ b/common/miiphyutil.c @@ -141,7 +141,8 @@ void miiphy_register(const char *name, /* initalize mii_dev struct fields */ new_dev-read = legacy_miiphy_read; new_dev-write = legacy_miiphy_write; - sprintf(new_dev-name, name); + strncpy(new_dev-name, name, MDIO_NAME_LEN); + new_dev-name[MDIO_NAME_LEN - 1] = 0; ldev-read = read; ldev-write = write; new_dev-priv = ldev; -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Hi Igor, Le 13/07/2011 07:52, Igor Grinberg a écrit : Hi Albert, On 07/08/11 00:06, Igor Grinberg wrote: On 07/07/11 20:46, Albert ARIBAUD wrote: Le 07/07/2011 18:51, Igor Grinberg a écrit : If we have this option and it is documented, then any new board can use it instead of thinking (although it is simple) where and how to dereference the bi_arch_number. Not sure I get you there. Can you elaborate on a more precise example that would show the benefits of it? For example, if you think of Christopher's patch (ARM: Warn when the machine ID isn't set.), If you need Christopher's patch, then there are cases when the machid is not set, right? When someone gets this warning, he thinks: Ah, I forgot the machid! and then goes to fix the code, but again he thinks, where is the best place to put it? For us, it is trivial, that it should be in board_init() function, but for newbies, it is not that trivial. With this patch, you get the explanation and also a place to put the machid definition. With this patch, you just define the configuration variable and the whole thing will be done for you. Another example would be the board/nvidia/*, the code is shared as much as possible, and the mach_type is set in the common code. That is something I would expect to be done for all ARM boards, not just for nvidia... I see your point. Now the issue I foresee is that this commonalization has benefits only for boards which currently set their bi_arch_number in board_init_f(), Vast majority of boards set their bi_arch_number in board_init(). I went through all the boards and there is only one that set it in board_early_init_f() and several that do this in checkboard(). This makes me think of v2 of this patch which will set the bi_arch_number in board_init_f() just before the init_sequence[] array is run. but has no incentive -- that's a code that will be used only in a few places and could stay that way for quite long, because boards that will not adhere to it will still build unchanged. Well, I don't like to force people do something by breaking their builds... In general, I think that any change should not break any existing code (at least not on purpose). At least, this is how it works in Linux. IOW, there is no benefit for e.g. ED Mini V2, to use CONFIG_MACH_TYPE, so why would it? Thus instead of simplifying and commonalizing, this feature will *add* to the code base complexity. Unless the goal is to add this macro *and* change all related board codes in the same patchset? I don't see it as feasible either. Well, I can do the change board/* wide, but it will take some time to accomplish. Also, we still don't have an exact list of boards for removal, so I'd like to wait until the removal takes place, so there will be less boards to consider. Any suggestion for ensuring adoption of the feature wherever it can be used? Currently, I can think of: 1) Changing all relevant boards to use it - will eliminate bad examples. 2) Pointing to the use of CONFIG_MACH_TYPE during code review. 3) Introduce one more config option, like CONFIG_DYNAMIC_MACH_TYPE and change the patch to something like: #ifndef CONFIG_DYNAMIC_MACH_TYPE bi_arch_number = CONFIG_MACH_TYPE; #endif If we decide to go for 3), it would integrate nicely with Christopher's patch. So, what will it be? If it will be 1 and 2, then I'd like to get this patch in, so I can start working on 1. If it will be 3, then I want to make the change and resubmit, hoping for current merge window... I don't think two macros are needed for this. Either the board config file targets a single Linux machine ID and it defines CONFIG_MACH_TYPE, or it targets several and somewhere in the board init code it sets bi_arch_number to one of some MACH_TYPE_ values without defining CONFIG_MACH_TYPE, so this one macro is enough and ...DYNAMIC... would be redundant. Solution 1 would be the most correct IMO but is a lot of work for you as a submitter -- to be clear, I understand it as changing *every* board that sets bi_arch_number in board code to setting it in (lib and) config file. As much as I like it, I myself would hesitate to take on such an effort, so I will not force it upon you. Pragmatism against perfection: let's go for 2, then. Change the boards you intended to change, and from now on reviewers for any change to a board should point out the move to CONFIG_MACH_TYPE as mandatory. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fdt: introduce fdt_create_phandle()
On Jul 14, 2011, at 9:01 AM, Gerald Van Baren wrote: On 07/14/2011 09:31 AM, Kumar Gala wrote: On May 10, 2011, at 3:14 PM, Timur Tabi wrote: The ePAPR specification says that phandle properties should be called phandle, and not linux,phandle. To facilitate the migration from linux,phandle to phandle, introduce function fdt_create_phandle(), which creates a phandle in a given node. For now, we create both the phandle and linux,phandle properties. A later version of this function will remove support for linux,phandle. Signed-off-by: Timur Tabiti...@freescale.com --- common/fdt_support.c | 40 include/fdt_support.h |1 + 2 files changed, 41 insertions(+), 0 deletions(-) Jerry, Any comments on this? - k I put it in my todo list on patchworks. What I have queued are two patches from upstream 0329-Support-ePAPR-compliant-phandle-properties.patch 0344-libfdt-Implement-property-iteration-functions.patch and... [U-Boot,v2] Add uboot fdt_high enviroment variable 2011-07-09 David A. Long gvb New [U-Boot,2/2,v3] powerpc/85xx: add support the ePAPR phandle property 2011-05-10Timur Tabi gvb New [U-Boot,1/2] fdt: introduce fdt_create_phandle() 2011-05-10 Timur Tabi gvb New [U-Boot,1/2] fdt: add prototype for fdt_increase_size() 2011-05-03 Timur Tabigvb New [U-Boot,1/2,v2] fdt: introduce fdt_verify_alias_address() and fdt_get_base_address()2011-05-03 Timur Tabi gvb New I'd add: http://patchwork.ozlabs.org/patch/103598/ at least for a review/ack. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Hi again Igor, Le 14/07/2011 16:10, Albert ARIBAUD a écrit : Pragmatism against perfection: let's go for 2, then. Change the boards you intended to change, and from now on reviewers for any change to a board should point out the move to CONFIG_MACH_TYPE as mandatory. Forgot to mention: That makes patches 2/3 and 3/3 ok for acceptance, but can you post a V2 of patch 1/3 in which documentation of CONFIG_MACH_TYPE describes it as mandatory (and forbids direct setting of bi_arch_number) for board configs with a single machine-type? Thanks in advance, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] initramfs support through the initrd mechanism of u-boot
Currently the support of Linux initial file system by u-boot is a file system image through initrd. I tweaked a little of both the lib_arm/armlinux.c and the initramfs of Linux (a gziped cpio) so that the initramfs file could be passed to the kernel. For example: bootm c0008000 c1008000 will pass c1008000 to kernel as the start address of a initramfs. However in the Linux kernel it seems that it expects a physical address of initrd start, but u-boot passes a virtual address if MMU is enable. So a virt_to_phy should be used on the address before it is passed to the kernel. I'm currently using a Mini6410 (with Samsung S3C6410 CPU), an ARM board from China. Thanks, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3+] I2C: mxc_i2c rework
On Thursday, July 14, 2011 03:55:03 PM Albert ARIBAUD wrote: Hi Marek, Le 13/07/2011 23:58, Marek Vasut a écrit : V3+: Add commit ID into commit message What prevents a simple V4 here? No change in code ... but I suspect there'll be V4 anyway. Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] initramfs support through the initrd mechanism of u-boot
Hi Thomas, Le 14/07/2011 16:17, Cao, Da-Shi (EB-Presales-ZTE/HW-GZ) a écrit : Currently the support of Linux initial file system by u-boot is a file system image through initrd. I tweaked a little of both the lib_arm/armlinux.c and the initramfs of Linux (a gziped cpio) so that the initramfs file could be passed to the kernel. Not sure why you need this. Can you not simply make a uImage of the initrd and leave bootm untouched? For example: bootm c0008000 c1008000 will pass c1008000 to kernel as the start address of a initramfs. That's already what's being done except for the format of the initramfs IIUC, see http://www.denx.de/wiki/view/DULG/LinuxRamdiskRoot for instance. However in the Linux kernel it seems that it expects a physical address of initrd start, but u-boot passes a virtual address if MMU is enable. So a virt_to_phy should be used on the address before it is passed to the kernel. Hmm... This should be a problem anyway, whether you pass a gzipped CPIO or an U-Boot initrd image I guess. How do you get to this diagnostic? I'm currently using a Mini6410 (with Samsung S3C6410 CPU), an ARM board from China. Thanks, Thomas Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3+] I2C: mxc_i2c rework
Hi again Marek, Le 14/07/2011 16:35, Marek Vasut a écrit : On Thursday, July 14, 2011 03:55:03 PM Albert ARIBAUD wrote: Hi Marek, Le 13/07/2011 23:58, Marek Vasut a écrit : V3+: Add commit ID into commit message What prevents a simple V4 here? No change in code ... but I suspect there'll be V4 anyway. Introducing variations in patch numbering, especially non-numeric variations of what is expected to be a number, is IMO useful only for testing how resilient patch processing tools can be. :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: Fix device tree padding associated with ramdisk
Hi Kumar, Wolfgang
On 07/06/2011 09:16 PM, Kumar Gala wrote:
When booting with a ramdisk we bump the amount of memory reserved for
the device tree by FDT_RAMDISK_OVERHEAD. However we did not increase
the actual size in the device tree blob to match.
Its possible on boundary cases that we dont have enough memory according
to the device tree blob and get errors like:
WARNING: could not set linux,initrd-end FDT_ERR_NOSPACE
We can easily fix this by setting the device tree size at the same time
we bump the amount of memory reserved for the device tree.
Signed-off-by: Kumar Galaga...@kernel.crashing.org
---
arch/powerpc/lib/bootm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index e01787d..4e0cb8f 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -288,8 +288,10 @@ static int boot_body_linux(bootm_headers_t *images)
return ret;
of_size = ret;
- if (*initrd_start *initrd_end)
+ if (*initrd_start *initrd_end) {
of_size += FDT_RAMDISK_OVERHEAD;
+ fdt_set_totalsize(*of_flat_tree, of_size);
+ }
/* Create a new LMB reservation */
lmb_reserve(lmb, (ulong)*of_flat_tree, of_size);
This looks good to me. Since it is in bootm.c and not in libfdt, I'll
let Wolfgang pick it up unless I hear otherwise.
Acked-by: Gerald Van Baren vanba...@cideas.com
Thanks,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
On 07/14/11 17:20, Albert ARIBAUD wrote: Hi again Igor, Le 14/07/2011 16:10, Albert ARIBAUD a écrit : Pragmatism against perfection: let's go for 2, then. Change the boards you intended to change, and from now on reviewers for any change to a board should point out the move to CONFIG_MACH_TYPE as mandatory. Forgot to mention: That makes patches 2/3 and 3/3 ok for acceptance, but can you post a V2 of patch 1/3 in which documentation of CONFIG_MACH_TYPE describes it as mandatory (and forbids direct setting of bi_arch_number) for board configs with a single machine-type? Ok. I have to make it v2 anyway, because the setting of bi_arch_number in the board.c has to be moved to board_init_f() - before the init_sequence[] array is run. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] arm: add CONFIG_MACH_TYPE setting and documentation
CONFIG_MACH_TYPE is used to set the machine type number in the
common arm code instead of setting it in the board code.
Boards with dynamically discoverable machine types can still set the
machine type number in the board code.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
v2: Document the option as mandatory.
Move the bi_arch_number setting to board_init_f()
README | 10 ++
arch/arm/lib/board.c |4
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 446966d..0b6802d 100644
--- a/README
+++ b/README
@@ -442,6 +442,16 @@ The following options need to be configured:
crash. This is needed for buggy hardware (uc101) where
no pull down resistor is connected to the signal IDE5V_DD7.
+ CONFIG_MACH_TYPE[relevant for ARM only][mandatory]
+
+ This setting is mandatory for all boards that have only one
+ machine type and must be used to specify the machine type
+ number as it appears in the ARM machine registry
+ (see http://www.arm.linux.org.uk/developer/machines/).
+ Only boards that have multiple machine types supported
+ in a single configuration file and the machine type is
+ runtime discoverable, do not have to use this setting.
+
- vxWorks boot parameters:
bootvx constructs a valid bootline using the following
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 169dfeb..9901694 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -281,6 +281,10 @@ void board_init_f (ulong bootflag)
gd-mon_len = _bss_end_ofs;
+#ifdef CONFIG_MACH_TYPE
+ gd-bd-bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
+#endif
+
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
Hi Anton, Le 13/07/2011 18:47, Anton Staaf a écrit : I agree in general that it is preferable to be as explicit as possible. But it is also good to be able to express your intent, instead of implementation when possible. In other words, I would rather be explicit about my intent, than the particular implementation. Seems to me that for you, showing intent and implementation are necessarily exclusive; however, Wolfgang's examples indeed show implementation, but they show intent as well, at least for me they do. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm, lib/board.c: Coding Style cleanup
Hi Heiko,
Sorry for having kept this patch unanswered so long. I am now on
holiday, which means *a bit* more time for U-Boot, so here comes:
Re: patch title, can you make it arm: libboard.c: ... rather than
arm, libboard.c ?
Also, make sure you rebase onto latest u-boot-arm/master for next
version: this one does not apply cleanly ATM.
Le 03/06/2011 10:11, Heiko Schocher a écrit :
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -92,26 +92,28 @@ extern void rtl8019_get_enetaddr (uchar * addr);
* May be supplied by boards if desired
*/
-void inline __coloured_LED_init (void) {}
-void coloured_LED_init (void) __attribute__((weak,
alias(__coloured_LED_init)));
-void inline __red_LED_on (void) {}
-void red_LED_on (void) __attribute__((weak, alias(__red_LED_on)));
-void inline __red_LED_off(void) {}
+inline void __coloured_LED_init(void) {}
+void coloured_LED_init(void)
+__attribute__((weak, alias(__coloured_LED_init)));
If you break the declaration in several lines, please leave some
indentation in the second and subsequent lines.
+inline void __red_LED_on(void) {}
+void red_LED_on(void) __attribute__((weak, alias(__red_LED_on)));
+inline void __red_LED_off(void) {}
void red_LED_off(void) __attribute__((weak, alias(__red_LED_off)));
-void inline __green_LED_on(void) {}
+inline void __green_LED_on(void) {}
void green_LED_on(void) __attribute__((weak, alias(__green_LED_on)));
-void inline __green_LED_off(void) {}
+inline void __green_LED_off(void) {}
void green_LED_off(void) __attribute__((weak, alias(__green_LED_off)));
-void inline __yellow_LED_on(void) {}
+inline void __yellow_LED_on(void) {}
void yellow_LED_on(void) __attribute__((weak, alias(__yellow_LED_on)));
-void inline __yellow_LED_off(void) {}
+inline void __yellow_LED_off(void) {}
void yellow_LED_off(void) __attribute__((weak, alias(__yellow_LED_off)));
-void inline __blue_LED_on(void) {}
+inline void __blue_LED_on(void) {}
void blue_LED_on(void) __attribute__((weak, alias(__blue_LED_on)));
-void inline __blue_LED_off(void) {}
+inline void __blue_LED_off(void) {}
void blue_LED_off(void) __attribute__((weak, alias(__blue_LED_off)));
-/
+/*
+
* Init Utilities *
* Some of this code should be moved into the core functions,
@@ -485,34 +490,37 @@ void board_init_r (gd_t *id, ulong dest_addr)
mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
#if !defined(CONFIG_SYS_NO_FLASH)
- puts (Flash: );
+ puts(Flash: );
- if ((flash_size = flash_init ()) 0) {
+ flash_size = flash_init();
+ if (flash_size 0) {
# ifdef CONFIG_SYS_FLASH_CHECKSUM
- print_size (flash_size, );
+ print_size(flash_size, );
/*
* Compute and print flash CRC if flashchecksum is set to 'y'
*
* NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
*/
- s = getenv (flashchecksum);
+ s = getenv(flashchecksum);
if (s (*s == 'y')) {
- printf ( CRC: %08X,
- crc32 (0, (const unsigned char *)
CONFIG_SYS_FLASH_BASE, flash_size)
+ printf( CRC: %08X,
+ crc32(0,
+ (const unsigned char *) CONFIG_SYS_FLASH_BASE,
+ flash_size)
Pleas indent deeper for the last two lines that belong to the call to crc32.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 01/16] [Timer]Fix misuse of ARM *timer_masked() functions outside arch/arm
Hi Wolfgang, Le 11/07/2011 23:57, Wolfgang Denk a écrit : Dear Graeme Russ, In message1309261269-4363-2-git-send-email-graeme.r...@gmail.com you wrote: Signed-off-by: Graeme Russgraeme.r...@gmail.com I consider this a bug fix, independent from the other dicussion. This should be applied in any case. Acked-by: Wolfgang Denkw...@denx.de Best regards, Wolfgang Denk Patch applies on u-boot-arm/master except for 4 files which are not found: board/ixdp425/flash.c, removed by commit 973af335e61eede3578371330abd3971805887f5, update/fix IXDP425 / IXDPG425 boards board/mpl/vcma9/flash.c: removed by commit 6d754843ff62312999a265162c67588913cab991, VCMA9: use CFI driver (and remove the old one) board/trab/cmd_trab.c and board/trab/flash.c: removed by commit 566e5cf451ae7e33e31bb62ae5b9b258e33f8609, ARM: drop unsupported 'trab' board If this is fine with everyone, I can pull this patch in u-boot-arm/master despite the four errors. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
On Thu, Jul 14, 2011 at 9:00 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Anton, Le 13/07/2011 18:47, Anton Staaf a écrit : I agree in general that it is preferable to be as explicit as possible. But it is also good to be able to express your intent, instead of implementation when possible. In other words, I would rather be explicit about my intent, than the particular implementation. Seems to me that for you, showing intent and implementation are necessarily exclusive; however, Wolfgang's examples indeed show implementation, but they show intent as well, at least for me they do. I'm not sure which example you mean. If you mean his #define of the masks explicitly, those are fine by me. My above statement is about the masking, oring and shifting that is done in the same way every time and could be encoded in a macro that makes it easier to see what exactly is going on. Or did I misunderstand which example you mean? Thanks, Anton Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] integratorap: disable dcache
On Thu, Jul 14, 2011 at 1:39 PM, Wolfgang Denk w...@denx.de wrote: Sorry, but again I have to point out that I really dislike papering over existing bugs. If the disable D-cache in bootm does not work, _this_ should be analyzed and fixed instead of globally disabling he data cache. No problem, I didn't label it as RFC since what it does is actually fix a regression. At one point U-boot was working on the Integrator and now it doesn't, it seems commit 880eff5cfb9df6f0855f4e48affd349ca64692e9 ARM: cp15: setup mmu and enable dcache is causing it. Heiko, Alessandro, do you have any hints on how to go about flushing and disabling the D-cache in bootm for ARM920T? It doesn't seem to work on this ARM CPU chip in its current form... Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On Thursday, July 14, 2011 05:14:07 Helmut Raiger wrote: On 07/13/2011 01:46 PM, Detlev Zundel wrote: The NDEBUG approach however, as Mike suggested, was what I was looking for in the first place. Again, not so great. U-boot uses all kinds of assert(), BUG_ON(), ASSERT() all over the place. This probably needs a project wide effort, which is why I simply threw in my NULL pointer check. we tend to look at the long term picture with the best/correct solution rather than one-offs which get thrown away in the end -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/4] ARM: Warn when the machine ID isn't set.
Linux cannot boot without it.
Signed-off-by: Christopher Harvey char...@matrox.com
---
V2:
Used a #define instead of a constant.
Used a printf instead of a debug.
---
V3:
Moved gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID; before the
init_sequence loop, so it doesn't overwrite existing values.
Removed unneeded braces.
Reminder, in V2 of this series there are 3 uncommited patches that
have no comments.
arch/arm/include/asm/u-boot.h |2 ++
arch/arm/lib/board.c |2 ++
arch/arm/lib/bootm.c |5 +
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index ed33327..81735de 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -48,4 +48,6 @@ typedef struct bd_info {
} bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#define BI_ARCH_NUMBER_INVALID 0x
+
#endif /* _U_BOOT_H_ */
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index fc52a26..1635aa1 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -281,6 +281,8 @@ void board_init_f (ulong bootflag)
gd-mon_len = _bss_end_ofs;
+ gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID;
+
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..8e75b5a 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,11 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if (machid == BI_ARCH_NUMBER_INVALID)
+ printf(Warning: machid not set.\n);
+#endif
+
show_boot_progress (15);
#ifdef CONFIG_OF_LIBFDT
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] miiphy: use strcpy() not sprintf()
On Thursday, July 14, 2011 09:49:23 Albert ARIBAUD wrote: Le 14/07/2011 14:31, Laurence Withers a écrit : In miiphy_register() the new device's name was initialised by passing a string parameter as the format string to sprintf(). As this would cause problems if it ever contained a '%' symbol, switch to using strcpy() instead. Please use strncpy() which will also guard against overflows. or BUG_ON(strlen(name) = MDIO_NAME_LEN) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] integratorap: remove hardcoded 32MB memory cmdline
On Thu, Jul 14, 2011 at 1:44 PM, Wolfgang Denk w...@denx.de wrote: --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h Please make sure to Cc: the board maintainer! Aw yes, that's one thing. Peter, are you still looking after the Integrator AP board support in U-boot? I mailed with Philippe who said ARM dropped support for the Integrator board, and given the state of the code in U-boot (doesn't compile, doesn't work) I might be the only one actually looking after it in practice. I'm happy to take over maintenance of it for a while atleast, if I have yours and/or Philippe's ACK. Thanks, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] post: fix indendation/brace confusion
From: James Kosin jko...@intcomgrp.com
The post.c code is missing braces around the pass case, and as a
result, the diagnostic function will post both fail and pass for
a failed test. The reason for this bug is probably the incorrect
indentation used, so when reading the code it seems like there
are proper braces.
Indent the code to the correct depth and put proper braces around
the else branch of the if statement.
Signed-off-by: James Kosin jko...@intcomgrp.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
post/post.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/post/post.c b/post/post.c
index 7660224..852d6a5 100644
--- a/post/post.c
+++ b/post/post.c
@@ -293,18 +293,18 @@ static int post_run_single (struct post_test *test,
gd-flags |= GD_FLG_POSTSTOP;
}
} else {
- if ((*test-test) (flags) != 0) {
- post_log (FAILED\n);
- show_boot_progress (-32);
- show_post_progress(i, POST_AFTER, POST_FAILED);
- if (test_flags POST_CRITICAL)
- gd-flags |= GD_FLG_POSTFAIL;
- if (test_flags POST_STOP)
- gd-flags |= GD_FLG_POSTSTOP;
- }
- else
- post_log (PASSED\n);
- show_post_progress(i, POST_AFTER, POST_PASSED);
+ if ((*test-test)(flags) != 0) {
+ post_log(FAILED\n);
+ show_boot_progress(-32);
+ show_post_progress(i, POST_AFTER, POST_FAILED);
+ if (test_flags POST_CRITICAL)
+ gd-flags |= GD_FLG_POSTFAIL;
+ if (test_flags POST_STOP)
+ gd-flags |= GD_FLG_POSTSTOP;
+ } else {
+ post_log(PASSED\n);
+ show_post_progress(i, POST_AFTER, POST_PASSED);
+ }
}
if ((test_flags POST_REBOOT) !(flags POST_MANUAL)) {
--
1.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On Wednesday, July 13, 2011 02:32:37 Helmut Raiger wrote: for future reference, please dont send html e-mails -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
Le 14/07/2011 19:29, Anton Staaf a écrit : On Thu, Jul 14, 2011 at 9:00 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Anton, Le 13/07/2011 18:47, Anton Staaf a écrit : I agree in general that it is preferable to be as explicit as possible. But it is also good to be able to express your intent, instead of implementation when possible. In other words, I would rather be explicit about my intent, than the particular implementation. Seems to me that for you, showing intent and implementation are necessarily exclusive; however, Wolfgang's examples indeed show implementation, but they show intent as well, at least for me they do. I'm not sure which example you mean. If you mean his #define of the masks explicitly, those are fine by me. My above statement is about the masking, oring and shifting that is done in the same way every time and could be encoded in a macro that makes it easier to see what exactly is going on. Or did I misunderstand which example you mean? You did not misunderstand the example -- but the way you just stated what you think of it is, I think, a confirmation of what I said: that it is your approach of the issue which is at odds with Wolfgang's and mine. Let us look at the terms you've just use to describe what you dislike : these are 'masking, oring and shifting' and 'done the same way every time'. I assume the second is not a criticism, but the foundation for suggesting a macro. That leaves 'masking, oring and shifting': it seems like for you it is unclear what this does, but it *does* tell what is going on just as much as a bitfield macro would -- actually it tells more, because '(x y) | z' (there is usually no shifting involved, BTW) is a design pattern in embedded software development, where this pattern is recognized at first sight for what it does -- at least I see them that way and Wolfgang probably does as well. Granted, a non-specialist in embedded SW might have problems understanding this, but U-Boot has more or less a requirement that developers contributing to it have some knowledge of embedded SW. The 'done in the same way every time' part, OTOH, might make sense -- that's code factorization, after all. But you could say the same of, for instance, assignments from structure members: they're done the same way every time : 'x = y.z', but there would be little point in wanting to hide that in a macro, because the macro would not add enough value. I think that's the main problem: a bitfield macro for computing masks and shifts and anding and oring would not add sufficient value with respect to the bare expression, which is still simple enough to be understood by most readers. (plus the issue of portability raised by Wolfgang, which I won't delve into as he's already developed it) Thanks, Anton HTH. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
Dear Anton Staaf, In message CAF6FioWbAvTnL0m2ch4Xd5O51bp7SX=llopg0dxnszsfwvv...@mail.gmail.com you wrote: I'm not sure which example you mean. If you mean his #define of the masks explicitly, those are fine by me. My above statement is about the masking, oring and shifting that is done in the same way every time and could be encoded in a macro that makes it easier to see what exactly is going on. Or did I misunderstand which example you mean? I disagree with your statement that such a macro makes it easier to see what exactly is going on. On contrary, such a macro would _hide_ what is going on. This may be ok and even intentional in some places, but here it is not helpful, even if it seems so you you. Quote Larry Wall (from the perlstyle(1) man page): Even if you aren't in doubt, consider the mental welfare of the per- son who has to maintain the code after you ... 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 Our business is run on trust. We trust you will pay in advance. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
On Thu, Jul 14, 2011 at 11:30 AM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message CAF6FioWbAvTnL0m2ch4Xd5O51bp7SX=llopg0dxnszsfwvv...@mail.gmail.com you wrote: I'm not sure which example you mean. If you mean his #define of the masks explicitly, those are fine by me. My above statement is about the masking, oring and shifting that is done in the same way every time and could be encoded in a macro that makes it easier to see what exactly is going on. Or did I misunderstand which example you mean? I disagree with your statement that such a macro makes it easier to see what exactly is going on. On contrary, such a macro would _hide_ what is going on. This may be ok and even intentional in some places, but here it is not helpful, even if it seems so you you. OK, I'm content to disagree on this and do it your way. :) I can do it my way on my projects. Thanks for the discussion. Quote Larry Wall (from the perlstyle(1) man page): Even if you aren't in doubt, consider the mental welfare of the per- son who has to maintain the code after you ... Taking style guides from Larry is not high on my list by the way. :) Thanks, Anton 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 Our business is run on trust. We trust you will pay in advance. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
Dear Anton Staaf, In message CAF6FioVOEuNcEsr=3jyxovs__do3ox+q00pndbrhdu+umjz...@mail.gmail.com you wrote: In both cases the value 20 needs to come from somewhere. So you would probably end up having: #define SCFR1_IPS_DIV_MASK 0x0380 #define SCFR1_IPS_DIV_SHIFT 20 and (value SCFR1_IPS_DIV_MASK) SCFR1_IPS_DIV_SHIFT (value ~SCFR1_IPS_DIV_MASK) | (5 SCFR1_IPS_DIV_SHIFT) BTW - you are correct about this. The file I grabbed the examples from is arch/powerpc/include/asm/immap_512x.h; here is the full context: 229 /* SCFR1 System Clock Frequency Register 1 */ 230 #define SCFR1_IPS_DIV 0x3 231 #define SCFR1_IPS_DIV_MASK 0x0380 232 #define SCFR1_IPS_DIV_SHIFT 23 233 234 #define SCFR1_PCI_DIV 0x6 235 #define SCFR1_PCI_DIV_MASK 0x0070 236 #define SCFR1_PCI_DIV_SHIFT 20 237 238 #define SCFR1_LPC_DIV_MASK 0x3800 239 #define SCFR1_LPC_DIV_SHIFT 11 240 241 /* SCFR2 System Clock Frequency Register 2 */ 242 #define SCFR2_SYS_DIV 0xFC00 243 #define SCFR2_SYS_DIV_SHIFT 26 And indeed we see code using this for example in arch/powerpc/cpu/mpc512x/speed.c: 98 reg = in_be32(im-clk.scfr[0]); 99 ips_div = (reg SCFR1_IPS_DIV_MASK) SCFR1_IPS_DIV_SHIFT; The nice thing (for me) here is, that without even thinking for a second I know exactly what is going on - there is nothing in this statements that require me too look up some macro definition. [Yes, of course this is based on the assumption that macro names register_MASK and register_SHIFT just do what they are suggest they are doing. But any such things get filtered out during the reviews.] 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 Vulcans never bluff. -- Spock, The Doomsday Machine, stardate 4202.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thursday, July 14, 2011, David Long dave.l...@linaro.org wrote: On Thu, 2011-07-14 at 09:10 -0400, Jerry Van Baren wrote: Hi Dave, This looks reasonable, with one minor nit... Need spaces around the = I will add the spaces before applying the patch unless you send an updated patch. OK, thanks much. Someone else recently pointed that out to me too. I can generate another update if you wish, but I'll let you handle that unless you say otherwise. FYI: In case it wasn't clear, this all came about because: 1) the Pandaboard has 1GB of RAM; 2) the presence of an fdt causes u-boot to relocate the fdt and ramdisk to the end of ram by default; 3) and the Linux kernel does not like having to access memory beyond about 3/4G (HIGHMEM) during early boot. Regardless of this patch, the pandaboard uboot still needs to be fixed. Setting an fdt_high variable is useful for debug, but it is not a fix. g. -dl -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BDI2000 configuration for P2020DS
Hi everyone, Does anyone have a BDI2000 configuration for the P2020DS that they could share with me? The documentation Freescale sent me claims that U-Boot is in a 4MB SPI flash, however, the U-Boot that came with the board is unable to initialize the SPI subsystem per their instructions. = sf probe 0 SF: Unsupported Manufacturer 00 Failed to initialize SPI flash at 0:0 I thought I'd use the BDI2000 to dump a copy of their U-Boot before I replace it with my own, just for good measure. Thank you, Ira ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/4] ARM: Warn when the machine ID isn't set.
Hi Christopher,
On 07/14/11 21:02, Christopher Harvey wrote:
Linux cannot boot without it.
Signed-off-by: Christopher Harvey char...@matrox.com
---
V2:
Used a #define instead of a constant.
Used a printf instead of a debug.
---
V3:
Moved gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID; before the
init_sequence loop, so it doesn't overwrite existing values.
Removed unneeded braces.
This one looks fine, except that you keep ignoring my question...
Please, see below
Reminder, in V2 of this series there are 3 uncommited patches that
have no comments.
arch/arm/include/asm/u-boot.h |2 ++
arch/arm/lib/board.c |2 ++
arch/arm/lib/bootm.c |5 +
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index ed33327..81735de 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -48,4 +48,6 @@ typedef struct bd_info {
}bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#define BI_ARCH_NUMBER_INVALID 0x
+
#endif /* _U_BOOT_H_ */
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index fc52a26..1635aa1 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -281,6 +281,8 @@ void board_init_f (ulong bootflag)
gd-mon_len = _bss_end_ofs;
+ gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID;
+
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..8e75b5a 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,11 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if (machid == BI_ARCH_NUMBER_INVALID)
+ printf(Warning: machid not set.\n);
+#endif
+
Is it essential to enclose that check in #ifdef DEBUG?
IMHO, it can be useful also with no DEBUG defined,
so I'd add it without the #ifdef DEBUG.
Also, in the printf line, you are mixing tabs with spaces
(sorry for not noticing this in previous versions...).
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Fri, 2011-07-15 at 03:50 +0900, Grant Likely wrote: Regardless of this patch, the pandaboard uboot still needs to be fixed. Setting an fdt_high variable is useful for debug, but it is not a fix. Then someone needs to own the issue of stopping the current u-boot default behavior of relocating the initrd and fdt to the end of RAM when an fdt is present. This is an issue for any Linux ARM system with more than 3/4GB of RAM, and probably for other 32-bit architectures. The logic that causes the problem is in architecture-independent code, and I'm not sure I'm necessarily the right guy to go rummaging around in there. There are too many implications for any other currently supported targets that use u-boot and fdt. This new u-boot environment variable stands on it's own as potentially useful, and allows us to avoid the problem (admittedly by specifying environment variable values that really should be the default in this case). -dl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Dear Graeme Russ,
In message 4e1ce6ec.1030...@gmail.com you wrote:
Also remember that if we are looking to inherit nanosecond time base from
Linux, it will be extremely unlikely that every board will support a native
1ns clock source. Typical examples would be 33MHz (~30ns) or 66MHz (~15ns).
In any case, there will be a lot of variance between boards, so we will
still need to cater for arbitrary resolutions
Please note that Linux makes no assumption of a 1 ns clock source. We
should hav eno problems on this front.
It's just macros. And we don't need to use them all. Actually
time_after() is all that's needed to satisfy our current usage.
Oh please, macro, inline function, function - They are all API 'functions'
- As you stated before, the bigger the API, the more people will abuse is
by using the wrong functions. You stated that you want to keep the public
profile of the API as small and tight as possible by rejecting the
additional functions previously proposed.
OK, so let's start with time_after() only.
Agreed - As said before (for the time being) the return value of any
arbitrary call to time() means nothing. It _may_ mean the number of
nanoseconds since power-up, but this is by no means guaranteed.
Actually, I do agree will Bill - time() is probably not the best name -
get_current_ns() or similar may be more meaningful (I still have not had a
chance to look at the Linux code)
If you don't want to use time, then let's use get_time() please - this
is close enough to the existing name so everybody familiar with the
code recognizes it immediately.
void udelay(u32 usec)
{
u64 then = time() + (u64)usec * (u64)1000;
while (!time_after(time(), then))
... do something, like trigger watchdogs etc ...
}
Yes, that is how I always imagined udelay()
...except that udelay() is guaranteed to be available very early in
the initialization sequence, long before we have normal timer
services which may - for example - be interrupt based.
For 'elapsed time' it should be sufficient to store the start value of
time() as early as possible in the (architecture specific) code.
I did mean 'elapsed between two code locations' such as profiling the init
functions - That was what API function #3 was all about.
Sounds trivial: store the value of time() and the begin and the end
of the interval and compute the difference?
OK, this is a new philosophy for the mix. I think it is a good one for the
record. But since we will always use time_after(time(), then) why don't we
simplify it to:
u64 start = time();
...
if (time_elapsed_since(start, TIMEOUT)) {
/* handle timeout */
}
This does not fit. time_elapsed_since() suggests it returns the length
of the interval, i. e. a number of tiume units - but it does something
different.
I like the time_after() approach very much because it does exactly
what the name says, and nothing more - so you can use it in a number
of ways - I recognise good old UNIX philosophy here: do one simple
thing, and do it well.
Regarding the we will always use time_after(time() ...) - we might
want to check if we really have to use time() here (and in a number of
other places - or if we can manage to come up with a simple timestamp
variable, similar to what jiffies is in Linux. That would simplify
the code even further. [Maybe #define jiffies time()? ;-) }
Do we? What exactly is the needed resolution of the underlying
hardware timer? So far, it appears sufficient to have it ticking with
1000 Hz or more. Are there really systems that cannot provide that?
The only architecture I remember that seemed prolematic was NIOS - but
then the NIOS documentation suggests that this might actually be
solvable.
Yes, but as stated before, there is a FPGA gate count trade-off which may
not always be possible. Plus, you break existing boards
Understood. Well, how work the Linux timers on these boards, then?
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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Dear J. William Campbell, In message 4e1cf2e0.1030...@comcast.net you wrote: Yes, this is true. However, the time_elapsed_since routine can do this dynamically (i.e. add twice the timer resolution) . I think you had That would IMHO be a very bad idea. We have a number of places where we have to deal with pretty long timeouts (usually because of protocol specifications that require this - often in the order of several seconds), where the normal path is very fast. The typical approach is to break the timeout into a large number of very short loops. Sometimes we use udelay() for this, other places use get_timer(). So assume we have a timeout of 5 seconds, and implement this as 50,000 loops of 100 microseconds. If you silently turn each of these into 20 milliseconds on NIOS, the timeout would become 1,000 seconds instead of 5 - users would return boards as broken and report it just freezes because nobody expects that it will wake up again after some 16 minutes. another function name (at_least) involved, but you can define time_elapsed_since as always compensating for the resolution. That will fix any resolution questions in a processor-specific way. It is either that or the ifdefs. One way or another, the resolution must be addressed. Up to now, the implicit resolution has been 1 ms, but we now know that is not general enough. It's not as simple as this. You have to change a lot of code to make this work for such slow clock systems. 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 Sometimes a man will tell his bartender things he'll never tell his doctor. -- Dr. Phillip Boyce, The Menagerie (The Cage), stardate unknown. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 14 Jul 2011 15:12:25 -0400 David Long dave.l...@linaro.org wrote: On Fri, 2011-07-15 at 03:50 +0900, Grant Likely wrote: Regardless of this patch, the pandaboard uboot still needs to be fixed. Setting an fdt_high variable is useful for debug, but it is not a fix. Then someone needs to own the issue of stopping the current u-boot default behavior of relocating the initrd and fdt to the end of RAM when an fdt is present. This is an issue for any Linux ARM system with more than 3/4GB of RAM, and probably for other 32-bit architectures. The logic that causes the problem is in architecture-independent code, and I'm not sure I'm necessarily the right guy to go rummaging around in there. There are too many implications for any other currently supported targets that use u-boot and fdt. You need to use lmb_reserve() to exclude any memory regions that are not suitable for boot images -- see powerpc's arch_lmb_reserve() and get_effective_memsize()/CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE. -scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] post: fix indendation/brace confusion
Thanks Mike for this...
I was making changes and wasn't sure why I added a call to remember the
post results for event the manual tests; so, I could do a report for
production purposes ... anyway my code was always marking the tests as
passed even if they failed which is how I caught this.
James Kosin
On 7/14/2011 2:15 PM, Mike Frysinger wrote:
From: James Kosin jko...@intcomgrp.com
The post.c code is missing braces around the pass case, and as a
result, the diagnostic function will post both fail and pass for
a failed test. The reason for this bug is probably the incorrect
indentation used, so when reading the code it seems like there
are proper braces.
Indent the code to the correct depth and put proper braces around
the else branch of the if statement.
Signed-off-by: James Kosin jko...@intcomgrp.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
post/post.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/post/post.c b/post/post.c
index 7660224..852d6a5 100644
--- a/post/post.c
+++ b/post/post.c
@@ -293,18 +293,18 @@ static int post_run_single (struct post_test *test,
gd-flags |= GD_FLG_POSTSTOP;
}
} else {
- if ((*test-test) (flags) != 0) {
- post_log (FAILED\n);
- show_boot_progress (-32);
- show_post_progress(i, POST_AFTER, POST_FAILED);
- if (test_flags POST_CRITICAL)
- gd-flags |= GD_FLG_POSTFAIL;
- if (test_flags POST_STOP)
- gd-flags |= GD_FLG_POSTSTOP;
- }
- else
- post_log (PASSED\n);
- show_post_progress(i, POST_AFTER, POST_PASSED);
+ if ((*test-test)(flags) != 0) {
+ post_log(FAILED\n);
+ show_boot_progress(-32);
+ show_post_progress(i, POST_AFTER, POST_FAILED);
+ if (test_flags POST_CRITICAL)
+ gd-flags |= GD_FLG_POSTFAIL;
+ if (test_flags POST_STOP)
+ gd-flags |= GD_FLG_POSTSTOP;
+ } else {
+ post_log(PASSED\n);
+ show_post_progress(i, POST_AFTER, POST_PASSED);
+ }
}
if ((test_flags POST_REBOOT) !(flags POST_MANUAL)) {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI2000 configuration for P2020DS
Dear Ira W. Snyder, In message 20110714185958.ge19...@ovro.caltech.edu you wrote: Does anyone have a BDI2000 configuration for the P2020DS that they could share with me? Abatron ships a p2020ds.cfg with their firmware for the BDI. Do you think this is not working or not good enough? The documentation Freescale sent me claims that U-Boot is in a 4MB SPI flash, however, the U-Boot that came with the board is unable to initialize the SPI subsystem per their instructions. ... I thought I'd use the BDI2000 to dump a copy of their U-Boot before I replace it with my own, just for good measure. Well, if it's really in SPI flash, then the BDI will not help you to dump it. The BDI cannot access SPI flash directly. 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 complex system that works is invariably found to have evolved from a simple system that worked. - John Gall, _Systemantics_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 01/16] [Timer]Fix misuse of ARM *timer_masked() functions outside arch/arm
Dear Albert ARIBAUD, In message 4e1f2100.2030...@aribaud.net you wrote: Patch applies on u-boot-arm/master except for 4 files which are not found: board/ixdp425/flash.c, removed by commit 973af335e61eede3578371330abd3971805887f5, update/fix IXDP425 / IXDPG425 boards board/mpl/vcma9/flash.c: removed by commit 6d754843ff62312999a265162c67588913cab991, VCMA9: use CFI driver (and remove the old one) board/trab/cmd_trab.c and board/trab/flash.c: removed by commit 566e5cf451ae7e33e31bb62ae5b9b258e33f8609, ARM: drop unsupported 'trab' board If this is fine with everyone, I can pull this patch in u-boot-arm/master despite the four errors. Please do. These files were all correctly removed recently. 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 In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find ... - Terry Pratchett, _Sourcery_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI2000 configuration for P2020DS
On Thu, Jul 14, 2011 at 09:45:37PM +0200, Wolfgang Denk wrote: Dear Ira W. Snyder, In message 20110714185958.ge19...@ovro.caltech.edu you wrote: Does anyone have a BDI2000 configuration for the P2020DS that they could share with me? Abatron ships a p2020ds.cfg with their firmware for the BDI. Do you think this is not working or not good enough? It says, right at the top: ; The values used to configure the memory controller ; are the ones U-boot uses to setup my system. ; Your system may need different ones !!! ; ; This configuration is not usable for U-boot debugging. ; Use it to debug example code loaded into SDRAM. I'm hoping for a configuration that can program the flash on a bricked board. Then I can flash anything I want without fear of rendering an expensive board useless. The documentation Freescale sent me claims that U-Boot is in a 4MB SPI flash, however, the U-Boot that came with the board is unable to initialize the SPI subsystem per their instructions. ... I thought I'd use the BDI2000 to dump a copy of their U-Boot before I replace it with my own, just for good measure. Well, if it's really in SPI flash, then the BDI will not help you to dump it. The BDI cannot access SPI flash directly. Thanks for the information. Ira ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 0/9] Prototype for generic SPL framework
Dear Daniel Schwierzeck, In message 1310569869-31810-1-git-send-email-daniel.schwierz...@googlemail.com you wrote: This patch series is the final proposal from Aneesh and myself for a generic SPL framework. The implementation already works and have been tested with in-tree and out-of-tree builds. The latest feedback from ML is already included. How it works ... It seems useful to add this How it works part as a new doc/README.SPL ; could you please add this? Also, the new CONFIG_SPL_* variables must be documented in the README. 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 You don't need a weatherman to know which way the wind blows. - Bob Dylan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
On Thu, Jul 14, 2011 at 11:44 AM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message CAF6FioVOEuNcEsr=3jyxovs__do3ox+q00pndbrhdu+umjz...@mail.gmail.com you wrote: In both cases the value 20 needs to come from somewhere. So you would probably end up having: #define SCFR1_IPS_DIV_MASK 0x0380 #define SCFR1_IPS_DIV_SHIFT 20 and (value SCFR1_IPS_DIV_MASK) SCFR1_IPS_DIV_SHIFT (value ~SCFR1_IPS_DIV_MASK) | (5 SCFR1_IPS_DIV_SHIFT) BTW - you are correct about this. The file I grabbed the examples from is arch/powerpc/include/asm/immap_512x.h; here is the full context: 229 /* SCFR1 System Clock Frequency Register 1 */ 230 #define SCFR1_IPS_DIV 0x3 231 #define SCFR1_IPS_DIV_MASK 0x0380 232 #define SCFR1_IPS_DIV_SHIFT 23 233 234 #define SCFR1_PCI_DIV 0x6 235 #define SCFR1_PCI_DIV_MASK 0x0070 236 #define SCFR1_PCI_DIV_SHIFT 20 237 238 #define SCFR1_LPC_DIV_MASK 0x3800 239 #define SCFR1_LPC_DIV_SHIFT 11 240 241 /* SCFR2 System Clock Frequency Register 2 */ 242 #define SCFR2_SYS_DIV 0xFC00 243 #define SCFR2_SYS_DIV_SHIFT 26 And indeed we see code using this for example in arch/powerpc/cpu/mpc512x/speed.c: 98 reg = in_be32(im-clk.scfr[0]); 99 ips_div = (reg SCFR1_IPS_DIV_MASK) SCFR1_IPS_DIV_SHIFT; I agree, this line is completely obvious and if it were the only sort of GET (or it's equivalent SET) version used I wouldn't have suggested the macro at all. It's the lines that are setting many fields simultaneously, sometimes with constant field values and sometimes with computed values that become a bit hard to parse, and would benefit from the abstraction. But good coding practice can break these statements up into a collection of simple ones to do the manipulations one at a time. Then the real benefit of the macro becomes a compression of the syntax, leading to shorter functions, and in my option a reduced time to parse and understand the actions. But as you say, it hides part of the implementation, but this is also true for any other function, such as the fact that writel does a memory barrier. But such functions are part of the existing U-Boot knowledge base, so their behavior is expected and understood by it's users. I see no reason that the same could not eventually be the case for field access macros. But as I've said, I'm OK with dropping this. Any indication above to the prior is simply me being an engineer who perceives a problem that I can solve and desiring to have my perspective validated. :) And now back to sending actual useful patches to the list. Thanks, Anton The nice thing (for me) here is, that without even thinking for a second I know exactly what is going on - there is nothing in this statements that require me too look up some macro definition. [Yes, of course this is based on the assumption that macro names register_MASK and register_SHIFT just do what they are suggest they are doing. But any such things get filtered out during the reviews.] 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 Vulcans never bluff. -- Spock, The Doomsday Machine, stardate 4202.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] gpio command: return value on write, additional actions
On Wednesday, July 06, 2011 06:36:00 Wolfgang Denk wrote: For consistency I would prefer to have all commands return the same type of information, i. e. either an error status (like we do with all other commands - any result values would then have to be passed as environment settings) going through the env seems a little wonky. i dont know of any other commands that do this, so i dont think there's any standard to work off of here ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 2011-07-14 at 14:43 -0500, Scott Wood wrote: You need to use lmb_reserve() to exclude any memory regions that are not suitable for boot images -- see powerpc's arch_lmb_reserve() and get_effective_memsize()/CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE. If one excludes HIGHMEM from the area u-boot is allowed to relocate the fdt/initrd to, then it will put it at the end of the 3/4GB boundary (can one exclude all memory above the kernel start address?). This splits memory into three, instead of two regions in the kernel. I don't think that split ever goes away. Then there's the additional region we already have to create for the Ducati memory. That's at least five memory regions total. There are only eight regions currently allowed by default. I don't have a feel for the implications of this, but it seems unnecessary. Again, I don't think the problem is where u-boot relocates this data TOO, but the fact that the new default is to relocate it at all. Is there a reason for relocating this stuff? The initrd always used to be happy left where it was. -dl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI2000 configuration for P2020DS
Dear Ira W. Snyder, In message 20110714195525.gf19...@ovro.caltech.edu you wrote: It says, right at the top: ; The values used to configure the memory controller ; are the ones U-boot uses to setup my system. ; Your system may need different ones !!! ; ; This configuration is not usable for U-boot debugging. ; Use it to debug example code loaded into SDRAM. Correct. For U-Boot debugging, you will normally remove / comment out all such config stuff anyway. Please see the manual. I'm hoping for a configuration that can program the flash on a bricked board. Then I can flash anything I want without fear of rendering an expensive board useless. If your code is really in SPI flash then you need to be able to initialize the RAM and load and start U-Boot theree, because the BDI cannot write SPI flash directly. 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 Pray: To ask that the laws of the universe be annulled in behalf of a single petitioner confessedly unworthy. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 0/9] Prototype for generic SPL framework
Dear Daniel Schwierzeck, In message 1310569869-31810-1-git-send-email-daniel.schwierz...@googlemail.com you wrote: This patch series is the final proposal from Aneesh and myself for a generic SPL framework. The implementation already works and have been tested with in-tree and out-of-tree builds. The latest feedback from ML is already included. I read your patches, and except to the documentation commetns I already made I have but only one question (I did not spend enough time to figure this out myself, sorry): Do you think the split of the patches is OK, i. e. do we maintain bisectability ? Assuming you reply yes, and add the docs I aseked for, you have my: Acked-by: Wolfgang Denk w...@denx.de 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 Gewöhnlich glaubt der Mensch, wenn er nur Worte hört, es müsse sich dabei doch auch was denken lassen. -- Goethe, Faust I ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI2000 configuration for P2020DS
On Thu, Jul 14, 2011 at 1:59 PM, Ira W. Snyder i...@ovro.caltech.edu wrote: The documentation Freescale sent me claims that U-Boot is in a 4MB SPI flash, however, the U-Boot that came with the board is unable to initialize the SPI subsystem per their instructions. = sf probe 0 SF: Unsupported Manufacturer 00 Failed to initialize SPI flash at 0:0 SPI is working for me. What version of u-boot are you running? Can you paste your boot log? -M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Correct CONFIG_(SYS_)CONSOLE_INFO_QUIET rename ommissions
Dear Albert, In message 1301393738-17625-1-git-send-email-gryr...@gmail.com Gray Remlin wrote: Correct some ommissions of renaming CONFIG_CONSOLE_INFO_QUIET to CONFIG_SYS_CONSOLE_INFO_QUIET Signed-off-by: Gray Remlin gryr...@gmail.com --- include/configs/edminiv2.h |2 +- include/configs/km_arm.h|2 +- include/configs/mv-common.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Do you have this patch on your list? In Patchwork: 88742 New [U-Boot] ARM: Correct CONFIG_(SYS_)CONSOLE_INFO_QUIET rename ommissions 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 Be careful what you wish for. You never know who will be listening. - Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 14 Jul 2011 16:09:16 -0400 David Long dave.l...@linaro.org wrote: On Thu, 2011-07-14 at 14:43 -0500, Scott Wood wrote: You need to use lmb_reserve() to exclude any memory regions that are not suitable for boot images -- see powerpc's arch_lmb_reserve() and get_effective_memsize()/CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE. If one excludes HIGHMEM from the area u-boot is allowed to relocate the fdt/initrd to, then it will put it at the end of the 3/4GB boundary (can one exclude all memory above the kernel start address?). You have memory below where the kernel is loaded? This splits memory into three, instead of two regions in the kernel. I don't think that split ever goes away. Then there's the additional region we already have to create for the Ducati memory. That's at least five memory regions total. There are only eight regions currently allowed by default. I don't have a feel for the implications of this, but it seems unnecessary. What do you mean by a region here, and why can there only be eight of them? Again, I don't think the problem is where u-boot relocates this data TOO, but the fact that the new default is to relocate it at all. Is there a reason for relocating this stuff? The initrd always used to be happy left where it was. The user specified address might be in flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI2000 configuration for P2020DS
On Thu, Jul 14, 2011 at 08:16:13PM +, McClintock Matthew-B29882 wrote: On Thu, Jul 14, 2011 at 1:59 PM, Ira W. Snyder i...@ovro.caltech.edu wrote: The documentation Freescale sent me claims that U-Boot is in a 4MB SPI flash, however, the U-Boot that came with the board is unable to initialize the SPI subsystem per their instructions. = sf probe 0 SF: Unsupported Manufacturer 00 Failed to initialize SPI flash at 0:0 SPI is working for me. What version of u-boot are you running? Can you paste your boot log? I'm using the U-Boot that came on the board: 2009.11-V100R00. I have not changed any DIP switches. My boot log is below. Thanks for the help, Ira U-Boot 2009.11-V100R00 (Dec 09 2010 - 14:39:42) CPU0: P2020E, Version: 2.0, (0x80ea0020) Core: E500, Version: 5.0, (0x80211050) Clock Configuration: CPU0:1200 MHz, CPU1:1200 MHz, CCB:600 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:37.500 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled I2C: ready SPI: ready DRAM: 2 GB L2:512 KB enabled MMC: FSL_ESDHC: 0 SF: Unsupported manufacturer 00 *** Warning - bad CRC, using default environment EEPROM: NXID v0 EEPROM: COMX PCIE3 connected to Slot0 as Root Complex (base addr ffe08000) PCIE3 on bus 00 - 00 PCIE2 connected to Slot 1 as Root Complex (base addr ffe09000) PCIE2 on bus 01 - 01 PCIE1 connected to Slot 2 as Root Complex (base addr ffe0a000) Current Status: LSR-11, LTSSM-16, PEX width-x1, Clock-2.5GT/s Scanning PCI bus 03 03 00 18ca 0027 0300 00 PCIE1 on bus 02 - 03 In:serial Out: serial Err: serial Net: eTSEC1, eTSEC2, eTSEC3 Hit any key to stop autoboot: 0 = = sf probe 0 SF: Unsupported manufacturer 00 Failed to initialize SPI flash at 0:0 = printenv ramboot=setenv bootargs root=/dev/ram rw DVO_OUTPUT=$DVO_OUTPUT console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $tftppath/$ramdiskfile;tftp $loadaddr $tftppath/$bootfile;tftp $fdtaddr $tftppath/$fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off DVO_OUTPUT=$DVO_OUTPUT console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $tftppath/$bootfile;tftp $fdtaddr $tftppath/$fdtfile;bootm $loadaddr - $fdtaddr bootdelay=10 baudrate=115200 loads_echo=1 ipaddr=192.168.0.250 serverip=192.168.0.197 rootpath=/local/tftpboot/COMX-P2020/current/rootfs_nfs gatewayip=192.168.0.1 netmask=255.255.255.0 hostname=COMX-P2020 bootfile=uImage loadaddr=100 bootcmd=run sdboot sdboot=setenv bootargs root=/dev/mmcblk0p2 rw rootdelay=$rootdelaysecond DVO_OUTPUT=$DVO_OUTPUT console=$consoledev,$baudrate $othbootargs; mmcinfo;ext2load mmc 0:2 $loadaddr /boot/$bootfile;ext2load mmc 0:2 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr sdfatboot=setenv bootargs root=/dev/ram rw rootdelay=$rootdelaysecond DVO_OUTPUT=$DVO_OUTPUT console=$consoledev,$baudrate $othbootargs; mmcinfo;fatload mmc 0:1 $loadaddr $bootfile;fatload mmc 0:1 $fdtaddr $fdtfile;fatload mmc 0:1 $ramdiskaddr $ramdiskfile;bootm $loadaddr $ramdiskaddr $fdtaddr usbboot=setenv bootargs root=/dev/sda1 rw rootdelay=$rootdelaysecond DVO_OUTPUT=$DVO_OUTPUT console=$consoledev,$baudrate $othbootargs;usb start;ext2load usb 0:1 $loadaddr /boot/$bootfile;ext2load usb 0:1 $fdtaddr /boot/$fdtfile;bootm $loadaddr - $fdtaddr usbfatboot=setenv bootargs root=/dev/ram rw DVO_OUTPUT=$DVO_OUTPUT console=$consoledev,$baudrate $othbootargs; usb start; fatload usb 0:2 $loadaddr $bootfile; fatload usb 0:2 $fdtaddr $fdtfile; fatload usb 0:2 $ramdiskaddr $ramdiskfile; bootm $loadaddr $ramdiskaddr $fdtaddr usbext2boot=setenv bootargs root=/dev/ram rw DVO_OUTPUT=$DVO_OUTPUT console=$consoledev,$baudrate $othbootargs; usb start; ext2load usb 0:4 $loadaddr $bootfile; ext2load usb 0:4 $fdtaddr $fdtfile; ext2load usb 0:4 $ramdiskaddr $ramdiskfile; bootm $loadaddr $ramdiskaddr $fdtaddr upgradespi=sf probe 0;setenv startaddr 0;setenv erasesize a;tftp 100 $tftppath/$uboot_spi;sf erase $startaddr $erasesize;sf write 100 $startaddr $filesize;sf erase 10 12 clearspienv=sf probe 0;sf erase 10 2 othbootargs=ramdisk_size=70 cache-sram-size=0x1 netdev=eth0 rootdelaysecond=15 uboot_nor=u-boot-nor.bin uboot_spi=u-boot-spi.bin uboot_sd=u-boot-sd.bin consoledev=ttyS0 ramdiskaddr=200 ramdiskfile=rootfs-dev.ext2.img fdtaddr=c0 fdtfile=comx.dtb tftppath=COMX-P2020/current DVO_OUTPUT=enable ethaddr=EC:9E:CD:01:4D:B4 eth1addr=EC:9E:CD:01:4D:B5 eth2addr=EC:9E:CD:01:4D:B6 ethact=eTSEC1 Environment size: 2804/8188 bytes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 2011-07-14 at 15:21 -0500, Scott Wood wrote: You have memory below where the kernel is loaded? Our boot script loads the kernel 2MB into physical RAM. It loads the initrd and fdt from the same NAND flash file system into RAM below that. When we boot without specifying an FDT, u-boot does not relocate the initrd. When we specify an FDT address in RAM, u-boot relocates both. We do not need that relocation (in this case at least). This splits memory into three, instead of two regions in the kernel. I don't think that split ever goes away. Then there's the additional region we already have to create for the Ducati memory. That's at least five memory regions total. There are only eight regions currently allowed by default. I don't have a feel for the implications of this, but it seems unnecessary. What do you mean by a region here, and why can there only be eight of them? Functionally identical and contiguous sections of RAM recorded in the Linux global meminfo data structure, and (mostly) operated on in code found in arch/arm/mm/. There's a define that sets the size of this array to 8. Again, I don't know the implications, if any, of having several versus a couple of these banks/regions. It just seems a bad idea to create more holes in the middle of physical RAM unless we really have to. Plus, we have to inform the kernel about them somehow. I don't have a clear idea how we would do that in a clean way. Seems to me it'd be uglier than the fdt_high approach. Maybe I'm missing something though. I'm certainly not a VM expert. Again, I don't think the problem is where u-boot relocates this data TOO, but the fact that the new default is to relocate it at all. Is there a reason for relocating this stuff? The initrd always used to be happy left where it was. The user specified address might be in flash. But in our case it is not. And we're now being relocated when we did not get relocated prior to FDT functionality. -dl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BDI2000 configuration for P2020DS
On Thu, Jul 14, 2011 at 3:41 PM, Ira W. Snyder i...@ovro.caltech.edu wrote: I'm using the U-Boot that came on the board: 2009.11-V100R00. I have not changed any DIP switches. My boot log is below. I think this version is missing stuff for SPI to work. Can you try a newer version? This board should support an altbank so you can test the image without erasing the current one. You could also try applying commit 9c4d8767 to your tree as well. -M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable
On Thu, 14 Jul 2011 17:20:53 -0400 David Long dave.l...@linaro.org wrote: When we boot without specifying an FDT, u-boot does not relocate the initrd. When we specify an FDT address in RAM, u-boot relocates both. We do not need that relocation (in this case at least). Well, that does sound strange. I'd think it would be based on whether you define CONFIG_SYS_BOOT_RAMDISK_HIGH, and whether initrd_high is set to 0x. Or were you just not telling bootm about the ramdisk before, and letting the kernel know about the address through some other means? What do you mean by a region here, and why can there only be eight of them? Functionally identical and contiguous sections of RAM recorded in the Linux global meminfo data structure, and (mostly) operated on in code found in arch/arm/mm/. There's a define that sets the size of this array to 8. Again, I don't know the implications, if any, of having several versus a couple of these banks/regions. I don't think we have this kind of thing on powerpc. We track unusable regions with lmb, based on things like the dtb memreserve list. It just seems a bad idea to create more holes in the middle of physical RAM unless we really have to. So add a mechanism for the user to override if you can justify a use for it, but the default should be allocated from an lmb that has had unusable addresses excluded. Plus, we have to inform the kernel about them somehow. I don't have a clear idea how we would do that in a clean way. I don't know how ARM does it, but on powerpc the kernel is told about the initrd/initramfs address range through the device tree, and the device tree address is in r3 on entry. The device tree blob is also marked reserved in the dtb memreserve list. The initrd/initramfs doesn't appear to be marked reserved, probably since the kernel had ways of avoiding that region since before flat device trees and memreserve came along. Again, I don't think the problem is where u-boot relocates this data TOO, but the fact that the new default is to relocate it at all. Is there a reason for relocating this stuff? The initrd always used to be happy left where it was. The user specified address might be in flash. But in our case it is not. It still needs to be supported. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 01/16] [Timer]Fix misuse of ARM *timer_masked() functions outside arch/arm
Hi Wolfgang, On 15/07/11 05:50, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message 4e1f2100.2030...@aribaud.net you wrote: Patch applies on u-boot-arm/master except for 4 files which are not found: board/ixdp425/flash.c, removed by commit 973af335e61eede3578371330abd3971805887f5, update/fix IXDP425 / IXDPG425 boards board/mpl/vcma9/flash.c: removed by commit 6d754843ff62312999a265162c67588913cab991, VCMA9: use CFI driver (and remove the old one) board/trab/cmd_trab.c and board/trab/flash.c: removed by commit 566e5cf451ae7e33e31bb62ae5b9b258e33f8609, ARM: drop unsupported 'trab' board If this is fine with everyone, I can pull this patch in u-boot-arm/master despite the four errors. Please do. These files were all correctly removed recently. I'm OK with this, but I'm about to rebase - After that, I will rename the series, truncate it to only include the ack'd patches, rev them to V2, set their respective in-reply-to to the WIP patches and set the remainder to RFC in patchwork So I could either: - Send a revised version as a separate patch for ARM and remove it from the series - Include it in the truncated series - Remove it from the series and let Albert process it as is Which do you prefer? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
On 7/14/2011 12:41 PM, Wolfgang Denk wrote: Dear J. William Campbell, In message4e1cf2e0.1030...@comcast.net you wrote: Yes, this is true. However, the time_elapsed_since routine can do this dynamically (i.e. add twice the timer resolution) . I think you had That would IMHO be a very bad idea. We have a number of places where we have to deal with pretty long timeouts (usually because of protocol specifications that require this - often in the order of several seconds), where the normal path is very fast. The typical approach is to break the timeout into a large number of very short loops. Sometimes we use udelay() for this, other places use get_timer(). So assume we have a timeout of 5 seconds, and implement this as 50,000 loops of 100 microseconds. If you silently turn each of these into 20 milliseconds on NIOS, the timeout would become 1,000 seconds instead of 5 - users would return boards as broken and report it just freezes because nobody expects that it will wake up again after some 16 minutes. Hi All, If such a condition existed, that is indeed what would happen. However, at present, such code is not being used on NIOS. We know this because the current work-around of resetting the timer at the start of any timeout operation extends the timeout to a minimum of 10 milliseconds. So we would be waiting 8 minutes currently, not 16, and I am pretty sure that is long enough for someone to notice. . I would be interested in seeing an example of such code as you refer to. Could you point me to one, because it seems to me that the only reason to code such a delay is that for some reason the user didn't want to keep looking at the termination condition so often. I think that that equivalent operation can be produced by a pretty simple re-coding of the loop. In any case, NIOS does not have the problem at present, so the suggested new work-around would be no worse than the present situation. It is also true that the hardware timer cannot be used in a reasonable version of udelay, as most of the desired delays may be very short relative to the timebase. A calibrated timing loop would be the best approach to the udelay problem. another function name (at_least) involved, but you can define time_elapsed_since as always compensating for the resolution. That will fix any resolution questions in a processor-specific way. It is either that or the ifdefs. One way or another, the resolution must be addressed. Up to now, the implicit resolution has been 1 ms, but we now know that is not general enough. It's not as simple as this. You have to change a lot of code to make this work for such slow clock systems. In general, that is true. There may be a few cases where a delay of less than the resolution is essential to make something work. There are probably lots of other cases where we can easily remove the restriction on the resolution. We cannot fix the first kind, no matter what we do, to work on a lower resolution timer. The second kind we can and probably should fix, because they are coded in an overly-restrictive manner. In any case, we don't absolutely have to fix them until somebody decides to use the code on a CPU with a low resolution timer. Practically speaking, the suggested solution will therefore work on all extant cases. Best Regards, Bill Campbell Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 05/16] [Timer]Remove reset_timer() for non-Nios2 arches
On 12/07/11 08:02, Wolfgang Denk wrote: Dear Graeme Russ, In message 1309261269-4363-6-git-send-email-graeme.r...@gmail.com you wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com Seems this patch conflicts with 03/16, which apparently already removed the same code, at least in some places? The conflict was due to a recent patch submitted outside this series - Fixed during rebase Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm, lib/board.c: Coding Style cleanup
Hi Heiko and Albert, 2011/7/15 Albert ARIBAUD albert.u.b...@aribaud.net Hi Heiko, Sorry for having kept this patch unanswered so long. I am now on holiday, which means *a bit* more time for U-Boot, so here comes: Re: patch title, can you make it arm: libboard.c: ... rather than arm, libboard.c ? Just remind both of you here, about the clean up patches, we have an other prefix for the patch title (subject). http://www.denx.de/wiki/U-Boot/Patches General Patch Submission Rules Non-functional changes, i.e. whitespace and reformatting changes, should be done in separate patches marked as cosmetic. This separation of functional and cosmetic changes greatly facilitates the review process. So, please use cosmetic: as the beginning prefix of your clear up patch. Also, make sure you rebase onto latest u-boot-arm/master for next version: this one does not apply cleanly ATM. [deleted] - printf ( CRC: %08X, - crc32 (0, (const unsigned char *) CONFIG_SYS_FLASH_BASE, flash_size) + printf( CRC: %08X, + crc32(0, + (const unsigned char *) CONFIG_SYS_FLASH_BASE, + flash_size) Pleas indent deeper for the last two lines that belong to the call to crc32. Amicalement, -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
