[U-Boot] Help with Cross-Compiling U-boot for PPC
Hi all, My goal is to (simply) build u-boot to run on my target processor which is MPC8349. My host environment where I will be building the u-boot is a SUSE linux system running on an intel x86 PC (therefore I will cross compile). I have followed the instructions on the wiki and README file, and created a u-boot.bin file. I after I load the u-boot.bin (with a BDI2000 debugger) and reset the device, it produces random (garbage) text through the serial port. It normally should produce a welcome message, etc.. Here are my steps: I have downloaded the latest u-boot version and unpacked it: v2011.12-rc2 Make distclean Make MPC8349EMDS_config CROSS_COMPILE=powerpc-linux- Export CROSSCOMPILE Make all (note that I derived the above commands from the README file in the u-boot directory (see sections at Line 274, line 3350) I believe my configuration of the BDI2000 debugger is correct as I've successfully loaded my older version of u-boot.bin (created by someone before me) many times with it and it worked. If there is an obvious step I am missing, or incorrect syntax, please let me know. Thanks in advance, Will Khan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] A Problem of u-boot on TI PandaBoard porting
Hi, I encounter some problems of u-boot porting on PandaBoard. I’m working on modifying u-boot to verify the hardware devices working well. Although there’s already a board configuration for PandaBoard (omap4_panda), I would like to create another one for my own project. The u-boot version is “U-Boot 2011.12-00046”, and I just duplicated the item of omap4_panda of “boards.cfg” and renamed it to “panda_test”, and did the same things as some u-boot porting guides which can be found on the web. Finally, after compiling, I can get ‘u-boot’, ‘u-boot.bin’, ‘u-boot.img’, ‘u-boot.lds’, ‘u-boot.map’ and ‘u-boot.srec’ in the top directory, but no MLO. There were error message prompt as below: *u-boot/spl/u-boot-spl.lds:1: syntax error make[1]: *** [/home/qian/Desktop/u-boot/spl/u-boot-spl] Error 1 make[1]: Leaving directory `/home/qian/Desktop/u-boot/spl' make: *** [spl/u-boot-spl.bin] Error 2* I’ve check the file ‘spl/u-boot-spl.lds’, the first line is a comment as below: *// add PandaTest Configuration* and the rest of the file are the same as defult PandaBoard build result. But when I just build defult omap4_panda_config, this comment would not appear. I guess that’s the syntax error, the *arm-none-eabi-ld* generate the ‘u-boot-spl.lds’ with a comment at first line. But it doesn’t happened when I just build u-boot for default PandaBoard. Is there any step I missed? Please let me know. Thank you very much! Qiao ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: Add support for TRATS board
This patch adds support for Samsung TRATS board
Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
MAINTAINERS |4 +
board/samsung/trats/Makefile| 44
board/samsung/trats/lowlevel_init.S | 284 +
board/samsung/trats/trats.c | 246 +++
board/samsung/trats/trats_setup.h | 460 +++
boards.cfg |1 +
include/configs/trats.h | 222 +
7 files changed, 1261 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/trats/Makefile
create mode 100644 board/samsung/trats/lowlevel_init.S
create mode 100644 board/samsung/trats/trats.c
create mode 100644 board/samsung/trats/trats_setup.h
create mode 100644 include/configs/trats.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a56ca10..c856c59 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -700,6 +700,10 @@ Minkyu Kang mk7.k...@samsung.com
s5p_goniARM ARMV7 (S5PC110 SoC)
s5pc210_universal ARM ARMV7 (EXYNOS4210 SoC)
+Heungjun Kim riverful@samsung.com
+
+ trats ARM ARMV7 (EXYNOS4210 SoC)
+
Chander Kashyap k.chan...@samsung.com
origen ARM ARMV7 (EXYNOS4210 SoC)
diff --git a/board/samsung/trats/Makefile b/board/samsung/trats/Makefile
new file mode 100644
index 000..5a31a7b
--- /dev/null
+++ b/board/samsung/trats/Makefile
@@ -0,0 +1,44 @@
+#
+# Copyright (C) 2010 Samsung Electronics
+# Heungjun Kim riverful@samsung.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y:= trats.o
+SOBJS := lowlevel_init.o
+
+SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(SOBJS) $(OBJS)
+ $(call cmd_link_o_target, $(SOBJS) $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/trats/lowlevel_init.S
b/board/samsung/trats/lowlevel_init.S
new file mode 100644
index 000..7b8e15b
--- /dev/null
+++ b/board/samsung/trats/lowlevel_init.S
@@ -0,0 +1,284 @@
+/*
+ * Lowlevel setup for TRATS board based on EXYNOS4210
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ * Heungjun Kim riverful@samsung.com
+ * Kyungmin Park kyungmin.p...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include version.h
+#include asm/arch/cpu.h
+#include asm/arch/clock.h
+#include trats_setup.h
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+ .globl lowlevel_init
+lowlevel_init:
+ push{lr}
+
+ /* r5 has always zero */
+ mov r5, #0
+ ldr r7, =EXYNOS4_GPIO_PART1_BASE
+ ldr r6, =EXYNOS4_GPIO_PART2_BASE
+
+ /*
+* PMIC manual reset
+* nPOWER: XEINT_23: GPX2[7]
+*/
+ ldr r1, =EXYNOS4_GPIO_X2_CON_VAL
+ str r1, [r6, #EXYNOS4_GPIO_X2_CON_OFFSET]
+ ldr r1, =EXYNOS4_GPIO_X2_DAT_VAL
+ str r1, [r6, #EXYNOS4_GPIO_X2_DAT_OFFSET]
+
+ /* init system clock */
+ bl system_clock_init
+
+ /* Disable Watchdog */
+ ldr r0,
[U-Boot] [PATCH] ARMV7: Add support for TRATS board
This patch adds support for Samsung TRATS board
Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
MAINTAINERS |4 +
board/samsung/trats/Makefile| 44
board/samsung/trats/lowlevel_init.S | 284 +
board/samsung/trats/trats.c | 246 +++
board/samsung/trats/trats_setup.h | 460 +++
boards.cfg |1 +
include/configs/trats.h | 222 +
7 files changed, 1261 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/trats/Makefile
create mode 100644 board/samsung/trats/lowlevel_init.S
create mode 100644 board/samsung/trats/trats.c
create mode 100644 board/samsung/trats/trats_setup.h
create mode 100644 include/configs/trats.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a56ca10..c856c59 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -700,6 +700,10 @@ Minkyu Kang mk7.k...@samsung.com
s5p_goniARM ARMV7 (S5PC110 SoC)
s5pc210_universal ARM ARMV7 (EXYNOS4210 SoC)
+Heungjun Kim riverful@samsung.com
+
+ trats ARM ARMV7 (EXYNOS4210 SoC)
+
Chander Kashyap k.chan...@samsung.com
origen ARM ARMV7 (EXYNOS4210 SoC)
diff --git a/board/samsung/trats/Makefile b/board/samsung/trats/Makefile
new file mode 100644
index 000..5a31a7b
--- /dev/null
+++ b/board/samsung/trats/Makefile
@@ -0,0 +1,44 @@
+#
+# Copyright (C) 2010 Samsung Electronics
+# Heungjun Kim riverful@samsung.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y:= trats.o
+SOBJS := lowlevel_init.o
+
+SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(SOBJS) $(OBJS)
+ $(call cmd_link_o_target, $(SOBJS) $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/trats/lowlevel_init.S
b/board/samsung/trats/lowlevel_init.S
new file mode 100644
index 000..7b8e15b
--- /dev/null
+++ b/board/samsung/trats/lowlevel_init.S
@@ -0,0 +1,284 @@
+/*
+ * Lowlevel setup for TRATS board based on EXYNOS4210
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ * Heungjun Kim riverful@samsung.com
+ * Kyungmin Park kyungmin.p...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include version.h
+#include asm/arch/cpu.h
+#include asm/arch/clock.h
+#include trats_setup.h
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+ .globl lowlevel_init
+lowlevel_init:
+ push{lr}
+
+ /* r5 has always zero */
+ mov r5, #0
+ ldr r7, =EXYNOS4_GPIO_PART1_BASE
+ ldr r6, =EXYNOS4_GPIO_PART2_BASE
+
+ /*
+* PMIC manual reset
+* nPOWER: XEINT_23: GPX2[7]
+*/
+ ldr r1, =EXYNOS4_GPIO_X2_CON_VAL
+ str r1, [r6, #EXYNOS4_GPIO_X2_CON_OFFSET]
+ ldr r1, =EXYNOS4_GPIO_X2_DAT_VAL
+ str r1, [r6, #EXYNOS4_GPIO_X2_DAT_OFFSET]
+
+ /* init system clock */
+ bl system_clock_init
+
+ /* Disable Watchdog */
+ ldr r0,
Re: [U-Boot] [PATCH] arm/omap3: limit chip select iteration based on board config
Dear Grant Erickson, In message 02a515f3-ccd2-4635-ad38-07de542a4...@gmail.com you wrote: That makes sense; however, I have deployed boards in the field for which an in-place X-Loader update isn't trivial and for which interoperability is key. In light of that, are you willing to accept the patch? * For CONFIG_NR_DRAM_BANKS set to 1, we get interop with old second stage boot such as X-Loader. * For CONFIG_NR_DRAM_BANKS set to 2 (most boards) the behavior is exactly as it is without the patch. This an ugly hack which I do not want to see in mainline. If you really think you need that, then please maintain it yourself out of tree. Thanks. 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 Horses just naturally have mohawk haircuts. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_nand: add biterror insertion command for NAND Flash
Hi Scott, On 01/04/2012 06:44 PM, Scott Wood wrote: On 01/04/2012 09:32 AM, Holger Brunck wrote: Initial implementation for unsafe feature for biterror insertion on NAND-Flash devices. The code flips single bits in the data block of the flash to simulate single bit-errors. Tested with Samsung K9F1G08U0D and Micron MT29F1G08ABADAWP on km_kirkwood boards. Do we still need dedicated code for this now that we have the ability to do raw writes? to be able to do raw writes was very usefull for me to reproduce a bug in the UBI layer in the past. Bitflips happen very rarely but they happen, and with this code you are able to force this and see how other SW layer handle this. Due to the fact there was an empty implementation in the u-boot code for this I thought it might be usefull for others too. Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Add support for TRATS board
Dear HeungJun, Kim,
In message 1325751248-23125-1-git-send-email-riverful@samsung.com you
wrote:
This patch adds support for Samsung TRATS board
Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
...
diff --git a/MAINTAINERS b/MAINTAINERS
index a56ca10..c856c59 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -700,6 +700,10 @@ Minkyu Kang mk7.k...@samsung.com
s5p_goniARM ARMV7 (S5PC110 SoC)
s5pc210_universal ARM ARMV7 (EXYNOS4210 SoC)
+Heungjun Kim riverful@samsung.com
+
+ trats ARM ARMV7 (EXYNOS4210 SoC)
+
Chander Kashyap k.chan...@samsung.com
Please keep list sorted (Ki... goes after Ka...).
+++ b/board/samsung/trats/Makefile
@@ -0,0 +1,44 @@
+#
+# Copyright (C) 2010 Samsung Electronics
+# Heungjun Kim riverful@samsung.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
Please see http://www.denx.de/wiki/view/U-Boot/Patches#Notes
We need GPLv2+ for all new files. Please fix globally.
+ */
+uart_asm_init:
...
+system_clock_init:
...
+system_power_init:
...
What are the compelling reasons to write thes functionms in assembler,
and not in C?
+int board_init(void)
+{
+ gpio1 = (struct exynos4_gpio_part1 *) EXYNOS4_GPIO_PART1_BASE;
+ gpio2 = (struct exynos4_gpio_part2 *) EXYNOS4_GPIO_PART2_BASE;
+
+ gd-bd-bi_boot_params = PHYS_SDRAM_1 + 0x100;
+
+ check_hw_revision();
+ printf(HW Revision:\t0x%x\n, board_rev);
+
+#if defined(CONFIG_PMIC)
+ pmic_init();
+#endif
+
+ return 0;
+}
Does this code build free wof warnings? I would expect to see
warnings here because of unused variables gpio1 and gpio2?
...
+/*
+ * High Level Configuration Options
+ * (easy to change)
+ */
+#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
+#define CONFIG_S5P 1 /* which is in a S5P Family */
+#define CONFIG_EXYNOS42101 /* which is in a EXYNOS4210 */
+#define CONFIG_TRATS 1 /* working with TRATS */
Please do not define values for variables that select features only.
Please fix globally.
+#include asm/arch/cpu.h/* get chip and board defs */
+
+#define CONFIG_ARCH_CPU_INIT
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_DISPLAY_BOARDINFO
+
+/* Keep L2 Cache Disabled */
+#define CONFIG_SYS_L2CACHE_OFF 1
+
+#define CONFIG_SYS_SDRAM_BASE0x4000
+#define CONFIG_SYS_TEXT_BASE 0x4480
+
+/* input clock of PLL: TRATS has 24MHz input clock at EXYNOS4210 */
+#define CONFIG_SYS_CLK_FREQ_C210 2400
+
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_CMDLINE_TAG
+#define CONFIG_INITRD_TAG
+#define CONFIG_REVISION_TAG
+#define CONFIG_CMDLINE_EDITING
+
+/* MACH_TYPE_TRATS macro will be removed once added to mach-types */
+#define MACH_TYPE_TRATS 3928
+#define CONFIG_MACH_TYPE MACH_TYPE_TRATS
+
+/* Size of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (1 20))
+
+/* select serial console configuration */
+#define CONFIG_SERIAL_MULTI 1
+#define CONFIG_SERIAL2 1 /* use SERIAL 2 */
+#define CONFIG_BAUDRATE 115200
+
+/* MMC */
+#define CONFIG_GENERIC_MMC 1
+#define CONFIG_MMC 1
+#define CONFIG_S5P_MMC 1
+
+/* PWM */
+#define CONFIG_PWM 1
...
+#define MBRPARTS_DEFAULT 20M(permanent)\
+ ,20M(boot)\
+ ,1G(system)\
+ ,100M(swap)\
+ ,-(UMS)\0
...
+ mbrparts= MBRPARTS_DEFAULT \
MBR ??? Is this a typo and you actually mean MTD ?
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
Es ist nicht genug zu wissen, man muß auch anwenden; es ist nicht ge-
nug zu wollen, man muß auch tun. -- Goethe, Maximen und Reflexionen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL
On Wed, Jan 4, 2012 at 4:56 PM, Scott Wood scottw...@freescale.com wrote: On 12/05/2011 05:17 PM, Marek Vasut wrote: This will be beneficial for the PXA3XX NAND driver, which uses the NAND IDs to identify the chip and configure the controller accordingly. Signed-off-by: Marek Vasut marek.va...@gmail.com Cc: Scott Wood scottw...@freescale.com --- drivers/mtd/nand/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index a63c0e4..46e79e3 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -35,10 +35,10 @@ COBJS-y += nand_spl_load.o endif else COBJS-y += nand.o -COBJS-y += nand_bbt.o -COBJS-y += nand_ids.o COBJS-y += nand_util.o endif +COBJS-y += nand_bbt.o +COBJS-y += nand_ids.o COBJS-y += nand_ecc.o COBJS-y += nand_base.o So, in theory with gc-sections this shouldn't increase the size of any SPL that currently successfully links (at least in the absence of things like weak symbols). However, I observed a devkit8000 build go from this: textdata bss dec hex filename 407091792 197764 240265 3aa89 /tmp/u-boot-arm/spl/u-boot-spl to this: textdata bss dec hex filename 422771792 197764 241833 3b0a9 /tmp/u-boot-arm/spl/u-boot-spl I verified that --function-sections/-fdata-sections/--gc-sections are being used on the SPL. It looks like strings are not getting dropped. If there's no way to fix this, this is going to be a big problem for the existing users of nand_spl to migrate to the new SPL model, unless the notion of include a bunch of stuff and let gc-sections take care of it is dropped. I'll confirm gc-sections/etc are not as awesome as we think. You can drop the size of current SPL builds (for say devkit8000) by taking things that should be dropped for us and forcing them out with #ifndef CONFIG_SPL_BUILD. Maybe if we had those LTO tables at the gc-sections time, it'd drop. But we can't rely on those. So instead of compiling in the nand-ids, it'd be better to allow SPL to pull in the whole NAND/MTD stack. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] EEYNOS: Add SMDK5250 board support
Hi Minkyu Kang,
On 5 January 2012 12:13, Minkyu Kang proms...@gmail.com wrote:
Dear Chander Kashyap,
On 27 December 2011 17:48, Chander Kashyap chander.kash...@linaro.org wrote:
Torsten Koschorrek koschor...@synertronixx.de
scb9328 ARM920T (i.MXL)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index b101f96..88e2fc0 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -125,10 +125,14 @@ static unsigned long exynos_get_pwm_clk(void)
if (s5p_get_cpu_rev() == 0) {
/*
- * CLK_SRC_PERIL0
+ * CLK_SRC_{PERIL0 | PERIC0}
* PWM_SEL [27:24]
*/
+#ifdef CONFIG_EXYNOS5
+ sel = readl(clk-src_peric0);
+#else
sel = readl(clk-src_peril0);
+#endif
NAK.
We don't allow to using ifdef for separating SoCs.
Please refer s5pc1xx case for solve it.
This comment apply to this patch globally.
Please remove '#ifdef CONFIG_EXYNOS5'.
I have tried to reuse the code. It is possible to remove
#ifdef CONFIG_EXYNOS5' in clock.c with cpu_is_s5pcXXX check.
Is it a acceptable solution? Or is it necessary to write SoC specific
function
in clock.c as done in case of s5pc1xx/clock.c.
Please Advice
Removing CONFIG_EXYNOS5 and following s5pc1xx case will not allow to
reuse the code in clock.c.
What is the technical hindrance of not using ifdefs?
No need to reuse the code, if SoCs are different.
If need, please separate the functions.
Yes, though SoC's are different, the functionality in clock.c is
similar. The only difference is the clock name in the clock structure
for Exynos4 and Exynos5 but the functionality is exactly same in
clock.c. To accommodate this change in clock name #ifdef is used.
Following is the function in clock .c which uses #ifdef to accommodate
the different clock name in SoC's.
static unsigned long exynos_get_pwm_clk(void)
{
struct exynos_clock *clk =
(struct exynos_clock *)samsung_get_base_clock();
unsigned long pclk, sclk;
unsigned int sel;
unsigned int ratio;
if (s5p_get_cpu_rev() == 0) {
/*
* CLK_SRC_{PERIL0 | PERIC0}
* PWM_SEL [27:24]
*/
#ifdef CONFIG_EXYNOS5
sel = readl(clk-src_peric0);
#else
sel = readl(clk-src_peril0);
#endif
sel = (sel 24) 0xf;
if (sel == 0x6)
sclk = get_pll_clk(MPLL);
else if (sel == 0x7)
sclk = get_pll_clk(EPLL);
else if (sel == 0x8)
sclk = get_pll_clk(VPLL);
else
return 0;
/*
* CLK_DIV_{PERIL3 | PERIC3}
* PWM_RATIO [3:0]
*/
#ifdef CONFIG_EXYNOS5
ratio = readl(clk-div_peric3);
#else
ratio = readl(clk-div_peril3);
#endif
ratio = ratio 0xf;
} else if (s5p_get_cpu_rev() == 1) {
sclk = get_pll_clk(MPLL);
ratio = 8;
} else
return 0;
pclk = sclk / (ratio + 1);
return pclk;
}
As listed above, the exynos_get_pwm_clk(() function is fully reusable
for both Exynos4 and Exynos5. The #ifdef was used to get around the
different clock names of Exynos4 and Exynos5.
Another option here could be, that the differing clock name
(src_peril0 for Exynos4 and src_peric0 for Exynos5) is resolved by
change the src_peric0 to src_peril0 for Exynos5, and clearly
commenting the reason for the deviation from the user manual. Would
this approach be acceptable ?
Thanks for your comments. Please let know your opinion about the
points listed in this email.
like this,
unsigned long get_arm_clk(void)
{
if (cpu_is_s5pc110())
return s5pc110_get_arm_clk();
else
return s5pc100_get_arm_clk();
}
Thanks.
Minkyu Kang
--
from. prom.
www.promsoft.net
--
with warm regards,
Chander Kashyap
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Add support for TRATS board
Hi Wolfgang Denk, Thanks for the comments. I'm preparing the modified version as you pointed out. But I have one curious thing among your comments. On 2012년 01월 05일 17:59, Wolfgang Denk wrote: Dear HeungJun, Kim, In message1325751248-23125-1-git-send-email-riverful@samsung.com you wrote: This patch adds support for Samsung TRATS board Signed-off-by: HeungJun, Kimriverful@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com ... + */ +uart_asm_init: ... +system_clock_init: ... +system_power_init: ... What are the compelling reasons to write thes functionms in assembler, and not in C? No. There is not specific reason. It's just to fit the convention with lowlevel_init.S file of any other previous boards based on Exynos4 SoC. And it's true it's easy to check the changes between these boards. So, I thought there's not a big problem whether this is changed to be C or not. I'm just curious the pros of using C rather than asm in this case. Could you explain it? Thank you. Regards, Heungjun Kim Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] doc: Add Tom Rini to git-mailrc
Tom is co-custodian of u-boot/ti fork, so add him to git-mailrc. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- doc/git-mailrc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/doc/git-mailrc b/doc/git-mailrc index 4039e55..4936003 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -42,7 +42,7 @@ alias at91 uboot, reinhardm alias davinciomap alias imxuboot, sbabic alias kirkwood uboot, prafulla -alias omap uboot, Sandeep Paulraj s-paul...@ti.com +alias omap uboot, Sandeep Paulraj s-paul...@ti.com, Tom Rini tr...@ti.com alias pxauboot, marex alias s3csamsung alias s5pc samsung -- 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 4/6] EEYNOS: Add SMDK5250 board support
Dear Chander Kashyap, In message canuqghhy8_6m1riva6rawry0pvrx5nnykxd_p+u340a0d4j...@mail.gmail.com you wrote: No need to reuse the code, if SoCs are different. If need, please separate the functions. Yes, though SoC's are different, the functionality in clock.c is similar. The only difference is the clock name in the clock structure for Exynos4 and Exynos5 but the functionality is exactly same in clock.c. To accommodate this change in clock name #ifdef is used. If this is the only difference, then I suggest just to rename the field in thesta structure. Although it makes sense to follow the names in the documentation, it is sometimes better tochose a more suitable name - a comment in the header file should be sufficient to explain the rename (and to provide an anchor in case something greps for the name as used in the docs). Maybe we can avoid both #ifdef's and code duplication this way? 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 What was sliced bread the greatest thing since? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Add support for TRATS board
Dear Kim, Heungjun, In message 4f05896d.8000...@samsung.com you wrote: What are the compelling reasons to write thes functionms in assembler, and not in C? No. There is not specific reason. It's just to fit the convention with Then please implement in C. lowlevel_init.S file of any other previous boards based on Exynos4 SoC. It has always been a bad idea to follow bad examples ;-) I'm just curious the pros of using C rather than asm in this case. Could you explain it? Readability? Easier maintenance? U-Boot is written in C. We use assembler only where it cannot be avoided or where there are significant anvantages over implementation in C. Here it seems there is no good reason for using assembler code. 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 panic: can't find / ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] cm-t35: add EEPROM module and pass Linux a serial number
From: Nikita Kiryanov nik...@compulab.co.il
Add board specific EEPROM handling module,
read the serial number from the EEPROM and pass it to Linux.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Changes in v2:
* Use CONFIG_SYS_I2C_EEPROM_ADDR instead of a custom define
* Fix strange linker warning: .bss section overlaps previous sections
by changing the type of the eeprom_layout static global variable to int
(probably this is a compiler bug).
board/cm_t35/Makefile|4 ++-
board/cm_t35/eeprom.c| 78 ++
board/cm_t35/eeprom.h| 38 ++
include/configs/cm_t35.h |3 ++
4 files changed, 122 insertions(+), 1 deletions(-)
create mode 100644 board/cm_t35/eeprom.c
create mode 100644 board/cm_t35/eeprom.h
diff --git a/board/cm_t35/Makefile b/board/cm_t35/Makefile
index 27693f0..894fa09 100644
--- a/board/cm_t35/Makefile
+++ b/board/cm_t35/Makefile
@@ -25,7 +25,9 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := cm_t35.o leds.o
+COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
+
+COBJS := cm_t35.o leds.o $(COBJS-y)
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/cm_t35/eeprom.c b/board/cm_t35/eeprom.c
new file mode 100644
index 000..93ed6cb
--- /dev/null
+++ b/board/cm_t35/eeprom.c
@@ -0,0 +1,78 @@
+/*
+ * (C) Copyright 2011 CompuLab, Ltd. www.compulab.co.il
+ *
+ * Authors: Nikita Kiryanov nik...@compulab.co.il
+ * Igor Grinberg grinb...@compulab.co.il
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+
+#include common.h
+#include i2c.h
+
+#define EEPROM_LAYOUT_VER_OFFSET 44
+#define BOARD_SERIAL_OFFSET20
+#define BOARD_SERIAL_OFFSET_LEGACY 8
+
+#define LAYOUT_INVALID 0
+#define LAYOUT_LEGACY 0xff
+
+static int eeprom_layout; /* Implicitly LAYOUT_INVALID */
+
+static int cm_t3x_eeprom_read(uint offset, uchar *buf, int len)
+{
+ return i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, offset,
+ CONFIG_SYS_I2C_EEPROM_ADDR_LEN, buf, len);
+}
+
+static int eeprom_setup_layout(void)
+{
+ int res;
+
+ if (eeprom_layout != LAYOUT_INVALID)
+ return 0;
+
+ res = cm_t3x_eeprom_read(EEPROM_LAYOUT_VER_OFFSET,
+ (uchar *)eeprom_layout, 1);
+ if (res) {
+ eeprom_layout = LAYOUT_INVALID;
+ return res;
+ }
+
+ if (eeprom_layout == 0 || eeprom_layout = 0x20)
+ eeprom_layout = LAYOUT_LEGACY;
+
+ return 0;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ u32 serial[2];
+ uint offset;
+
+ memset(serialnr, 0, sizeof(*serialnr));
+ if (eeprom_setup_layout())
+ return;
+
+ offset = (eeprom_layout != LAYOUT_LEGACY) ?
+ BOARD_SERIAL_OFFSET : BOARD_SERIAL_OFFSET_LEGACY;
+ if (cm_t3x_eeprom_read(offset, (uchar *)serial, 8))
+ return;
+
+ if (serial[0] != 0x serial[1] != 0x) {
+ serialnr-low = serial[0];
+ serialnr-high = serial[1];
+ }
+}
diff --git a/board/cm_t35/eeprom.h b/board/cm_t35/eeprom.h
new file mode 100644
index 000..97a002a
--- /dev/null
+++ b/board/cm_t35/eeprom.h
@@ -0,0 +1,38 @@
+/*
+ * (C) Copyright 2011 CompuLab, Ltd. www.compulab.co.il
+ *
+ * Authors: Nikita Kiryanov nik...@compulab.co.il
+ * Igor Grinberg grinb...@compulab.co.il
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+#ifndef _EEPROM_
+#define _EEPROM_
+
+#include common.h
+
+#ifndef CONFIG_DRIVER_OMAP34XX_I2C
+void get_board_serial(struct
[U-Boot] [PATCH v2 4/6] omap3: make get_board_rev() function weak
From: Nikita Kiryanov nik...@compulab.co.il
Current get_board_rev() function returns a hard coded value which is
obviously incorrect for the majority of boards.
Allow boards to provide a correct implementation by making this function
weak.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Changes in v2:
* Changed the way get_board_rev is defined as weak -
remove alias and just add __weak in definition.
arch/arm/cpu/armv7/omap3/sys_info.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/sys_info.c
b/arch/arm/cpu/armv7/omap3/sys_info.c
index 22887ae..3c80113 100644
--- a/arch/arm/cpu/armv7/omap3/sys_info.c
+++ b/arch/arm/cpu/armv7/omap3/sys_info.c
@@ -30,6 +30,7 @@
#include asm/arch/mem.h /* get mem tables */
#include asm/arch/sys_proto.h
#include i2c.h
+#include linux/compiler.h
extern omap3_sysinfo sysinfo;
static struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
@@ -197,7 +198,7 @@ u32 get_gpmc0_width(void)
* get_board_rev() - setup to pass kernel board revision information
* returns:(bit[0-3] sub version, higher bit[7-4] is higher version)
*/
-u32 get_board_rev(void)
+u32 __weak get_board_rev(void)
{
return 0x20;
}
--
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] NAND: Allow nand_ids and nand_bbt to be compiled in SPL
On Thu, Jan 5, 2012 at 2:09 AM, Marek Vasut marek.va...@gmail.com wrote: On Wed, Jan 4, 2012 at 4:56 PM, Scott Wood scottw...@freescale.com wrote: On 12/05/2011 05:17 PM, Marek Vasut wrote: This will be beneficial for the PXA3XX NAND driver, which uses the NAND IDs to identify the chip and configure the controller accordingly. Signed-off-by: Marek Vasut marek.va...@gmail.com Cc: Scott Wood scottw...@freescale.com --- drivers/mtd/nand/Makefile | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index a63c0e4..46e79e3 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -35,10 +35,10 @@ COBJS-y += nand_spl_load.o endif else COBJS-y += nand.o -COBJS-y += nand_bbt.o -COBJS-y += nand_ids.o COBJS-y += nand_util.o endif +COBJS-y += nand_bbt.o +COBJS-y += nand_ids.o COBJS-y += nand_ecc.o COBJS-y += nand_base.o So, in theory with gc-sections this shouldn't increase the size of any SPL that currently successfully links (at least in the absence of things like weak symbols). However, I observed a devkit8000 build go from this: text data bss dec hex filename 40709 1792 197764 240265 3aa89 /tmp/u-boot-arm/spl/u-boot-spl to this: text data bss dec hex filename 42277 1792 197764 241833 3b0a9 /tmp/u-boot-arm/spl/u-boot-spl I verified that --function-sections/-fdata-sections/--gc-sections are being used on the SPL. It looks like strings are not getting dropped. If there's no way to fix this, this is going to be a big problem for the existing users of nand_spl to migrate to the new SPL model, unless the notion of include a bunch of stuff and let gc-sections take care of it is dropped. I'll confirm gc-sections/etc are not as awesome as we think. You can drop the size of current SPL builds (for say devkit8000) by taking things that should be dropped for us and forcing them out with #ifndef CONFIG_SPL_BUILD. Maybe if we had those LTO tables at the gc-sections time, it'd drop. But we can't rely on those. So instead of compiling in the nand-ids, it'd be better to allow SPL to pull in the whole NAND/MTD stack. Possible, but without doing #Ifndef hacks, the size grows a good bit (don't have the #s handy right now), and with #ifndef hacks it's just a kb or so in growth. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc: Add Tom Rini to git-mailrc
2012/1/5 Igor Grinberg grinb...@compulab.co.il: Tom is co-custodian of u-boot/ti fork, so add him to git-mailrc. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- doc/git-mailrc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/doc/git-mailrc b/doc/git-mailrc index 4039e55..4936003 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -42,7 +42,7 @@ alias at91 uboot, reinhardm alias davinci omap alias imx uboot, sbabic alias kirkwood uboot, prafulla -alias omap uboot, Sandeep Paulraj s-paul...@ti.com +alias omap uboot, Sandeep Paulraj s-paul...@ti.com, Tom Rini tr...@ti.com alias pxa uboot, marex alias s3c samsung alias s5pc samsung -- 1.7.3.4 Wolfgang, what happened to http://patchwork.ozlabs.org/patch/131434/ ? It's listed as accepted but I don't see it in tree... Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] cm-t35: add EEPROM module and pass Linux a serial number
Dear Igor Grinberg,
In message 1325764937-7342-1-git-send-email-grinb...@compulab.co.il you wrote:
From: Nikita Kiryanov nik...@compulab.co.il
Add board specific EEPROM handling module,
read the serial number from the EEPROM and pass it to Linux.
...
* Fix strange linker warning: .bss section overlaps previous sections
by changing the type of the eeprom_layout static global variable to int
(probably this is a compiler bug).
Probably it is now. Did you inspect the linke rmap?
+static int cm_t3x_eeprom_read(uint offset, uchar *buf, int len)
+{
+ return i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, offset,
+ CONFIG_SYS_I2C_EEPROM_ADDR_LEN, buf, len);
+}
Is there any specific reason why you cannot use the standard
eeprom_read() function here?
--- /dev/null
+++ b/board/cm_t35/eeprom.h
...
+#ifndef CONFIG_DRIVER_OMAP34XX_I2C
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ /*
+ * This corresponds to what happens when we can communicate with the
+ * eeprom but don't get a valid board serial value.
+ */
+ serialnr-low = 0;
+ serialnr-high = 0;
+};
+#endif /* CONFIG_DRIVER_OMAP34XX_I2C */
Please do NOT place code into header files.
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 mouse is an elephant built by the Japanese.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc: Add Tom Rini to git-mailrc
Dear Tom, In message CA+M6bXmGP9j0mVfGcJ3kOFjbHU6bhzMN3D0H=6oddz4fpf5...@mail.gmail.com you wrote: Wolfgang, what happened to http://patchwork.ozlabs.org/patch/131434/ ? It's listed as accepted but I don't see it in tree... Thanks! Neither can I. Strange. (Re-) Applied now. 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 There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious defi- ciencies. - Charles Anthony Richard Hoare ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fat: reset VFAT short alias checksum on first match
Dear Sergei Shtylyov, In message 201201021954.29410.sshtyl...@ru.mvista.com you wrote: The VFAT short alias checksum read from a long file name is only overwritten when another long file name appears in a directory list. Until then it renders short file names invisible that have the same checksum. Reset the checksum on first match. Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com Signed-off-by: Martin Mueller martin.muell...@de.bosch.com --- fs/fat/fat.c |2 ++ 1 file changed, 2 insertions(+) Applied, thanks. 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 Landing: a controlled mid-air collision with a planet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tools/env/fw_env.h comment/code mismatch
Dear Frans Meulenbroeks, In message cacw_htaiy-1qkik1h5f3yor31fj62ev2ban-q7nx+bpyfrf...@mail.gmail.com you wrote: I see two possible fixes: 1: add a // before the #define to make the code in accordance with the comment That would trigger a checkpatch error (no C++ commnts) ;-) 2: reprase the comment so it is in accordance with the code Whatever is preferred? It appears that the use of /etc/fw_env.config has become pretty much standard, so we should probably change the comment to reflect current use. Thanks. 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 The important thing about being a leader is not being right or wrong, but being *certain*.- Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env.h: added a few missing defines
Dear Frans Meulenbroeks, In message 1325512063-15583-1-git-send-email-fransmeulenbro...@gmail.com you wrote: The README file lists 4 defined that were not actually present in the .h file but that were needed to get things working with settings compiled in. They are Added these to the .h file (the values above are the ones from the README file) Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com --- Noticed this was not applied and still pending in my git tree Couldn't find a trace that I actually posted it so here it is (possibly again) tools/env/fw_env.h |4 1 files changed, 4 insertions(+), 0 deletions(-) Applied, thanks. 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've been programming for (35-9=) 24 years myself, and I find the best way to learn a new language is to *read* every example snippet I can find, with a reference book close by. Eventually, the *rhythm* of the language starts pounding in my head... and my fluency is close at hand. That's how I learned Perl, and now I'm one of the drummers. :-) -- Randal L. Schwartz in 8cvi6p2tir@gadget.cscaper.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/image.c: align usage of fdt_high with initrd_high
Dear Shawn Guo, In message 1325254347-17701-1-git-send-email-shawn@linaro.org you wrote: The commit message of a28afca (Add uboot fdt_high enviroment variable) states that fdt_high behaves similarly to the existing initrd_high. But fdt_high actually has an outstanding difference from initrd_high. The former specifies the start address, while the later specifies the end address. As fdt_high and initrd_high will likely be used together, it'd be nice to have them behave same. The patch changes the behavior of fdt_high to have it aligned with initrd_high. Can you please also update the documentation to avoid any such confusion? Thanks. 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 IBM uses what I like to call the 'hole-in-the-ground technique' to destroy the competition. IBM digs a big HOLE in the ground and covers it with leaves. It then puts a big POT OF GOLD nearby. Then it gives the call, 'Hey, look at all this gold, get over here fast.' As soon as the competitor approaches the pot, he falls into the pit - John C. Dvorak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] phy: add phy_smsc_init() declaration
Dear Vladimir Zapolskiy, In message 1325207917-16911-1-git-send-email...@mleia.com you wrote: This trivial change removes a compilation warning: 8 phy.c: In function 'phy_init': phy.c:448:2: warning: implicit declaration of function 'phy_smsc_init' 8 Signed-off-by: Vladimir Zapolskiy v...@mleia.com Cc: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com --- include/phy.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Applied, thanks. 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 Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick- les Worth). Which is to say that Europeans call him by name, but Americans call him by value. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env.c: use default env values if config file cannot be opened
Dear Frans Meulenbroeks, In message 1325098913-29909-1-git-send-email-fransmeulenbro...@gmail.com you wrote: If the config file cannot be opened currently one gets an error even though the build in names/sizes are probably ok. By setting the default values first and only exit if there is a read error and not when the config file can be opened the program will try the default settings. I have to admit that I don't like this change of behaviour. When configured for use with a config file, all errors should be treated the same. But that's just my $ 0.02. Are there any other opinions / votes how to proceed 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 Artificial Intelligence is no match for natural stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] fpga: add definition for Xilinx Spartan-6 XC6SLX4
Dear Stefano Babic, In message 1325090823-8051-1-git-send-email-sba...@denx.de you wrote: Signed-off-by: Stefano Babic sba...@denx.de --- include/spartan3.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) Applied, thanks. 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 Only in our dreams we are free. The rest of the time we need wages. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] FPGA: use debug() instead of module debug printf
Dear Stefano Babic, In message 1325090823-8051-2-git-send-email-sba...@denx.de you wrote: Replace also __FUNCTION__ with standard __func__ Signed-off-by: Stefano Babic sba...@denx.de --- common/cmd_fpga.c | 59 +--- 1 files changed, 28 insertions(+), 31 deletions(-) Applied, thanks. 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 Don't try to outweird me, three-eyes. I get stranger things than you free with my breakfast cereal. - Zaphod Beeblebrox in Hitchhiker's Guide to the Galaxy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] fpga: Spartan-3: let print the progress if configured
Dear Stefano Babic, In message 1325090823-8051-3-git-send-email-sba...@denx.de you wrote: CONFIG_SYS_FPGA_PROG_FEEDBACK was already introduced to print the current status of FPGA loading - an undef in the code made this CONFIG_ useless. Signed-off-by: Stefano Babic sba...@denx.de --- drivers/fpga/spartan3.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Applied, thanks. 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 This is now. Later is later. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: omap3: Added Teejet mt_ventoux
Dear Stefano Babic, In message 1325090823-8051-4-git-send-email-sba...@denx.de you wrote: The mt_ventoux board is a custom board using the Technexion TAM3517 module. Signed-off-by: Stefano Babic sba...@denx.de --- MAINTAINERS |1 + board/teejet/mt_ventoux/Makefile | 44 board/teejet/mt_ventoux/mt_ventoux.c | 235 +++ board/teejet/mt_ventoux/mt_ventoux.h | 429 ++ boards.cfg |1 + include/configs/mt_ventoux.h | 61 + 6 files changed, 771 insertions(+), 0 deletions(-) create mode 100644 board/teejet/mt_ventoux/Makefile create mode 100644 board/teejet/mt_ventoux/mt_ventoux.c create mode 100644 board/teejet/mt_ventoux/mt_ventoux.h create mode 100644 include/configs/mt_ventoux.h 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 Bugs are by far the largest and most successful class of entity, with nearly a million known species. In this res- pect they outnumber all the other known creatures about four to one. -- Professor Snope's Encyclopedia of Animal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: omap3: Added Teejet mt_ventoux
On Thu, Jan 5, 2012 at 8:21 AM, Wolfgang Denk w...@denx.de wrote: Dear Stefano Babic, In message 1325090823-8051-4-git-send-email-sba...@denx.de you wrote: The mt_ventoux board is a custom board using the Technexion TAM3517 module. Signed-off-by: Stefano Babic sba...@denx.de --- MAINTAINERS | 1 + board/teejet/mt_ventoux/Makefile | 44 board/teejet/mt_ventoux/mt_ventoux.c | 235 +++ board/teejet/mt_ventoux/mt_ventoux.h | 429 ++ boards.cfg | 1 + include/configs/mt_ventoux.h | 61 + 6 files changed, 771 insertions(+), 0 deletions(-) create mode 100644 board/teejet/mt_ventoux/Makefile create mode 100644 board/teejet/mt_ventoux/mt_ventoux.c create mode 100644 board/teejet/mt_ventoux/mt_ventoux.h create mode 100644 include/configs/mt_ventoux.h Acked-by: Wolfgang Denk w...@denx.de And I will apply this to u-boot-ti/master once the FPGA parts hit u-boot-arm. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/2] ext4fs ls load support
Dear uma.shan...@samsung.com, In message 1325038933-10587-1-git-send-email-uma.shan...@samsung.com you wrote: From: Uma Shankar uma.shan...@samsung.com Signed-off-by: Uma Shankar uma.shan...@samsung.com Signed-off-by: Manjunatha C Achar a.manjuna...@samsung.com Signed-off-by: Iqbal Shareef iqbal@samsung.com Signed-off-by: Hakgoo Lee goodguy@samsung.com --- Changes for v2: - Code cleanup, changed comment style - camel case removed, resolved code alignment issues - memory allocation logic changed, removed busybox logic - Modified ext4 load to remove grub dependency (GPLv3) Changes for v1: - Removed checkpatch warnings and errors - Moved common API's of ext2 and ext4 to one generic header file Makefile |2 +- common/Makefile |1 + common/cmd_ext2.c |1 + common/cmd_ext4.c | 249 ++ fs/Makefile |1 + fs/ext2/dev.c |1 + fs/ext2/ext2fs.c | 340 +++--- fs/ext4/Makefile | 51 + fs/ext4/ext4_common.c | 565 + fs/ext4/ext4_common.h | 48 + fs/ext4/ext4fs.c | 219 +++ include/ext2fs.h | 16 +- include/ext4fs.h | 133 include/ext_common.h | 198 + 14 files changed, 1501 insertions(+), 324 deletions(-) create mode 100644 common/cmd_ext4.c create mode 100644 fs/ext4/Makefile create mode 100644 fs/ext4/ext4_common.c create mode 100644 fs/ext4/ext4_common.h create mode 100644 fs/ext4/ext4fs.c create mode 100644 include/ext4fs.h create mode 100644 include/ext_common.h Applied, thanks. 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 This is now. Later is later. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] ext4fs write support
Dear uma.shan...@samsung.com, In message 1325039007-10611-1-git-send-email-uma.shan...@samsung.com you wrote: From: Uma Shankar uma.shan...@samsung.com Signed-off-by: Uma Shankar uma.shan...@samsung.com Signed-off-by: Manjunatha C Achar a.manjuna...@samsung.com Signed-off-by: Iqbal Shareef iqbal@samsung.com Signed-off-by: Hakgoo Lee goodguy@samsung.com --- Changes for v2: - Code cleanup, changed comment style - camel case removed, resolved code alignment issues - memory allocation logic changed, removed busybox logic - Modified ext4 load to remove grub dependency (GPLv3) - Introduced new Config for ext4 write Changes for v1: - Removed checkpatch warnings and errors - Moved common API's of ext2 and ext4 to one generic header file common/cmd_ext4.c | 141 + fs/ext4/Makefile |1 + fs/ext4/README | 46 ++ fs/ext4/crc16.c| 62 +++ fs/ext4/crc16.h| 16 + fs/ext4/ext4_common.c | 1380 fs/ext4/ext4_common.h | 20 + fs/ext4/ext4_journal.c | 662 +++ fs/ext4/ext4_journal.h | 147 + fs/ext4/ext4fs.c | 972 ++ include/ext4fs.h | 12 + 11 files changed, 3459 insertions(+), 0 deletions(-) create mode 100644 fs/ext4/README create mode 100644 fs/ext4/crc16.c create mode 100644 fs/ext4/crc16.h create mode 100644 fs/ext4/ext4_journal.c create mode 100644 fs/ext4/ext4_journal.h Applied, thanks. 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 Youth doesn't excuse everything. -- Dr. Janice Lester (in Kirk's body), Turnabout Intruder, stardate 5928.5. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/2] ext4fs ls load support
Dear uma.shan...@samsung.com, In message 1325038933-10587-1-git-send-email-uma.shan...@samsung.com you wrote: From: Uma Shankar uma.shan...@samsung.com Signed-off-by: Uma Shankar uma.shan...@samsung.com Signed-off-by: Manjunatha C Achar a.manjuna...@samsung.com Signed-off-by: Iqbal Shareef iqbal@samsung.com Signed-off-by: Hakgoo Lee goodguy@samsung.com --- Changes for v2: - Code cleanup, changed comment style - camel case removed, resolved code alignment issues - memory allocation logic changed, removed busybox logic - Modified ext4 load to remove grub dependency (GPLv3) Changes for v1: - Removed checkpatch warnings and errors - Moved common API's of ext2 and ext4 to one generic header file Makefile |2 +- common/Makefile |1 + common/cmd_ext2.c |1 + common/cmd_ext4.c | 249 ++ fs/Makefile |1 + fs/ext2/dev.c |1 + fs/ext2/ext2fs.c | 340 +++--- fs/ext4/Makefile | 51 + fs/ext4/ext4_common.c | 565 + fs/ext4/ext4_common.h | 48 + fs/ext4/ext4fs.c | 219 +++ include/ext2fs.h | 16 +- include/ext4fs.h | 133 include/ext_common.h | 198 + 14 files changed, 1501 insertions(+), 324 deletions(-) create mode 100644 common/cmd_ext4.c create mode 100644 fs/ext4/Makefile create mode 100644 fs/ext4/ext4_common.c create mode 100644 fs/ext4/ext4_common.h create mode 100644 fs/ext4/ext4fs.c create mode 100644 include/ext4fs.h create mode 100644 include/ext_common.h Oops. No, I cannot apply this. When I enable CONFIG_CMD_EXT4 in a board config file, I get this: + ./MAKEALL TQM860L Configuring for TQM860L board... common/libcommon.o: In function `do_ext4_load': /home/wd/git/u-boot/work/common/cmd_ext4.c:143: undefined reference to `ext2fs_set_blk_dev' common/libcommon.o: In function `do_ext4_ls': /home/wd/git/u-boot/work/common/cmd_ext4.c:220: undefined reference to `ext2fs_set_blk_dev' fs/ext4/libext4fs.o: In function `ext4fs_read_file': /home/wd/git/u-boot/work/fs/ext4/ext4fs.c:152: undefined reference to `ext2fs_devread' /home/wd/git/u-boot/work/fs/ext4/ext4fs.c:178: undefined reference to `ext2fs_devread' /home/wd/git/u-boot/work/fs/ext4/ext4fs.c:192: undefined reference to `ext2fs_devread' fs/ext4/libext4fs.o: In function `ext4fs_ls': /home/wd/git/u-boot/work/fs/ext4/ext4fs.c:211: undefined reference to `ext2fs_find_file' /home/wd/git/u-boot/work/fs/ext4/ext4fs.c:218: undefined reference to `ext2fs_iterate_dir' fs/ext4/libext4fs.o: In function `ext4fs_blockgroup': /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1479: undefined reference to `ext2fs_devread' fs/ext4/libext4fs.o: In function `ext4fs_read_inode': /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1506: undefined reference to `ext2fs_devread' fs/ext4/libext4fs.o: In function `ext4fs_get_extent_block': /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1457: undefined reference to `ext2fs_devread' fs/ext4/libext4fs.o: In function `read_allocated_block': /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1601: undefined reference to `ext2fs_devread' /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1648: undefined reference to `ext2fs_devread' fs/ext4/libext4fs.o:/home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1686: more undefined references to `ext2fs_devread' follow fs/ext4/libext4fs.o: In function `ext4fs_open': /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1876: undefined reference to `ext2fs_find_file' fs/ext4/libext4fs.o: In function `ext4fs_mount': /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1907: undefined reference to `ext2fs_devread' /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1934: undefined reference to `inode_size' /home/wd/git/u-boot/work/fs/ext4/ext4_common.c:1936: undefined reference to `ext2fs_root' make: *** [/work/wd/tmp-ppc/u-boot] Error 1 It seems this happens when you only enable CONFIG_CMD_EXT4, without explicitly enabling CONFIG_CMD_EXT2 as well. Please fix this - if the ext4 code needs ext2, then it should automatically enable this option. Hm... How much code duplication (for ext2 and ext4 commands) does this cause? 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 The trouble with our times is that the future is not what it used to be. - Paul Valery ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help with Cross-Compiling U-boot for PPC
On 01/04/2012 04:35 PM, Will Khan wrote: Hi all, My goal is to (simply) build u-boot to run on my target processor which is MPC8349. My host environment where I will be building the u-boot is a SUSE linux system running on an intel x86 PC (therefore I will cross compile). I have followed the instructions on the wiki and README file, and created a u-boot.bin file. I after I load the u-boot.bin (with a BDI2000 debugger) and reset the device, it produces random (garbage) text through the serial port. It normally should produce a welcome message, etc.. Here are my steps: I have downloaded the latest u-boot version and unpacked it: v2011.12-rc2 Make distclean Make MPC8349EMDS_config CROSS_COMPILE=powerpc-linux- Export CROSSCOMPILE Make all (note that I derived the above commands from the README file in the u-boot directory (see sections at Line 274, line 3350) I believe my configuration of the BDI2000 debugger is correct as I've successfully loaded my older version of u-boot.bin (created by someone before me) many times with it and it worked. If there is an obvious step I am missing, or incorrect syntax, please let me know. Yes, debug u-boot with GDB using the BDI... Load youru-boot image in the BDI, set the PC to the entry point, then in a shell, fire up your cross debugger via powerpc-linux-gdb u-boot, then in gdb, connect to your target via target remote abatron IP:2001 (where abatron ip is the hostname or IP address of your Abatron), and you can then debug the code on the board. I'd look at the UART initialisation to make sure the baud rate is correct (i.e. do you have the proper cpu frequencies set, and the proper derived UART divisor(s) for your desired baud rate)... -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: factor out the env_get_char_spec() function
Dear Igor Grinberg, In message 1324906390-26264-1-git-send-email-grinb...@compulab.co.il you wrote: env_get_char_spec() function is duplicated across multiple environment files. Remove the duplication by providing a default implementation. Add weak declaration, so the default implementation can be overridden. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- common/env_common.c |7 +++ common/env_flash.c |5 - common/env_mgdisk.c |5 - common/env_mmc.c |5 - common/env_nand.c|5 - common/env_nowhere.c |5 - common/env_nvram.c |6 ++ common/env_onenand.c |5 - common/env_sf.c |5 - 9 files changed, 9 insertions(+), 39 deletions(-) Applied, thanks. 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 It all seemed, he thought, to be rather a lot of trouble to go to just sharpen a razor blade. - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [trivial] common.h: remove value from bool defines
Dear Igor Grinberg, In message 1324882432-8798-1-git-send-email-grinb...@compulab.co.il you wrote: Several boolean defines have a value assigned. Remove the value as defining the symbol is enough. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- include/common.h | 16 1 files changed, 8 insertions(+), 8 deletions(-) Applied, thanks. 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 Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. - Fred Allen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [trivial] env: remove value from boolean defines
Dear Igor Grinberg, In message 1324813377-16764-1-git-send-email-grinb...@compulab.co.il you wrote: Several boolean defines have a value assigned. Remove the value as defining the symbol is enough. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- include/environment.h |8 tools/envcrc.c|6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) Applied, thanks. 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 Common sense and a sense of humor are the same thing, moving at different speeds. A sense of humor is just common sense, dancing. - Clive James ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/mkenvimage.c: Fix a merge issue
Dear Horst Kronstorfer, In message 1324723318-32752-1-git-send-email-hkron...@frequentis.com you wrote: With bfcc40bb09b05c90cc3b1496abb270eb8aa72134 'optopt' was reverted. Signed-off-by: Horst Kronstorfer hkron...@frequentis.com --- tools/mkenvimage.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. 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 The net result is a system that is not only binary compatible with 4.3 BSD, but is even bug for bug compatible in almost all features. - Avadit Tevanian, Jr., Architecture-Independent Virtual Memory Management for Parallel and Distributed Environments: The Mach Approach ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env.c: use default env values if config file cannot be opened
2012/1/5 Wolfgang Denk w...@denx.de Dear Frans Meulenbroeks, In message 1325098913-29909-1-git-send-email-fransmeulenbro...@gmail.com you wrote: If the config file cannot be opened currently one gets an error even though the build in names/sizes are probably ok. By setting the default values first and only exit if there is a read error and not when the config file can be opened the program will try the default settings. I have to admit that I don't like this change of behaviour. When configured for use with a config file, all errors should be treated the same. But that's just my $ 0.02. Are there any other opinions / votes how to proceed here? Best regards, Wolfgang Denk As you mentioned in another reply the common practice nowadays seems to be to use a conf file. This has the disadvantage that the conf file can get lost or misplaced. For embedded systems I would prefer compiled-in values (or maybe an autosensing version that just seeks into /dev/mtd0 or so to find the actual location of the environment, if the sector size is known it would not be too hard. BTW: it could also be argued that the specification of the config file should be in the board config, not in fw_env.h. Frans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Dear Thierry Reding, In message 1321524246-5187-2-git-send-email-thierry.red...@avionic-design.de you wrote: The AVP on Tegra2 doesn't boot properly when U-Boot is linked against the GCC provided libgcc. To work around this, always build and link against a private libgcc for Tegra2-based boards. I notice this patch only now, when pulling in from u-boot-arm. I will accept this only temporarily. Why don't you use a working tool chain instead, or fix the one you are using? 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 COBOL is for morons. -- E.W. Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
Dear Albert ARIBAUD, In message 4ef59ae7.9030...@aribaud.net you wrote: Hi Wolfgang, Following the opening of the merge window, the following changes since commit bfcc40bb09b05c90cc3b1496abb270eb8aa72134: Merge branch 'next' of ../next (2011-12-23 20:53:58 +0100) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Christian Riesch (7): spl: display_options.o is required for SPI flash support in SPL sf: Add spi_boot() to allow booting from SPI flash in an SPL arm, davinci: Add SPL support for DA850 SoCs arm, da850evm: Add an SPL for SPI boot mkimage: Fix variable length header support arm, davinci: Add support for generating AIS images to the Makefile arm, davinci: Fix build warnings for cam_enc_4xx Fabio Estevam (1): vision2: Fix checkpatch warning Simon Glass (14): tegra2: Tidy UART selection tegra2: Add UARTB support tegra2: config: Enable SPI flash on Seaboard tegra2: Enable SPI environment on Seaboard tegra2: Implement SPI / UART GPIO switch tegra2: spi: Support SPI / UART switch tegra2: Plumb in SPI/UART switch code tegra: Fix build error in plutux, medcom tegra: Move cpu_init_cp15() to arch_cpu_init() tegra: Move clock_early_init() to arch_cpu_init() tegra: add clock_ll_start_uart() to enable UART prior to reloc tegra: Add a function mux feature tegra: Add support for UART init in cpu board.c tegra: Move boards over to use arch-level board UART function Stefano Babic (2): ARM: omap3: added common configuration for Technexion TAM3517 ARM: omap3: add support to Technexion twister board Thierry Reding (7): tegra2: Always build with USE_PRIVATE_LIBGCC=yes. tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000. tegra2: Move tegra2_mmc_init() prototype to public header. tegra2: Add common Avionic Design Tamonten support. tegra2: Add Avionic Design Plutux support. tegra2: Add Avionic Design Medcom support. tegra2: Optimize out-of-tree build for Ventana. Thomas Weber (1): Devkit8000: Switch over to enable_gpmc_cs_config Tom Warren (2): tegra2: spi: Add SPI driver for Tegra2 SOC arm: Tegra: Fix Harmony and Ventana builds in u-boot-tegra/master .gitignore |1 + MAINTAINERS|6 + Makefile | 13 + arch/arm/cpu/arm926ejs/davinci/Makefile|3 +- arch/arm/cpu/arm926ejs/davinci/spl.c | 35 ++- arch/arm/cpu/armv7/tegra2/Makefile |2 +- arch/arm/cpu/armv7/tegra2/board.c | 58 +++ arch/arm/cpu/armv7/tegra2/clock.c | 14 + arch/arm/cpu/armv7/tegra2/config.mk|2 + arch/arm/cpu/armv7/tegra2/funcmux.c| 58 +++ arch/arm/include/asm/arch-tegra2/board.h | 30 ++ arch/arm/include/asm/arch-tegra2/clock.h | 11 + arch/arm/include/asm/arch-tegra2/funcmux.h | 41 ++ arch/arm/include/asm/arch-tegra2/mmc.h | 27 ++ arch/arm/include/asm/arch-tegra2/tegra2.h |1 + arch/arm/include/asm/arch-tegra2/tegra2_spi.h | 76 arch/arm/include/asm/arch-tegra2/uart-spi-switch.h | 46 +++ board/avionic-design/common/tamonten.c | 116 ++ board/avionic-design/common/tamonten.h | 32 ++ board/avionic-design/medcom/Makefile | 50 +++ board/avionic-design/medcom/medcom.c | 45 +++ board/avionic-design/plutux/Makefile | 50 +++ board/avionic-design/plutux/plutux.c | 45 +++ board/davinci/da8xxevm/da850evm.c |4 +- board/davinci/da8xxevm/u-boot-spl.lds | 73 board/nvidia/common/Makefile | 47 +++ board/nvidia/common/board.c| 73 +--- board/nvidia/common/board.h|2 +- board/nvidia/common/uart-spi-switch.c | 138 +++ board/nvidia/harmony/Makefile |1 - board/nvidia/harmony/harmony.c |2 +- board/nvidia/seaboard/Makefile |1 - board/nvidia/seaboard/seaboard.c |5 +- board/nvidia/ventana/Makefile |6 +- board/technexion/twister/Makefile | 38 ++ board/technexion/twister/twister.c | 116 ++ board/technexion/twister/twister.h | 411 board/timll/devkit8000/devkit8000.c| 19 +- board/ttcontrol/vision2/vision2.c |3 +- boards.cfg
Re: [U-Boot] [PATCH] tools/env: allow overwrite of ethaddr on default
Dear Grant Erickson, In message 1324580395-27004-1-git-send-email-maratho...@gmail.com you wrote: This patch allows the U-Boot user space companion utility, fw_setenv, to overwrite the 'ethaddr' key/value pair if the current value is set to a per-board-configured default. This change allows 'fw_setenv' to match the behavior of 'setenv' / 'env set' on the U-Boot command line. Signed-off-by: Grant Erickson maratho...@gmail.com --- tools/env/fw_env.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) Applied, thanks. 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 The Buddha, the Godhead, resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower. - R. Pirsig, Zen and the Art of Motorcycle Maintenance ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Michal Simek, In message 4ef2f20b.6050...@monstr.eu you wrote: Are there going to be any users for this code? Sure. This driver lies out of mainline code for quite some times. ll_temac is IP core which is used by Microblaze and xilinx ppc. There are two options for network IP. The first is emaclite driver which is in the mainline and high speed and especially 1Gb/s LAN ll_temac driver. Then let's add it when the first board gets submitted that uses it. 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 Nobody trips over mountains. It is the small pebble that causes you to stumble. Pass all the pebbles in your path and you will find you have crossed the mountain. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ext2: Cache line align indirection buffers
Dear Simon Glass, In message 1324497688-26529-1-git-send-email-...@chromium.org you wrote: Make ext2 use cache line aligned buffers for reading from the filesystem. This is needed when caches are enabled because unaligned cache invalidates are not safe. Signed-off-by: Simon Glass s...@chromium.org --- fs/ext2/ext2fs.c | 18 -- 1 files changed, 12 insertions(+), 6 deletions(-) Applied, thanks. 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 Real Programmers always confuse Christmas and Halloween because OCT 31 == DEC 25 ! - Andrew Rutherford (andr...@ucs.adelaide.edu.au) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] fs/fat: Fix FAT detection to support non-DOS partition tables
Dear Kyle Moffett, In message 1324487292-7299-2-git-send-email-kyle.d.moff...@boeing.com you wrote: The FAT filesystem code currently ends up requiring that the partition table be a DOS MBR, as it checks for the DOS 0x55 0xAA signature on the partition table (which may be Mac, EFI, ISO9660, etc) before actually computing the partition offset. This fixes support for accessing a FAT filesystem in an ISO9660 boot volume (El-Torito format) by reordering the filesystem checks and reading the 0x55 0xAA DOS boot signature and FAT/FAT32 magic number from the first sector of the partition instead of from sector 0. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com -- v2: I have removed the unnecessary static initializers. All the variables are memset to 0 as part of the BSS, and cur_dev is only initialized after the rest of the variables have been set correctly. --- fs/fat/fat.c | 117 +++--- 1 files changed, 54 insertions(+), 63 deletions(-) Applied, thanks. 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 Plan to throw one away. You will anyway. - Fred Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] fs/fat: Improve error handling
Dear Kyle Moffett, In message 1324487292-7299-3-git-send-email-kyle.d.moff...@boeing.com you wrote: The FAT filesystem fails silently in inexplicable ways when given a filesystem with a block-size that does not match the device sector size. In theory this is not an unsupportable combination but requires a major rewrite of a lot of the filesystem. Until that occurs, the filesystem should detect that scenario and display a helpful error message. This scenario in particular occurred on a 512-byte blocksize FAT fs stored in an El-Torito boot volume on a CD-ROM (2048-byte sector size). Additionally, in many circumstances the -block_read method will not return a negative number to indicate an error but instead return 0 to indicate the number of blocks successfully read (IE: None). The FAT filesystem should defensively check to ensure that it got all of the sectors that it asked for when reading. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com -- v2: No change --- fs/fat/fat.c | 18 ++ 1 files changed, 14 insertions(+), 4 deletions(-) Applied, thanks. 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 CONSUMER NOTICE: Because of the Uncertainty Principle, It Is Impossible for the Consumer to Find Out at the Same Time Both Precisely Where This Product Is and How Fast It Is Moving. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb_storage: Fix EHCI out of buffer pointers with CD-ROM
Dear Kyle Moffett, In message 1324487292-7299-4-git-send-email-kyle.d.moff...@boeing.com you wrote: When performing large bulk reads from a CD or DVD using the U-Boot usb_storage driver, it generates requests of up to 20 blocks at a time. With a standard 512-byte block size, that is 10240 bytes and within the limit of U-Boot's EHCI driver (maximum 5 pages at 4k per page). Unfortunately CD-ROM media has a 2048-byte blocksize, resulting in a maximum transfer size of 40960 bytes, which does not fit. Since the EHCI specification is impossibly obtuse and far beyond my comprehension, I chose to dynamically compute the limit based on the blocksize. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com -- v2: Minor whitespace fixes --- common/usb_storage.c | 45 + 1 files changed, 25 insertions(+), 20 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de An organization dries up if you don't challenge it with growth. - Mark Shepherd, former President and CEO of Texas Instruments ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avoid flash writes for new keys, with no values with fw_setenv
Dear Sridhar Addagada, In message 1324457962.60605.yahoomail...@web120203.mail.ne1.yahoo.com you wrote: This will avoid flash writes for fw_setenv command where the key is not present the environment and no value has been provided. Line too long. And your patch is white space corrupted. Please fix your mailer, or better use git-format-patch and git-send-email instead. Also, make sure to always call fw_env_close(). 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 If there are self-made purgatories, then we all have to live in them. -- Spock, This Side of Paradise, stardate 3417.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FAT: update the second FAT when writing a file
Dear Donggeun Kim, In message 1324442067-6448-1-git-send-email-dg77@samsung.com you wrote: After susccessful write to the FAT partition, fsck program may print warning message due to different FAT, provided that the filesystem supports two FATs. This patch makes the second FAT to be same with the first one when writing a file. Signed-off-by: Donggeun Kim dg77@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- fs/fat/fat_write.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) Applied, thanks. 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 can't evaluate a man by logic alone. -- McCoy, I, Mudd, stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] cmd_fat: add FAT write command
Dear Donggeun Kim, In message 1324431247-17998-1-git-send-email-dg77@samsung.com you wrote: Once CONFIG_FAT_WRITE is defined, users can invoke 'fatwrite' command that saves data in RAM as a FAT file. By removing variable of 'part_size' in fs/fat.c, compile error occurs when enabling FAT write feature. The variable should be declared only when CONFIG_FAT_WRITE is defined. This patch also removes compile error when FAT write is enabled and compile warning when FAT write is disabled. Signed-off-by: Donggeun Kim dg77@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Changes for v3: - use cmd_usage function Changes for v2: - merge the patch that fixes compile error when enabling FAT write - change do_fat_fswrite to be static function common/cmd_fat.c | 57 ++ fs/fat/fat.c |7 ++ 2 files changed, 64 insertions(+), 0 deletions(-) This does not apply any more, please rebase against current master and resubmit. Sorry. 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 The years of peak mental activity are undoubtedly between the ages of four and eighteen. At four we know all the questions, at eighteen all the answers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10] Correctly handle input files beginning with several newlines
Dear David Wagner, In message 1324429169-10177-1-git-send-email-david.wag...@free-electrons.com you wrote: Also, fix some comments (minor) Signed-off-by: David Wagner david.wag...@free-electrons.com --- tools/mkenvimage.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Applied, thanks. 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 Sorry, but my karma just ran over your dogma. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 03/10] mkenvimage: Correct the includes and add a missing one
Dear David Wagner, In message 1324429120-10141-1-git-send-email-david.wag...@free-electrons.com you wrote: compiler.h and u-boot/crc.h need to be included from U-Boot's headers. stdlib.h was missing. Signed-off-by: David Wagner david.wag...@free-electrons.com --- This version is rebased on top of 'next' (it didn't apply anymore, after Horst Kronstorfer's patches). Please rebase against current master and resubmit. Thanks. 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 There are things that are so serious that you can only joke about them- Heisenberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] net: add Calxeda xgmac driver
Dear Rob Herring, In message 1323983750-3399-1-git-send-email-robherri...@gmail.com you wrote: From: Rob Herring rob.herr...@calxeda.com This adds ethernet driver for Calxeda xgmac found on Highbank SOC. Signed-off-by: Rob Herring rob.herr...@calxeda.com --- v3: - whitespace fixes - move reset to .init function - fix calxedaxgmac_initialize return values - fix 2 build warnings v2: -Convert register base plus offset to struct -drop ethaddr env setting -drop valid mac address check README |3 + drivers/net/Makefile |1 + drivers/net/calxedaxgmac.c | 553 include/netdev.h |1 + 4 files changed, 558 insertions(+), 0 deletions(-) create mode 100644 drivers/net/calxedaxgmac.c Applied, thanks. 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 penny saved is a penny to squander. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] ARM: highbank: enable networking and pxe
Dear Rob Herring, In message 1323983750-3399-2-git-send-email-robherri...@gmail.com you wrote: From: Rob Herring rob.herr...@calxeda.com This enables the XGMAC ethernet driver and networking related config options. Signed-off-by: Jason Hobbs jason.ho...@calxeda.com Signed-off-by: Rob Herring rob.herr...@calxeda.com --- v3: - make board_eth_init return number of devices initialized v2: -drop CONFIG_NET_MULTI -drop leftover 'verify' env setting board/highbank/highbank.c | 12 include/configs/highbank.h | 18 -- 2 files changed, 28 insertions(+), 2 deletions(-) Applied, thanks. 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 C++ was an interesting and valuable experiment, but we've learned its lessons and it's time to move on. - Peter Curran in dcqm4z@isgtec.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
On 01/05/2012 08:50 AM, Wolfgang Denk wrote: Dear Thierry Reding, In message 1321524246-5187-2-git-send-email-thierry.red...@avionic-design.de you wrote: The AVP on Tegra2 doesn't boot properly when U-Boot is linked against the GCC provided libgcc. To work around this, always build and link against a private libgcc for Tegra2-based boards. I notice this patch only now, when pulling in from u-boot-arm. I will accept this only temporarily. Why don't you use a working tool chain instead, or fix the one you are using? I believe the issue isn't that the toolchain is broken, but due to the mix of multiple CPU types on Tegra, all of which run the same U-Boot binary. U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue running U-Boot. The libraries included in the toolchain are built for the ARMv7 CPUs, and hence fail to operate correctly when used by the portion of U-Boot which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC, there are overrides in the U-Boot build process such that some/all of U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc built by U-Boot solves this. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Hi Stephen, On Thu, Jan 5, 2012 at 8:53 AM, Stephen Warren swar...@nvidia.com wrote: On 01/05/2012 08:50 AM, Wolfgang Denk wrote: Dear Thierry Reding, In message 1321524246-5187-2-git-send-email-thierry.red...@avionic-design.de you wrote: The AVP on Tegra2 doesn't boot properly when U-Boot is linked against the GCC provided libgcc. To work around this, always build and link against a private libgcc for Tegra2-based boards. I notice this patch only now, when pulling in from u-boot-arm. I will accept this only temporarily. Why don't you use a working tool chain instead, or fix the one you are using? I believe the issue isn't that the toolchain is broken, but due to the mix of multiple CPU types on Tegra, all of which run the same U-Boot binary. U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue running U-Boot. The libraries included in the toolchain are built for the ARMv7 CPUs, and hence fail to operate correctly when used by the portion of U-Boot which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC, there are overrides in the U-Boot build process such that some/all of U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc built by U-Boot solves this. Yes that's right, but actually I have never delved into exactly why. Perhaps it is an integer divide or internal memcpy() call early in the code. We might be able to find the offending C library code, given enough time, and perhaps arrange not to call it. A little fragile though. Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] net: ll_temac: Add LL TEMAC driver to u-boot
Am Donnerstag, den 05.01.2012, 17:10 +0100 schrieb Wolfgang Denk: Dear Michal Simek, In message 4ef2f20b.6050...@monstr.eu you wrote: Are there going to be any users for this code? Sure. This driver lies out of mainline code for quite some times. ll_temac is IP core which is used by Microblaze and xilinx ppc. There are two options for network IP. The first is emaclite driver which is in the mainline and high speed and especially 1Gb/s LAN ll_temac driver. Then let's add it when the first board gets submitted that uses it. Michals latest Microblaze platform patches will enable this driver for board/xilinx/microblaze-generic and we know about a success story on a propietary Virtex5 FX board (ppc440) -- tested by Ricardo Ribalda. So it could be save to add the driver together with Michals platform patches. It works fine to me on different ML605 (Virtex 6) and SP3ADSP1800 (Spartan 3) Microblaze systems but ... Last week, I received hints from Andy Fleming to improve the PHYLIB handling and avoid deprecated code. So I'll rework the driver and present a new v8 patch as soon as possible. -- Best regards, Stephan Linz __ MB-Ref: http://www.li-pro.de/xilinx_mb:mbref:start OpenDCC: http://www.li-pro.net/opendcc.phtml PC/M: http://www.li-pro.net/pcm.phtml Sourceforge: http://sourceforge.net/users/slz Gitorious: https://gitorious.org/~slz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Simon, -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: Thursday, January 05, 2012 10:07 AM To: Stephen Warren Cc: Wolfgang Denk; Thierry Reding; u-boot@lists.denx.de; Tom Warren Subject: Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes. Hi Stephen, On Thu, Jan 5, 2012 at 8:53 AM, Stephen Warren swar...@nvidia.com wrote: On 01/05/2012 08:50 AM, Wolfgang Denk wrote: Dear Thierry Reding, In message 1321524246-5187-2-git-send-email-thierry.reding@avionic- design.de you wrote: The AVP on Tegra2 doesn't boot properly when U-Boot is linked against the GCC provided libgcc. To work around this, always build and link against a private libgcc for Tegra2-based boards. I notice this patch only now, when pulling in from u-boot-arm. I will accept this only temporarily. Why don't you use a working tool chain instead, or fix the one you are using? I believe the issue isn't that the toolchain is broken, but due to the mix of multiple CPU types on Tegra, all of which run the same U-Boot binary. U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue running U-Boot. The libraries included in the toolchain are built for the ARMv7 CPUs, and hence fail to operate correctly when used by the portion of U-Boot which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC, there are overrides in the U-Boot build process such that some/all of U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc built by U-Boot solves this. Yes that's right, but actually I have never delved into exactly why. Perhaps it is an integer divide or internal memcpy() call early in the code. We might be able to find the offending C library code, given enough time, and perhaps arrange not to call it. A little fragile though. IIRC, it was a divide that caused an undefined instruction exception. You can run U-Boot w/o the UE_PRIVATE_LIBGCC, and break in w/JTAG and look at the undefined instr shadow regs (sp/lr/pc) and find the opcode that caused the fault pretty easily, again IIRC. But USE_PRIVATE_LIBGCC was intended for just this problem, and works fine. Tom Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix logic for selection of CONFIG_SYS_DEF_EEPROM_ADDR
Any comments on this patch? If not, could it please be applied/merged? It fixes a definite bug on the HWW-1U-1A board. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ On Dec 15, 2011, at 21:15, Kyle Moffett wrote: A board with CONFIG_SPI and CONFIG_ENV_EEPROM_IS_ON_I2C will get: #define CONFIG_SYS_DEF_EEPROM_ADDR 0 Instead of the expected: #define CONFIG_SYS_DEF_EEPROM_ADDR CONFIG_SYS_I2C_EEPROM_ADDR As a result, the eeprom command is unusable because it calls i2c_read() and i2c_write() but always uses an address of 0x00. This fixes the logic for that particular case, hopefully without breaking any other board configurations. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com Cc: Heiko Schocher h...@denx.de --- include/common.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/common.h b/include/common.h index 5cfdd76..8a1b401 100644 --- a/include/common.h +++ b/include/common.h @@ -402,13 +402,13 @@ extern void pic_write (uchar reg, uchar val); * Set this up regardless of board * type, to prevent errors. */ -#if defined(CONFIG_SPI) || !defined(CONFIG_SYS_I2C_EEPROM_ADDR) +#if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) +# define CONFIG_SYS_DEF_EEPROM_ADDR 0 +#elif !defined(CONFIG_SYS_I2C_EEPROM_ADDR) # define CONFIG_SYS_DEF_EEPROM_ADDR 0 #else -#if !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) # define CONFIG_SYS_DEF_EEPROM_ADDR CONFIG_SYS_I2C_EEPROM_ADDR #endif -#endif /* CONFIG_SPI || !defined(CONFIG_SYS_I2C_EEPROM_ADDR) */ #if defined(CONFIG_SPI) extern void spi_init_f (void); -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fw_env.h: fix comment
made description according to implementation (where the config file is the default). Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com --- tools/env/fw_env.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/env/fw_env.h b/tools/env/fw_env.h index 9258c79..cfbe108 100644 --- a/tools/env/fw_env.h +++ b/tools/env/fw_env.h @@ -22,8 +22,8 @@ */ /* - * To build the utility with the run-time configuration - * uncomment the next line. + * To build the utility with the static configuration + * comment out the next line. * See included fw_env.config sample file * for notes on configuration. */ -- 1.7.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] add nand spl boot for qi_lb60 board
On 01/04/2012 06:24 PM, Xiangfu Liu wrote: Hi yes. I have cpmpared this. but I can't find where is the problem. attachment is the u-boot.map diff. after remove those 'extern' the u-boot-nand-spl is exact same. binary file. map file both same. but the u-boot.bin/map changed. Please help me take a look. Use mips-whatever-objdump -dlrsh on the good and bad u-boot binaries (or on any .o files you suspect may be relevant), to see more specifically what's different. You may also want to try compiling suspect files to assembly and comparing the differences there. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 1/8] Strip mkenvimage
Signed-off-by: David Wagner david.wag...@free-electrons.com --- tools/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index a5f989a..64bcc4d 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -194,6 +194,7 @@ $(obj)xway-swap-bytes$(SFX):$(obj)xway-swap-bytes.o $(obj)mkenvimage$(SFX):$(obj)crc32.o $(obj)mkenvimage.o $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ + $(HOSTSTRIP) $@ $(obj)mkimage$(SFX): $(obj)aisimage.o \ $(obj)crc32.o \ -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3 3/8] mkenvimage: Correct the includes and add a missing one
compiler.h and u-boot/crc.h need to be included from U-Boot's headers. stdlib.h was missing. Signed-off-by: David Wagner david.wag...@free-electrons.com --- tools/mkenvimage.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c index 7d33143..bc18736 100644 --- a/tools/mkenvimage.c +++ b/tools/mkenvimage.c @@ -31,14 +31,15 @@ #include errno.h #include fcntl.h #include stdio.h +#include stdlib.h #include stdint.h #include string.h #include unistd.h -#include compiler.h +#include compiler.h #include sys/types.h #include sys/stat.h -#include u-boot/crc.h +#include u-boot/crc.h #include version.h #define CRC_SIZE sizeof(uint32_t) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3 5/8] mkenvimage: Read/Write from/to stdin/out by default or if the filename is -
Signed-off-by: David Wagner david.wag...@free-electrons.com
---
tools/mkenvimage.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index eb9a8f2..6db2b21 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -173,15 +173,9 @@ int main(int argc, char **argv)
memset(envptr, padbyte, envsize);
/* Open the input file ... */
- if (optind = argc) {
- fprintf(stderr, Please specify an input filename\n);
- return EXIT_FAILURE;
- }
-
- txt_filename = argv[optind];
- if (strcmp(txt_filename, -) == 0) {
+ if (optind = argc || strcmp(argv[optind], -) == 0) {
int readbytes = 0;
- int readlen = sizeof(*envptr) * 2048;
+ int readlen = sizeof(*envptr) * 4096;
txt_fd = STDIN_FILENO;
do {
@@ -199,6 +193,7 @@ int main(int argc, char **argv)
} while (readbytes == readlen);
} else {
+ txt_filename = argv[optind];
txt_fd = open(txt_filename, O_RDONLY);
if (txt_fd == -1) {
fprintf(stderr, Can't open \%s\: %s\n,
@@ -288,11 +283,16 @@ int main(int argc, char **argv)
memcpy(dataptr, targetendian_crc, sizeof(uint32_t));
- bin_fd = creat(bin_filename, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
- if (bin_fd == -1) {
- fprintf(stderr, Can't open output file \%s\: %s\n,
- bin_filename, strerror(errno));
- return EXIT_FAILURE;
+ if (!bin_filename || strcmp(bin_filename, -) == 0) {
+ bin_fd = STDOUT_FILENO;
+ } else {
+ bin_fd = creat(bin_filename, S_IRUSR | S_IWUSR | S_IRGRP |
+S_IWGRP);
+ if (bin_fd == -1) {
+ fprintf(stderr, Can't open output file \%s\: %s\n,
+ bin_filename, strerror(errno));
+ return EXIT_FAILURE;
+ }
}
if (write(bin_fd, dataptr, sizeof(*dataptr) * datasize) !=
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 4/8] mkenvimage: More error handling
Verbosly fail if the target environment size or the padding byte are badly
formated.
Verbosly fail if something bad happens when reading from standard input.
Signed-off-by: David Wagner david.wag...@free-electrons.com
---
tools/mkenvimage.c | 32 ++--
1 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index bc18736..eb9a8f2 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -93,7 +93,17 @@ int main(int argc, char **argv)
switch (option) {
case 's':
datasize = strtol(optarg, NULL, 0);
- break;
+ if (!errno)
+ break;
+
+ if (errno == ERANGE)
+ fprintf(stderr, Bad integer format: %s\n,
+ optarg);
+ else
+ fprintf(stderr, Error while parsing %s: %s\n,
+ optarg, strerror(errno));
+
+ return EXIT_FAILURE;
case 'o':
bin_filename = strdup(optarg);
if (!bin_filename) {
@@ -109,7 +119,17 @@ int main(int argc, char **argv)
break;
case 'p':
padbyte = strtol(optarg, NULL, 0);
- break;
+ if (!errno)
+ break;
+
+ if (errno == ERANGE)
+ fprintf(stderr, Bad integer format: %s\n,
+ optarg);
+ else
+ fprintf(stderr, Error while parsing %s: %s\n,
+ optarg, strerror(errno));
+
+ return EXIT_FAILURE;
case 'h':
usage(prg);
return EXIT_SUCCESS;
@@ -166,7 +186,15 @@ int main(int argc, char **argv)
do {
filebuf = realloc(filebuf, readlen);
+ if (!filebuf) {
+ fprintf(stderr, Can't realloc memory for the
input file buffer\n);
+ return EXIT_FAILURE;
+ }
readbytes = read(txt_fd, filebuf + filesize, readlen);
+ if (errno) {
+ fprintf(stderr, Error while reading stdin:
%s\n, strerror(errno));
+ return EXIT_FAILURE;
+ }
filesize += readbytes;
} while (readbytes == readlen);
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3 2/8] mkenvimage: correct and clarify comments and error messages
Also, don't split error messages over several lines as per a coding style
exception making them easier to grep.
Signed-off-by: David Wagner david.wag...@free-electrons.com
---
tools/mkenvimage.c | 41 +++--
1 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index c5ed373..7d33143 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -45,12 +45,9 @@
static void usage(const char *exec_name)
{
- fprintf(stderr, %s [-h] [-r] [-b] [-p byte]
- -s environment partition size -o output input file\n
+ fprintf(stderr, %s [-h] [-r] [-b] [-p byte] -s environment
partition size -o output input file\n
\n
- This tool takes a key=value input file (same as would a
- `printenv' show) and generates the corresponding environment
- image, ready to be flashed.\n
+ This tool takes a key=value input file (same as would a
`printenv' show) and generates the corresponding environment image, ready to be
flashed.\n
\n
\tThe input file is in format:\n
\t\tkey1=value1\n
@@ -58,8 +55,7 @@ static void usage(const char *exec_name)
\t\t...\n
\t-r : the environment has multiple copies in flash\n
\t-b : the target is big endian (default is little endian)\n
- \t-p byte : fill the image with byte bytes instead of
- 0xff bytes\n
+ \t-p byte : fill the image with byte bytes instead of 0xff
bytes\n
\t-V : print version information and exit\n
\n
If the input file is \-\, data is read from standard input\n,
@@ -100,8 +96,7 @@ int main(int argc, char **argv)
case 'o':
bin_filename = strdup(optarg);
if (!bin_filename) {
- fprintf(stderr, Can't strdup() the output
- filename\n);
+ fprintf(stderr, Can't strdup() the output
filename\n);
return EXIT_FAILURE;
}
break;
@@ -118,7 +113,7 @@ int main(int argc, char **argv)
usage(prg);
return EXIT_SUCCESS;
case 'V':
- printf(%s version %s\n, prg, PLAIN_VERSION);
+ printf(%s version %s\n, argv[0], PLAIN_VERSION);
return EXIT_SUCCESS;
case ':':
fprintf(stderr, Missing argument for option -%c\n,
@@ -134,22 +129,21 @@ int main(int argc, char **argv)
/* Check datasize and allocate the data */
if (datasize == 0) {
- fprintf(stderr,
- Please specify the size of the environment
- partition.\n);
+ fprintf(stderr, Please specify the size of the environment
partition.\n);
usage(prg);
return EXIT_FAILURE;
}
dataptr = malloc(datasize * sizeof(*dataptr));
if (!dataptr) {
- fprintf(stderr, Can't alloc dataptr.\n);
+ fprintf(stderr, Can't alloc %d bytes for dataptr.\n,
+ datasize);
return EXIT_FAILURE;
}
/*
* envptr points to the beginning of the actual environment (after the
-* crc and possible `redundant' bit
+* crc and possible `redundant' byte
*/
envsize = datasize - (CRC_SIZE + redundant);
envptr = dataptr + CRC_SIZE + redundant;
@@ -185,8 +179,8 @@ int main(int argc, char **argv)
/* ... and check it */
ret = fstat(txt_fd, txt_file_stat);
if (ret == -1) {
- fprintf(stderr, Can't stat() on \%s\:
- %s\n, txt_filename, strerror(errno));
+ fprintf(stderr, Can't stat() on \%s\: %s\n,
+ txt_filename, strerror(errno));
return EXIT_FAILURE;
}
@@ -200,13 +194,9 @@ int main(int argc, char **argv)
}
ret = close(txt_fd);
}
- /*
-* The right test to do is = (not ) because of the additional
-* ending \0. See below.
-*/
- if (filesize = envsize) {
- fprintf(stderr, The input file is larger than the
- environment partition size\n);
+ /* The +1 is for the additionnal ending \0. See below. */
+ if (filesize + 1 envsize) {
+ fprintf(stderr, The input file is larger than the environment
partition size\n);
return EXIT_FAILURE;
}
@@ -255,8 +245,7 @@ int main(int argc, char **argv)
[U-Boot] [PATCHv2 6/8] mkenvimage: Use mmap() when reading from a regular file
Signed-off-by: David Wagner david.wag...@free-electrons.com
---
tools/mkenvimage.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index 6db2b21..58f1d0b 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -38,6 +38,7 @@
#include compiler.h
#include sys/types.h
#include sys/stat.h
+#include sys/mman.h
#include u-boot/crc.h
#include version.h
@@ -209,14 +210,16 @@ int main(int argc, char **argv)
}
filesize = txt_file_stat.st_size;
- /* Read the raw input file and transform it */
- filebuf = malloc(sizeof(*envptr) * filesize);
- ret = read(txt_fd, filebuf, sizeof(*envptr) * filesize);
- if (ret != sizeof(*envptr) * filesize) {
- fprintf(stderr, Can't read the whole input file\n);
+
+ filebuf = mmap(NULL, sizeof(*envptr) * filesize, PROT_READ,
+ MAP_PRIVATE, txt_fd, 0);
+ ret = close(txt_fd);
+ if (filebuf == MAP_FAILED) {
+ fprintf(stderr, mmap (%ld bytes) failed: %s\n,
+ sizeof(*envptr) * filesize,
+ strerror(errno));
return EXIT_FAILURE;
}
- ret = close(txt_fd);
}
/* The +1 is for the additionnal ending \0. See below. */
if (filesize + 1 envsize) {
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 7/8] mkenvimage: Don't try to detect comments in the input file
Remove this feature since it seems impossible to reliably detect them.
Signed-off-by: David Wagner david.wag...@free-electrons.com
---
tools/mkenvimage.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index 58f1d0b..a3d4e27 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -249,14 +249,6 @@ int main(int argc, char **argv)
/* End of a variable */
envptr[ep++] = '\0';
}
- } else if (filebuf[fp] == '#') {
- if (fp != 0 filebuf[fp-1] == '\n') {
- /* This line is a comment, let's skip it */
- while (fp txt_file_stat.st_size fp++
- filebuf[fp] != '\n');
- } else {
- envptr[ep++] = filebuf[fp];
- }
} else {
envptr[ep++] = filebuf[fp];
}
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3 8/8] mkenvimage: Really set the redundant byte when applicable
Signed-off-by: David Wagner david.wag...@free-electrons.com
---
tools/mkenvimage.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index a3d4e27..c1e6cad 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -276,7 +276,9 @@ int main(int argc, char **argv)
crc = crc32(0, envptr, envsize);
targetendian_crc = bigendian ? cpu_to_be32(crc) : cpu_to_le32(crc);
- memcpy(dataptr, targetendian_crc, sizeof(uint32_t));
+ memcpy(dataptr, targetendian_crc, sizeof(targetendian_crc));
+ if (redundant)
+ dataptr[sizeof(targetendian_crc)] = 1;
if (!bin_filename || strcmp(bin_filename, -) == 0) {
bin_fd = STDOUT_FILENO;
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SMSC 9215 MII mode
Is anyone working on a patch to use the MII mode in the SMSC9215? Would anyone be interested in such a patch? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_nand: add biterror insertion command for NAND Flash
On 01/05/2012 02:59 AM, Holger Brunck wrote: Hi Scott, On 01/04/2012 06:44 PM, Scott Wood wrote: On 01/04/2012 09:32 AM, Holger Brunck wrote: Initial implementation for unsafe feature for biterror insertion on NAND-Flash devices. The code flips single bits in the data block of the flash to simulate single bit-errors. Tested with Samsung K9F1G08U0D and Micron MT29F1G08ABADAWP on km_kirkwood boards. Do we still need dedicated code for this now that we have the ability to do raw writes? to be able to do raw writes was very usefull for me to reproduce a bug in the UBI layer in the past. Bitflips happen very rarely but they happen, and with this code you are able to force this and see how other SW layer handle this. Due to the fact there was an empty implementation in the u-boot code for this I thought it might be usefull for others too. The biterr stub has been around since before we had raw writes. If we decide we don't need a separate biterr command, we should remove the stub. Anything the biterr command does should be possible with raw writes, so while having a dedicated command might be slightly more convenient, I don't think it's worth the extra code size, review/fix iterations, and maintenance. Does anyone else have a strong opinion on the matter? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] fs/fat: Fix FAT detection to support non-DOS partition tables
Dear Kyle Moffett, In message 1324487292-7299-2-git-send-email-kyle.d.moff...@boeing.com you wrote: The FAT filesystem code currently ends up requiring that the partition table be a DOS MBR, as it checks for the DOS 0x55 0xAA signature on the partition table (which may be Mac, EFI, ISO9660, etc) before actually computing the partition offset. This fixes support for accessing a FAT filesystem in an ISO9660 boot volume (El-Torito format) by reordering the filesystem checks and reading the 0x55 0xAA DOS boot signature and FAT/FAT32 magic number from the first sector of the partition instead of from sector 0. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com Arg... This causes build warnings: fat.c: In function 'fat_register_device': fat.c:66:15: warning: variable 'found_partition' set but not used [-Wunused-but-set-variable] I fix this when applying. 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 Bankers do it with interest (penalty for early withdrawal). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Dear Stephen Warren, In message 4f05d596.6030...@nvidia.com you wrote: I will accept this only temporarily. Why don't you use a working tool chain instead, or fix the one you are using? I believe the issue isn't that the toolchain is broken, but due to the mix of multiple CPU types on Tegra, all of which run the same U-Boot binary. When we can solve this issue with our own version of the libgcc, then we can also solve it by using a tool chain that provides the needed lingcc code. U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue running U-Boot. OK, so you have to use a tool chain which provides libgcc code for armv4t systems. What exactly is the problem here? The libraries included in the toolchain are built for the ARMv7 CPUs, SO this is not the right tool chain for the job. Ecactly what I said. and hence fail to operate correctly when used by the portion of U-Boot which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC, there are overrides in the U-Boot build process such that some/all of U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc built by U-Boot solves this. No, this is NOT a solution, it is a workaround for an inappropriate toolchain. If you want to build code for an armv4t system, you must use a tool chain that supports it. 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 Small is beautiful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Dear Simon Glass, In message capnjgz2wcqf2tpwwfudkg7y_xdeyhbfrenqxxrjg6eu7yj9...@mail.gmail.com you wrote: The libraries included in the toolchain are built for the ARMv7 CPUs, and hence fail to operate correctly when used by the portion of U-Boot which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC, there are overrides in the U-Boot build process such that some/all of U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc built by U-Boot solves this. Yes that's right, but actually I have never delved into exactly why. Perhaps it is an integer divide or internal memcpy() call early in the code. We might be able to find the offending C library code, given enough time, and perhaps arrange not to call it. A little fragile though. That would be the totally wrong approach. Problems should be solved where they originate. Here this appears to be the tool chain, which does not provide a version of libgcc suitable for amv4t configurations. 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 All men should freely use those seven words which have the power to make any marriage run smoothly: You know dear, you may be right. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Stephan Linz, In message 1325783490.7827.45.camel@keto you wrote: Michals latest Microblaze platform patches will enable this driver for board/xilinx/microblaze-generic and we know about a success story on a propietary Virtex5 FX board (ppc440) -- tested by Ricardo Ribalda. So it could be save to add the driver together with Michals platform patches. It works fine to me on different ML605 (Virtex 6) and SP3ADSP1800 (Spartan 3) Microblaze systems but ... Frankly, I don't care at all about reports that it is working for this or that out of tree port. As long as there is no code in mainline that will use the driver and thus profide a way to test if it's actually compile clean, I will not add it. Last week, I received hints from Andy Fleming to improve the PHYLIB handling and avoid deprecated code. So I'll rework the driver and present a new v8 patch as soon as possible. OK. Please submit it only if it comes with code that references the driver. 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 History tends to exaggerate. -- Col. Green, The Savage Curtain, stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
On 01/05/2012 12:16 PM, Wolfgang Denk wrote: In message 4f05d596.6030...@nvidia.com you wrote: ... The libraries included in the toolchain are built for the ARMv7 CPUs, SO this is not the right tool chain for the job. Ecactly what I said. and hence fail to operate correctly when used by the portion of U-Boot which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC, there are overrides in the U-Boot build process such that some/all of U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc built by U-Boot solves this. No, this is NOT a solution, it is a workaround for an inappropriate toolchain. If you want to build code for an armv4t system, you must use a tool chain that supports it. But we don't want to generate code for ARMv4 in general, but rather ARMv7 as the toolchain does. Only a tiny part of the code needs to be built for ARMv4, and in general we want to benefit from using ARMv7. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH] DaVinci/i2c: allow multiple buses
On Wed, Dec 21, 2011 at 10:36 PM, Jérôme Carretero cj-ub...@zougloub.eu wrote:
Hi Tom,
I'm requesting comments on the following (untested) patch.
It adds support for multiple i2c buses on davinci_i2c, without altering one
line of code.
What I don't like is that I'm doing a bit of macro black magic to transform
constants into variables.
But I don't know whether refactoring the code would be accepted, so this is a
first shot.
So, this follows the example of other i2c drivers, but as Wolfgang
likes to point out, following another bad example isn't a valid reason
to do something. So, is this the right way or a bad example to
follow, Wolfgang or Heiko? Thanks!
Regards,
--
cJ
commit 53d99d331dc7fc4bf3384a59bbca564bf1b85f6b
Author: Jerome Carretero cj-ub...@zougloub.eu
Date: Thu Dec 22 00:26:13 2011 -0500
DaVinci/i2c: Support for multiple buses
diff --git a/arch/arm/include/asm/arch-davinci/i2c_defs.h
b/arch/arm/include/asm/arch-davinci/i2c_defs.h
index 24cd268..1d24fbf 100644
--- a/arch/arm/include/asm/arch-davinci/i2c_defs.h
+++ b/arch/arm/include/asm/arch-davinci/i2c_defs.h
@@ -25,13 +25,18 @@
#ifndef _DAVINCI_I2C_H_
#define _DAVINCI_I2C_H_
+#include asm/arch/hardware.h
+
#define I2C_WRITE 0
#define I2C_READ 1
#ifndef CONFIG_SOC_DA8XX
-#define I2C_BASE 0x01c21000
+# define I2C_BASE DAVINCI_I2C_BASE
+# define I2C_DEFAULT_BASE I2C_BASE
#else
-#define I2C_BASE 0x01c22000
+# define I2C_BASE0 DAVINCI_I2C0_BASE
+# define I2C_BASE1 DAVINCI_I2C1_BASE
+# define I2C_DEFAULT_BASE I2C_BASE0
#endif
#define I2C_OA (I2C_BASE + 0x00)
diff --git a/drivers/i2c/davinci_i2c.c b/drivers/i2c/davinci_i2c.c
index 2abddfb..be7fb7a 100644
--- a/drivers/i2c/davinci_i2c.c
+++ b/drivers/i2c/davinci_i2c.c
@@ -29,6 +29,44 @@
#include asm/arch/hardware.h
#include asm/arch/i2c_defs.h
+#if defined(CONFIG_I2C_MULTI_BUS)
+
+static unsigned int bus_initialized[I2C_BUS_MAX];
+static unsigned int current_bus;
+static unsigned long i2c_base = I2C_DEFAULT_BASE;
+
+#ifndef I2C_BASE
+# define I2C_BASE i2c_base
+#else
+# error CONFIG_I2C_MULTI_BUS *and* I2C_BASE defined !
+#endif
+
+int i2c_set_bus_num(unsigned int bus)
+{
+ if ((bus 0) || (bus = I2C_BUS_MAX)) { // TODO where to put
I2C_BUS_MAX ?
+ printf(Bad bus: %d\n, bus);
+ return -1;
+ }
+
+ if (bus == 1)
+ i2c_base = I2C_BASE1;
+ else
+ i2c_base = I2C_BASE0;
+
+ current_bus = bus;
+
+ if (!bus_initialized[current_bus])
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+ return 0;
+}
+
+unsigned int i2c_get_bus_num(void)
+{
+ return current_bus;
+}
+
+#endif
+
#define CHECK_NACK() \
do {\
if (tmp (I2C_TIMEOUT | I2C_STAT_NACK)) {\
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [trivial] common.h: remove value from bool defines
Dear Igor Grinberg, In message 1324882432-8798-1-git-send-email-grinb...@compulab.co.il you wrote: Several boolean defines have a value assigned. Remove the value as defining the symbol is enough. trivial, but broken. This patch breaks a ton of builds like this: Configuring for MPC8308RDB board... start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition textdata bss dec hex filename 2133526648 39212 259212 3f48c /work/wd/tmp-ppc/u-boot Configuring for MPC8313ERDB_33 - Board: MPC8313ERDB, Options: SYS_33MHZ start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition textdata bss dec hex filename 266218 13360 42048 321626 4e85a /work/wd/tmp-ppc/u-boot Configuring for MPC8313ERDB_66 - Board: MPC8313ERDB, Options: SYS_66MHZ start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition textdata bss dec hex filename 266218 13360 42048 321626 4e85a /work/wd/tmp-ppc/u-boot Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: SYS_33MHZ,NAND_U_BOOT start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition /work/wd/tmp-ppc/nand_spl/board/freescale/mpc8313erdb/start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition textdata bss dec hex filename 266621 13356 42064 322041 4e9f9 /work/wd/tmp-ppc/u-boot Configuring for MPC8313ERDB_NAND_66 - Board: MPC8313ERDB, Options: SYS_66MHZ,NAND_U_BOOT start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition /work/wd/tmp-ppc/nand_spl/board/freescale/mpc8313erdb/start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition textdata bss dec hex filename 266621 13356 42064 322041 4e9f9 /work/wd/tmp-ppc/u-boot Configuring for MPC8315ERDB board... start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition textdata bss dec hex filename 316680 13708 76464 406852 63544 /work/wd/tmp-ppc/u-boot Configuring for MPC8315ERDB_NAND - Board: MPC8315ERDB, Options: NAND_U_BOOT start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition /work/wd/tmp-ppc/nand_spl/board/freescale/mpc8315erdb/start.S:39:0: warning: _LINUX_CONFIG_H redefined [enabled by default] /home/wd/git/u-boot/work/include/common.h:28:0: note: this is the location of the previous definition textdata bss dec hex filename 317099 13704 76464 407267 636e3 /work/wd/tmp-ppc/u-boot or even Configuring for TQM8272 board... In file included from /home/wd/git/u-boot/work/lib/asm-offsets.c:18:0: /home/wd/git/u-boot/work/include/common.h:83:0: warning: CONFIG_MPC8260 redefined [enabled by default] /home/wd/git/u-boot/work/include/configs/TQM8272.h:36:0: note: this is the location of the previous definition In file included from traps.c:35:0: /home/wd/git/u-boot/work/include/common.h:83:0: warning: CONFIG_MPC8260 redefined [enabled by default] /home/wd/git/u-boot/work/include/configs/TQM8272.h:36:0: note: this is the location of the previous definition In file included from serial_smc.c:33:0: /home/wd/git/u-boot/work/include/common.h:83:0: warning: CONFIG_MPC8260 redefined [enabled by default] /home/wd/git/u-boot/work/include/configs/TQM8272.h:36:0: note: this is the location of the previous definition In file included from part.c:24:0: /home/wd/git/u-boot/work/include/common.h:83:0: warning: CONFIG_MPC8260 redefined [enabled by default] /home/wd/git/u-boot/work/include/configs/TQM8272.h:36:0: note: this is the location of the previous definition In file included from serial_scc.c:31:0: /home/wd/git/u-boot/work/include/common.h:83:0: warning: CONFIG_MPC8260 redefined [enabled by default] /home/wd/git/u-boot/work/include/configs/TQM8272.h:36:0: note: this is the location of the previous definition In file included from cpu.c:43:0: /home/wd/git/u-boot/work/include/common.h:83:0: warning: CONFIG_MPC8260 redefined [enabled by default] /home/wd/git/u-boot/work/include/configs/TQM8272.h:36:0: note: this is the location
Re: [U-Boot] [PATCH] Fix logic for selection of CONFIG_SYS_DEF_EEPROM_ADDR
Dear Kyle Moffett, In message 1324001741-15282-1-git-send-email-kyle.d.moff...@boeing.com you wrote: A board with CONFIG_SPI and CONFIG_ENV_EEPROM_IS_ON_I2C will get: #define CONFIG_SYS_DEF_EEPROM_ADDR 0 Instead of the expected: #define CONFIG_SYS_DEF_EEPROM_ADDR CONFIG_SYS_I2C_EEPROM_ADDR As a result, the eeprom command is unusable because it calls i2c_read() and i2c_write() but always uses an address of 0x00. ... -#if defined(CONFIG_SPI) || !defined(CONFIG_SYS_I2C_EEPROM_ADDR) +#if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) +# define CONFIG_SYS_DEF_EEPROM_ADDR 0 That should probably rather be # define CONFIG_SYS_DEF_EEPROM_ADDR CONFIG_SYS_SPI_EEPROM_ADDR instead? +#elif !defined(CONFIG_SYS_I2C_EEPROM_ADDR) # define CONFIG_SYS_DEF_EEPROM_ADDR 0 #else -#if !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) # define CONFIG_SYS_DEF_EEPROM_ADDR CONFIG_SYS_I2C_EEPROM_ADDR #endif -#endif /* CONFIG_SPI || !defined(CONFIG_SYS_I2C_EEPROM_ADDR) */ All this code should be moved out of common.h. Actually all users of CONFIG_SYS_DEF_EEPROM_ADDR (if they don't even define this variable directly in their private code) only use I2C, so they should probably rather use CONFIG_SYS_I2C_EEPROM_ADDR instead (board/w7o/w7o.c, board/w7o/cmd_vpd.c, board/w7o/vpd.c, board/mpl/common/common_util.c) Only common/cmd_eeprom.c, common/env_eeprom.c appear to support both I2C and SPI. 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 Do we define evil as the absence of goodness? It seems only logical that shit happens--we discover this by the process of elimination. -- Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Dear Stephen Warren, In message 4f05fcbd.2040...@nvidia.com you wrote: No, this is NOT a solution, it is a workaround for an inappropriate toolchain. If you want to build code for an armv4t system, you must use a tool chain that supports it. But we don't want to generate code for ARMv4 in general, but rather Then just turn on the ARMv4 specific options (-march=armv4t -mno-thumb -mthumb-interwork -mtune=arm920t ???) for the files that need it. But as soon as any of these files liks code from libgcc you have to decide. ARMv7 as the toolchain does. Only a tiny part of the code needs to be built for ARMv4, and in general we want to benefit from using ARMv7. Then you should probably still link against a ARMv4 specific libgcc. If you were building U-Boot's libgcc code with optimization set for ARMv7 this would not fix anything. 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'd rather be led to hell than managed to heaven. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] expection for help with ethernet driver for DP83849
Dear Sir, Sorry to bother you. I find your email on the website 'lists.denx.de'. I am anxious about the ethernet driver for DP83849. I am looking for the ethernet driver for DP83849 on MPC8387XERDB motherboard. Are you happy to help me with it ? Could you please share it with the driver file for it? Thank you very much. Best regards, Jinming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Hi, On Thu, Jan 5, 2012 at 12:17 PM, Wolfgang Denk w...@denx.de wrote: Dear Stephen Warren, In message 4f05fcbd.2040...@nvidia.com you wrote: No, this is NOT a solution, it is a workaround for an inappropriate toolchain. If you want to build code for an armv4t system, you must use a tool chain that supports it. But we don't want to generate code for ARMv4 in general, but rather Then just turn on the ARMv4 specific options (-march=armv4t -mno-thumb -mthumb-interwork -mtune=arm920t ???) for the files that need it. But as soon as any of these files liks code from libgcc you have to decide. Perhaps we could adjust Tegra's config.mk to use ARMv4T when not building with the private libgcc? ARMv7 as the toolchain does. Only a tiny part of the code needs to be built for ARMv4, and in general we want to benefit from using ARMv7. Then you should probably still link against a ARMv4 specific libgcc. If you were building U-Boot's libgcc code with optimization set for ARMv7 this would not fix anything. It might be possible to specify ARMv4T on the link flags and have it pick up the v4T library, even if nearly everything else is ARMv7? Regards, Simon 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'd rather be led to hell than managed to heaven. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
On 01/05/2012 01:42 PM, Simon Glass wrote: Hi, On Thu, Jan 5, 2012 at 12:17 PM, Wolfgang Denk w...@denx.de wrote: Dear Stephen Warren, In message 4f05fcbd.2040...@nvidia.com you wrote: No, this is NOT a solution, it is a workaround for an inappropriate toolchain. If you want to build code for an armv4t system, you must use a tool chain that supports it. But we don't want to generate code for ARMv4 in general, but rather Then just turn on the ARMv4 specific options (-march=armv4t -mno-thumb -mthumb-interwork -mtune=arm920t ???) for the files that need it. That's exactly what we've already done, but that doesn't affect code that gets pulled in from libgcc, which is what USE_PRIVATE_LIBGCC affects IIUC. But as soon as any of these files liks code from libgcc you have to decide. Perhaps we could adjust Tegra's config.mk to use ARMv4T when not building with the private libgcc? I believe the relevant U-Boot source files are already built for ARMv4T, it's just libgcc that's the issue. ARMv7 as the toolchain does. Only a tiny part of the code needs to be built for ARMv4, and in general we want to benefit from using ARMv7. Then you should probably still link against a ARMv4 specific libgcc. If you were building U-Boot's libgcc code with optimization set for ARMv7 this would not fix anything. It might be possible to specify ARMv4T on the link flags and have it pick up the v4T library, even if nearly everything else is ARMv7? I don't think we use any multilib toolchains, so I don't think that's possible. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] initcall revisited - A new idea to discuss
Hi Wolfgang,
On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme,
In message 4f02da64.60...@gmail.com you wrote:
[snip]
INIT_FUNC(cpu_init_f, f, fred, blah, foo);
Generates the string:
f:cpu_init_f:fred:blah:foo
and we can parse each of the elf archives to obtain a list of string
pointers from the .initfuncs, extract the strings and process them to
generate the init arrays
and add:
/DISCARD/ : { *(.initfuncs*) }
to the linker script to throw away the strings
It's a tad ugly under the hood, but the output will be very clean
Does this sound like a plan?
Yes. Looks good to me.
One thing comes to mind: it would be nice if we can find a way that
the INIT_FUNC definitions behave similar to weak functions - if an
init_func can be redefined / overwritten / modified by board specific
code we eventually have a very nice way to get rid of the related
#ifdef's.
I have a thought on this. How about a SKIP_INIT macro. Here's the idea
using SDRAM as an example:
At the arch level you may have
INIT_FUNC(sdram_init, f, sdram, console,)
so sdram_init sets the sdram requisite and must be done after all
console requisites have been completed.
Now if a SoC or board has an init that must be done before SDRAM:
INIT_FUNC(pre_sdram_init, f, pre_sdram, , sdram)
So this sets the pre_sdram requisite, requires no other initialisation
before running and must happen before and sdram init functions are run
Now lets say the Soc or board has a unique sdram init function that
overrides the arch's sdram init. We could just use weak functions and
allow the SoC or board to override sdram_init. But what if the SoC or
board has additional pre-requisite (or post-requisite) init requirements?
So in the SoC or board file:
SKIP_INIT(sdram)
INIT_FUNC(board_sdram_init, f, board_sdram,pre_sdram,vreg,console, )
Using board_sdram versus sdram_init is cricital:
The init sequence build tool will first create the entire init sequence
including the functions marked as sdram and board_sdram. But after
building the arrays, it will strip out all the functions marked as sdram
init functions. The reason the entire list has to be build first is so the
functions that rely on sdram can be added without unmet prerequisite
errors.
Of course, if you use SKIP_INIT(foo), you need to make sure that any
replacement INIT_FUNC will do everything foo did to make your board work.
Interestingly, this allows the following:
INIT_FUNC(calc_relocation, fr, calc_reloc, sdram, )
INIT_FUNC(copy_uboot_to_ram, fr, copy_to_ram, calc_relocation, )
INIT_FUNC(do_elf_reloc_adjusments, fr, elf_reloc, copy_to_ram, )
INIT_FUNC(clear_bss, fr, clear_bss, calc_reloc, )
#ifdef CONFIG_SYS_SKIP_RELOCATION
SKIP_INIT(calc_reloc)
SKIP_INIT(copy_to_ram)
SKIP_INIT(elf_reloc)
#endif
So if CONFIG_SYS_SKIP_RELOCATION is defined, relocation is not performed,
but clear_bss still is
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: Allow nand_ids and nand_bbt to be compiled in SPL
On 01/05/2012 08:15 AM, Tom Rini wrote: On Thu, Jan 5, 2012 at 2:09 AM, Marek Vasut marek.va...@gmail.com wrote: I'll confirm gc-sections/etc are not as awesome as we think. You can drop the size of current SPL builds (for say devkit8000) by taking things that should be dropped for us and forcing them out with #ifndef CONFIG_SPL_BUILD. Maybe if we had those LTO tables at the gc-sections time, it'd drop. But we can't rely on those. So instead of compiling in the nand-ids, it'd be better to allow SPL to pull in the whole NAND/MTD stack. Possible, but without doing #Ifndef hacks, the size grows a good bit (don't have the #s handy right now), and with #ifndef hacks it's just a kb or so in growth. Whatever the set of things is that you want to pull in for these SPLs, it needs to be a separate config option from the one that enables libnand.o to be included, so that other SPLs can pull in smaller NAND implementations. Is there any reason to keep defines like CONFIG_SPL_NAND_SUPPORT (versus LIBS-y += drivers/mtd/nand/libnand.o), if everything within that directory needs a separate config symbol to enable it inside an SPL (just like a normal build)? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AES128 in U-Boot
On Wednesday 21 December 2011 15:12:20 Simon Glass wrote: Can we use public domain code? It seems incompatible with the restrictions in the GPL how so ? public domain (by its definition) has no copyright or license to worry about. so you literally could (legally) do whatever you want with it. thus it's fine for adding to u-boot. -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] Starting point of uboot learning from scratch..pls helpeom
http://www.denx.de/wiki/U-Boot -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 build system question
On Wednesday 21 December 2011 06:21:21 Bharath H S wrote: I had a question regarding uboot build system. One starts a build for platform1 and without cleaning tree builds for platform2, what is the expected result? make platform1_config make platform2_config Is the final product build of platform2 or goes to inconsistent state or implementation dependent? `make foo_config make foo` should always output the same result regardless of the initial state. if it isn't, post a patch to fix it. -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 V5] nand_spl_simple: store ecc data on the stack
On 12/15/2011 03:55 AM, Stefano Babic wrote: Currently nand_spl_simple puts it's temp data at 0x1 offset in SDRAM which is likely to contain already loaded data. The patch saves the oob data and the ecc on the stack replacing the fixed address in RAM. Signed-off-by: Stefano Babic sba...@denx.de CC: Ilya Yanok ya...@emcraft.com CC: Scott Wood scottw...@freescale.com CC: Tom Rini tom.r...@gmail.com CC: Simon Schwarz simonschwarz...@googlemail.com CC: Wolfgang Denk w...@denx.de Applied to u-boot-nand-flash -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/9] openrisc: Add cpu files
On Thursday 22 December 2011 06:39:32 Stefan Kristiansson wrote:
On Thu, Dec 22, 2011 at 10:09:30AM +0100, Michal Simek wrote:
Stefan Kristiansson wrote:
+
+void dcache_enable(void)
+{
+ mtspr(SPR_SR, mfspr(SPR_SR) | SPR_SR_DCE);
+ asm volatile(l.nop);
+ asm volatile(l.nop);
+ asm volatile(l.nop);
+ asm volatile(l.nop);
+ asm volatile(l.nop);
+ asm volatile(l.nop);
+ asm volatile(l.nop);
+ asm volatile(l.nop);
This is interesting. Are there 8 nops?
Is there any reason for that? Is it just any waiting?
If yes, maybe it will be worth to add any comment.
Yes, the number of nops are kind of arbitrary,
they are there to add some headroom for the cache
to startup without any load/stores in flight.
But you are right, a comment about this might be in place.
this is usually why the ISA provides some sort of sync or latch mechanism.
that way code is deterministic instead of being unsettling arbitrary (like it
is 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
[U-Boot] [PATCH] MAKEALL: display SPL size if present
This makes it easier to detect changes in the SPL portion,
as can currently be done for the main U-Boot image.
Signed-off-by: Scott Wood scottw...@freescale.com
---
MAKEALL |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index f735af6..395e982 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -508,6 +508,11 @@ build_target() {
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
+
+ if [ -e ${BUILD_DIR}/spl/u-boot-spl ]; then
+ ${CROSS_COMPILE}size ${BUILD_DIR}/spl/u-boot-spl \
+ | tee -a ${LOG_DIR}/$target.MAKELOG
+ fi
}
build_targets() {
for t in $@ ; do
--
1.7.7.rc3.4.g8d714
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/env: fix cross-compilation
On Thursday 22 December 2011 13:39:35 Grant Erickson wrote: This patch fixes the make infrastructure for the fw_printenv tool such that it is built, by default, as a cross-compilation for the target board when so requested with TOOLSUBDIRS on the U-Boot make command line. how is this any simpler than the existing method ? make tools HOSTCC=some-random-target-gcc the current tools/ subdir is consistent in its handling. this patch would break that. -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 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
Dear Stephen, In message 4f060dd1.9050...@nvidia.com you wrote: It might be possible to specify ARMv4T on the link flags and have it pick up the v4T library, even if nearly everything else is ARMv7? I don't think we use any multilib toolchains, so I don't think that's possible. I don't even think you need one with multilib support. You need one that provides a libgcc for armv4t, that's all. It is wrong, always and everywhere, NOT to try to fix the problems at the origin. If your tool chain does not meet your requirements, then the first action should always be to get a working tool chain - ideally by getting the deficiencies of the currnt one fixed, or by using another one. Working around such problems may be a short term approach to get things running quickly. But it appears that more and more people make it a habit to do just that, without even trying to get the real problems fixed upstream. That's bad, bad, bad. 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'd rather be led to hell than managed to heaven. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib/string: added strndup
On Thursday 22 December 2011 13:16:56 Grant Erickson wrote:
+#ifndef __HAVE_ARCH_STRNDUP
+extern char * strndup(const char *,__kernel_size_t);
+#endif
no space after that first *, and add a space after the ,
since your definition uses size_t, then use that rather than __kernel_size_t
--- a/lib/string.c
+++ b/lib/string.c
+#ifndef __HAVE_ARCH_STRNDUP
+char * strndup(const char *s, size_t n)
no space after that first *
+ if ((s == NULL) ||
+ ((new = malloc (len + 1)) == NULL) ) {
+ return NULL;
+ }
please split this up such as:
if (s == NULL)
return s;
new = malloc(len + 1);
if (new == NULL)
return new;
+ strncpy (new, s, len);
no space before that (
-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] lib/string: added strndup
Dear Mike Frysinger,
In message 201201051821.35774.vap...@gentoo.org you wrote:
+ if ((s == NULL) ||
+ ((new = malloc (len + 1)) == NULL) ) {
+ return NULL;
+ }
please split this up such as:
I'm OK with the splitting, but...
if (s == NULL)
return s;
new = malloc(len + 1);
if (new == NULL)
return new;
... in both cases, a return NULL is much easier to parse for the
human and identical for the compiler, so that should be used.
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
Good morning. This is the telephone company. Due to repairs, we're
giving you advance notice that your service will be cut off indefi-
nitely at ten o'clock. That's two minutes from now.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/env: fix cross-compilation
On Jan 5, 2012, at 3:18 PM, Mike Frysinger wrote: On Thursday 22 December 2011 13:39:35 Grant Erickson wrote: This patch fixes the make infrastructure for the fw_printenv tool such that it is built, by default, as a cross-compilation for the target board when so requested with TOOLSUBDIRS on the U-Boot make command line. how is this any simpler than the existing method ? make tools HOSTCC=some-random-target-gcc the current tools/ subdir is consistent in its handling. this patch would break that. Mike, Because it's broken with respect to how the rest of U-Boot is built. I already specify the cross-compiler via CROSS_COMPILE when I build u-boot.bin and u-boot.img, that I need to specify the same compiler in two different ways to build executables for the same target platform is broken and, it sounds like, as are the rest of the tools subdirectories. If fw_setenv were a build host-based tool or if it made sense as a build host-based tool, then using HOSTCC would be sensible. Best, Grant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] stuck after redirecting stdout to nc
On Monday 02 January 2012 09:50:42 ran shalit wrote: On uboot loading, I checking a specific environement (called consoleddev), to decide to rediect console to nc or staying in serial. I then see some strange behaviour: if the environment tell uboot to redirect to net console, everything works well, but only if the ethernet cable is connected. if it is not connected then I see that the kernel is not loading. there could easily be a bug where netconsole does not work if the network is not available. patches welcome to add timeouts. -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] Add support for MMC to fw_printenv/setenv
On Monday 02 January 2012 18:49:11 Christian Daudt wrote:
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
+static int fd_is_mtd(int fd)
...
+ rc = ioctl (fd, MEMGETINFO, mtdinfo);
no space before the (
+ if (rc 0) {
+ // Failed MEMGETINFO, not MTD
+ return 0;
+ } else {
+ // Succeeded, MTD
+ return 1;
+ }
do not use // comments
-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] AES128 in U-Boot
Hi Mike, On Thu, Jan 5, 2012 at 3:07 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 21 December 2011 15:12:20 Simon Glass wrote: Can we use public domain code? It seems incompatible with the restrictions in the GPL how so ? public domain (by its definition) has no copyright or license to worry about. so you literally could (legally) do whatever you want with it. thus it's fine for adding to u-boot. -mike OK that's fine then, thanks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: remove NAND_MAX_CHIPS definitions
On 11/20/2011 08:10 AM, Vladimir Zapolskiy wrote: This change follows the change by Wolfgang Grandegger (commit 6c869637fef), which allows to remove useless NAND_MAX_CHIPS definitions in board config files. Signed-off-by: Vladimir Zapolskiy v...@mleia.com Cc: Wolfgang Grandegger w...@grandegger.com Cc: Scott Wood scottw...@freescale.com Applied to u-boot-nand-flash (and a patch coming to get some additional instances that crept in, plus instances of CONFIG_SYS_NAND_MAX_CHIPS that are set to the default value of 1). Marek: this removes NAND_MAX_CHIPS from m28evk.h, which set it to the non-default value of 8. This setting was never effective, since NAND_MAX_CHIPS stopped being used used years before m28evk.h was introduced. Does this board want CONFIG_SYS_NAND_MAX_CHIPS = 8? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
