Re: [U-Boot] [PATCH] MC13892: Add REGMODE0 bits definitions
On 09/28/2011 02:07 PM, Marek Vasut wrote: Signed-off-by: Marek Vasutmarek.va...@gmail.com Cc: Stefano Babicsba...@denx.de --- Applied to u-boot-imx, thanks Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Orphan EVB64260_750CX board
Dear Wolfgang Denk, In message 1321477170-19053-1-git-send-email...@denx.de you wrote: The last maintainer (Eran Man) cannot be reached any more. Signed-off-by: Wolfgang Denk w...@denx.de --- MAINTAINERS |6 +- 1 files changed, 1 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 Pain is a thing of the mind. The mind can be controlled. -- Spock, Operation -- Annihilate! stardate 3287.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: remove duplicate macros in e1000.h
Dear Timur Tabi, In message 1320164455-12345-1-git-send-email-ti...@freescale.com you wrote: Some of the EEPROM Word Offset macros, and a few others, are defined twice in e1000.h. Signed-off-by: Timur Tabi ti...@freescale.com --- drivers/net/e1000.h | 11 --- 1 files changed, 0 insertions(+), 11 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 things love can drive a man to -- the ecstasies, the mise- ries, the broken rules, the desperate chances, the glorious failures and the glorious victories. -- McCoy, Requiem for Methuselah, stardate 5843.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: fix unused variable waring for e1000 driver
Dear Roy Zang, In message 1320654156-3240-1-git-send-email-tie-fei.z...@freescale.com you wrote: Fix the following build warning in drivers/net/e1000.c e1000.c: In function 'e1000_reset_hw': e1000.c:1373:11: warning: variable 'icr' set but not used [-Wunused-but-set-variable] e1000.c: In function 'e1000_phy_init_script': e1000.c:4395:11: warning: variable 'ret_val' set but not used [-Wunused-but-set-variable] Signed-off-by: Roy Zang tie-fei.z...@freescale.com Cc: Wolfgang Denk w...@denx.de Cc: Kyle Moffett kyle.d.moff...@boeing.com --- drivers/net/e1000.c |6 +++--- 1 files changed, 3 insertions(+), 3 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 They say a little knowledge is a dangerous thing, but it is not one half so bad as a lot of ignorance. - Terry Pratchett, _Equal Rites_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] x86: Wrap small helper functions from libgcc to avoid an ABI mismatch
When gcc compiles some 64 bit operations on a 32 bit machine, it generates calls to small functions instead of instructions which do the job directly. Those functions are defined in libgcc and transparently provide whatever functionality was necessary. Unfortunately, u-boot can be built with a non-standard ABI when libgcc isn't. More specifically, u-boot uses -mregparm. When the u-boot and libgcc are linked together, very confusing bugs can crop up, for instance seemingly normal integer division or modulus getting the wrong answer or even raising a spurious divide by zero exception. This change borrows (steals) a technique and some code from coreboot which solves this problem by creating wrappers which translate the calling convention when calling the functions in libgcc. Unfortunately that means that these instructions which had already been turned into functions have even more overhead, but more importantly it makes them work properly. To find all of the functions that needed wrapping, u-boot was compiled without linking in libgcc. All the symbols the linker complained were undefined were presumed to be the symbols that are needed from libgcc. These were a subset of the symbols covered by the coreboot code, so it was used unmodified. To prevent symbols which are provided by libgcc but not currently wrapped (or even known about) from being silently linked against by code generated by libgcc, a new copy of libgcc is created where all the symbols are prefixed with __normal_. Without being purposefully wrapped, these symbols will cause linker errors instead of silently introducing very subtle, confusing bugs. Another approach would be to whitelist symbols from libgcc and strip out all the others. The problem with this approach is that it requires the white listed symbols to be specified three times, once for objcopy, once so the linker inserts the wrapped, and once to generate the wrapper itself, while this implementation needs it to be listed only twice. There isn't much tangible difference in what each approach produces, so this one was preferred. Signed-off-by: Gabe Black gabebl...@chromium.org --- Changes in v2: - Change the [x86] tag to x86: - Mention -mregparm in the commit message. - Get rid of a stray line which snuck in during a rebase. Changes in v3: - Prevent symbols from libgcc which aren't wrapped from getting silently picked up by the linker. arch/x86/config.mk|7 +++ arch/x86/lib/Makefile |6 ++ arch/x86/lib/gcc.c| 38 ++ 3 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 arch/x86/lib/gcc.c diff --git a/arch/x86/config.mk b/arch/x86/config.mk index fe9083f..23cacff 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -41,3 +41,10 @@ PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden PLATFORM_LDFLAGS += --emit-relocs -Bsymbolic -Bsymbolic-functions LDFLAGS_FINAL += --gc-sections -pie +LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3 +LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3 + +NORMAL_LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name) +PREFIXED_LIBGCC = $(OBJTREE)/arch/$(ARCH)/lib/$(shell basename $(NORMAL_LIBGCC)) + +export USE_PRIVATE_LIBGCC=$(shell dirname $(PREFIXED_LIBGCC)) diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index eb5fa10..16db73f 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -32,6 +32,7 @@ SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o COBJS-y+= board.o COBJS-y+= bootm.o +COBJS-y+= gcc.o COBJS-y+= interrupts.o COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o @@ -49,6 +50,11 @@ OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) $(LIB):$(obj).depend $(OBJS) $(call cmd_link_o_target, $(OBJS)) +$(PREFIXED_LIBGCC): $(NORMAL_LIBGCC) + $(OBJCOPY) $ $@ --prefix-symbols=__normal_ + +$(LIB): $(PREFIXED_LIBGCC) + # # defines $(obj).depend target diff --git a/arch/x86/lib/gcc.c b/arch/x86/lib/gcc.c new file mode 100644 index 000..4043431 --- /dev/null +++ b/arch/x86/lib/gcc.c @@ -0,0 +1,38 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2009 coresystems GmbH + * + * 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; version 2 or later of the License. + * + * 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
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, November 17, 2011 1:57 AM To: Michael Walle Cc: Prafulla Wadaskar; Valentin Longchamp; Siddarth Gore; Simon Guinot; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver Dear Michael Walle, In message 20162115.0.mich...@walle.cc you wrote: Could you please revise your assessment? I would really appreciate if we could clean this up. Regarding Prafulla's NAK? Yes - I'd really appreciate if Prafulla woudl withdraw his NAK, Hi All I withdraw my NAK for this patch. Let's remove mac randomization support for mvgbe driver. If needed, for any particular board, it will be addressed separately. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] M28EVK: Enable USB HOST support
Marek Vasut wrote: Marek Vasut wrote: Marek Vasut wrote: Hi Marek, u-boot-v2011.09 doesn't support for imx28. I need complete support patch for mx28. where can i get those patches? for which version of u-boot this patches supports..? Regards, Manoj http://git.denx.de/?p=u-boot/u-boot-imx.git;a=summary M Thanks Marek, Patches applied.. on usb start command i'm getting scanning bus for devices... New Device 0 then its freezes after getting the debug message enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 can u help me on this further? Regards, Manoj There is a mail with subject [U-Boot] [PATCH] GCC4.6: Fix common/usb.c on xscale in uboot ML ... apply the patch and retry. What GCC do you use? M Hello Marek, I'm using u-boot version : u-boot-imx gcc version:4.3.3 When i try to add this Patch [U-Boot] [PATCH] GCC4.6: Fix common/usb.c on xscale I'm getting: patching file usb.c Hunk #1 FAILED at 263. Hunk #2 FAILED at 313. 2 out of 2 hunks FAILED -- saving rejects to file usb.c.rej then i made some changes for common/usb.c as per the patch,even it gets freezes after printing the debug msg. enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 Regards, Manoj Are you using top-of-the-tree u-boot-imx/master? You shouldn't need to apply any patches. That'd explain why you're getting errors applying the last USB patch I suggested. Also, please try ELDK5.0 toolchain. M Marek, ya i'm using master code and now its working fine.. Regards, Manoj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: e1000: fix gcc 4.6 compiler warnings
Dear Kim Phillips, In message 1321480020-32662-1-git-send-email-kim.phill...@freescale.com you wrote: Configuring for caddy2 - Board: vme8349, Options: CADDY2 e1000.c: In function 'e1000_reset_hw': e1000.c:1373:11: warning: variable 'icr' set but not used [-Wunused-but-set-variable] e1000.c: In function 'e1000_phy_init_script': e1000.c:4395:11: warning: variable 'ret_val' set but not used [-Wunused-but-set-variable] Signed-off-by: Kim Phillips kim.phill...@freescale.com --- drivers/net/e1000.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) Thanks, but this has already been fixed by Roy Zang's patch: 11/07 Roy Zang [PATCH] e1000: fix unused variable waring for e1000 driver Gmane: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/115716 Patchwork: 124011 Accepted [U-Boot] e1000: fix unused variable waring for e1000 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 Too many people are ready to carry the stool when the piano needs to be moved. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] x86: Wrap small helper functions from libgcc to avoid an ABI mismatch
On Thu, Nov 17, 2011 at 1:01 AM, Gabe Black gabebl...@chromium.org wrote: When gcc compiles some 64 bit operations on a 32 bit machine, it generates calls to small functions instead of instructions which do the job directly. Those functions are defined in libgcc and transparently provide whatever functionality was necessary. Unfortunately, u-boot can be built with a non-standard ABI when libgcc isn't. More specifically, u-boot uses -mregparm. When the u-boot and libgcc are linked together, very confusing bugs can crop up, for instance seemingly normal integer division or modulus getting the wrong answer or even raising a spurious divide by zero exception. This change borrows (steals) a technique and some code from coreboot which solves this problem by creating wrappers which translate the calling convention when calling the functions in libgcc. Unfortunately that means that these instructions which had already been turned into functions have even more overhead, but more importantly it makes them work properly. To find all of the functions that needed wrapping, u-boot was compiled without linking in libgcc. All the symbols the linker complained were undefined were presumed to be the symbols that are needed from libgcc. These were a subset of the symbols covered by the coreboot code, so it was used unmodified. To prevent symbols which are provided by libgcc but not currently wrapped (or even known about) from being silently linked against by code generated by libgcc, a new copy of libgcc is created where all the symbols are prefixed with __normal_. Without being purposefully wrapped, these symbols will cause linker errors instead of silently introducing very subtle, confusing bugs. Another approach would be to whitelist symbols from libgcc and strip out all the others. The problem with this approach is that it requires the white listed symbols to be specified three times, once for objcopy, once so the linker inserts the wrapped, and once to generate the wrapper itself, while this implementation needs it to be listed only twice. There isn't much tangible difference in what each approach produces, so this one was preferred. Signed-off-by: Gabe Black gabebl...@chromium.org --- Changes in v2: - Change the [x86] tag to x86: - Mention -mregparm in the commit message. - Get rid of a stray line which snuck in during a rebase. Changes in v3: - Prevent symbols from libgcc which aren't wrapped from getting silently picked up by the linker. arch/x86/config.mk|7 +++ arch/x86/lib/Makefile |6 ++ arch/x86/lib/gcc.c| 38 ++ 3 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 arch/x86/lib/gcc.c diff --git a/arch/x86/config.mk b/arch/x86/config.mk index fe9083f..23cacff 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -41,3 +41,10 @@ PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden PLATFORM_LDFLAGS += --emit-relocs -Bsymbolic -Bsymbolic-functions LDFLAGS_FINAL += --gc-sections -pie +LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3 +LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3 + +NORMAL_LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name) +PREFIXED_LIBGCC = $(OBJTREE)/arch/$(ARCH)/lib/$(shell basename $(NORMAL_LIBGCC)) + +export USE_PRIVATE_LIBGCC=$(shell dirname $(PREFIXED_LIBGCC)) diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index eb5fa10..16db73f 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -32,6 +32,7 @@ SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o COBJS-y+= board.o COBJS-y+= bootm.o +COBJS-y+= gcc.o COBJS-y+= interrupts.o COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o @@ -49,6 +50,11 @@ OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) $(LIB):$(obj).depend $(OBJS) $(call cmd_link_o_target, $(OBJS)) +$(PREFIXED_LIBGCC): $(NORMAL_LIBGCC) + $(OBJCOPY) $ $@ --prefix-symbols=__normal_ + +$(LIB): $(PREFIXED_LIBGCC) + # # defines $(obj).depend target diff --git a/arch/x86/lib/gcc.c b/arch/x86/lib/gcc.c new file mode 100644 index 000..4043431 --- /dev/null +++ b/arch/x86/lib/gcc.c @@ -0,0 +1,38 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2009 coresystems GmbH + * + * 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; version 2 or later of the License. + * + * 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 + *
[U-Boot] [PATCH] mmc: add host_caps checking avoid switch card improperly
Add a host capability checking to avoid the mmc stack switch the card to HIGHSPEED mode when the card supports HIGHSPEED while the host doesn't. This patch avoid furthur transaction problem when the mmc/sd card runs different mode to the host. Signed-off-by: Macpaul Lin macp...@andestech.com --- drivers/mmc/mmc.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 21665ec..ce34d05 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -785,6 +785,16 @@ retry_scr: if (!(__be32_to_cpu(switch_status[3]) SD_HIGHSPEED_SUPPORTED)) return 0; + /* +* If the host doesn't support SD_HIGHSPEED, do not switch card to +* HIGHSPEED mode even if the card support SD_HIGHSPPED. +* This can avoid furthur problem when the card runs in different +* mode between the host. +*/ + if (!((mmc-host_caps MMC_MODE_HS_52MHz) || + (mmc-host_caps MMC_MODE_HS))) + return 0; + err = sd_switch(mmc, SD_SWITCH_SWITCH, 0, 1, (u8 *)switch_status); if (err) -- 1.7.3.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] x86: Fix a few recently added bugs
From: Gabe Black gabebl...@chromium.org
Signed-off-by: Gabe Black gabebl...@chromium.org
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
arch/x86/cpu/cpu.c |1 +
arch/x86/lib/board.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 48d2f7a..61d0b69 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -37,6 +37,7 @@
#include asm/processor.h
#include asm/processor-flags.h
#include asm/interrupt.h
+#include linux/compiler.h
/*
* Constructor for a conventional segment GDT (or LDT) entry
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 18e0ede..d742fec 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -220,6 +220,9 @@ static int do_elf_reloc_fixups(void)
Elf32_Addr *offset_ptr_rom;
Elf32_Addr *offset_ptr_ram;
+ /* The size of the region of u-boot that runs out of RAM. */
+ uintptr_t size = (uintptr_t)__bss_end - (uintptr_t)__text_start;
+
do {
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf32_Addr *)re_src-r_offset;
@@ -228,7 +231,8 @@ static int do_elf_reloc_fixups(void)
if (offset_ptr_rom = (Elf32_Addr *)CONFIG_SYS_TEXT_BASE) {
/* Switch to the in-RAM version */
- offset_ptr_ram = offset_ptr_rom + gd-reloc_off;
+ offset_ptr_ram = (Elf32_Addr *)((ulong)offset_ptr_rom +
+ gd-reloc_off);
/* Check that the target points into .text */
if (*offset_ptr_ram = CONFIG_SYS_TEXT_BASE
--
1.7.5.2.317.g391b14
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] x86: Fix a few recently added bugs
Eep - This is a stand-alone patch and not part of a multi-part patch series
(forgot to edit the subject)
Regards,
Graeme
On 17/11/11 20:32, Graeme Russ wrote:
From: Gabe Black gabebl...@chromium.org
Signed-off-by: Gabe Black gabebl...@chromium.org
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
arch/x86/cpu/cpu.c |1 +
arch/x86/lib/board.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 48d2f7a..61d0b69 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -37,6 +37,7 @@
#include asm/processor.h
#include asm/processor-flags.h
#include asm/interrupt.h
+#include linux/compiler.h
/*
* Constructor for a conventional segment GDT (or LDT) entry
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 18e0ede..d742fec 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -220,6 +220,9 @@ static int do_elf_reloc_fixups(void)
Elf32_Addr *offset_ptr_rom;
Elf32_Addr *offset_ptr_ram;
+ /* The size of the region of u-boot that runs out of RAM. */
+ uintptr_t size = (uintptr_t)__bss_end - (uintptr_t)__text_start;
+
do {
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf32_Addr *)re_src-r_offset;
@@ -228,7 +231,8 @@ static int do_elf_reloc_fixups(void)
if (offset_ptr_rom = (Elf32_Addr *)CONFIG_SYS_TEXT_BASE) {
/* Switch to the in-RAM version */
- offset_ptr_ram = offset_ptr_rom + gd-reloc_off;
+ offset_ptr_ram = (Elf32_Addr *)((ulong)offset_ptr_rom +
+ gd-reloc_off);
/* Check that the target points into .text */
if (*offset_ptr_ram = CONFIG_SYS_TEXT_BASE
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] ftsdc010: improve performance and capability
This patch improve the performance by spliting flag examination code
in ftsdc010_send_cmd() into 3 functions.
This patch also reordered the function which made better capability to
some high performance cards against to the next version of ftsdc010
hardware.
Signed-off-by: Macpaul Lin macp...@andestech.com
---
Changes for v2:
- Fix the problem if we read status register too fast in FTSDC010_CMD_RETRY
loop. If we read status register here too fast, the hardware will report
RSP_TIMEOUT incorrectly.
Changes for v3:
- Remove host high speed capability due to hardware limitation.
- Remove unused variables.
drivers/mmc/ftsdc010_esdhc.c | 184 +++---
1 files changed, 101 insertions(+), 83 deletions(-)
diff --git a/drivers/mmc/ftsdc010_esdhc.c b/drivers/mmc/ftsdc010_esdhc.c
index e38dd87..23d21ad 100644
--- a/drivers/mmc/ftsdc010_esdhc.c
+++ b/drivers/mmc/ftsdc010_esdhc.c
@@ -90,8 +90,13 @@ static void ftsdc010_pio_read(struct mmc_host *host, char
*buf, unsigned int siz
while (size) {
status = readl(host-reg-status);
+ debug(%s: size: %08x\n, __func__, size);
if (status FTSDC010_STATUS_FIFO_ORUN) {
+
+ debug(%s: FIFO OVERRUN: sta: %08x\n,
+ __func__, status);
+
fifo = host-fifo_len size ?
size : host-fifo_len;
@@ -146,7 +151,7 @@ static void ftsdc010_pio_write(struct mmc_host *host, const
char *buf,
while (size) {
status = readl(host-reg-status);
- if (status FTSDC010_STATUS_FIFO_ORUN) {
+ if (status FTSDC010_STATUS_FIFO_URUN) {
fifo = host-fifo_len size ?
size : host-fifo_len;
@@ -158,7 +163,6 @@ static void ftsdc010_pio_write(struct mmc_host *host, const
char *buf,
writel(*ptr, host-reg-dwr);
ptr++;
}
-
} else {
udelay(1);
if (++retry = FTSDC010_PIO_RETRY) {
@@ -169,56 +173,19 @@ static void ftsdc010_pio_write(struct mmc_host *host,
const char *buf,
}
}
-static int ftsdc010_pio_check_status(struct mmc *mmc, struct mmc_cmd *cmd,
+static int ftsdc010_check_rsp(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
{
struct mmc_host *host = mmc-priv;
-
unsigned int sta, clear;
- unsigned int i;
-
- /* check response and hardware status */
- clear = 0;
-
- /* chech CMD_SEND */
- for (i = 0; i FTSDC010_CMD_RETRY; i++) {
- sta = readl(host-reg-status);
- /* Command Complete */
- if (sta FTSDC010_STATUS_CMD_SEND) {
- if (!data)
- clear |= FTSDC010_CLR_CMD_SEND;
- break;
- }
- }
-
- if (i FTSDC010_CMD_RETRY) {
- printf(%s: send command timeout\n, __func__);
- return TIMEOUT;
- }
-
- /* debug: print status register and command index*/
- debug(sta: %08x cmd %d\n, sta, cmd-cmdidx);
- /* handle data FIFO */
- if ((sta FTSDC010_STATUS_FIFO_ORUN) ||
- (sta FTSDC010_STATUS_FIFO_URUN)) {
-
- /* Wrong DATA FIFO Flag */
- if (data == NULL)
- printf(%s, data fifo wrong: sta: %08x cmd %d\n,
- __func__, sta, cmd-cmdidx);
-
- if (sta FTSDC010_STATUS_FIFO_ORUN)
- clear |= FTSDC010_STATUS_FIFO_ORUN;
- if (sta FTSDC010_STATUS_FIFO_URUN)
- clear |= FTSDC010_STATUS_FIFO_URUN;
- }
+ sta = readl(host-reg-status);
+ debug(%s: sta: %08x cmd %d\n, __func__, sta, cmd-cmdidx);
/* check RSP TIMEOUT or FAIL */
if (sta FTSDC010_STATUS_RSP_TIMEOUT) {
/* RSP TIMEOUT */
- debug(%s: RSP timeout: sta: %08x cmd %d\n,
- __func__, sta, cmd-cmdidx);
+ debug(%s: RSP timeout: sta: %08x\n, __func__, sta);
clear |= FTSDC010_CLR_RSP_TIMEOUT;
writel(clear, host-reg-clr);
@@ -226,47 +193,62 @@ static int ftsdc010_pio_check_status(struct mmc *mmc,
struct mmc_cmd *cmd,
return TIMEOUT;
} else if (sta FTSDC010_STATUS_RSP_CRC_FAIL) {
/* clear response fail bit */
- debug(%s: RSP CRC FAIL: sta: %08x cmd %d\n,
- __func__, sta, cmd-cmdidx);
+ debug(%s: RSP CRC FAIL: sta: %08x\n, __func__, sta);
clear |= FTSDC010_CLR_RSP_CRC_FAIL;
writel(clear, host-reg-clr);
- return 0;
+ return COMM_ERR;
} else if (sta
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
Hi Gabe, On 17/11/11 11:27, Gabe Black wrote: Add a target for running u-boot as a coreboot payload in boards.cfg. Signed-off-by: Gabe Black gabebl...@chromium.org --- Changes in v2: Change capitalization of the x86 tag. Changes in v3: Move the Signed-off-by line up. Changes in v4: Change the summary tag style. boards.cfg |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index 8b7a03b..4b2a1a7 100644 --- a/boards.cfg +++ b/boards.cfg @@ -272,6 +272,7 @@ tcm-bf518blackfinblackfin tcm-bf537blackfinblackfin eNET x86 x86eNET- sc520 eNET:SYS_TEXT_BASE=0x3804 eNET_SRAMx86 x86eNET- sc520 eNET:SYS_TEXT_BASE=0x1900 +coreboot-x86 x86 x86coreboot chromebook-x86 corebootcoreboot:SYS_TEXT_BASE=0xFC sandbox sandbox sandbox sandbox sandbox- cobra5272m68kmcf52x2 cobra5272 - idmr m68kmcf52x2 As mentioned by others before, there is no reason to have these as discrete patches - Please merge into a single 'Add coreboot payload' Is there any real reason to reference 'chromebook-x86'? And finally, what is the plan for motherboard specific coreboot variants? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra2: Fix out-of-tree build for Ventana.
Since Ventana is derived from Seaboard and requires seaboard.c to build, make sure board/nvidia/seaboard is created in the build tree. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- board/nvidia/ventana/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/board/nvidia/ventana/Makefile b/board/nvidia/ventana/Makefile index 9e5a87f..d5140c8 100644 --- a/board/nvidia/ventana/Makefile +++ b/board/nvidia/ventana/Makefile @@ -25,6 +25,7 @@ include $(TOPDIR)/config.mk ifneq ($(OBJTREE),$(SRCTREE)) +$(shell mkdir -p $(obj)../seaboard) $(shell mkdir -p $(obj)../common) endif -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] [cosmetic], i2c: Codingstyle cleanup for i2c evb64260 board driver
There are some magic constants in this drivers, which I cannot
fixup ... Eran, can you help here?
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Eran Man e...@nbase.co.il
---
- changes for v2:
- corrected some typos in v1 patch
board/evb64260/i2c.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/board/evb64260/i2c.c b/board/evb64260/i2c.c
index 3eae3d9..d943baa 100644
--- a/board/evb64260/i2c.c
+++ b/board/evb64260/i2c.c
@@ -20,25 +20,25 @@ static void
i2c_init(int speed, int slaveaddr)
{
unsigned int n, m, freq, margin, power;
- unsigned int actualN = 0, actualM = 0;
+ unsigned int actualn = 0, actualm = 0;
unsigned int control, status;
- unsigned int minMargin = 0x;
+ unsigned int minmargin = 0x;
unsigned int tclk = 12500;
DP(puts(i2c_init\n));
for (n = 0 ; n 8 ; n++) {
for (m = 0 ; m 16 ; m++) {
- power = 2n; /* power = 2^(n+1) */
- freq = tclk/(10*(m+1)*power);
+ power = 2 n; /* power = 2^(n+1) */
+ freq = tclk / (10 * (m + 1) * power);
if (speed freq)
margin = speed - freq;
else
margin = freq - speed;
- if (margin minMargin) {
- minMargin = margin;
- actualN = n;
- actualM = m;
+ if (margin minmargin) {
+ minmargin = margin;
+ actualn = n;
+ actualm = m;
}
}
}
@@ -55,7 +55,7 @@ i2c_init(int speed, int slaveaddr)
DP(puts(set baudrate\n));
- GT_REG_WRITE(I2C_STATUS_BAUDE_RATE, (actualM 3) | actualN);
+ GT_REG_WRITE(I2C_STATUS_BAUDE_RATE, (actualm 3) | actualn);
GT_REG_WRITE(I2C_CONTROL, (0x1 2) | (0x1 6));
udelay(I2C_DELAY * 10);
@@ -257,11 +257,11 @@ i2c_read(uchar dev_addr, unsigned int offset, int len,
uchar *data,
int ten_bit)
{
uchar status = 0;
- unsigned int i2cFreq = 40;
+ unsigned int i2cfreq = 40;
DP(puts(i2c_read\n));
- i2c_init(i2cFreq, 0);
+ i2c_init(i2cfreq, 0);
status = i2c_start();
@@ -280,7 +280,7 @@ i2c_read(uchar dev_addr, unsigned int offset, int len,
uchar *data,
return status;
}
- i2c_init(i2cFreq, 0);
+ i2c_init(i2cfreq, 0);
status = i2c_start();
if (status) {
--
1.7.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] tegra2: Fixes for running mainline U-Boot.
The following series contains two patches that allow mainline U-Boot to boot standalone on Tegra2-based boards. It assumes the standard NVIDIA flashing tools as provided by the Linux4Tegra package. The series is based on patches that have already been reviewed but haven't been merged upstream yet. They are available in patchwork here: http://patchwork.ozlabs.org/patch/122888 http://patchwork.ozlabs.org/patch/122887 http://patchwork.ozlabs.org/patch/122889 http://patchwork.ozlabs.org/patch/123845 (9 patches) Thierry Reding (2): tegra2: Always build with USE_PRIVATE_LIBGCC=yes. tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000. arch/arm/cpu/armv7/tegra2/config.mk |2 ++ include/configs/tegra2-common.h |2 +- 2 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
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. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/cpu/armv7/tegra2/config.mk |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/tegra2/config.mk b/arch/arm/cpu/armv7/tegra2/config.mk index 8f9bdc9..2303dba 100644 --- a/arch/arm/cpu/armv7/tegra2/config.mk +++ b/arch/arm/cpu/armv7/tegra2/config.mk @@ -29,3 +29,5 @@ ifdef CONFIG_TEGRA2 CFLAGS_arch/arm/lib/board.o += -march=armv4t endif + +USE_PRIVATE_LIBGCC = yes -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000.
NVIDIA's flashing tools assume that the bootloader is loaded at address 0x00108000. Instead of requiring non-standard builds of those tools which allow a load address of 0x00E08000, this commit just switches all Tegra2 boards to use the standard load address. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Simon Glass s...@chromium.org --- include/configs/tegra2-common.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h index e233b1c..f7b6232 100644 --- a/include/configs/tegra2-common.h +++ b/include/configs/tegra2-common.h @@ -152,7 +152,7 @@ #define PHYS_SDRAM_1 TEGRA2_SDRC_CS0 #define PHYS_SDRAM_1_SIZE 0x2000 /* 512M */ -#define CONFIG_SYS_TEXT_BASE 0x00E08000 +#define CONFIG_SYS_TEXT_BASE 0x00108000 #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 #define CONFIG_SYS_INIT_RAM_ADDR CONFIG_STACKBASE -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] tegra2: Move tegra2_mmc_init() prototype to public header.
tegra2_mmc_init() is implemented by the Tegra2 MMC driver. Since most of
the Tegra2-based boards will need to call it, this commit exports it in
the new public asm/arch/mmc.h header file to prevent each board from
providing its own prototype.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
arch/arm/include/asm/arch-tegra2/mmc.h | 27 +++
board/nvidia/common/board.h|1 -
board/nvidia/harmony/harmony.c |2 +-
board/nvidia/seaboard/seaboard.c |2 +-
drivers/mmc/tegra2_mmc.h |2 --
5 files changed, 29 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra2/mmc.h
diff --git a/arch/arm/include/asm/arch-tegra2/mmc.h
b/arch/arm/include/asm/arch-tegra2/mmc.h
new file mode 100644
index 000..c1f12db
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra2/mmc.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (c) 2011, Google Inc. All rights reserved.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _TEGRA2_MMC_H_
+#define _TEGRA2_MMC_H_
+
+int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
+
+#endif /* TEGRA2_MMC_H_ */
diff --git a/board/nvidia/common/board.h b/board/nvidia/common/board.h
index 1f57086..d0cc03a 100644
--- a/board/nvidia/common/board.h
+++ b/board/nvidia/common/board.h
@@ -25,6 +25,5 @@
#define _BOARD_H_
void gpio_config_uart(void);
-int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
#endif /* BOARD_H */
diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
index 3cbe820..d5e147d 100644
--- a/board/nvidia/harmony/harmony.c
+++ b/board/nvidia/harmony/harmony.c
@@ -25,11 +25,11 @@
#include asm/io.h
#include asm/arch/tegra2.h
#include asm/arch/pinmux.h
+#include asm/arch/mmc.h
#include asm/gpio.h
#ifdef CONFIG_TEGRA2_MMC
#include mmc.h
#endif
-#include ../common/board.h
/*
* Routine: gpio_config_uart
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index aa77f12..7618d14 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -25,11 +25,11 @@
#include asm/io.h
#include asm/arch/tegra2.h
#include asm/arch/pinmux.h
+#include asm/arch/mmc.h
#include asm/gpio.h
#ifdef CONFIG_TEGRA2_MMC
#include mmc.h
#endif
-#include ../common/board.h
/*
* Routine: gpio_config_uart_seaboard
diff --git a/drivers/mmc/tegra2_mmc.h b/drivers/mmc/tegra2_mmc.h
index b2f6c5b..67c00db 100644
--- a/drivers/mmc/tegra2_mmc.h
+++ b/drivers/mmc/tegra2_mmc.h
@@ -127,7 +127,5 @@ struct mmc_host {
int cd_gpio;/* Change Detect GPIO */
};
-int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
-
#endif /* __ASSEMBLY__ */
#endif /* __TEGRA2_MMC_H_ */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] tegra2: Add Avionic Design Tamonten boards.
This series adds support for the Avionic Design Tamonten processor module and two boards based on Tamonten. The series is based on patches that have already been reviewed but haven't been merged yet. They are available in patchwork here: http://patchwork.ozlabs.org/patch/122888 http://patchwork.ozlabs.org/patch/122887 http://patchwork.ozlabs.org/patch/122889 http://patchwork.ozlabs.org/patch/123845 (9 patches) Thierry Reding (4): 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. MAINTAINERS|5 + arch/arm/include/asm/arch-tegra2/mmc.h | 27 ++ board/avionic-design/common/tamonten.c | 160 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/nvidia/common/board.h|1 - board/nvidia/harmony/harmony.c |2 +- board/nvidia/seaboard/seaboard.c |2 +- boards.cfg |2 + drivers/mmc/tegra2_mmc.h |2 - include/configs/medcom.h | 62 include/configs/plutux.h | 62 15 files changed, 542 insertions(+), 5 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra2/mmc.h create mode 100644 board/avionic-design/common/tamonten.c create mode 100644 board/avionic-design/common/tamonten.h create mode 100644 board/avionic-design/medcom/Makefile create mode 100644 board/avionic-design/medcom/medcom.c create mode 100644 board/avionic-design/plutux/Makefile create mode 100644 board/avionic-design/plutux/plutux.c create mode 100644 include/configs/medcom.h create mode 100644 include/configs/plutux.h -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] tegra2: Add common Avionic Design Tamonten support.
Tamonten is an NVIDIA Tegra2-based SO-DIMM processor module that is
derived from the Harmony reference design.
Changes in v3:
* Remove unused gpio_config_uart().
* Remove call to tegra2_start().
* Use new tegra2_mmc_init().
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
board/avionic-design/common/tamonten.c | 160
board/avionic-design/common/tamonten.h | 32 +++
2 files changed, 192 insertions(+), 0 deletions(-)
create mode 100644 board/avionic-design/common/tamonten.c
create mode 100644 board/avionic-design/common/tamonten.h
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
new file mode 100644
index 000..98aa0f8
--- /dev/null
+++ b/board/avionic-design/common/tamonten.c
@@ -0,0 +1,160 @@
+/*
+ * (C) Copyright 2010,2011
+ * NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2011
+ * Avionic Design GmbH www.avionic-design.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include ns16550.h
+#include asm/io.h
+#include asm/gpio.h
+#include asm/arch/tegra2.h
+#include asm/arch/sys_proto.h
+#include asm/arch/clk_rst.h
+#include asm/arch/clock.h
+#include asm/arch/pinmux.h
+#include asm/arch/uart.h
+#include asm/arch/mmc.h
+#include tamonten.h
+
+#ifdef CONFIG_TEGRA2_MMC
+#include mmc.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+const struct tegra2_sysinfo sysinfo = {
+ CONFIG_TEGRA2_BOARD_STRING
+};
+
+/*
+ * Routine: timer_init
+ * Description: init the timestamp and lastinc value
+ */
+int timer_init(void)
+{
+ return 0;
+}
+
+static void enable_uart(enum periph_id pid)
+{
+ /* Assert UART reset and enable clock */
+ reset_set_enable(pid, 1);
+ clock_enable(pid);
+ clock_ll_set_source(pid, 0);/* UARTx_CLK_SRC = 00, PLLP_OUT0 */
+
+ /* wait for 2us */
+ udelay(2);
+
+ /* De-assert reset to UART */
+ reset_set_enable(pid, 0);
+}
+
+/*
+ * Routine: clock_init_uart
+ * Description: init the PLL and clock for the UART(s)
+ */
+static void clock_init_uart(void)
+{
+#if defined(CONFIG_TEGRA2_ENABLE_UARTD)
+ enable_uart(PERIPH_ID_UART4);
+#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
+}
+
+/*
+ * Routine: pin_mux_uart
+ * Description: setup the pin muxes/tristate values for the UART(s)
+ */
+static void pin_mux_uart(void)
+{
+#if defined(CONFIG_TEGRA2_ENABLE_UARTD)
+ pinmux_set_func(PINGRP_GMC, PMUX_FUNC_UARTD);
+
+ pinmux_tristate_disable(PINGRP_GMC);
+#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
+}
+
+#ifdef CONFIG_TEGRA2_MMC
+/*
+ * Routine: pin_mux_mmc
+ * Description: setup the pin muxes/tristate values for the SDMMC(s)
+ */
+static void pin_mux_mmc(void)
+{
+ /* SDMMC4: config 3, x8 on 2nd set of pins */
+ pinmux_set_func(PINGRP_ATB, PMUX_FUNC_SDIO4);
+ pinmux_set_func(PINGRP_GMA, PMUX_FUNC_SDIO4);
+ pinmux_set_func(PINGRP_GME, PMUX_FUNC_SDIO4);
+
+ pinmux_tristate_disable(PINGRP_ATB);
+ pinmux_tristate_disable(PINGRP_GMA);
+ pinmux_tristate_disable(PINGRP_GME);
+}
+#endif
+
+/*
+ * Routine: board_init
+ * Description: Early hardware init.
+ */
+int board_init(void)
+{
+ clock_init();
+ clock_verify();
+
+ /* boot param addr */
+ gd-bd-bi_boot_params = (NV_PA_SDRAM_BASE + 0x100);
+
+ return 0;
+}
+
+#ifdef CONFIG_TEGRA2_MMC
+/* this is a weak define that we are overriding */
+int board_mmc_init(bd_t *bd)
+{
+ debug(board_mmc_init called\n);
+ /* Enable muxes, etc. for SDMMC controllers */
+ pin_mux_mmc();
+ gpio_config_mmc();
+
+ debug(board_mmc_init: init eMMC\n);
+ /* init dev 0, eMMC chip, with 4-bit bus */
+ tegra2_mmc_init(0, 4, -1, GPIO_PH2);
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_BOARD_EARLY_INIT_F
+int board_early_init_f(void)
+{
+ /* Initialize essential common plls */
+ clock_early_init();
+
+ /* Initialize UART clocks */
+ clock_init_uart();
+
+ /* Initialize periph pinmuxes */
+ pin_mux_uart();
+
+ return 0;
+}
+#endif /* EARLY_INIT */
diff --git a/board/avionic-design/common/tamonten.h
b/board/avionic-design/common/tamonten.h
new file mode 100644
index
[U-Boot] [PATCH v3 3/4] tegra2: Add Avionic Design Plutux support.
The Plutux is a set-top box device based on the Tamonten processor
module. It can be connected to a display via an HDMI output.
Changes in v3:
* Remove unused implementation of gpio_config_uart().
* Implement MMC/SD card detection.
* Drop board_mmc_getcd() which is now implemented by common Tegra2
code.
* Add MAINTAINERS entry.
Changes in v2:
* No longer override the default CONFIG_SYS_TEXT_BASE setting.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
MAINTAINERS |4 ++
board/avionic-design/plutux/Makefile | 50 +++
board/avionic-design/plutux/plutux.c | 45
boards.cfg |1 +
include/configs/plutux.h | 62 ++
5 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 board/avionic-design/plutux/Makefile
create mode 100644 board/avionic-design/plutux/plutux.c
create mode 100644 include/configs/plutux.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d24d7ad..bb92ad9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -782,6 +782,10 @@ Stelian Pop stelian@leadtechdesign.com
at91sam9263ek ARM926EJS (AT91SAM9263 SoC)
at91sam9rlekARM926EJS (AT91SAM9RL SoC)
+Thierry Reding thierry.red...@avionic-design.de
+
+ plutux Tegra2 (ARM7 A9 Dual Core)
+
Tom Rini tr...@ti.com
omap3_evm ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/avionic-design/plutux/Makefile
b/board/avionic-design/plutux/Makefile
new file mode 100644
index 000..b0c318c
--- /dev/null
+++ b/board/avionic-design/plutux/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2010,2011
+# NVIDIA Corporation www.nvidia.com
+# (C) Copyright 2011
+# Avionic Design GmbH www.avionic-design.de
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)../common)
+endif
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o
+COBJS += ../common/tamonten.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/avionic-design/plutux/plutux.c
b/board/avionic-design/plutux/plutux.c
new file mode 100644
index 000..42c8094
--- /dev/null
+++ b/board/avionic-design/plutux/plutux.c
@@ -0,0 +1,45 @@
+/*
+ * (C) Copyright 2010,2011
+ * NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2011
+ * Avionic Design GmbH www.avionic-design.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/gpio.h
+#include asm/arch/tegra2.h
+#ifdef CONFIG_TEGRA2_MMC
+#include mmc.h
+#endif
+
+#ifdef CONFIG_TEGRA2_MMC
+/*
+ * Routine: gpio_config_mmc
+ * Description: Set GPIOs for SD card
+ */
+void gpio_config_mmc(void)
+{
+ /* configure pin as input for card detect */
+ gpio_request(GPIO_PH2, SD4 CD);
+ gpio_direction_input(GPIO_PH2);
+}
+#endif
diff --git a/boards.cfg b/boards.cfg
index 5c2e01b..e6a4a41 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -232,6 +232,7 @@ xaeniax arm pxa
xm250
[U-Boot] [PATCH v3 4/4] tegra2: Add Avionic Design Medcom support.
The Medcom is a 16:9 15 terminal that is used for patient infotainment
in hospitals.
Changes in v3:
* Remove unused implementation of gpio_config_uart().
* Implement MMC/SD card detection.
* Drop board_mmc_getcd() which is now implemented by common Tegra2
code.
* Add MAINTAINERS entry.
Changes in v2:
* No longer override the default CONFIG_SYS_TEXT_BASE setting.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
MAINTAINERS |1 +
board/avionic-design/medcom/Makefile | 50 +++
board/avionic-design/medcom/medcom.c | 45
boards.cfg |1 +
include/configs/medcom.h | 62 ++
5 files changed, 159 insertions(+), 0 deletions(-)
create mode 100644 board/avionic-design/medcom/Makefile
create mode 100644 board/avionic-design/medcom/medcom.c
create mode 100644 include/configs/medcom.h
diff --git a/MAINTAINERS b/MAINTAINERS
index bb92ad9..a9a0f88 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -785,6 +785,7 @@ Stelian Pop stelian@leadtechdesign.com
Thierry Reding thierry.red...@avionic-design.de
plutux Tegra2 (ARM7 A9 Dual Core)
+ medcom Tegra2 (ARM7 A9 Dual Core)
Tom Rini tr...@ti.com
diff --git a/board/avionic-design/medcom/Makefile
b/board/avionic-design/medcom/Makefile
new file mode 100644
index 000..b0c318c
--- /dev/null
+++ b/board/avionic-design/medcom/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2010,2011
+# NVIDIA Corporation www.nvidia.com
+# (C) Copyright 2011
+# Avionic Design GmbH www.avionic-design.de
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+ifneq ($(OBJTREE),$(SRCTREE))
+$(shell mkdir -p $(obj)../common)
+endif
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o
+COBJS += ../common/tamonten.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/avionic-design/medcom/medcom.c
b/board/avionic-design/medcom/medcom.c
new file mode 100644
index 000..42c8094
--- /dev/null
+++ b/board/avionic-design/medcom/medcom.c
@@ -0,0 +1,45 @@
+/*
+ * (C) Copyright 2010,2011
+ * NVIDIA Corporation www.nvidia.com
+ * (C) Copyright 2011
+ * Avionic Design GmbH www.avionic-design.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/gpio.h
+#include asm/arch/tegra2.h
+#ifdef CONFIG_TEGRA2_MMC
+#include mmc.h
+#endif
+
+#ifdef CONFIG_TEGRA2_MMC
+/*
+ * Routine: gpio_config_mmc
+ * Description: Set GPIOs for SD card
+ */
+void gpio_config_mmc(void)
+{
+ /* configure pin as input for card detect */
+ gpio_request(GPIO_PH2, SD4 CD);
+ gpio_direction_input(GPIO_PH2);
+}
+#endif
diff --git a/boards.cfg b/boards.cfg
index e6a4a41..be2e53d 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -233,6 +233,7 @@ xm250arm pxa
zipitz2 arm pxa
jornada arm sa1100
plutux arm armv7 plutux
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
On Thu, Nov 17, 2011 at 1:43 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Gabe, On 17/11/11 11:27, Gabe Black wrote: Add a target for running u-boot as a coreboot payload in boards.cfg. Signed-off-by: Gabe Black gabebl...@chromium.org --- Changes in v2: Change capitalization of the x86 tag. Changes in v3: Move the Signed-off-by line up. Changes in v4: Change the summary tag style. boards.cfg |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index 8b7a03b..4b2a1a7 100644 --- a/boards.cfg +++ b/boards.cfg @@ -272,6 +272,7 @@ tcm-bf518blackfinblackfin tcm-bf537blackfinblackfin eNET x86 x86eNET - sc520 eNET:SYS_TEXT_BASE=0x3804 eNET_SRAMx86 x86eNET - sc520 eNET:SYS_TEXT_BASE=0x1900 +coreboot-x86 x86 x86coreboot chromebook-x86 corebootcoreboot:SYS_TEXT_BASE=0xFC sandbox sandbox sandbox sandbox sandbox- cobra5272m68kmcf52x2 cobra5272 - idmr m68kmcf52x2 As mentioned by others before, there is no reason to have these as discrete patches - Please merge into a single 'Add coreboot payload' Ok. Since there are more patches here than I sent out previously and one big patch seemed like it was more than exactly one complete logical change I wanted to find out how these should be merged. If they should all be merged, then that answers the question. Is there any real reason to reference 'chromebook-x86'? I don't follow. I'm not referencing it, that's what we're calling our board since it's an x86 chromebook. And finally, what is the plan for motherboard specific coreboot variants? We haven't worked out all the details, but our current working plan is that coreboot itself will be specialized per board and that U-Boot will stay fairly generic and be specialized as needed using the device tree. We may find that a single version of U-Boot with a superset of drivers is too big and we need to have different configs for each variant. Gabe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
Hi Gabe, On 17/11/11 21:11, Gabe Black wrote: On Thu, Nov 17, 2011 at 1:43 AM, Graeme Russ graeme.r...@gmail.com mailto:graeme.r...@gmail.com wrote: Hi Gabe, On 17/11/11 11:27, Gabe Black wrote: Add a target for running u-boot as a coreboot payload in boards.cfg. Signed-off-by: Gabe Black gabebl...@chromium.org [snip] As mentioned by others before, there is no reason to have these as discrete patches - Please merge into a single 'Add coreboot payload' Ok. Since there are more patches here than I sent out previously and one big patch seemed like it was more than exactly one complete logical change I wanted to find out how these should be merged. If they should all be merged, then that answers the question. Well, if a given patch is meaningless without another, they really should be combined. Of course there are exceptions, like adding a new driver - The code for it gets added in one patch, and the usage in a board in another Is there any real reason to reference 'chromebook-x86'? I don't follow. I'm not referencing it, that's what we're calling our board since it's an x86 chromebook. I mean, if this is 'generic', why is there a reference to the chromebook? And finally, what is the plan for motherboard specific coreboot variants? We haven't worked out all the details, but our current working plan is that coreboot itself will be specialized per board and that U-Boot will stay fairly generic and be specialized as needed using the device tree. We may find that a single version of U-Boot with a superset of drivers is too big and we need to have different configs for each variant. This probably won't work in and of itself without a major overhaul of the U-Boot driver architecture :) Boards will need their own config for Ethernet drivers for example Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
Dear Prafulla, In message f766e4f80769bd478052fb6533fa745d1a14ee2...@sc-vexch4.marvell.com you wrote: I withdraw my NAK for this patch. Let's remove mac randomization support for mvgbe driver. If needed, for any particular board, it will be addressed separately. Thanks a lot - highly appreciated. 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'm a programmer: I don't buy software, I write it. -- Tom Christiansen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] arm:exynos4:samsung:nuri Support for NURI target.
This patch adds support for Samsung's Exynos4 Nuri reference board. New exynos4_nuri board has been added to boards.cfg Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes for v2: - MAINTAINERS file updated - CONFIG_MACH_TYPE added - hw_revision routine Changes for v3: - Entry to MAINTAINERS file added to preserve an alphabetical order - Redefinition of MACH_TYPE removed from exynos4_nuri.h - Code cleanup (dead spaces removed) ./tools/checkpatch.pl - total: 0 errors, 0 warnings, 867 lines checked NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE --- MAINTAINERS|4 + board/samsung/nuri/Makefile| 45 board/samsung/nuri/lowlevel_init.S | 395 board/samsung/nuri/nuri.c | 201 ++ boards.cfg |1 + include/configs/exynos4_nuri.h | 209 +++ 6 files changed, 855 insertions(+), 0 deletions(-) create mode 100644 board/samsung/nuri/Makefile create mode 100644 board/samsung/nuri/lowlevel_init.S create mode 100644 board/samsung/nuri/nuri.c create mode 100644 include/configs/exynos4_nuri.h diff --git a/MAINTAINERS b/MAINTAINERS index 576fea8..aa1fc15 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -724,6 +724,10 @@ Valentin Longchamp valentin.longch...@keymile.com km_kirkwood ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) +Łukasz Majewski l.majew...@samsung.com + + exynos4_nuriARM ARMV7 (S5PC210 SoC) + Nishanth Menon n...@ti.com omap3_sdp3430 ARM ARMV7 (OMAP3xx SoC) diff --git a/board/samsung/nuri/Makefile b/board/samsung/nuri/Makefile new file mode 100644 index 000..27566de --- /dev/null +++ b/board/samsung/nuri/Makefile @@ -0,0 +1,45 @@ +# +# Copyright (C) 2010 Samsung Electronics +# Minkyu Kang mk7.k...@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 as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS-y:= nuri.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/nuri/lowlevel_init.S b/board/samsung/nuri/lowlevel_init.S new file mode 100644 index 000..67635bb --- /dev/null +++ b/board/samsung/nuri/lowlevel_init.S @@ -0,0 +1,395 @@ +/* + * Lowlevel setup for universal board based on S5PC210 + * + * Copyright (C) 2010 Samsung Electronics + * 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 as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include config.h +#include version.h +#include asm/arch/cpu.h +#include asm/arch/clock.h + +/* + * Register usages: + * + * r5 has zero always + * r7 has GPIO part1 base 0x1140 + * r6 has GPIO part2 base 0x1100 + */ + + .globl lowlevel_init +lowlevel_init: + mov r11, lr + + /* r5 has always zero */ + mov r5, #0 + +
[U-Boot] [PATCH] mmc: Implement card detection.
Check for board-specific card detect each time an MMC/SD device is
initialized. If card detection is not implemented, this code behaves as
before and continues assuming a card is present. If no card is detected,
has_init is reset for the MMC/SD device (to force initialization next
time) and an error is returned.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/mmc.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 37ce6e8..d18c095 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1191,6 +1191,15 @@ block_dev_desc_t *mmc_get_dev(int dev)
int mmc_init(struct mmc *mmc)
{
int err, retry = 3;
+ u8 card_detect = 0;
+
+ if (board_mmc_getcd(card_detect, mmc) == 0) {
+ if (!card_detect) {
+ mmc-has_init = 0;
+ printf(MMC: no card present\n);
+ return NO_CARD_ERR;
+ }
+ }
if (mmc-has_init)
return 0;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm:exynos4:samsung:nuri Support for NURI target.
On 17 November 2011 16:41, Lukasz Majewski l.majew...@samsung.com wrote: This patch adds support for Samsung's Exynos4 Nuri reference board. New exynos4_nuri board has been added to boards.cfg Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes for v2: - MAINTAINERS file updated - CONFIG_MACH_TYPE added - hw_revision routine Changes for v3: - Entry to MAINTAINERS file added to preserve an alphabetical order - Redefinition of MACH_TYPE removed from exynos4_nuri.h - Code cleanup (dead spaces removed) ./tools/checkpatch.pl - total: 0 errors, 0 warnings, 867 lines checked NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE --- MAINTAINERS|4 + board/samsung/nuri/Makefile| 45 board/samsung/nuri/lowlevel_init.S | 395 board/samsung/nuri/nuri.c | 201 ++ boards.cfg |1 + include/configs/exynos4_nuri.h | 209 +++ 6 files changed, 855 insertions(+), 0 deletions(-) create mode 100644 board/samsung/nuri/Makefile create mode 100644 board/samsung/nuri/lowlevel_init.S create mode 100644 board/samsung/nuri/nuri.c create mode 100644 include/configs/exynos4_nuri.h diff --git a/MAINTAINERS b/MAINTAINERS index 576fea8..aa1fc15 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -724,6 +724,10 @@ Valentin Longchamp valentin.longch...@keymile.com km_kirkwood ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) +Łukasz Majewski l.majew...@samsung.com + + exynos4_nuriARM ARMV7 (S5PC210 SoC) + Nishanth Menon n...@ti.com omap3_sdp3430 ARM ARMV7 (OMAP3xx SoC) diff --git a/board/samsung/nuri/Makefile b/board/samsung/nuri/Makefile new file mode 100644 index 000..27566de --- /dev/null +++ b/board/samsung/nuri/Makefile @@ -0,0 +1,45 @@ +# +# Copyright (C) 2010 Samsung Electronics +# Minkyu Kang mk7.k...@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 as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS-y:= nuri.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/nuri/lowlevel_init.S b/board/samsung/nuri/lowlevel_init.S new file mode 100644 index 000..67635bb --- /dev/null +++ b/board/samsung/nuri/lowlevel_init.S @@ -0,0 +1,395 @@ +/* + * Lowlevel setup for universal board based on S5PC210 + * + * Copyright (C) 2010 Samsung Electronics + * 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 as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include config.h +#include version.h +#include asm/arch/cpu.h +#include asm/arch/clock.h + +/* + * Register usages: + * + * r5 has zero always + * r7 has GPIO part1
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
On 11/17/11, Graeme Russ graeme.r...@gmail.com wrote: Hi Gabe, [snip] I don't follow. I'm not referencing it, that's what we're calling our board since it's an x86 chromebook. I mean, if this is 'generic', why is there a reference to the chromebook? I think a name like coreboot-x86 could make sense here, but it shouldn't have dependence on drivers specific for chromebook hardware. Only 'generic' drivers as vesa video and keyboard input needs to be referenced on it. Then others developers could extend it to their specific hardware, adding items like ethernet, mmc/sd driver, etc Best Regards, Alan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
On 11/16/2011 10:35 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message d75ba016-4e89-4cea-acec-cc322ff58...@kernel.crashing.org you wrote: Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. On suggestion I'd have is we improve our use of patchworks. Right now there is way too much 'stale' on patchworks so its difficult to extract what needs to be looked at from what might be owned by existing maintainers. As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Sure, but anyway to avoid conflicts I suggest that who takes care of a patch *firstly* sets his name as delegate into patchwork before doing something. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: davici_emac: Fix condition for number of phy detects
From: Prabhakar Lad prabhakar.cse...@gmail.com
Fix the condition for number of phys in
davinci_eth_phy_detect() function.
CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT indicates number of
phys. From this commit id dc02badab480563b0bf9d3908046ea9d6b22ae63
davinci emac initilazed one less than the number of phy count.
Signed-off-by: Prabhakar Lad prabhakar.cse...@gmail.com
---
drivers/net/davinci_emac.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 36c33af..34b6f94 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -176,7 +176,7 @@ static int davinci_eth_phy_detect(void)
for (i = 0, j = 0; i 32; i++)
if (phy_act_state (1 i)) {
count++;
- if (count CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
+ if (count = CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
active_phy_addr[j++] = i;
} else {
printf(%s: to many PHYs detected.\n,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH] ARM: davici_emac: Fix condition for number of phy detects
From: Prabhakar Lad prabhakar.cse...@gmail.com
Fix the condition for number of phys in
davinci_eth_phy_detect() function.
CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT indicates number of
phys. From this commit id dc02badab480563b0bf9d3908046ea9d6b22ae63
davinci emac initilazed one less than the number of phy count.
Signed-off-by: Prabhakar Lad prabhakar.cse...@gmail.com
---
drivers/net/davinci_emac.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 36c33af..34b6f94 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -176,7 +176,7 @@ static int davinci_eth_phy_detect(void)
for (i = 0, j = 0; i 32; i++)
if (phy_act_state (1 i)) {
count++;
- if (count CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
+ if (count = CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
active_phy_addr[j++] = i;
} else {
printf(%s: to many PHYs detected.\n,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: davici_emac: Fix condition for number of phy detects
Hello prabhakar.cse...@gmail.com
prabhakar.cse...@gmail.com wrote:
From: Prabhakar Lad prabhakar.cse...@gmail.com
Fix the condition for number of phys in
davinci_eth_phy_detect() function.
CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT indicates number of
phys. From this commit id dc02badab480563b0bf9d3908046ea9d6b22ae63
davinci emac initilazed one less than the number of phy count.
Signed-off-by: Prabhakar Lad prabhakar.cse...@gmail.com
---
drivers/net/davinci_emac.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 36c33af..34b6f94 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -176,7 +176,7 @@ static int davinci_eth_phy_detect(void)
for (i = 0, j = 0; i 32; i++)
if (phy_act_state (1 i)) {
count++;
- if (count CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
+ if (count = CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
active_phy_addr[j++] = i;
} else {
printf(%s: to many PHYs detected.\n,
good catch!
Acked-by: Heiko Schocher h...@denx.de
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] tools: checkpatch.pl from Linux added to tools
Dear Joe Hershberger, In message 1318968419-7686-1-git-send-email-joe.hershber...@ni.com you wrote: Added from Linux - commit 30ecad51849ae132dc6ef6ddb62d499c7257515b Include config file to ignore common false-positives Signed-off-by: Joe Hershberger joe.hershber...@ni.com Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Wolfgang Denk w...@denx.de --- Changes for v2: - Remove exceptions that were needed for CONFIG_ROOTPATH patches - Add exceptions for min/max and simple_strtoul .checkpatch.conf| 15 + tools/checkpatch.pl | 3337 +++ 2 files changed, 3352 insertions(+), 0 deletions(-) create mode 100644 .checkpatch.conf create mode 100755 tools/checkpatch.pl 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 optimum committee has no members. - Norman Augustine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
On Nov 17, 2011, at 6:40 AM, Stefano Babic wrote: On 11/16/2011 10:35 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message d75ba016-4e89-4cea-acec-cc322ff58...@kernel.crashing.org you wrote: Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. On suggestion I'd have is we improve our use of patchworks. Right now there is way too much 'stale' on patchworks so its difficult to extract what needs to be looked at from what might be owned by existing maintainers. As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Sure, but anyway to avoid conflicts I suggest that who takes care of a patch *firstly* sets his name as delegate into patchwork before doing something. Agreed, my thinking was that for the non-maintained patches, the maintainer that pulls a patch in to their tree would mark themselves as the delegate of the patch. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
On Nov 16, 2011, at 3:35 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message d75ba016-4e89-4cea-acec-cc322ff58...@kernel.crashing.org you wrote: Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. On suggestion I'd have is we improve our use of patchworks. Right now there is way too much 'stale' on patchworks so its difficult to extract what needs to be looked at from what might be owned by existing maintainers. As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Can we say no new patches are going into upstream (your tree) until maintainers go cleanup patchworks? Such that the # of non-delegated patches is only one or two pages worth, rather than 11. - k ___ 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
Hi Mike, Le 16/11/2011 04:53, Mike Frysinger a écrit : i thought Albert said he didn't want this last time we explicitly asked about creating an arm/tegra sub-arch tree ... i think there should be one -mike Uhm, no, I don't think I said I was against creating a Tegra U-Boot repo. What I may have said is that I don't want to fetch from a repo located somewhere else that on the Denx git server. If a u-boot-tegra repo is created on the Denx server, I'll be happy to pull from it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Sandeep, Le 16/11/2011 16:24, s-paul...@ti.com a écrit : The following changes since commit 75acc4d7c1c9081e06d1197c6da01361cf1bce92: Heiko Schocher (1): arm, davinci: add DAVINCI_MMC_CLKID are available in the git repository at: git://git.denx.de/u-boot-ti.git master Sanjeev Premi (2): part_efi: Fix compile errors omap3evm: Add support for EFI partitions disk/part_efi.c |6 +++--- include/configs/omap3_evm.h |1 + 2 files changed, 4 insertions(+), 3 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PPC4xx: usbdev.c used at all?
Hi Marri, I just touched the file arch/powerpc/cpu/ppc4xx/usbdev.c again to remove some GCC 4.6 compiler warnings. While doing this I wondered (again) if anybody is using this driver at all. I definitely never did. And I'm wondering if this code is useful at all. So Marri (or anybody else): Do you need this driver in U-Boot? If not, I'll just remove it in a short while. Thanks. Best regards, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
Dear Kumar Gala, In message dec2dbe6-d658-4504-b157-7b57bb637...@kernel.crashing.org you wrote: As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Can we say no new patches are going into upstream (your tree) until maintainers go cleanup patchworks? Such that the # of non-delegated patches is only one or two pages worth, rather than 11. With no new patches you mean that I will stop applying already posted patches, or new postings to the ML? I'm fine with both... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Be careful what you wish for. You never know who will be listening. - Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/17] env: move extern default_environment[] to environment.h
On 11/07/2011 12:13 PM, Igor Grinberg wrote: Extract all extern declarations for default_environment[] out of c files into the environment.h header. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Cc: Stefan Roese s...@denx.de --- board/zeus/zeus.c |1 - common/env_dataflash.c |2 -- common/env_flash.c |2 -- common/env_mgdisk.c|3 --- common/env_mmc.c |3 --- common/env_nand.c |3 --- common/env_nowhere.c |2 -- common/env_nvram.c |2 -- common/env_onenand.c |3 --- common/env_sf.c|3 --- include/environment.h |2 ++ 11 files changed, 2 insertions(+), 24 deletions(-) Hi Igor, this patch breaks several boards because tools cannot be compiled clean: gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/stefano/Projects/u-boot-staging/include -idirafter /home/stefano/Projects/u-boot-staging/include2 -idirafter /home/stefano/Projects/u-boot-staging/include -I /home/stefano/Projects/u-boot-staging/lib/libfdt -I /home/stefano/Projects/u-boot-staging/tools -DCONFIG_SYS_TEXT_BASE=0x0200 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o envcrc.o envcrc.c -c envcrc.c:80:1: Fehler: unbekannter Typname: »env_t« make[1]: *** [envcrc.o] Fehler 1 You can try with the cmi_mpc5xx board, but it is only an example - I get the same errors with several ARM boards, because at the end environment.h is not included. Can you take a look at it ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] arm:exynos4:samsung:nuri Support for NURI target.
This patch adds support for Samsung's Exynos4 Nuri reference board. New exynos4_nuri board has been added to boards.cfg Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes for v2: - MAINTAINERS file updated - CONFIG_MACH_TYPE added - hw_revision routine Changes for v3: - Entry to MAINTAINERS file added to preserve an alphabethical order - Redefinition of MACH_TYPE removed at exynos4_nuri.h - Code cleanup (dead spaces removed) Changes for v4: - get_ram_size() check added to dram_init() - Use of MACH_TYPE_NURI defined at ./arch/arm/include/asm/mach-types.h instead of a hard coded value - Comments correction ./tools/checkpatch.pl - total: 0 errors, 0 warnings, 875 lines checked NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE --- MAINTAINERS|4 + board/samsung/nuri/Makefile| 45 board/samsung/nuri/lowlevel_init.S | 395 board/samsung/nuri/nuri.c | 208 +++ boards.cfg |1 + include/configs/exynos4_nuri.h | 210 +++ 6 files changed, 863 insertions(+), 0 deletions(-) create mode 100644 board/samsung/nuri/Makefile create mode 100644 board/samsung/nuri/lowlevel_init.S create mode 100644 board/samsung/nuri/nuri.c create mode 100644 include/configs/exynos4_nuri.h diff --git a/MAINTAINERS b/MAINTAINERS index 576fea8..aa1fc15 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -724,6 +724,10 @@ Valentin Longchamp valentin.longch...@keymile.com km_kirkwood ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) +Łukasz Majewski l.majew...@samsung.com + + exynos4_nuriARM ARMV7 (S5PC210 SoC) + Nishanth Menon n...@ti.com omap3_sdp3430 ARM ARMV7 (OMAP3xx SoC) diff --git a/board/samsung/nuri/Makefile b/board/samsung/nuri/Makefile new file mode 100644 index 000..27566de --- /dev/null +++ b/board/samsung/nuri/Makefile @@ -0,0 +1,45 @@ +# +# Copyright (C) 2010 Samsung Electronics +# Minkyu Kang mk7.k...@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 as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS-y:= nuri.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/nuri/lowlevel_init.S b/board/samsung/nuri/lowlevel_init.S new file mode 100644 index 000..67635bb --- /dev/null +++ b/board/samsung/nuri/lowlevel_init.S @@ -0,0 +1,395 @@ +/* + * Lowlevel setup for universal board based on S5PC210 + * + * Copyright (C) 2010 Samsung Electronics + * 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 as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include config.h +#include version.h +#include asm/arch/cpu.h +#include asm/arch/clock.h + +/* + * Register usages: + *
Re: [U-Boot] PPC4xx: usbdev.c used at all?
We do not use it or plan to use it. Matthias On 17.11.2011 15:04, Stefan Roese wrote: Hi Marri, I just touched the file arch/powerpc/cpu/ppc4xx/usbdev.c again to remove some GCC 4.6 compiler warnings. While doing this I wondered (again) if anybody is using this driver at all. I definitely never did. And I'm wondering if this code is useful at all. So Marri (or anybody else): Do you need this driver in U-Boot? If not, I'll just remove it in a short while. Thanks. Best regards, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
On Nov 17, 2011, at 8:10 AM, Wolfgang Denk wrote: Dear Kumar Gala, In message dec2dbe6-d658-4504-b157-7b57bb637...@kernel.crashing.org you wrote: As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Can we say no new patches are going into upstream (your tree) until maintainers go cleanup patchworks? Such that the # of non-delegated patches is only one or two pages worth, rather than 11. With no new patches you mean that I will stop applying already posted patches, or new postings to the ML? I'm fine with both... I meant the stop applying patches… not sure how we'd stop people posting new patches to the ML ;) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Nov 17, 2011, at 7:55 AM, Albert ARIBAUD wrote: Hi Sandeep, Le 16/11/2011 16:24, s-paul...@ti.com a écrit : The following changes since commit 75acc4d7c1c9081e06d1197c6da01361cf1bce92: Heiko Schocher (1): arm, davinci: add DAVINCI_MMC_CLKID are available in the git repository at: git://git.denx.de/u-boot-ti.git master Sanjeev Premi (2): part_efi: Fix compile errors omap3evm: Add support for EFI partitions disk/part_efi.c |6 +++--- include/configs/omap3_evm.h |1 + 2 files changed, 4 insertions(+), 3 deletions(-) Applied to u-boot-arm/master, thanks! Guys, can you please cleanup patchworks for all the ARM patches and other ARM sub-maintainers: http://patchwork.ozlabs.org/project/uboot/list/ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
On 11/17/2011 08:56 AM, Thierry Reding wrote: I had actually set Doug Anderson diand...@chromium.org on Cc because he was involved with the initial patch but for some reason he got stripped from Cc. Does anybody know why this is happening? Probably Doug has received the first e-mail. I noted that git send-email strips the CC addresses (maybe to avoid SPAM ?), but the e-mail is sent anyway. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
* Stefano Babic wrote: On 11/17/2011 08:56 AM, Thierry Reding wrote: I had actually set Doug Anderson diand...@chromium.org on Cc because he was involved with the initial patch but for some reason he got stripped from Cc. Does anybody know why this is happening? Probably Doug has received the first e-mail. I noted that git send-email strips the CC addresses (maybe to avoid SPAM ?), but the e-mail is sent anyway. I don't think git send-email is stripping the Cc header because I've seen it work properly for other mailing lists. Perhaps the mailing list software is the culprit here? Could it be that it strips people that are subscribed (and will receive the mails anyway) but not those that aren't subscribed? Not that Tom Warren wasn't stripped from Cc. Thierry pgpT9FB1YOXiL.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/17] env: move extern default_environment[] to environment.h
Hi Stefano, On 11/17/11 16:12, Stefano Babic wrote: On 11/07/2011 12:13 PM, Igor Grinberg wrote: Extract all extern declarations for default_environment[] out of c files into the environment.h header. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Cc: Stefan Roese s...@denx.de --- board/zeus/zeus.c |1 - common/env_dataflash.c |2 -- common/env_flash.c |2 -- common/env_mgdisk.c|3 --- common/env_mmc.c |3 --- common/env_nand.c |3 --- common/env_nowhere.c |2 -- common/env_nvram.c |2 -- common/env_onenand.c |3 --- common/env_sf.c|3 --- include/environment.h |2 ++ 11 files changed, 2 insertions(+), 24 deletions(-) Hi Igor, this patch breaks several boards because tools cannot be compiled clean: gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/stefano/Projects/u-boot-staging/include -idirafter /home/stefano/Projects/u-boot-staging/include2 -idirafter /home/stefano/Projects/u-boot-staging/include -I /home/stefano/Projects/u-boot-staging/lib/libfdt -I /home/stefano/Projects/u-boot-staging/tools -DCONFIG_SYS_TEXT_BASE=0x0200 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o envcrc.o envcrc.c -c envcrc.c:80:1: Fehler: unbekannter Typname: »env_t« make[1]: *** [envcrc.o] Fehler 1 You can try with the cmi_mpc5xx board, but it is only an example - I get the same errors with several ARM boards, because at the end environment.h is not included. Can you take a look at it ? I don't have the ppc cross tool chain at hand, can you tell me which ARM board(s) get broken, so I can verify this? Also, I think it is not that patch but the next one: [PATCH 04/17] env: move extern environment[] to environment.h Can you please check if the attached patch fixes the envcrc.c problem? Thanks. -- Regards, Igor. diff --git a/tools/envcrc.c b/tools/envcrc.c index 12913c2..111d9f6 100644 --- a/tools/envcrc.c +++ b/tools/envcrc.c @@ -61,6 +61,7 @@ #endif /* CONFIG_ENV_IS_IN_FLASH */ #if defined(ENV_IS_EMBEDDED) !defined(CONFIG_BUILD_ENVCRC) +# include environment.h # define CONFIG_BUILD_ENVCRC 1 #endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/17] env: move extern default_environment[] to environment.h
On 11/17/2011 04:14 PM, Igor Grinberg wrote: I don't have the ppc cross tool chain at hand, can you tell me which ARM board(s) get broken, so I can verify this? Also, I think it is not that patch but the next one: [PATCH 04/17] env: move extern environment[] to environment.h You're right, but that was the result bisecting the tree. Can you please check if the attached patch fixes the envcrc.c problem? Yes, it is fixed - it is the missing environment.h. The board is built, as well as the other powerpc boards (the ones I tested up now). Can you resend only the [PATCH 04/17] ? Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot]automatic reset of variables to defaults
Hello u-boot users list, I am experiencing a problem concerning variables being set and later getting lost. In order to boot a Linux on a quite small plattform (Eddy CPU: http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I have to reset the variable OS_SDRAM from its initial value of 0x2000 to 0x2100. If I don't do so, the bootloader reports problems extracting my kernel. This must be due to my kernel being bigger than expected by u-boot. These are the steps, that I take: [code] setenv OS_SDRAM 0x2100 saveenv reset [/code] Anyway, this way, it works fine. Sometimes, the bootloader looses this configuration and resets its variable OS_SDRAM back to its default value. Once, the bootloader has reset this value, it cannot boot anymore(well, of course not, since I had to manually alter this value in order to make it boot my linux). Annoyingly, I cannot surely reproduce this error. I tried rebooting it over 3 days in 2-minute-steps and the error won't occur. In addition, I tried giving random input to the console of u-boot for 3 days (again in 2-minute-steps) and still the error won't come up. Two questions: 1. What else might be the cause of this? 2. How could I prevent u-boot from resetting to its default value? I'd be happy for any kind of help. Best regards, Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot]automatic reset of variables to defaults
Hello u-boot users list, I am experiencing a problem concerning variables being set and later getting lost. In order to boot a Linux on a quite small plattform (Eddy CPU: http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I have to reset the variable OS_SDRAM from its initial value of 0x2000 to 0x2100. If I don't do so, the bootloader reports problems extracting my kernel. This must be due to my kernel being bigger than expected by u-boot. These are the steps, that I take: [code] setenv OS_SDRAM 0x2100 saveenv reset [/code] Anyway, this way, it works fine. Sometimes, the bootloader looses this configuration and resets its variable OS_SDRAM back to its default value. Once, the bootloader has reset this value, it cannot boot anymore(well, of course not, since I had to manually alter this value in order to make it boot my linux). Annoyingly, I cannot surely reproduce this error. I tried rebooting it over 3 days in 2-minute-steps and the error won't occur. In addition, I tried giving random input to the console of u-boot for 3 days (again in 2-minute-steps) and still the error won't come up. Two questions: 1. What else might be the cause of this? 2. How could I prevent u-boot from resetting to its default value? I'd be happy for any kind of help. Best regards, Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Improve Power Management in SMC911X driver.
On 11/15/2011 02:40 PM, Bertrand Cachet wrote:
From datasheet, when READY bit is set inside PM_CTRL register, it means that
device is already in *normal* (D0) mode = it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in sleep (D1/D2) mode.
Signed-off-by: Bertrand Cachet bertrand.cac...@heig-vd.ch
---
v2: Improve code styling by grouping two narrow comments.
v3: Place versions information under scissors line.
v4: Use tabs instead of spaces (vimrc problem)
drivers/net/smc911x.h |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..a290073 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,11 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
- /* Take out of PM setting first */
- if (smc911x_reg_read(dev, PMT_CTRL) PMT_CTRL_READY) {
+ /*
+ * Take out of PM setting first
+ * Device is already wake up if PMT_CTRL_READY bit is set
+ */
+ if ((smc911x_reg_read(dev, PMT_CTRL) PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
Agree, this is the correct behavior. However, checkpatch report errors
(due to leading white space instead of tabs in the comment you added):
ERROR: code indent should use tabs where possible
#29: FILE: drivers/net/smc911x.h:475:
+ ^I * Take out of PM setting first$
WARNING: please, no space before tabs
#29: FILE: drivers/net/smc911x.h:475:
+ ^I * Take out of PM setting first$
ERROR: code indent should use tabs where possible
#30: FILE: drivers/net/smc911x.h:476:
+ ^I * Device is already wake up if PMT_CTRL_READY bit is set$
WARNING: please, no space before tabs
#30: FILE: drivers/net/smc911x.h:476:
+ ^I * Device is already wake up if PMT_CTRL_READY bit is set$
total: 2 errors, 2 warnings, 13 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
Can you fix and repost (maybe setting me as CC, I will take care of your
patch).
Thanks,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/17] env: move extern environment[] to environment.h
Extract all extern declarations for environment out of c files
into the environment.h header.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
v2: fix compilation for envcrc.c by including environment.h
(Thanks Stefano)
common/env_flash.c|4 +---
common/env_mmc.c |3 +--
common/env_nand.c |3 +--
common/env_onenand.c |6 +-
include/environment.h |4
tools/envcrc.c|5 +++--
6 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/common/env_flash.c b/common/env_flash.c
index 1383f3c..a32bfcf 100644
--- a/common/env_flash.c
+++ b/common/env_flash.c
@@ -49,9 +49,7 @@ DECLARE_GLOBAL_DATA_PTR;
char * env_name_spec = Flash;
#ifdef ENV_IS_EMBEDDED
-
-extern uchar environment[];
-env_t *env_ptr = (env_t *)(environment[0]);
+env_t *env_ptr = environment;
static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
diff --git a/common/env_mmc.c b/common/env_mmc.c
index a0c0ece..cb75887 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -35,8 +35,7 @@
char *env_name_spec = MMC;
#ifdef ENV_IS_EMBEDDED
-extern uchar environment[];
-env_t *env_ptr = (env_t *)(environment[0]);
+env_t *env_ptr = environment;
#else /* ! ENV_IS_EMBEDDED */
env_t *env_ptr = NULL;
#endif /* ENV_IS_EMBEDDED */
diff --git a/common/env_nand.c b/common/env_nand.c
index 94d4417..d975322 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -59,8 +59,7 @@ char *env_name_spec = NAND;
#if defined(ENV_IS_EMBEDDED)
-extern uchar environment[];
-env_t *env_ptr = (env_t *)(environment[0]);
+env_t *env_ptr = environment;
#elif defined(CONFIG_NAND_ENV_DST)
env_t *env_ptr = (env_t *)CONFIG_NAND_ENV_DST;
#else /* ! ENV_IS_EMBEDDED */
diff --git a/common/env_onenand.c b/common/env_onenand.c
index b1f266b..c09fdf3 100644
--- a/common/env_onenand.c
+++ b/common/env_onenand.c
@@ -44,10 +44,6 @@ char *env_name_spec = OneNAND;
#define ONENAND_MAX_ENV_SIZE 4096
#define ONENAND_ENV_SIZE(mtd) (ONENAND_MAX_ENV_SIZE - ENV_HEADER_SIZE)
-#ifdef ENV_IS_EMBEDDED
-extern uchar environment[];
-#endif /* ENV_IS_EMBEDDED */
-
DECLARE_GLOBAL_DATA_PTR;
uchar env_get_char_spec(int index)
@@ -64,7 +60,7 @@ void env_relocate_spec(void)
int rc;
size_t retlen;
#ifdef ENV_IS_EMBEDDED
- char *buf = (char *)environment[0];
+ char *buf = (char *)environment;
#else
loff_t env_addr = CONFIG_ENV_ADDR;
char onenand_env[ONENAND_MAX_ENV_SIZE];
diff --git a/include/environment.h b/include/environment.h
index 20775da..951803f 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -154,6 +154,10 @@ typedef struct environment_s {
unsigned char data[ENV_SIZE]; /* Environment data */
} env_t;
+#ifdef ENV_IS_EMBEDDED
+extern env_t environment;
+#endif /* ENV_IS_EMBEDDED */
+
extern const unsigned char default_environment[];
#ifndef DO_DEPS_ONLY
diff --git a/tools/envcrc.c b/tools/envcrc.c
index feebbab..111d9f6 100644
--- a/tools/envcrc.c
+++ b/tools/envcrc.c
@@ -61,6 +61,7 @@
#endif /* CONFIG_ENV_IS_IN_FLASH */
#if defined(ENV_IS_EMBEDDED) !defined(CONFIG_BUILD_ENVCRC)
+# include environment.h
# define CONFIG_BUILD_ENVCRC 1
#endif
@@ -77,7 +78,7 @@ extern uint32_t crc32 (uint32_t, const unsigned char *,
unsigned int);
#ifdef CONFIG_BUILD_ENVCRC
extern unsigned int env_size;
-extern unsigned char environment;
+extern env_t environment;
#endif /* CONFIG_BUILD_ENVCRC */
int main (int argc, char **argv)
@@ -85,7 +86,7 @@ int main (int argc, char **argv)
#ifdef CONFIG_BUILD_ENVCRC
unsigned char pad = 0x00;
uint32_t crc;
- unsigned char *envptr = environment,
+ unsigned char *envptr = (unsigned char *)environment,
*dataptr = envptr + ENV_HEADER_SIZE;
unsigned int datasize = ENV_SIZE;
unsigned int eoe;
--
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] disk: part_efi: Fix parameters passed to is_gpt_valid().
Thierry Reding wrote at Thursday, November 17, 2011 12:05 AM: Something apparently went wrong when the patch in commit deb5ca8 was applied. Commit f75dd58 changed the type of gpt_head to be a pointer and correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got applied, the gpt_head was again reverted to (gpt_head), which was the state before deb5ca8. This commit fixes the passing of gpt_head into is_gpt_valid(). I already posted this patch a while back: http://patchwork.ozlabs.org/patch/122485/ -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Improve Power Management in SMC911X driver.
Hi Stefano, Bertrand,
On 11/17/11 17:52, Stefano Babic wrote:
On 11/15/2011 02:40 PM, Bertrand Cachet wrote:
From datasheet, when READY bit is set inside PM_CTRL register, it means that
device is already in *normal* (D0) mode = it doesn't need to be wake-up.
With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
bits of PM_CTRL register is in sleep (D1/D2) mode.
Signed-off-by: Bertrand Cachet bertrand.cac...@heig-vd.ch
---
v2: Improve code styling by grouping two narrow comments.
v3: Place versions information under scissors line.
v4: Use tabs instead of spaces (vimrc problem)
drivers/net/smc911x.h |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 8ce08a9..a290073 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -471,8 +471,11 @@ static void smc911x_reset(struct eth_device *dev)
{
int timeout;
-/* Take out of PM setting first */
-if (smc911x_reg_read(dev, PMT_CTRL) PMT_CTRL_READY) {
+/*
+ * Take out of PM setting first
+ * Device is already wake up if PMT_CTRL_READY bit is set
+ */
+if ((smc911x_reg_read(dev, PMT_CTRL) PMT_CTRL_READY) == 0) {
/* Write to the bytetest will take out of powerdown */
smc911x_reg_write(dev, BYTE_TEST, 0x0);
Agree, this is the correct behavior. However, checkpatch report errors
(due to leading white space instead of tabs in the comment you added):
Are you sure you are testing the right version (v4)?
Because, I get different errors/warnings on that patch (see below)
ERROR: code indent should use tabs where possible
#29: FILE: drivers/net/smc911x.h:475:
+ ^I * Take out of PM setting first$
WARNING: please, no space before tabs
#29: FILE: drivers/net/smc911x.h:475:
+ ^I * Take out of PM setting first$
ERROR: code indent should use tabs where possible
#30: FILE: drivers/net/smc911x.h:476:
+ ^I * Device is already wake up if PMT_CTRL_READY bit is set$
WARNING: please, no space before tabs
#30: FILE: drivers/net/smc911x.h:476:
+ ^I * Device is already wake up if PMT_CTRL_READY bit is set$
total: 2 errors, 2 warnings, 13 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
My checkpatch.pl reports:
cut
ERROR: trailing whitespace
#133: FILE: drivers/net/smc911x.h:474:
+^I/*^M$
ERROR: trailing whitespace
#134: FILE: drivers/net/smc911x.h:475:
+^I * Take out of PM setting first^M$
ERROR: trailing whitespace
#135: FILE: drivers/net/smc911x.h:476:
+^I * Device is already wake up if PMT_CTRL_READY bit is set^M$
ERROR: DOS line endings
#136: FILE: drivers/net/smc911x.h:477:
+^I */^M$
ERROR: DOS line endings
#137: FILE: drivers/net/smc911x.h:478:
+^Iif ((smc911x_reg_read(dev, PMT_CTRL) PMT_CTRL_READY) == 0) {^M$
total: 5 errors, 0 warnings, 13 lines checked
---cut-
Anyway, those need to be fixed.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
* Stephen Warren wrote: Thierry Reding wrote at Thursday, November 17, 2011 12:05 AM: Something apparently went wrong when the patch in commit deb5ca8 was applied. Commit f75dd58 changed the type of gpt_head to be a pointer and correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got applied, the gpt_head was again reverted to (gpt_head), which was the state before deb5ca8. This commit fixes the passing of gpt_head into is_gpt_valid(). I already posted this patch a while back: http://patchwork.ozlabs.org/patch/122485/ I wasn't aware of that. Please ignore then. Thierry pgp7j29ElXzll.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Improve Power Management in SMC911X driver.
On 11/17/2011 05:21 PM, Igor Grinberg wrote: Agree, this is the correct behavior. However, checkpatch report errors (due to leading white space instead of tabs in the comment you added): Are you sure you are testing the right version (v4)? Because, I get different errors/warnings on that patch (see below) The right version, yes. Maybe I have a an old checkpatch.pl, I must update it. Anyway, those need to be fixed. Right. -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
Doug is in the CC field (via Outlook in my 'U-Boot' folder @ work), and has been for every message in this thread. -Original Message- From: Thierry Reding [mailto:thierry.red...@avionic-design.de] Sent: Thursday, November 17, 2011 8:08 AM To: Stefano Babic Cc: Tom Warren; Doug Anderson; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid(). * PGP Signed by an unknown key * Stefano Babic wrote: On 11/17/2011 08:56 AM, Thierry Reding wrote: I had actually set Doug Anderson diand...@chromium.org on Cc because he was involved with the initial patch but for some reason he got stripped from Cc. Does anybody know why this is happening? Probably Doug has received the first e-mail. I noted that git send-email strips the CC addresses (maybe to avoid SPAM ?), but the e-mail is sent anyway. I don't think git send-email is stripping the Cc header because I've seen it work properly for other mailing lists. Perhaps the mailing list software is the culprit here? Could it be that it strips people that are subscribed (and will receive the mails anyway) but not those that aren't subscribed? Not that Tom Warren wasn't stripped from Cc. Thierry * Unknown Key * 0xA2E3269F --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra2: Fix out-of-tree build for Ventana.
Thierry Reding wrote at Thursday, November 17, 2011 2:48 AM: Since Ventana is derived from Seaboard and requires seaboard.c to build, make sure board/nvidia/seaboard is created in the build tree. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de Acked-by: Stephen Warren swar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Thierry Reding
Sent: Thursday, November 17, 2011 12:35 PM
To: u-boot@lists.denx.de
Cc: Tom Warren
Subject: [U-Boot] [PATCH] disk: part_efi: Fix parameters
passed to is_gpt_valid().
Something apparently went wrong when the patch in commit deb5ca8 was
applied. Commit f75dd58 changed the type of gpt_head to be a
pointer and
correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got
applied, the gpt_head was again reverted to (gpt_head), which was the
state before deb5ca8.
This commit fixes the passing of gpt_head into is_gpt_valid().
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
disk/part_efi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index e7f2714..ddf80a7 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
}
/* This function validates AND fills in the GPT header
and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- (gpt_head), gpt_pte) != 1) {
+ gpt_head, gpt_pte) != 1) {
printf(%s: *** ERROR: Invalid GPT ***\n, __func__);
return;
}
@@ -169,7 +169,7 @@ int
get_partition_info_efi(block_dev_desc_t * dev_desc, int part,
/* This function validates AND fills in the GPT header
and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- (gpt_head), gpt_pte) != 1) {
+ gpt_head, gpt_pte) != 1) {
printf(%s: *** ERROR: Invalid GPT ***\n, __func__);
return -1;
}
--
I had already posted 2 revisions of this patch:
http://lists.denx.de/pipermail/u-boot/2011-November/109791.html
http://lists.denx.de/pipermail/u-boot/2011-November/109899.html
And they are included in this pull request:
http://lists.denx.de/pipermail/u-boot/2011-November/110017.html
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
Agreed--I see myself in the CC from the start. Thanks for Stephen to pointing to the fix that he already posted. -Doug --- On Thu, Nov 17, 2011 at 9:02 AM, Tom Warren twar...@nvidia.com wrote: Doug is in the CC field (via Outlook in my 'U-Boot' folder @ work), and has been for every message in this thread. -Original Message- From: Thierry Reding [mailto:thierry.red...@avionic-design.de] Sent: Thursday, November 17, 2011 8:08 AM To: Stefano Babic Cc: Tom Warren; Doug Anderson; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid(). * PGP Signed by an unknown key * Stefano Babic wrote: On 11/17/2011 08:56 AM, Thierry Reding wrote: I had actually set Doug Anderson diand...@chromium.org on Cc because he was involved with the initial patch but for some reason he got stripped from Cc. Does anybody know why this is happening? Probably Doug has received the first e-mail. I noted that git send-email strips the CC addresses (maybe to avoid SPAM ?), but the e-mail is sent anyway. I don't think git send-email is stripping the Cc header because I've seen it work properly for other mailing lists. Perhaps the mailing list software is the culprit here? Could it be that it strips people that are subscribed (and will receive the mails anyway) but not those that aren't subscribed? Not that Tom Warren wasn't stripped from Cc. Thierry * Unknown Key * 0xA2E3269F --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about baud rate
Hi Dan, I'm using a board similar to canyonlands with a ppc460ex. The baud rate for ttyS0 is set to 115200 by the console= bootarg, but I'd also like to set ttyS1-3 to 115200 also. Why doe you want to setup this parameters from the outside? Really only the serial device used for a console needs to be setup by firmware. All other serial devices should be initialized by the user space programs using them. For each of the three uarts, the device tree has the following line: current-speed = 0; /* Filled in by U-Boot */ Checking current U-Boot code, I believe this comment is simply wrong. I cannot see any part in the canyonlands / or generic 4xx infrastructure that fixes up these properties. Maybe Stefan can comment on this though. How do I go about configuring u-boot to fill these with the baud rate I choose? Sorry for the silly question! I don;t think its a silly question, but I also think that you do not need the configuration ;) Cheers Detlev -- One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm/pxa: fix and cleanup of pxa_mem_setup macro v2
WARNING: This macro do not assume the values for K0DB4, KxDB2, KxFREE, K1RUN, K2RUN and APD bits of CONFIG_SYS_MDREFR_VAL as it was done early on many pxa platforms. All pxa developers that plan to use this macro should check the validity of their MDREFR values. v1: * strict following to section 6.4.10 of Intel PXA27xx Developer's Manual. * use r7 to store CONFIG_SYS_MDREFR_VAL as r6 is used in pxa_wait_ticks. v2: * rename pxa_mem_setup macro to pxa2xx_mem_setup * setting of MDREFR[K1RUN] and MDREFR[K2RUN] bits may be optional * skip certain configuration steps if SDRAM is not present/configured * improve/fix comments Hi, was there any final conclusion on this one ? It seems it was superseded by changes in uboot? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] M28EVK: Enable USB HOST support
Marek Vasut wrote: Marek Vasut wrote: Marek Vasut wrote: Hi Marek, u-boot-v2011.09 doesn't support for imx28. I need complete support patch for mx28. where can i get those patches? for which version of u-boot this patches supports..? Regards, Manoj http://git.denx.de/?p=u-boot/u-boot-imx.git;a=summary M Thanks Marek, Patches applied.. on usb start command i'm getting scanning bus for devices... New Device 0 then its freezes after getting the debug message enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 can u help me on this further? Regards, Manoj There is a mail with subject [U-Boot] [PATCH] GCC4.6: Fix common/usb.c on xscale in uboot ML ... apply the patch and retry. What GCC do you use? M Hello Marek, I'm using u-boot version : u-boot-imx gcc version:4.3.3 When i try to add this Patch [U-Boot] [PATCH] GCC4.6: Fix common/usb.c on xscale I'm getting: patching file usb.c Hunk #1 FAILED at 263. Hunk #2 FAILED at 313. 2 out of 2 hunks FAILED -- saving rejects to file usb.c.rej then i made some changes for common/usb.c as per the patch,even it gets freezes after printing the debug msg. enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 Regards, Manoj Are you using top-of-the-tree u-boot-imx/master? You shouldn't need to apply any patches. That'd explain why you're getting errors applying the last USB patch I suggested. Also, please try ELDK5.0 toolchain. M Marek, ya i'm using master code and now its working fine.. Is it because of [U-Boot] [PATCH] GCC4.6: Fix common/usb.c on xscale or ELDK5.0 or Using u-boot/master ? What did you change? Anyway, it's good to hear!! M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Efika: Configure additional regulators for HDMI output
On 09/28/2011 02:19 PM, Marek Vasut wrote: Signed-off-by: Marek Vasutmarek.va...@gmail.com Cc: Stefano Babicsba...@denx.de --- board/efikamx/efikamx.c | 16 +++- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c index 29fff72..276753c 100644 --- a/board/efikamx/efikamx.c +++ b/board/efikamx/efikamx.c @@ -222,7 +222,7 @@ static void power_init(void) Hi Marek, sorry, I missed this patch - I rebased myself on the actual u-boot-imx, and I applied it. Can you take a look at it to check if it is still ok ? Applied to u-boot-imx, thanks. Best regards, Stefano Babic Jana, you have efikamx and I can get you HDMI cable. Can you recheck tomorrow ? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot
Hi, I am trying to boot beagle board by uart can anybody help me on this issue? I am sorry but I do not understand what you are trying to do. Can you please explain a bit more on what you want to do and what is not working? A good question[1] is the prerequisite for a good answer ;) Cheers Detlev [1] http://catb.org/~esr/faqs/smart-questions.html -- Due to the change in scope, STUN has also been renamed from Simple Traversal of UDP through NAT to Session Traversal Utilities for NAT. The acronym remains STUN, which is all anyone ever remembers anyway.-- rfc5389 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] tegra2: Fixes for running mainline U-Boot.
Thierry Reding wrote at Thursday, November 17, 2011 3:04 AM: The following series contains two patches that allow mainline U-Boot to boot standalone on Tegra2-based boards. It assumes the standard NVIDIA flashing tools as provided by the Linux4Tegra package. The series is based on patches that have already been reviewed but haven't been merged upstream yet. They are available in patchwork here: http://patchwork.ozlabs.org/patch/122888 http://patchwork.ozlabs.org/patch/122887 http://patchwork.ozlabs.org/patch/122889 http://patchwork.ozlabs.org/patch/123845 (9 patches) Thierry Reding (2): tegra2: Always build with USE_PRIVATE_LIBGCC=yes. tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000. The series: Tested-by: Stephen Warren swar...@nvidia.com Acked-by: Stephen Warren swar...@nvidia.com (On Seaboard/Springbank, booted a Linux kernel) Thanks for cleaning this up. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] arm: Remove jornada link script
This link script seems old and incompatible with relocation and its
own sa1000 start.S file. It isn't used because the CPU's link script
was picked up in preference to this.
Signed-off-by: Simon Glass s...@chromium.org
---
board/jornada/u-boot.lds | 58
-- 1 files changed, 0
insertions(+), 58 deletions(-)
delete mode 100644 board/jornada/u-boot.lds
diff --git a/board/jornada/u-boot.lds b/board/jornada/u-boot.lds
deleted file mode 100644
index c75b21f..000
--- a/board/jornada/u-boot.lds
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * (C) Copyright 2000-2004
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- * 2004 (c) MontaVista Software, Inc.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
-OUTPUT_ARCH(arm)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- cpu/sa1100/start.o (.text)
- *(.text)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : { *(.data) }
-
- . = ALIGN(4);
- .got : { *(.got) }
-
-
- . = .;
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
-
- . = ALIGN(4);
- __bss_start = .;
- .bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
- __bss_end__ = .;
-}
Please CC jornada guy next time. Anyway, it looks ok to me, but IMO needs some
testing.
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] tegra2: Move tegra2_mmc_init() prototype to public header.
Thierry Reding wrote at Thursday, November 17, 2011 3:10 AM: tegra2_mmc_init() is implemented by the Tegra2 MMC driver. Since most of the Tegra2-based boards will need to call it, this commit exports it in the new public asm/arch/mmc.h header file to prevent each board from providing its own prototype. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de This 1 patch, Acked-by: Stephen Warren swar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Thanks for cleaning this up. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about baud rate
Why doe you want to setup this parameters from the outside? Really only the serial device used for a console needs to be setup by firmware. All other serial devices should be initialized by the user space programs using them. I would like my startup script to cat messages to ttyS1, as well as to the console (ttyS0). Basically for the purpose of informing users that the firmware cannot execute for some reason (we don't like to give access to the console). I was trying to avoid including stty or setserial, but if this is the accepted way to configure the serial port it's not a big deal ;-) For each of the three uarts, the device tree has the following line: current-speed = 0; /* Filled in by U-Boot */ Checking current U-Boot code, I believe this comment is simply wrong. I cannot see any part in the canyonlands / or generic 4xx infrastructure that fixes up these properties. Maybe Stefan can comment on this though. Interesting...I also tried manually entering a value here, but it didn't seem to have any effect. Maybe it just isn't used? Sorry for the silly question! I don;t think its a silly question, but I also think that you do not need the configuration ;) Cheers Detlev Thanks for your response! Regards, Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot]automatic reset of variables to defaults
Dear Dennis Borgmann, In message 4ec52bd7.2090...@googlemail.com you wrote: I am experiencing a problem concerning variables being set and later getting lost. It is impossible to comment on this without knowing _anything_ about your system - which exact version of U-boot you are running (well, obviously it is an ot-of-tree port, so it's twice impossible to help), which CPU / SoC tthis is, which board, etc. These are the steps, that I take: [code] setenv OS_SDRAM 0x2100 This makes no sense to me, as none of the mainline versions of U-Boot uses such a setting. Sometimes, the bootloader looses this configuration and resets its variable OS_SDRAM back to its default value. Once, the bootloader has What are the exact circumstances and especially the exct error messages when this happens? Where is the environment stored on your board? [In NOR or NAND flash or ... ?] Are you using redundant environment? 1. What else might be the cause of this? We don't know your code, so how could we comment? 2. How could I prevent u-boot from resetting to its default value? We don;t understand the nature of the problem, so how could we recommend a cure? 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 HANDLE WITH EXTREME CARE: This Product Contains Minute Electrically Charged Particles Moving at Velocities in Excess of Five Hundred Million Miles Per Hour. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Efika: Configure additional regulators for HDMI output
2011/11/17 Marek Vasut marek.va...@gmail.com Jana, you have efikamx and I can get you HDMI cable. Can you recheck tomorrow ? M Ok, I can. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodians - please lend a hand
Hi Stefano, On 11/16/2011 07:51 PM, Wolfgang Denk wrote: Wolfgang, Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. I have tried with a couple of patches (network related), and then I wanted to test if push works. As u-boot-staging should be open for all custodians, I was expecting I should use the same mechanism, and then I tried with: git push ssh://gu-...@git.denx.de/u-boot-staging sba...@denx.de ...but the new branch sba...@denx.de is now part of u-boot-imx, not u-boot-staging ! Where is the mistake ? Indeed - this is because of the setup of the custodian trees. The git action is directly coupled to the user account so the account gu-imx will _only_ be able to work inside that tree. Effectively, the directory part of the URL is discarded... The correct usage is of course as Wolfgang points out through the gu-staging user. Best wishes Detlev -- Due to the change in scope, STUN has also been renamed from Simple Traversal of UDP through NAT to Session Traversal Utilities for NAT. The acronym remains STUN, which is all anyone ever remembers anyway.-- rfc5389 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 2/4] gpio: Replace ARM gpio.h with the common API in include/asm-generic
On Fri, Nov 11, 2011 at 5:07 PM, Kim Phillips kim.phill...@freescale.com wrote: On Fri, 11 Nov 2011 15:55:36 -0600 Joe Hershberger joe.hershber...@ni.com wrote: ARM boards should use the generic GPIO API This means changing gpio to unsigned type Remove the unused gpio_toggle() function which is not part of the API Comment that free should not modify pin state Signed-off-by: Joe Hershberger joe.hershber...@ni.com Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Kim Phillips kim.phill...@freescale.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- I've tested this series on the 8313, and I'm ok with it going in: Acked-by: Kim Phillips kim.phill...@freescale.com I need an ack from the ARM GPIO guys to apply it though (assuming it is to go through 83xx). It has been Acked by ARM guys several times in several forms. It's pretty straightforward. Not sure if Albert was planning to look at this again. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot]automatic reset of variables to defaults
Hello u-boot users list, I am experiencing a problem concerning variables being set and later getting lost. In order to boot a Linux on a quite small plattform (Eddy CPU: http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I have to reset the variable OS_SDRAM from its initial value of 0x2000 to 0x2100. If I don't do so, the bootloader reports problems extracting my kernel. This must be due to my kernel being bigger than expected by u-boot. These are the steps, that I take: [code] setenv OS_SDRAM 0x2100 saveenv reset [/code] Anyway, this way, it works fine. Sometimes, the bootloader looses this configuration and resets its variable OS_SDRAM back to its default value. Once, the bootloader has reset this value, it cannot boot anymore(well, of course not, since I had to manually alter this value in order to make it boot my linux). Annoyingly, I cannot surely reproduce this error. I tried rebooting it over 3 days in 2-minute-steps and the error won't occur. In addition, I tried giving random input to the console of u-boot for 3 days (again in 2-minute-steps) and still the error won't come up. Probably something's overwriting your uboot in ram. Anyway, is the board supported mainline? Two questions: 1. What else might be the cause of this? 2. How could I prevent u-boot from resetting to its default value? I'd be happy for any kind of help. Best regards, Dennis Try getting mainline support for the board, that way you'll have the latest fixes. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot]automatic reset of variables to defaults
On 11/17/2011 10:46 AM, Dennis Borgmann wrote: Hello u-boot users list, I am experiencing a problem concerning variables being set and later getting lost. This sounds like your environment variables in flash got erased or corrupted. The question is why. Where is your u-boot env being saved? Normal flash? I2C-attached flash? Other? (I2C flash is inherently less robust than we like due to weaknesses in the protocol.) I am assuming normal flash... * Do you have flash write protection enabled (prevents inadvertent flash scribbling, especially a problem if your linux or programs are not stable). * Do you understand your flash memory layout (can you draw a diagram of it)? Is something like a flash file system inadvertently overlayed on top of the u-boot env? If you have a flash file system inadvertently configured to use the same memory space as your u-boot env, it will randomly overwrite it based on file activity. * Do you use linux utilities to read/write your u-boot env? When the failure occurs, what does the memory dump of the actual u-boot flash storage area look like? Quite often the overwrite pattern leaves valuable clues as to who did it. * If it is all 0xFF, someone just erased it. * If some bits are set to zero that should be ones, someone probably did an inadvertent write to the memory (writing a '0' to a '1' bit turns it to a '0', writing a '0' or '1' to a '0' bit doesn't change it). * Does it look like file data? [snip] Annoyingly, I cannot surely reproduce this error. I tried rebooting it over 3 days in 2-minute-steps and the error won't occur. In addition, I tried giving random input to the console of u-boot for 3 days (again in 2-minute-steps) and still the error won't come up. We've all been there and feel your pain. :-( Two questions: 1. What else might be the cause of this? Someone (likely software, possibly hardware) is corrupting or erasing your u-boot env storage in flash. 2. How could I prevent u-boot from resetting to its default value? Fix whoever is doing the scribbling. There is no other way. I'd be happy for any kind of help. Best regards, Dennis Good luck, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
Hi Thierry, * Stefano Babic wrote: On 11/17/2011 08:56 AM, Thierry Reding wrote: I had actually set Doug Anderson diand...@chromium.org on Cc because he was involved with the initial patch but for some reason he got stripped from Cc. Does anybody know why this is happening? Probably Doug has received the first e-mail. I noted that git send-email strips the CC addresses (maybe to avoid SPAM ?), but the e-mail is sent anyway. I don't think git send-email is stripping the Cc header because I've seen it work properly for other mailing lists. Perhaps the mailing list software is the culprit here? Could it be that it strips people that are subscribed (and will receive the mails anyway) but not those that aren't subscribed? Not that Tom Warren wasn't stripped from Cc. Actually I know that sometimes there are such phenomena on the mailing list, but as yet I failed to find a reason for it. What I saw in the past is that the CC field of individual mails sent to individual subscribers has a reduced CC field with respect to the original mail, i.e. a mail I received had a stripped header compared to what is in the archives. I will try to look into this when I find some time. Cheers Detlev -- Whatever you do will be insignificant, but it is very important that you do it. -- Mahatma Gandhi -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] arm:exynos4:samsung:nuri Support for NURI target.
This patch adds support for Samsung's Exynos4 Nuri reference board. New exynos4_nuri board has been added to boards.cfg Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes for v2: - MAINTAINERS file updated - CONFIG_MACH_TYPE added - hw_revision routine Changes for v3: - Entry to MAINTAINERS file added to preserve an alphabethical order - Redefinition of MACH_TYPE removed at exynos4_nuri.h - Code cleanup (dead spaces removed) Changes for v4: - get_ram_size() check added to dram_init() - Use of MACH_TYPE_NURI defined at ./arch/arm/include/asm/mach-types.h instead of a hard coded value - Comments correction ./tools/checkpatch.pl - total: 0 errors, 0 warnings, 875 lines checked NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE --- MAINTAINERS|4 + board/samsung/nuri/Makefile| 45 board/samsung/nuri/lowlevel_init.S | 395 board/samsung/nuri/nuri.c | 208 +++ boards.cfg |1 + include/configs/exynos4_nuri.h | 210 +++ 6 files changed, 863 insertions(+), 0 deletions(-) create mode 100644 board/samsung/nuri/Makefile create mode 100644 board/samsung/nuri/lowlevel_init.S create mode 100644 board/samsung/nuri/nuri.c create mode 100644 include/configs/exynos4_nuri.h diff --git a/MAINTAINERS b/MAINTAINERS index 576fea8..aa1fc15 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -724,6 +724,10 @@ Valentin Longchamp valentin.longch...@keymile.com km_kirkwood ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) +Łukasz Majewski l.majew...@samsung.com + + exynos4_nuriARM ARMV7 (S5PC210 SoC) + Nishanth Menon n...@ti.com omap3_sdp3430 ARM ARMV7 (OMAP3xx SoC) diff --git a/board/samsung/nuri/Makefile b/board/samsung/nuri/Makefile new file mode 100644 index 000..27566de --- /dev/null +++ b/board/samsung/nuri/Makefile @@ -0,0 +1,45 @@ +# +# Copyright (C) 2010 Samsung Electronics +# Minkyu Kang mk7.k...@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 as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +COBJS-y := nuri.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/nuri/lowlevel_init.S b/board/samsung/nuri/lowlevel_init.S new file mode 100644 index 000..67635bb --- /dev/null +++ b/board/samsung/nuri/lowlevel_init.S @@ -0,0 +1,395 @@ +/* + * Lowlevel setup for universal board based on S5PC210 + * + * Copyright (C) 2010 Samsung Electronics + * 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 as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include config.h
Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().
* Doug Anderson wrote: Agreed--I see myself in the CC from the start. That leaves me really confused. Thierry pgptqQ3sZUSiB.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sbc8548 build broken?
Hello, I downloaded the ELDK 4.2 and installed it. I got the u-boot source from git://git.denx.de/u-boot-mpc85xx.git. When I try to build u-boot for sbc8548 I get the following error: arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute': /home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375: undefined reference to `fsl_ddr_get_dimm_params' make: *** [u-boot] Error 1 Any help or advice is appreciated. Thanks, Robert Hurdle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: allow to export only selected variables
Dear Wolfgang Denk,
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -125,7 +125,7 @@ static int env_print(char *name)
}
/* print whole list */
- len = hexport_r(env_htab, '\n',res, 0);
+ len = hexport_r(env_htab, '\n',res, 0, 0, NULL);
if (len 0) {
puts(res);
Here you extended the function signature by adding 2 new arguments and
therefore you had to touch 12 existing function calls so to add the
default values for the new args.
In my previous patches, I had renamed the sibling himport_r() function
to himport_ex() with the 2 extra args and reimplemented himport_r() as a
wrapper, so to maintain compatibility with the existing code.
Just to realize now that, after some reworking, there is only one
function call to the original himport_r() left.
I'm going to get rid of this renaming.
I mean: completely opposite approaches... funny, huh?
Best,
Gerlando Falauto
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SSBI driver
Hi I am trying to implement a SSBI driver for a board. . The driver is meant to be portable to multiple boards by the same vendor. Keeping this in mind 1)Would drivers/misc/ be the right location to implement this driver? 2)If not can I make a ($vendor)-common in the cpu directory to implement the driver given that the driver is going to be applicable for multiple socs by the same vendor. ie have something like the below. have arch/arm/cpu/armv7/($vendor)-common arch/arm/cpu/armv7/($SOC). I believe there is already precedent for this? Any input is appreciated. Thanks Hanumant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sbc8548 build broken?
Dear Robert Hurdle, In message 5498e86a4a68b14a8a06d0380640d04a016d217a6...@atca01em01.adsi.aitech.ent you wrote: I downloaded the ELDK 4.2 and installed it. I got the u-boot source from git://git.denx.de/u-boot-mpc85xx.git. When I try to build u-boot for sbc8548 I get the following error: arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute': /home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375: undefined reference to `fsl_ddr_get_dimm_params' make: *** [u-boot] Error 1 I cannot confirm this - using current top of tree I get: + MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG + BUILD_DIR=/work/wd/tmp-ppc + ./MAKEALL sbc8548 Configuring for sbc8548 board... textdata bss dec hex filename 1999288956 24576 233460 38ff4 /work/wd/tmp-ppc/u-boot - SUMMARY Boards compiled: 1 -- 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 Pig: An animal (Porcus omnivorous) closely allied to the human race by the splendor and vivacity of its appetite, which, however, is in- ferior in scope, for it balks at pig.- Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: allow to export only selected variables
Dear Wolfgang Denk,
--- a/include/search.h
+++ b/include/search.h
@@ -91,7 +91,8 @@ extern int hstrstr_r(const char *__match, int __last_idx,
ENTRY ** __retval,
extern int hdelete_r(const char *__key, struct hsearch_data *__htab);
extern ssize_t hexport_r(struct hsearch_data *__htab,
- const char __sep, char **__resp, size_t __size);
+ const char __sep, char **__resp, size_t __size,
+ int argc, char * const argv[]);
extern int himport_r(struct hsearch_data *__htab,
const char *__env, size_t __size, const char __sep,
diff --git a/lib/hashtable.c b/lib/hashtable.c
index 6895550..b7ba341 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -478,7 +478,8 @@ static int cmpkey(const void *p1, const void *p2)
}
ssize_t hexport_r(struct hsearch_data *htab, const char sep,
- char **resp, size_t size)
+ char **resp, size_t size,
+ int argc, char * const argv[])
{
ENTRY *list[htab-size];
char *res, *p;
What happened to please indent with TABs only?
Have I missed something, perhaps?
Thank you,
Gerlando Falauto
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SSBI driver
Dear hanumant, In message 4ec55809.2090...@codeaurora.org you wrote: I am trying to implement a SSBI driver for a board. . The driver is meant to be portable to multiple boards by the same vendor. Maybe you would get more help if you explained what SSBI might be. Is it: SSBISingle Scope Background Investigation SSBISpecies-Specific Biological Information SSBISalomon Smith Barney Inc. (bank) SSBIStichting Stimulering Bedrijfsmatig Imkeren If you happen to mean Single-Wire Serial Bus Interface then you should probably use the more common name 1-wire. 1)Would drivers/misc/ be the right location to implement this driver? I would expect to find such drivers in drivers/w1/ as used in Linux. 2)If not can I make a ($vendor)-common in the cpu directory to implement the driver given that the driver is going to be applicable for multiple socs by the same vendor. ie have something like the below. That makes no sense. If in doubt, look at the organization of the Linux tree. There such code is in drivers/w1/ and I see no reason why we would have to do different. 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 you're not part of the solution, you're part of the problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: allow to export only selected variables
Dear Gerlando Falauto,
In message 4ec55b4f.4060...@keymile.com you wrote:
ssize_t hexport_r(struct hsearch_data *htab, const char sep,
-char **resp, size_t size)
+char **resp, size_t size,
+int argc, char * const argv[])
{
ENTRY *list[htab-size];
char *res, *p;
What happened to please indent with TABs only?
Have I missed something, perhaps?
Yes, you missed this error in the initial code review :-)
[Unfortunaltely I haven't found yet a way to convince Lindent or
similar to use only TABs in places like that. Hints welcome.]
Please feel free to submit cleanup-patches.
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
Wenn das dann in die Hose geht, nehme ich es auf meine Kappe.
-- Rudi Völler, 15. Nov 2003
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SSBI driver
Dear hanumant, please always keep the mailing list on Cc: In message 4ec561a4.8050...@codeaurora.org you wrote: If you happen to mean Single-Wire Serial Bus Interface then you should probably use the more common name 1-wire. Thanks. Yes it is Single-Wire Serial Bus Interface. ... Yes, now that you suggest this I do think this would be more appropriate. Though looking at the u-boot master branch, I don't find any drivers/w1. We don't have generic 1-wire drivers yet. The only one I'm aware of is a custom driver deeply embedded into the code of ESD's CPCI405 board (see board/esd/cpci405/cpci405.c). Do you suggest I create a w1 directory based on the linux kernel implementation and add my 1-wire (ssbi) driver to it. Yes. 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 something is different, it's either better or worse, and usually both.- Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sbc8548 build broken?
Dear Robert Hurdle, please do not top-post / full quote. And always make sure to keep the mailing list on cc: In message 5498e86a4a68b14a8a06d0380640d04a016d217a6...@atca01em01.adsi.aitech.ent you wrote: Thank you for checking it. What does ... using current top of tree mean? Top of tree of the master branch of the mainline repository, see http://git.denx.de/?p=u-boot.git;a=summary So be specific, git commit 0562219 2011-11-17 14:27:11 +0100 tools: checkpatch.pl from Linux added to tools 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 bad reputation UNIX has gotten is totally undeserved, laid on by people who don't understand, who have not gotten in there and tried anything. -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] board/amcc/taihu/flash.c: Fix GCC 4.6 build warnings
Fix:
flash.c: In function 'flash_erase_1':
flash.c:514:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]
flash.c: In function 'flash_erase_2':
flash.c:956:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Stefan Roese s...@denx.de
---
total: 0 errors, 0 warnings, 46 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE
0003-board-amcc-taihu-flash.c-Fix-GCC-4.6-build-warnings.patch has no obvious
style problems and is ready for submission.
board/amcc/taihu/flash.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/board/amcc/taihu/flash.c b/board/amcc/taihu/flash.c
index e9fbbb1..63968a4 100644
--- a/board/amcc/taihu/flash.c
+++ b/board/amcc/taihu/flash.c
@@ -511,7 +511,7 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
{
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE
*) (info-start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
- int flag, prot, sect, l_sect;
+ int flag, prot, sect;
int i;
if ((s_first 0) || (s_first s_last)) {
@@ -542,8 +542,6 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
printf(\n);
}
- l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
@@ -569,7 +567,6 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
addr[CONFIG_SYS_FLASH_ADDR1] =
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE)
0x00300030; /* sector erase */
}
- l_sect = sect;
/*
* Wait for each sector to complete, it's more
* reliable. According to AMD Spec, you must
@@ -953,7 +950,7 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
{
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE
*) (info-start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
- int flag, prot, sect, l_sect;
+ int flag, prot, sect;
int i;
if ((s_first 0) || (s_first s_last)) {
@@ -984,8 +981,6 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
printf(\n);
}
- l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
@@ -1011,7 +1006,6 @@ static int flash_erase_2(flash_info_t * info, int
s_first, int s_last)
addr[CONFIG_SYS_FLASH_CHAR_ADDR1] =
(CONFIG_SYS_FLASH_WORD_SIZE) 0x;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE)
0x30303030; /* sector erase */
}
- l_sect = sect;
/*
* Wait for each sector to complete, it's more
* reliable. According to AMD Spec, you must
--
1.7.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] board/amcc/common/flash.c: Fix GCC 4.6 build warning
Fix:
In file included from flash.c:45:0:
../common/flash.c: In function 'flash_erase':
../common/flash.c:399:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Stefan Roese s...@denx.de
---
total: 0 errors, 0 warnings, 46 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE
0001-board-amcc-common-flash.c-Fix-GCC-4.6-build-warning.patch has no obvious
style problems and is ready for submission.
board/amcc/common/flash.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/board/amcc/common/flash.c b/board/amcc/common/flash.c
index 8f23375..1960fc1 100644
--- a/board/amcc/common/flash.c
+++ b/board/amcc/common/flash.c
@@ -396,7 +396,7 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
{
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE
*) (info-start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
- int flag, prot, sect, l_sect;
+ int flag, prot, sect;
int i;
if ((s_first 0) || (s_first s_last)) {
@@ -427,8 +427,6 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
printf(\n);
}
- l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
@@ -454,7 +452,6 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
addr[CONFIG_SYS_FLASH_ADDR1] =
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE)
0x00300030; /* sector erase */
}
- l_sect = sect;
/*
* Wait for each sector to complete, it's more
* reliable. According to AMD Spec, you must
@@ -825,7 +822,7 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
{
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE
*) (info-start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
- int flag, prot, sect, l_sect;
+ int flag, prot, sect;
int i;
if ((s_first 0) || (s_first s_last)) {
@@ -856,8 +853,6 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
printf(\n);
}
- l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
@@ -883,7 +878,6 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
addr[CONFIG_SYS_FLASH_ADDR1] =
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE)
0x00300030; /* sector erase */
}
- l_sect = sect;
/*
* Wait for each sector to complete, it's more
* reliable. According to AMD Spec, you must
--
1.7.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] board/amcc/yucca/flash.c: Fix GCC 4.6 build warnings
Fix:
flash.c: In function 'flash_erase_1':
flash.c:425:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]
flash.c: In function 'flash_erase_2':
flash.c:834:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Stefan Roese s...@denx.de
---
total: 0 errors, 0 warnings, 46 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE
0002-board-amcc-yucca-flash.c-Fix-GCC-4.6-build-warnings.patch has no obvious
style problems and is ready for submission.
board/amcc/yucca/flash.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/board/amcc/yucca/flash.c b/board/amcc/yucca/flash.c
index 20b6af9..ab513f9 100644
--- a/board/amcc/yucca/flash.c
+++ b/board/amcc/yucca/flash.c
@@ -422,7 +422,7 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
{
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE
*) (info-start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
- int flag, prot, sect, l_sect;
+ int flag, prot, sect;
int i;
if ((s_first 0) || (s_first s_last)) {
@@ -449,8 +449,6 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
printf(\n);
- l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
@@ -476,7 +474,6 @@ int flash_erase(flash_info_t * info, int s_first, int
s_last)
addr[CONFIG_SYS_FLASH_ADDR1] =
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE)
0x00300030; /* sector erase */
}
- l_sect = sect;
/*
* Wait for each sector to complete, it's more
* reliable. According to AMD Spec, you must
@@ -831,7 +828,7 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
{
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE
*) (info-start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
- int flag, prot, sect, l_sect;
+ int flag, prot, sect;
int i;
if ((s_first 0) || (s_first s_last)) {
@@ -858,8 +855,6 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
printf(\n);
- l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
@@ -885,7 +880,6 @@ static int flash_erase_2(flash_info_t * info, int s_first,
int s_last)
addr[CONFIG_SYS_FLASH_ADDR1] =
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE)
0x00300030; /* sector erase */
}
- l_sect = sect;
/*
* Wait for each sector to complete, it's more
* reliable. According to AMD Spec, you must
--
1.7.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] checkpatch compliance
On 10/08/2011 12:28 AM, Joe Hershberger wrote: Hi Wolfgang, I'm attempting to make the files I touched in several recent patch-series chechkpatch.pl compliant. I've hit several cases which fail and probably shouldn't. For each of these cases, should the warning / error just be ignored or reported to checkpatch maintainers or altered some other way? What is wrong with something like: ERROR: do not initialise statics to 0 or NULL #35: FILE: serial.c:32: +static struct serial_device *serial_devices = NULL; ERROR: do not initialise statics to 0 or NULL #36: FILE: serial.c:33: +static struct serial_device *serial_current = NULL; Since it's a bootloader, should we also ignore it with: --ignore INITIALISED_STATIC Or maybe not? Thanks, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about baud rate
Hi Dan, Why doe you want to setup this parameters from the outside? Really only the serial device used for a console needs to be setup by firmware. All other serial devices should be initialized by the user space programs using them. I would like my startup script to cat messages to ttyS1, as well as to the console (ttyS0). Basically for the purpose of informing users that the firmware cannot execute for some reason (we don't like to give access to the console). I was trying to avoid including stty or setserial, but if this is the accepted way to configure the serial port it's not a big deal ;-) Personally I believe that every software task should setup as much as possible from what it knows to be needed for its own work. For a serial program this includes setting the baud rate and the communications parameter like 8/n/1. For each of the three uarts, the device tree has the following line: current-speed = 0; /* Filled in by U-Boot */ Checking current U-Boot code, I believe this comment is simply wrong. I cannot see any part in the canyonlands / or generic 4xx infrastructure that fixes up these properties. Maybe Stefan can comment on this though. Interesting...I also tried manually entering a value here, but it didn't seem to have any effect. Maybe it just isn't used? This may very well be the case. An answer can probably be found on the linux ppc mailing list[1] ;) Sorry for the silly question! I don;t think its a silly question, but I also think that you do not need the configuration ;) Cheers Detlev Thanks for your response! You're welcome! Detlev [1] http://dir.gmane.org/gmane.linux.ports.ppc64.devel PowerPC developers ML linuxppc-...@ozlabs.org -- Every time history repeats itself the price goes up. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodians - please lend a hand
On Thu, Nov 17, 2011 at 12:19 PM, Detlev Zundel d...@denx.de wrote: Hi Stefano, On 11/16/2011 07:51 PM, Wolfgang Denk wrote: Wolfgang, Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. I have tried with a couple of patches (network related), and then I wanted to test if push works. As u-boot-staging should be open for all custodians, I was expecting I should use the same mechanism, and then I tried with: git push ssh://gu-...@git.denx.de/u-boot-staging sba...@denx.de ...but the new branch sba...@denx.de is now part of u-boot-imx, not u-boot-staging ! Where is the mistake ? Indeed - this is because of the setup of the custodian trees. The git action is directly coupled to the user account so the account gu-imx will _only_ be able to work inside that tree. Effectively, the directory part of the URL is discarded... The correct usage is of course as Wolfgang points out through the gu-staging user. Might I humbly suggest that the custodians just push changes to a separate branch in their own trees? It should be effectively the same, but without everyone possibly hitting the same repository at the same time... Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] checkpatch compliance
Dear Gerlando Falauto, In message 4ec56a2e.2000...@keymile.com you wrote: What is wrong with something like: ERROR: do not initialise statics to 0 or NULL #35: FILE: serial.c:32: +static struct serial_device *serial_devices = NULL; ERROR: do not initialise statics to 0 or NULL #36: FILE: serial.c:33: +static struct serial_device *serial_current = NULL; Since it's a bootloader, should we also ignore it with: Why? Why don't you just follow the advise and remove the redundant initializers? 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 you know anything? I should have thought anyone knows that who knows anything about anything... - Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodians - please lend a hand
Dear Andy, In message cakwjmd4anjg05fmrs+dhmzq6k-rnalwvkp2-y5t5pujyasz...@mail.gmail.com you wrote: Might I humbly suggest that the custodians just push changes to a separate branch in their own trees? It should be effectively the same, I'd prefer to have it in one central location. This also makes it easier for others to check what's already present there. but without everyone possibly hitting the same repository at the same time... On the day where you see performance problems because too many custodians try to push too many patches to u-boot-staging simultaneously I will rent a faster server. Promised :-) 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 As a general rule, the freedom of any people can be judged by the volume of their laughter. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload
On Thu, Nov 17, 2011 at 2:26 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Gabe, On 17/11/11 21:11, Gabe Black wrote: On Thu, Nov 17, 2011 at 1:43 AM, Graeme Russ graeme.r...@gmail.com mailto:graeme.r...@gmail.com wrote: Hi Gabe, On 17/11/11 11:27, Gabe Black wrote: Add a target for running u-boot as a coreboot payload in boards.cfg. Signed-off-by: Gabe Black gabebl...@chromium.org [snip] As mentioned by others before, there is no reason to have these as discrete patches - Please merge into a single 'Add coreboot payload' Ok. Since there are more patches here than I sent out previously and one big patch seemed like it was more than exactly one complete logical change I wanted to find out how these should be merged. If they should all be merged, then that answers the question. Well, if a given patch is meaningless without another, they really should be combined. Of course there are exceptions, like adding a new driver - The code for it gets added in one patch, and the usage in a board in another Is there any real reason to reference 'chromebook-x86'? I don't follow. I'm not referencing it, that's what we're calling our board since it's an x86 chromebook. I mean, if this is 'generic', why is there a reference to the chromebook? The way it's ended up, the coreboot CPU is generic to coreboot, the board is generic to chromebooks, and the config is either generic to chromebooks or, if we decide we need it to be, specialized per specific chromebook. And finally, what is the plan for motherboard specific coreboot variants? We haven't worked out all the details, but our current working plan is that coreboot itself will be specialized per board and that U-Boot will stay fairly generic and be specialized as needed using the device tree. We may find that a single version of U-Boot with a superset of drivers is too big and we need to have different configs for each variant. This probably won't work in and of itself without a major overhaul of the U-Boot driver architecture :) Boards will need their own config for Ethernet drivers for example This is working just fine so far, actually. It may not scale and we won't be able to have more than one kind of certain things, but in the mean time it's working for us. We are aware of these potential/eventual problems though. Gabe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] checkpatch compliance
On Thursday 17 November 2011 15:10:22 Gerlando Falauto wrote: On 10/08/2011 12:28 AM, Joe Hershberger wrote: Hi Wolfgang, I'm attempting to make the files I touched in several recent patch-series chechkpatch.pl compliant. I've hit several cases which fail and probably shouldn't. For each of these cases, should the warning / error just be ignored or reported to checkpatch maintainers or altered some other way? What is wrong with something like: ERROR: do not initialise statics to 0 or NULL #35: FILE: serial.c:32: +static struct serial_device *serial_devices = NULL; ERROR: do not initialise statics to 0 or NULL #36: FILE: serial.c:33: +static struct serial_device *serial_current = NULL; newer gcc is smart enough to put these into .bss. i think older ones were not and put these into .data. in either case, the initialization is redundant (by virtue of the static), so i'd just drop the = NULL. -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
