[U-Boot] [PATCH] powerpc/mpc85xx: The end address of the bss in the SPL should be 4byte alignment
From: Ying Zhang There will clear the BSS in the function clear_bss(), the reset address of the BSS started from the __bss_start, and increased by four-byte increments, finally stoped depending on the adress is equal to the _bss_end. If the end address __bss_end is not alignment to 4byte, it will be an infinite loop. The end address of the bss should be 4byte aligned. Signed-off-by: Ying Zhang --- arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds index dff2398..154438b 100644 --- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds +++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds @@ -1,5 +1,5 @@ /* - * (C) Copyright 2006 + * (C) Copyright 2013 * Wolfgang Denk, DENX Software Engineering, w...@denx.de * * Copyright 2009 Freescale Semiconductor, Inc. @@ -98,5 +98,6 @@ SECTIONS *(.sbss*) *(.bss*) } + . = ALIGN(4); __bss_end = .; } -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/mpc85xx: The end address of the bss in the SPL should be 4byte alignment
From: Ying Zhang There will clear the BSS in the function clear_bss(), the reset address of the BSS started from the __bss_start, and increased by four-byte increments, finally stoped depending on the adress is equal to the _bss_end. If the end address __bss_end is not alignment to 4byte, it will be an infinite loop. The end address of the bss should be 4byte aligned. This patch is on top of the patch "powerpc/mpc85xx: support application without resetvec segment in the linker script". Signed-off-by: Ying Zhang --- arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds index dff2398..154438b 100644 --- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds +++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds @@ -1,5 +1,5 @@ /* - * (C) Copyright 2006 + * (C) Copyright 2013 * Wolfgang Denk, DENX Software Engineering, w...@denx.de * * Copyright 2009 Freescale Semiconductor, Inc. @@ -98,5 +98,6 @@ SECTIONS *(.sbss*) *(.bss*) } + . = ALIGN(4); __bss_end = .; } -- 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 1/2] power: exynos-tmu: fix warnings and clean up code
Hello Minkyu, On 23 April 2013 08:08, Simon Glass wrote: > On Fri, Apr 12, 2013 at 9:43 PM, Naveen Krishna Ch > wrote: > > On 6 April 2013 03:51, Naveen Krishna Chatradhi > > wrote: > >> From: Naveen Krishna Chatradhi > >> > >> This patch does the folowing > >> 1. change the data types for unsigned int variable to unsigned > >> 2. change the tmu_base type to struct exynos5_tmu_reg * > >> 3. Add timer functionality for get_cur_temp() > >> 4. error handling in the get_tmu_fdt_values() > >> 5. Add check for curr_temp reading > >> 6. some cosmotic changes. > >> > >> Signed-off-by: Naveen Krishna Chatradhi > >> Reviewed-by: Vadim Bendebury > > Acked-by: Simon Glass > Any update on this patch. Simon has given an ACK for this patch a while ago. -- Shine bright, (: Nav :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] mx31pdk: copy SPL directly, not using relocate_code.
Signed-off-by: Albert ARIBAUD
---
Changes in v2:
- dropped relocate_code() call from mx31pdk SPL
board/freescale/mx31pdk/mx31pdk.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/board/freescale/mx31pdk/mx31pdk.c
b/board/freescale/mx31pdk/mx31pdk.c
index 49158bd..4f6cfee 100644
--- a/board/freescale/mx31pdk/mx31pdk.c
+++ b/board/freescale/mx31pdk/mx31pdk.c
@@ -39,7 +39,21 @@ DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_SPL_BUILD
void board_init_f(ulong bootflag)
{
- relocate_code(CONFIG_SPL_TEXT_BASE);
+ /*
+* copy ourselves from where we are running to where we were
+* linked at. Use ulong pointers as all addresses involved
+* are 4-byte-aligned.
+*/
+ ulong *start_ptr, *end_ptr, *link_ptr, *run_ptr, *dst;
+ asm volatile ("ldr %0, =_start" : "=r"(start_ptr));
+ asm volatile ("ldr %0, =_end" : "=r"(end_ptr));
+ asm volatile ("ldr %0, =board_init_f" : "=r"(link_ptr));
+ asm volatile ("adr %0, board_init_f" : "=r"(run_ptr));
+ for (dst = start_ptr; dst < end_ptr; dst++)
+ *dst = *(dst+(run_ptr-link_ptr));
+ /*
+* branch to nand_boot's link-time address.
+*/
asm volatile("ldr pc, =nand_boot");
}
#endif
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] Factorize ARM relocate_code instances
This series replaces all instances of relocate_code in various start.S files from the ARM architecture with a single instance in arch/arm/lib/relocate.S. This is done in steps, each step keeping the whole of ARM U-Boot buildable and runnable and touching as little code as necessary. 1. Drop mx31pdk SPL call to relocate_code In SPL of mx31pdk, board_init_f calls relocate_code to move SPL from the NAND read buffer to SRAM. This move is not a relocation and is thus better implemented as a simple ad hoc copy loop. 2. Drop tx25 SPL call to relocate_code Same as mx31pdk. 3. Prevent all SPLs from assembling relocate_code Now that no SPL uses relocate_code any more, remove it completely from SPL builds by putting it entirely between #ifndef CONFIG_SPL_BUILD and #endif preprocessor conditional. 4. Actual factorization of relocate_code Remove all instances of relocate_code from start.S and create a new file, arch/arm/lib/relocate.S, to provide the new single instance of relocate_code. The only non-trivial change is that for PXA25X, a call to unlock (actually disable) dcache is moved from before relocating to after relocating. As this cache is either locked-as-RAM or disabled, but never used as actual DDR cache, this move has no performance effect on relocation and no functional impact either. Changes in v2: - dropped relocate_code() call from mx31pdk SPL - dropped relocate_code() call from tx25 SPL - dropped all relocate_code instances from SPL builds - use ENTRY / ENDPROC macros - preserve PXA25X dcache unlocking Albert ARIBAUD (4): mx31pdk: copy SPL directly, not using relocate_code. tx25: copy SPL directly, not using relocate_code. arm: do not compile relocate_code() for SPL builds arm: factorize relocate_code routine arch/arm/cpu/arm1136/start.S | 81 --- arch/arm/cpu/arm1176/start.S | 77 - arch/arm/cpu/arm720t/start.S | 77 - arch/arm/cpu/arm920t/start.S | 77 - arch/arm/cpu/arm925t/start.S | 77 - arch/arm/cpu/arm926ejs/start.S| 81 --- arch/arm/cpu/arm946es/start.S | 77 - arch/arm/cpu/arm_intcm/start.S| 77 - arch/arm/cpu/armv7/start.S| 78 -- arch/arm/cpu/ixp/start.S | 77 - arch/arm/cpu/pxa/start.S | 96 +++- arch/arm/cpu/s3c44b0/start.S | 77 - arch/arm/cpu/sa1100/start.S | 77 - arch/arm/lib/Makefile |1 + arch/arm/lib/relocate.S | 111 + board/freescale/mx31pdk/mx31pdk.c | 16 +- board/karo/tx25/tx25.c| 16 +- 17 files changed, 151 insertions(+), 1022 deletions(-) create mode 100644 arch/arm/lib/relocate.S -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] tx25: copy SPL directly, not using relocate_code.
Signed-off-by: Albert ARIBAUD
---
Changes in v2:
- dropped relocate_code() call from tx25 SPL
board/karo/tx25/tx25.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 2952eba..461e21f 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -35,7 +35,21 @@ DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_SPL_BUILD
void board_init_f(ulong bootflag)
{
- relocate_code(CONFIG_SPL_TEXT_BASE);
+ /*
+* copy ourselves from where we are running to where we were
+* linked at. Use ulong pointers as all addresses involved
+* are 4-byte-aligned.
+*/
+ ulong *start_ptr, *end_ptr, *link_ptr, *run_ptr, *dst;
+ asm volatile ("ldr %0, =_start" : "=r"(start_ptr));
+ asm volatile ("ldr %0, =_end" : "=r"(end_ptr));
+ asm volatile ("ldr %0, =board_init_f" : "=r"(link_ptr));
+ asm volatile ("adr %0, board_init_f" : "=r"(run_ptr));
+ for (dst = start_ptr; dst < end_ptr; dst++)
+ *dst = *(dst+(run_ptr-link_ptr));
+ /*
+* branch to nand_boot's link-time address.
+*/
asm volatile("ldr pc, =nand_boot");
}
#endif
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] arm: do not compile relocate_code() for SPL builds
Signed-off-by: Albert ARIBAUD --- Changes in v2: - dropped all relocate_code instances from SPL builds arch/arm/cpu/arm1136/start.S | 11 +++ arch/arm/cpu/arm1176/start.S | 11 +-- arch/arm/cpu/arm720t/start.S | 11 +-- arch/arm/cpu/arm920t/start.S | 12 +--- arch/arm/cpu/arm925t/start.S | 11 +-- arch/arm/cpu/arm926ejs/start.S | 11 +++ arch/arm/cpu/arm946es/start.S | 11 +-- arch/arm/cpu/arm_intcm/start.S | 11 +-- arch/arm/cpu/armv7/start.S |6 ++ arch/arm/cpu/ixp/start.S | 11 +-- arch/arm/cpu/pxa/start.S |8 ++-- arch/arm/cpu/s3c44b0/start.S | 11 +-- arch/arm/cpu/sa1100/start.S| 11 +-- 13 files changed, 55 insertions(+), 81 deletions(-) diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index ccea2d5..1eec2e0 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -104,10 +104,6 @@ _TEXT_BASE: _bss_start_ofs: .word __bss_start - _start -.globl _image_copy_end_ofs -_image_copy_end_ofs: - .word __image_copy_end - _start - .globl _bss_end_ofs _bss_end_ofs: .word __bss_end - _start @@ -173,6 +169,7 @@ next: /*--*/ +#ifndef CONFIG_SPL_BUILD /* * void relocate_code(addr_moni) * @@ -195,7 +192,6 @@ copy_loop: cmp r0, r2 /* until source end address [r2]*/ blo copy_loop -#ifndef CONFIG_SPL_BUILD /* * fix .rel.dyn relocations */ @@ -233,14 +229,13 @@ fixnext: add r2, r2, #8 /* each rel.dyn entry is 8 bytes */ cmp r2, r3 blo fixloop -#endif relocate_done: bx lr -#ifndef CONFIG_SPL_BUILD - +_image_copy_end_ofs: + .word __image_copy_end - _start _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index f20da8e..3c2a52c 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -112,10 +112,6 @@ _TEXT_BASE: _bss_start_ofs: .word __bss_start - _start -.globl _image_copy_end_ofs -_image_copy_end_ofs: - .word __image_copy_end - _start - .globl _bss_end_ofs _bss_end_ofs: .word __bss_end - _start @@ -225,6 +221,7 @@ skip_tcmdisable: /*--*/ +#ifndef CONFIG_SPL_BUILD /* * void relocate_code(addr_moni) * @@ -247,7 +244,6 @@ copy_loop: cmp r0, r2 /* until source end address [r2]*/ blo copy_loop -#ifndef CONFIG_SPL_BUILD /* * fix .rel.dyn relocations */ @@ -285,12 +281,13 @@ fixnext: add r2, r2, #8 /* each rel.dyn entry is 8 bytes */ cmp r2, r3 blo fixloop -#endif relocate_done: bx lr +_image_copy_end_ofs: + .word __image_copy_end - _start _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: @@ -298,6 +295,8 @@ _rel_dyn_end_ofs: _dynsym_start_ofs: .word __dynsym_start - _start +#endif + .globl c_runtime_cpu_setup c_runtime_cpu_setup: diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S index 9facc7e..983f8ad 100644 --- a/arch/arm/cpu/arm720t/start.S +++ b/arch/arm/cpu/arm720t/start.S @@ -101,10 +101,6 @@ _TEXT_BASE: _bss_start_ofs: .word __bss_start - _start -.globl _image_copy_end_ofs -_image_copy_end_ofs: - .word __image_copy_end - _start - .globl _bss_end_ofs _bss_end_ofs: .word __bss_end - _start @@ -155,6 +151,7 @@ reset: /*--*/ +#ifndef CONFIG_SPL_BUILD /* * void relocate_code(addr_moni) * @@ -177,7 +174,6 @@ copy_loop: cmp r0, r2 /* until source end address [r2]*/ blo copy_loop -#ifndef CONFIG_SPL_BUILD /* * fix .rel.dyn relocations */ @@ -215,12 +211,13 @@ fixnext: add r2, r2, #8 /* each rel.dyn entry is 8 bytes */ cmp r2, r3 blo fixloop -#endif relocate_done: mov pc, lr +_image_copy_end_ofs: + .word __image_copy_end - _start _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: @@ -228,6 +225,8 @@ _rel_dyn_end_ofs: _dynsym_start_ofs: .word __dynsym_start - _start +#endif + .globl c_runtime_cpu_setup c_runtime_cpu_setup: diff --git a/arch/arm/cpu/arm920t/start.S b/arch/arm/cpu/arm920t/start.S index 6250025..889329f 100644 --- a/arch/arm/cpu/arm920t/start.S +++ b/arch/arm/cpu/arm920t/start.S @@ -89,10 +89,6 @@ _TEXT_BASE: _bss_start_ofs: .word __bss_start - _start -.globl _image_copy_end_ofs -_ima
[U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
Replace all relocate_code routines from ARM start.S files
with a single instance in file arch/arm/lib/relocate.S.
For PXA, this requires moving the dcache unlocking code
from within relocate_code into c_runtime_cpu_setup.
Signed-off-by: Albert ARIBAUD
---
Changes in v2:
- use ENTRY / ENDPROC macros
- preserve PXA25X dcache unlocking
arch/arm/cpu/arm1136/start.S | 76 ---
arch/arm/cpu/arm1176/start.S | 76 ---
arch/arm/cpu/arm720t/start.S | 76 ---
arch/arm/cpu/arm920t/start.S | 75 ---
arch/arm/cpu/arm925t/start.S | 76 ---
arch/arm/cpu/arm926ejs/start.S | 76 ---
arch/arm/cpu/arm946es/start.S | 76 ---
arch/arm/cpu/arm_intcm/start.S | 76 ---
arch/arm/cpu/armv7/start.S | 76 ---
arch/arm/cpu/ixp/start.S | 76 ---
arch/arm/cpu/pxa/start.S | 92 -
arch/arm/cpu/s3c44b0/start.S | 76 ---
arch/arm/cpu/sa1100/start.S| 76 ---
arch/arm/lib/Makefile |1 +
arch/arm/lib/relocate.S| 111
15 files changed, 121 insertions(+), 994 deletions(-)
create mode 100644 arch/arm/lib/relocate.S
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 1eec2e0..edf249d 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -169,82 +169,6 @@ next:
/*--*/
-#ifndef CONFIG_SPL_BUILD
-/*
- * void relocate_code(addr_moni)
- *
- * This function relocates the monitor code.
- */
- .globl relocate_code
-relocate_code:
- mov r6, r0 /* save addr of destination */
-
- adr r0, _start
- subsr9, r6, r0 /* r9 <- relocation offset */
- beq relocate_done /* skip relocation */
- mov r1, r6 /* r1 <- scratch for copy_loop */
- ldr r3, _image_copy_end_ofs
- add r2, r0, r3 /* r2 <- source end address */
-
-copy_loop:
- ldmia r0!, {r10-r11} /* copy from source address [r0]*/
- stmia r1!, {r10-r11} /* copy to target address [r1]*/
- cmp r0, r2 /* until source end address [r2]*/
- blo copy_loop
-
- /*
-* fix .rel.dyn relocations
-*/
- ldr r0, _TEXT_BASE /* r0 <- Text base */
- ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */
- add r10, r10, r0/* r10 <- sym table in FLASH */
- ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */
- add r2, r2, r0 /* r2 <- rel dyn start in FLASH */
- ldr r3, _rel_dyn_end_ofs/* r3 <- rel dyn end ofs */
- add r3, r3, r0 /* r3 <- rel dyn end in FLASH */
-fixloop:
- ldr r0, [r2]/* r0 <- location to fix up, IN FLASH!
*/
- add r0, r0, r9 /* r0 <- location to fix up in RAM */
- ldr r1, [r2, #4]
- and r7, r1, #0xff
- cmp r7, #23 /* relative fixup? */
- beq fixrel
- cmp r7, #2 /* absolute fixup? */
- beq fixabs
- /* ignore unknown type of fixup */
- b fixnext
-fixabs:
- /* absolute fix: set location to (offset) symbol value */
- mov r1, r1, LSR #4 /* r1 <- symbol index in .dynsym */
- add r1, r10, r1 /* r1 <- address of symbol in table */
- ldr r1, [r1, #4]/* r1 <- symbol value */
- add r1, r1, r9 /* r1 <- relocated sym addr */
- b fixnext
-fixrel:
- /* relative fix: increase location by offset */
- ldr r1, [r0]
- add r1, r1, r9
-fixnext:
- str r1, [r0]
- add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
- cmp r2, r3
- blo fixloop
-
-relocate_done:
-
- bx lr
-
-_image_copy_end_ofs:
- .word __image_copy_end - _start
-_rel_dyn_start_ofs:
- .word __rel_dyn_start - _start
-_rel_dyn_end_ofs:
- .word __rel_dyn_end - _start
-_dynsym_start_ofs:
- .word __dynsym_start - _start
-
-#endif
-
.globl c_runtime_cpu_setup
c_runtime_cpu_setup:
diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
index 3c2a52c..65292bc 100644
--- a/arch/arm/cpu/arm1176/start.S
+++ b/arch/arm/cpu/arm1176/start.S
@@ -221,82 +221,6 @@ skip_tcmdisable:
/*--*/
-#ifndef CONFIG_SPL_BUILD
-/*
- * void relocate_code(addr_moni)
- *
- * This function relocate
Re: [U-Boot] [PATCH v2 0/4] Factorize ARM relocate_code instances
On Tue, 14 May 2013 11:50:26 +0200, Albert ARIBAUD wrote: > This series replaces all instances of relocate_code in > various start.S files from the ARM architecture with a > single instance in arch/arm/lib/relocate.S. Additional (read: late) note: I have dropped the 'make some symbols compiler-generated' part of the series, as this is not needed to factorize relocation_code per se and I want to keep things simple. I'll reintroduce the compiler-generated symbols stuff as part of a later patch series about optimizing relocate_code -- that will go to [NEXT] since we're outside the merge window now. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add support for Congatec Conga-QEVAl board
Add minimal support (only boot from mmc device) for the Congatec Conga-QEVAl Evaluation Carrier Board with a conga-Qmx6 module. Signed-off-by: Leo Sartre --- Rework of the first version of the patch. All unnecessary code was removed from the board file to offer only boot from mmc. Copyright where restored (sorry for the last patch). MAINTAINERS |4 + board/congatec/cgtqmx6/Makefile | 42 board/congatec/cgtqmx6/README| 28 ++ board/congatec/cgtqmx6/cgtqmx6.c | 181 ++ boards.cfg |1 + include/configs/cgtqmx6.h| 197 ++ 6 files changed, 453 insertions(+) create mode 100644 board/congatec/cgtqmx6/Makefile create mode 100644 board/congatec/cgtqmx6/README create mode 100644 board/congatec/cgtqmx6/cgtqmx6.c create mode 100644 include/configs/cgtqmx6.h diff --git a/MAINTAINERS b/MAINTAINERS index 643a5ac..b61484b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -889,6 +889,10 @@ Steve Sakoman omap3_overo ARM ARMV7 (OMAP3xx SoC) +Leo Sartre + + cgtqmx6 i.MX6Q + Jens Scharsig eb_cpux9k2 ARM920T (AT91RM9200 SoC) diff --git a/board/congatec/cgtqmx6/Makefile b/board/congatec/cgtqmx6/Makefile new file mode 100644 index 000..a17603e --- /dev/null +++ b/board/congatec/cgtqmx6/Makefile @@ -0,0 +1,42 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# (C) Copyright 2013 Adeneo Embedded +# +# 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 := cgtqmx6.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/congatec/cgtqmx6/README b/board/congatec/cgtqmx6/README new file mode 100644 index 000..12e6b28 --- /dev/null +++ b/board/congatec/cgtqmx6/README @@ -0,0 +1,28 @@ +U-Boot for the Congatec Conga-QEVAl Evaluation Carrier board + +This file contains information for the port of U-Boot to the Congatec +Conga-QEVAl Evaluation Carrier board. + +1. Boot source, boot from SD card +- + +This version of u-boot works only on the SD card. By default, the +Congatec board can boot only from the SPI-NOR. +But, with the u-boot version provided with the board you can write boot +registers to force the board to reboot and boot from the SD slot. If +"bmode" command is not available from your pre-installed u-boot, these +instruction will produce the same effect: + +conga-QMX6 U-Boot > mw.l 0x20d8040 0x3850 +conga-QMX6 U-Boot > mw.l 0x020d8044 0x1000 +conga-QMX6 U-Boot > reset +resetting ... + +The the board will reboot and, if you burnt your SD correctly the +board will use u-boot that live into the SD + +To copy the resulting u-boot.imx to the SD card: + + sudo dd if=u-boot.imx of=/dev/xxx bs=512 seek=2&&sudo sync + +Note: Replace xxx with the device representing the SD card in your system. diff --git a/board/congatec/cgtqmx6/cgtqmx6.c b/board/congatec/cgtqmx6/cgtqmx6.c new file mode 100644 index 000..d05d529 --- /dev/null +++ b/board/congatec/cgtqmx6/cgtqmx6.c @@ -0,0 +1,185 @@ +/* + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This file is based on mx6qsabrelite.c + * Copyright (C) 2013, Adeneo Embedded + * Leo Sartre, + * + * 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 re
Re: [U-Boot] [PATCH 03/21] fsl_ifc: add support for different IFC bank count
Hi Andy,
Please find my replies in line.
Thanks,
Mingkai
From: Andy Fleming [mailto:aflem...@gmail.com]
Sent: Saturday, May 11, 2013 5:49 AM
To: sun york-R58495; Hu Mingkai-B21284
Cc: Fleming Andy-AFLEMING; U-Boot list
Subject: Re: [U-Boot] [PATCH 03/21] fsl_ifc: add support for different IFC bank
count
On Fri, Mar 22, 2013 at 12:23 PM, York Sun
mailto:york...@freescale.com>> wrote:
From: Mingkai Hu mailto:mingkai...@freescale.com>>
Calculate reserved fields according to IFC bank count
1. Move csor_ext register behind csor register and fix res offset
2. move ifc bank count to config_mpc85xx.h to support 8 bank count
There's no IFC controller instead of eLBC controller on some platforms,
such as MPC8536, P2041, P3041, P4080 etc, so there's no macro definition
for the number of IFC chip select(CONFIG_SYS_FSL_IFC_BANK_COUNT) which
is used in the IFC controller header file fsl_ifc.h on these platforms.
This paragraph is pretty confusing. Is this just explaining that IFC_BANK_COUNT
isn't being defined for devices that don't use IFC? Or is it explaining why you
have to guard fsl_ifc.h with a #ifdef?
[Mingkai] Both. Some devices doesn't use IFC, thus, there's no IFC_BANK_COUNT
for these devices. While some common files include fsl_ifc.h, which needs
IFC_BANK_COUNT definition, that's the reason why I have to guard fsl_ifc.h. I
will change it to the following:
3. Guard fsl_ifc.h with CONFIG_FSL_IFC to eliminate the compile error on some
devices that doesn't have IFC controller.
Signed-off-by: Mingkai Hu
mailto:mingkai...@freescale.com>>
---
arch/powerpc/cpu/mpc85xx/cpu.c|2 +-
arch/powerpc/cpu/mpc8xxx/fsl_ifc.c| 58 -
arch/powerpc/include/asm/config_mpc85xx.h |7
arch/powerpc/include/asm/fsl_ifc.h| 42 +++--
4 files changed, 96 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index df2ab6d..379a7df 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -34,8 +34,8 @@
#include
#include
#include
-#include
#include
+#include
#include
#include
#include
diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
b/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
index 56b319f..f0da355 100644
--- a/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
+++ b/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c
@@ -26,7 +26,7 @@ void print_ifc_regs(void)
int i, j;
printf("IFC Controller Registers\n");
- for (i = 0; i < FSL_IFC_BANK_COUNT; i++) {
+ for (i = 0; i < CONFIG_SYS_FSL_IFC_BANK_COUNT; i++) {
printf("CSPR%d:0x%08X\tAMASK%d:0x%08X\tCSOR%d:0x%08X\n",
i, get_ifc_cspr(i), i, get_ifc_amask(i),
i, get_ifc_csor(i));
@@ -94,4 +94,60 @@ void init_early_memctl_regs(void)
set_ifc_amask(IFC_CS3, CONFIG_SYS_AMASK3);
set_ifc_csor(IFC_CS3, CONFIG_SYS_CSOR3);
#endif
+
+#ifdef CONFIG_SYS_CSPR4_EXT
+ set_ifc_cspr_ext(IFC_CS4, CONFIG_SYS_CSPR4_EXT);
+#endif
+#if defined(CONFIG_SYS_CSPR4) && defined(CONFIG_SYS_CSOR4)
There seem to be a large number of CONFIG options associated with each and
every new bank. It's following the pattern of the existing code, so I'll accept
it, but I can't help but think that some of these config options are entirely
redundant (would we ever have CSPR4, and *not* CSOR4?). This is, admittedly,
based only on a high-level view of the code -- I'm not familiar with the
specifics of the IFC design.
[...]
[Mingkai] These codes are redundant, we can factor this out in another separate
patch.
Prabhakar, what would you say here?
diff --git a/arch/powerpc/include/asm/fsl_ifc.h
b/arch/powerpc/include/asm/fsl_ifc.h
index ba41b73..debcb6b 100644
--- a/arch/powerpc/include/asm/fsl_ifc.h
+++ b/arch/powerpc/include/asm/fsl_ifc.h
@@ -21,6 +21,7 @@
#ifndef __ASM_PPC_FSL_IFC_H
#define __ASM_PPC_FSL_IFC_H
+#ifdef CONFIG_FSL_IFC
#include
#include
[...]
@@ -907,6 +910,22 @@ struct fsl_ifc_gpcm {
u32 res4[0x1F3];
};
+#ifdef CONFIG_SYS_FSL_IFC_BANK_COUNT
+#if (CONFIG_SYS_FSL_IFC_BANK_COUNT <= 8)
+#define CONFIG_SYS_FSL_IFC_CSPR_RES \
+ (0x25 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_AMASK_RES \
+ (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_CSOR_RES \
+ (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_FTIM_RES \
+ (0x90 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 0xc)
These aren't really config values. They are values derived from a CONFIG value,
and they only have local scope (so there's no need for the very global scoping
of the names).
Also... Are these correct? 0x25 is a strange amount of gap in register space.
[Mingkai]They're correct. I've test it on T4, C293QDS and P1010RDB platform
when I submitted this patch.
The value 0x25 is caused by the fact that the 0x25 is represents the length of
cspr (148 bytes) in unit 4 bytes.
Here is the ma
Re: [U-Boot] Your message to U-Boot awaits moderator approval
Hi all, I sent a mail to u-boot@lists.denx.de list and then got this message. I'm the member of u-boot@lists.denx.de. Maillist, and can receive the mail from this list. What's going wrong here? Thanks, Mingkai > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > Sent: Tuesday, May 14, 2013 5:15 PM > To: Hu Mingkai-B21284 > Subject: Your message to U-Boot awaits moderator approval > > Your mail to 'U-Boot' with the subject > > RE: [U-Boot] [PATCH 03/21] fsl_ifc: add support for different IFC > bank count > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > http://lists.denx.de/mailman/confirm/u- > boot/a9058e02baf256a7f7d9e4ed74f7c4d2083ad81d > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. Please see some more comments inline below. On 13/05/13 22:37, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/26/2013 11:59 AM, Lubomir Popov wrote: >> Hi Tom, >> >> On 25/04/13 22:01, Tom Rini wrote: >>> On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote: >>> Signed-off-by: Lubomir Popov >>> >>> Thought I had reviewed this already, sorry. >> Thanks for your review. During the past month U-Boot has changed; I >> have tried to follow as well (although I'm engaged with other >> stuff) and some of your remarks have been already fixed. Please see >> my comments inline below. >> >> Anyway, I guess that a V2 patch shall have to be referenced against >> the current master. Or against u-boot-ti/next? > > OK, sorry for the late reply again. Now that u-boot-arm has resynced > with master, I've also resynced and gotten a pull done. You can use > either u-boot-arm/master or u-boot-ti/master. > >> >> Please note that for this board to work with the defined >> configuration, the following patches are also required >> (unfortunately some are already quite old and might cause >> conflicts): >> >> - Power: http://patchwork.ozlabs.org/patch/232732/. Potential >> conflict with Nishanth Menon's series of March 26, applied to >> u-boot-ti/next. - For I2C support: * The patch series of Apr. 8 >> that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all >> OMAP5 boards). * The modified i2c driver: >> http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5 >> boards). - For USB support: * >> http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 >> boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all >> OMAP5 boards) > > OK. Please make sure these still apply and if not update and re-send. > I think I've already grabbed a few of these. > > [snip] +#define USB_HOST_HS_CLKCTRL_MASK 0x0100D7C0 /* CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define USB_TLL_HS_CLKCTRL_MASK0x0700 /* CM_L3INIT_USB_TLL_HS_CLKCTRL */ >>> >>> Some header please. >> Currently moved to board header. I wondered if a common OMAP header >> wouldn't be more suitable, but having in mind that the utilized USB >> ports (and thus the clocks that should be enabled) vary from board >> to board, perhaps this (i.e. board header) is the best place. > > The masks won't change tho, yes? Common header somewhere. These are in fact not masks, but enable bits (sort of confusing terminology found throughout TI headers). Now renamed to ..._CLKCTRL_EN; staying in board header. > >>> + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); >>> >>> Again, do please. >> This should be (*scrm)->auxclk0. The problem is that the >> omap5_scrm_regs struct (holding the auxclk0 member) has to be >> defined somewhere in the common OMAP5 headers. Sricharan? Or should >> I hack around? > > Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. > > [snip] >>> Ah, since you do have this part already, just update the rest as >>> I had said. >> /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define >> MACH_TYPE_SOM5_EVB 4545 #endif #define CONFIG_MACH_TYPE >> MACH_TYPE_SOM5_EVB >> >> Is this OK? > > I think we'd decided in general to not do ifndef and just always > define it. > +/* Enable all clocks: */ +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define CONFIG_SYS_ENABLE_PADS_ALL /* Enable all PADS for now */ >>> >>> Not allowed. >> Shall see to it. What if one needs to test pins and connections >> during board bring-up, e.g. via gpio commands? > > Then code in what you need at the time, drop later. > > [snip] >>> This is a little un-clear. If MMC will be in mmc like the uEVM, >>> just do so, and if no storage of env, leave it as NOWHERE. >> Cerrently looks like this: /* MMC ENV related defines */ #undef >> CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #und
Re: [U-Boot] [PATCH 2/4] mpc8xx: Correct cast of im_cpm.cp_dparam
Dear Tom, In message <20130513223447.5d86c380...@gemini.denx.de> I wrote: > > In message <1368477117-32669-2-git-send-email-tr...@ti.com> you wrote: > > We must cast this to unsigned char not unsigned short to avoid warnings. > > But this is wrong. We're actually reading a 16 bit value here. > > I think there was previous discussion, and Scott Wodd has a patch out > there, which just needed some minor fixing... Scott's patch is here: http://patchwork.ozlabs.org/patch/210599/ Scott, do you have any plans to submit an updated version? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All men should freely use those seven words which have the power to make any marriage run smoothly: You know dear, you may be right. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/mpc85xx: The end address of the bss in the SPL should be 4byte alignment
Dear ying.zh...@freescale.com, In message <1368520918-22496-1-git-send-email-ying.zh...@freescale.com> you wrote: > From: Ying Zhang You mark this patch as V2 but there is no history of changes. Please always include information what exactly was changed. > There will clear the BSS in the function clear_bss(), the reset address of > the BSS started from the __bss_start, and increased by four-byte increments, > finally stoped depending on the adress is equal to the _bss_end. If the end > address __bss_end is not alignment to 4byte, it will be an infinite loop. > > The end address of the bss should be 4byte aligned. NAK. This is the wrong way to fix this. Instead, the test in the loop should be fixed to test for "<=". > /* > - * (C) Copyright 2006 > + * (C) Copyright 2013 > * Wolfgang Denk, DENX Software Engineering, w...@denx.de And PLEASE do not mess with _my_ copyrights!!! 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 God runs electromagnetics by wave theory on Monday, Wednesday, and Friday, and the Devil runs them by quantum theory on Tuesday, Thurs- day, and Saturday. -- William Bragg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Your message to U-Boot awaits moderator approval
Dear Hu Mingkai-B21284, In message you wrote: > > I sent a mail to u-boot@lists.denx.de list and then got this message. > I'm the member of u-boot@lists.denx.de. Maillist, and can receive the mail > from this list. > > What's going wrong here? Nothing, I think. > > The reason it is being held: > > > > Post by non-member to a members-only list Either you sent the message using a different sender address, or you sent it before your subscription to the ML was completed. 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 Making files is easy under the UNIX operating system. Therefore, users tend to create numerous files using large amounts of file space. It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files. - System V.2 administrator's guide ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support
This series contain the support for Freescale Vybrid MVF600 CPU and MVF600TWR board. Vybird devices are built on an asymmetrical-multiprocessing architecture using ARM cores. The families in the Vybrid portfolio span entry-level, single core Cortex-A class SoCs all the way to dual heterogeneous core SoCs with multiple communication and connectivity options. Part of the Vybrid platform, MVF600 is a dual-core eMPU combining the ARM Cortex A5 and Cortex M4 cores. The u-boot runs on Cortex A5 core. MVF600 shares some IPs with i.MX family, such as FEC,ESDHC,WATCHDOG,I2C,ASRC and ESAI. MVF600 also shares some IPs with ColdFire family, such as eDMA and DSPI. MVF600 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU. More documents for this soc can be found at: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fsrch=1&sr=5 http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRID Changes in v2: - Remove vybrid-common directory - Rename directory name 'vybrid' to 'mvf600' - Add generic.c file - Rewrite get_reset_cause() to make it readable - Remove reset_cpu(), and use the function in imx_watchdog.c - Rewrite timer.c file - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk() - Remove lowlevel_init.S, and add clock_init() in board_early_init_f() - Remove useless CONFIG_SYS_ defines - Move CONFIG_MACH_TYPE to board configuration file - Define C structures and access C structures to set/read registers - Remove useless errata - Remove useless macros - Rename directory name 'arch-vybrid' to 'arch-mvf600' - Use common iomux-v3 code - Use common FEC driver fec_mxc.c - Add watchdog support - Add an entry to MAINTAINERS file - Rename directory name 'vybird' to 'mvf600twr' - Use standard method to set gd->ram_size - Rewrite board_mmc_getcd() function - Remove useless undef - Remove hardcoded IP addresses and MAC addresses - Move CONFIG_MACH_TYPE to board configuration file Alison Wang (6): arm: mvf600: Add Vybrid MVF600 CPU support arm: mvf600: Add IOMUX support for Vybrid MVF600 arm: mvf600: Add FEC support for Vybrid MVF600 arm: mvf600: Add watchdog support for Vybrid MVF600 arm: mvf600: Add uart support for Vybrid MVF600 arm: mvf600: Add basic support for Vybrid MVF600TWR board MAINTAINERS | 4 ++ Makefile| 2 +- arch/arm/cpu/armv7/mvf600/Makefile | 42 +++ arch/arm/cpu/armv7/mvf600/generic.c | 309 arch/arm/cpu/armv7/mvf600/timer.c | 144 ++ arch/arm/imx-common/Makefile| 2 +- arch/arm/imx-common/iomux-v3.c | 6 ++ arch/arm/include/asm/arch-mvf600/clock.h| 38 ++ arch/arm/include/asm/arch-mvf600/crm_regs.h | 170 arch/arm/include/asm/arch-mvf600/imx-regs.h | 201 arch/arm/include/asm/arch-mvf600/mvf_pins.h | 92 arch/arm/include/asm/imx-common/iomux-v3.h | 18 + board/freescale/mvf600twr/Makefile | 39 +++ board/freescale/mvf600twr/imximage.cfg | 35 ++ board/freescale/mvf600twr/mvf600twr.c | 403 + boards.cfg | 1 + drivers/net/fec_mxc.c | 6 +- drivers/serial/Makefile | 1 + drivers/serial/serial_lpuart.c | 161 ++ drivers/watchdog/Makefile | 2 +- include/configs/mvf600twr.h | 147 ++ 21 files changed, 1819 insertions(+), 4 deletions(-) create mode 100644 arch/arm/cpu/armv7/mvf600/Makefile create mode 100644 arch/arm/cpu/armv7/mvf600/generic.c create mode 100644 arch/arm/cpu/armv7/mvf600/timer.c create mode 100644 arch/arm/include/asm/arch-mvf600/clock.h create mode 100644 arch/arm/include/asm/arch-mvf600/crm_regs.h create mode 100644 arch/arm/include/asm/arch-mvf600/imx-regs.h create mode 100644 arch/arm/include/asm/arch-mvf600/mvf_pins.h create mode 100644 board/freescale/mvf600twr/Makefile create mode 100644 board/freescale/mvf600twr/imximage.cfg create mode 100644 board/freescale/mvf600twr/mvf600twr.c create mode 100644 drivers/serial/serial_lpuart.c create mode 100644 include/configs/mvf600twr.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] arm: mvf600: Add Vybrid MVF600 CPU support
This patch adds generic codes to support Freescale's Vybrid MVF600 CPU. It aligns Vybrid MVF600 platform with i.MX platform. As there are some differences between MVF600 and i.MX platforms, the specific codes are in the arch/arm/cpu/armv7/mvf600 directory. Signed-off-by: Alison Wang --- Changes in v2: - Remove vybrid-common directory - Rename directory name 'vybrid' to 'mvf600' - Add generic.c file - Rewrite get_reset_cause() to make it readable - Remove reset_cpu(), and use the function in imx_watchdog.c - Rewrite timer.c file - Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk() - Remove lowlevel_init.S, and add clock_init() in board_early_init_f() - Remove useless CONFIG_SYS_ defines - Move CONFIG_MACH_TYPE to board configuration file - Define C structures and access C structures to set/read registers - Remove useless errata - Remove useless macros - Rename directory 'arch-vybrid' to 'arch-mvf600' Makefile| 2 +- arch/arm/cpu/armv7/mvf600/Makefile | 42 arch/arm/cpu/armv7/mvf600/generic.c | 309 arch/arm/cpu/armv7/mvf600/timer.c | 144 + arch/arm/include/asm/arch-mvf600/clock.h| 38 arch/arm/include/asm/arch-mvf600/crm_regs.h | 170 +++ arch/arm/include/asm/arch-mvf600/imx-regs.h | 201 ++ arch/arm/include/asm/arch-mvf600/mvf_pins.h | 92 + 8 files changed, 997 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/mvf600/Makefile create mode 100644 arch/arm/cpu/armv7/mvf600/generic.c create mode 100644 arch/arm/cpu/armv7/mvf600/timer.c create mode 100644 arch/arm/include/asm/arch-mvf600/clock.h create mode 100644 arch/arm/include/asm/arch-mvf600/crm_regs.h create mode 100644 arch/arm/include/asm/arch-mvf600/imx-regs.h create mode 100644 arch/arm/include/asm/arch-mvf600/mvf_pins.h diff --git a/Makefile b/Makefile index c52f0f1..9df2138 100644 --- a/Makefile +++ b/Makefile @@ -341,7 +341,7 @@ ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(C LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif -ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs)) +ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs mvf600)) LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o endif diff --git a/arch/arm/cpu/armv7/mvf600/Makefile b/arch/arm/cpu/armv7/mvf600/Makefile new file mode 100644 index 000..9232cd4 --- /dev/null +++ b/arch/arm/cpu/armv7/mvf600/Makefile @@ -0,0 +1,42 @@ +# +# Copyright 2013 Freescale Semiconductor, Inc. +# +# 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$(SOC).o + +COBJS += generic.o +COBJS += timer.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +all: $(obj).depend $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv7/mvf600/generic.c b/arch/arm/cpu/armv7/mvf600/generic.c new file mode 100644 index 000..f21ce73 --- /dev/null +++ b/arch/arm/cpu/armv7/mvf600/generic.c @@ -0,0 +1,309 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * 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 +#include +#include +#include +#include +#include +#ifdef CONFIG_FSL_ESDHC +#include +#endif + +#ifdef CONFIG_FSL_ESDHC +DECLARE_GLOBAL_DATA
[U-Boot] [PATCH v2 2/6] arm: mvf600: Add IOMUX support for Vybrid MVF600
This patch adds the IOMUX support for Vybrid MVF600 platform. There is a little difference for IOMUXC module between MVF600 and i.MX platform, the muxmode and pad configuration share one 32bit register on MVF600, but they are two independent registers on I.MX platform. A CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. Signed-off-by: Alison Wang --- Changes in v2: - Use common iomux-v3 code arch/arm/imx-common/Makefile | 2 +- arch/arm/imx-common/iomux-v3.c | 6 ++ arch/arm/include/asm/imx-common/iomux-v3.h | 18 ++ 3 files changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile index 8bba8a5..3378931 100644 --- a/arch/arm/imx-common/Makefile +++ b/arch/arm/imx-common/Makefile @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libimx-common.o -ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6)) +ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6 mvf600)) COBJS-y= iomux-v3.o endif ifeq ($(SOC),$(filter $(SOC),mx5 mx6)) diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c index 7fe5ce7..35880c7 100644 --- a/arch/arm/imx-common/iomux-v3.c +++ b/arch/arm/imx-common/iomux-v3.c @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) if (sel_input_ofs) __raw_writel(sel_input, base + sel_input_ofs); +#ifdef CONFIG_IOMUX_SHARE_CONF_REG + if (!(pad_ctrl & NO_PAD_CTRL)) + __raw_writel((mux_mode << PAD_MUX_MODE_SHIFT) | pad_ctrl, + base + pad_ctrl_ofs); +#else if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) __raw_writel(pad_ctrl, base + pad_ctrl_ofs); +#endif } void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list, diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h b/arch/arm/include/asm/imx-common/iomux-v3.h index 0b4e763..7005fde 100644 --- a/arch/arm/include/asm/imx-common/iomux-v3.h +++ b/arch/arm/include/asm/imx-common/iomux-v3.h @@ -121,6 +121,24 @@ typedef u64 iomux_v3_cfg_t; #define PAD_CTL_DSE_40ohm (6 << 3) #define PAD_CTL_DSE_34ohm (7 << 3) +#elif defined(CONFIG_MVF600) + +#define PAD_MUX_MODE_SHIFT 20 + +#definePAD_CTL_PUS_47K_UP (1 << 4) +#definePAD_CTL_PUS_100K_UP (2 << 4) +#define PAD_CTL_PUE(1 << 2) +#define PAD_CTL_PKE(1 << 3) + +#define PAD_CTL_SPEED_HIGH (3 << 12) +#define PAD_CTL_SPEED_MED (1 << 12) + +#define PAD_CTL_DSE_20ohm (7 << 6) +#define PAD_CTL_DSE_25ohm (6 << 6) +#define PAD_CTL_DSE_50ohm (3 << 6) + +#define PAD_CTL_OBE_IBE_ENABLE (3 << 0) + #else #define PAD_CTL_DVS(1 << 13) -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] arm: mvf600: Add FEC support for Vybrid MVF600
This patch adds FEC support for Vybrid MVF600 platform. Add code to use RMII for MVF600. Signed-off-by: Alison Wang --- Changes in v2: - Use common FEC driver fec_mxc.c drivers/net/fec_mxc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 4dbcdca..21e58f4 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -518,7 +518,11 @@ static int fec_open(struct eth_device *edev) u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED; u32 rcr = (readl(&fec->eth->r_cntrl) & ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) | - FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE; + FEC_RCNTRL_MII_MODE; + if (fec->xcv_type == RGMII) + rcr |= FEC_RCNTRL_RGMII; + else if (fec->xcv_type == RMII) + rcr |= FEC_RCNTRL_RMII; if (speed == _1000BASET) ecr |= FEC_ECNTRL_SPEED; else if (speed != _100BASET) -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] arm: mvf600: Add watchdog support for Vybrid MVF600
This patch adds watchdog support for Vybrid MVF600 platform. Signed-off-by: Alison Wang --- Changes in v2: - Add watchdog support - Use reset_cpu() in imx_watchdog.c drivers/watchdog/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 13e7c37..40946df 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -27,7 +27,7 @@ LIB := $(obj)libwatchdog.o COBJS-$(CONFIG_AT91SAM9_WATCHDOG) += at91sam9_wdt.o COBJS-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o -ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6)) +ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 mvf600)) COBJS-y += imx_watchdog.o endif COBJS-$(CONFIG_TNETV107X_WATCHDOG) += tnetv107x_wdt.o -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] arm: mvf600: Add uart support for Vybrid MVF600
This patch adds lpuart support for Vybrid MVF600 platform.
Signed-off-by: TsiChung Liew
Signed-off-by: Alison Wang
---
Changes in v2:
- Define C structures and access C structures to set/read registers
- Change the names to reuse this driver on other platforms
drivers/serial/Makefile| 1 +
drivers/serial/serial_lpuart.c | 161 +
2 files changed, 162 insertions(+)
create mode 100644 drivers/serial/serial_lpuart.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index fbc4e97..bb6559b 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -52,6 +52,7 @@ COBJS-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
COBJS-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
COBJS-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
COBJS-$(CONFIG_ZYNQ_SERIAL) += serial_zynq.o
+COBJS-$(CONFIG_FSL_LPUART) += serial_lpuart.o
ifndef CONFIG_SPL_BUILD
COBJS-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
new file mode 100644
index 000..6ae7f77
--- /dev/null
+++ b/drivers/serial/serial_lpuart.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UART_BASE UART1_BASE
+
+struct lpuart_fsl {
+ u8 ubdh;
+ u8 ubdl;
+ u8 uc1;
+ u8 uc2;
+ u8 us1;
+ u8 us2;
+ u8 uc3;
+ u8 ud;
+ u8 uma1;
+ u8 uma2;
+ u8 uc4;
+ u8 uc5;
+ u8 ued;
+ u8 umodem;
+ u8 uir;
+ u8 reserved;
+ u8 upfifo;
+ u8 ucfifo;
+ u8 usfifo;
+ u8 utwfifo;
+ u8 utcfifo;
+ u8 urwfifo;
+ u8 urcfifo;
+ u8 rsvd[28];
+};
+
+#define US1_TDRE(1 << 7)
+#define US1_RDRF(1 << 5)
+#define UC2_TE (1 << 3)
+#define UC2_RE (1 << 2)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct lpuart_fsl *base = (struct lpuart_fsl *)UART_BASE;
+
+static void lpuart_serial_setbrg(void)
+{
+ u32 clk = mvf_get_clock(MVF_UART_CLK);
+ u16 sbr;
+
+ if (!gd->baudrate)
+ gd->baudrate = CONFIG_BAUDRATE;
+
+ sbr = (u16)(clk / (16 * gd->baudrate));
+ /* place adjustment later - n/32 BRFA */
+
+ __raw_writeb(sbr >> 8, &base->ubdh);
+ __raw_writeb(sbr & 0xff, &base->ubdl);
+}
+
+static int lpuart_serial_getc(void)
+{
+ u8 status;
+
+ while (!(__raw_readb(&base->us1) & US1_RDRF))
+ WATCHDOG_RESET();
+
+ status = __raw_readb(&base->us1);
+ status |= US1_RDRF;
+ __raw_writeb(status, &base->us1);
+
+ return __raw_readb(&base->ud);
+}
+
+static void lpuart_serial_putc(const char c)
+{
+ if (c == '\n')
+ serial_putc('\r');
+
+ while (!(__raw_readb(&base->us1) & US1_TDRE))
+ WATCHDOG_RESET();
+
+ __raw_writeb(c, &base->ud);
+}
+
+/*
+ * Test whether a character is in the RX buffer
+ */
+static int lpuart_serial_tstc(void)
+{
+ if (__raw_readb(&base->urcfifo) == 0)
+ return 0;
+
+ return 1;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int lpuart_serial_init(void)
+{
+ u8 ctrl;
+
+ ctrl = __raw_readb(&base->uc2);
+ ctrl &= ~UC2_RE;
+ ctrl &= ~UC2_TE;
+ __raw_writeb(ctrl, &base->uc2);
+
+ __raw_writeb(0, &base->umodem);
+ __raw_writeb(0, &base->uc1);
+
+ /* provide data bits, parity, stop bit, etc */
+
+ serial_setbrg();
+
+ __raw_writeb(UC2_RE | UC2_TE, &base->uc2);
+
+ return 0;
+}
+
+static struct serial_device lpuart_serial_drv = {
+ .name = "lpuart_serial",
+ .start = lpuart_serial_init,
+ .stop = NULL,
+ .setbrg = lpuart_serial_setbrg,
+ .putc = lpuart_serial_putc,
+ .puts = default_serial_puts,
+ .getc = lpuart_serial_getc,
+ .tstc = lpuart_serial_tstc,
+};
+
+void lpuart_serial_initialize(void)
+{
+ serial_register(&lpuart_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+ return &lpuart_serial_drv;
+}
--
1.8.0
__
[U-Boot] [PATCH v2 6/6] arm: mvf600: Add basic support for Vybrid MVF600TWR board
MVF600TWR is a board based on Vybrid MVF600 SoC. This patch adds basic support for Vybrid MVF600TWR board. Signed-off-by: Alison Wang Signed-off-by: Jason Jin Signed-off-by: TsiChung Liew --- Changes in v2: - Add an entry to MAINTAINERS file - Rename directory name 'vybird' to 'mvf600twr' - Use standard method to set gd->ram_size - Rewrite board_mmc_getcd() function - Remove useless undef - Remove hardcoded IP addresses and MAC addresses - Remove useless CONFIG_SYS_ defines - Define C structures and access C structures to set/read registers - Move CONFIG_MACH_TYPE to board configuration file - Use common iomux-v3 code MAINTAINERS| 4 + board/freescale/mvf600twr/Makefile | 39 board/freescale/mvf600twr/imximage.cfg | 35 +++ board/freescale/mvf600twr/mvf600twr.c | 403 + boards.cfg | 1 + include/configs/mvf600twr.h| 147 6 files changed, 629 insertions(+) create mode 100644 board/freescale/mvf600twr/Makefile create mode 100644 board/freescale/mvf600twr/imximage.cfg create mode 100644 board/freescale/mvf600twr/mvf600twr.c create mode 100644 include/configs/mvf600twr.h diff --git a/MAINTAINERS b/MAINTAINERS index c05433a..d32ac66 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1057,6 +1057,10 @@ Eric Nelson nitrogen6s i.MX6S 512MB nitrogen6s1gi.MX6S 1GB +Alison Wang + + mvf600twr MVF600 + - Unknown / orphaned boards: diff --git a/board/freescale/mvf600twr/Makefile b/board/freescale/mvf600twr/Makefile new file mode 100644 index 000..7416228 --- /dev/null +++ b/board/freescale/mvf600twr/Makefile @@ -0,0 +1,39 @@ +# +# Copyright 2013 Freescale Semiconductor, Inc. +# +# 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 := $(BOARD).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/freescale/mvf600twr/imximage.cfg b/board/freescale/mvf600twr/imximage.cfg new file mode 100644 index 000..33ead0f --- /dev/null +++ b/board/freescale/mvf600twr/imximage.cfg @@ -0,0 +1,35 @@ +/* + * Copyright 2013 Freescale Semiconductor, 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. 51 Franklin Street Fifth Floor Boston, + * MA 02110-1301 USA + * + * Refer docs/README.imxmage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ + +/* image version */ +IMAGE_VERSION 2 + +/* + * Boot Device : one of + * spi, sd (the board has no nand neither onenand) + */ +BOOT_FROM sd diff --git a/board/freescale/mvf600twr/mvf600twr.c b/board/freescale/mvf600twr/mvf600twr.c new file mode 100644 index 000..500ceb8 --- /dev/null +++ b/board/freescale/mvf600twr/mvf600twr.c @@ -0,0 +1,403 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * 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 l
Re: [U-Boot] [PATCH v2] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT
On Tue, May 14, 2013 at 03:52:04AM +, Zhang Ying-B40530 wrote: > -Original Message- > From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini > Sent: Tuesday, May 14, 2013 6:13 AM > To: Zhang Ying-B40530 > Cc: u-boot@lists.denx.de; Wood Scott-B07421; Xie Xiaobo-R63061; Zhang > Ying-B40530 > Subject: Re: [U-Boot] [PATCH v2] common/Makefile: Add new symbol > CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT > > On Mon, May 13, 2013 at 03:07:57PM +0800, ying.zh...@freescale.com wrote: > > > From: Ying Zhang > > > > There will need the environment in SPL for reasons other than network > > support (in particular, hwconfig contains info for how to set up DDR). > > > > Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT in > > common/Makefile. > [snip] > > --- a/common/Makefile > > +++ b/common/Makefile > > @@ -44,7 +44,6 @@ COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_r.o > > COBJS-y += cmd_boot.o > > COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o > > COBJS-y += cmd_help.o > > -COBJS-y += cmd_nvedit.o > > COBJS-y += cmd_version.o > > > > # environment > > @@ -67,7 +66,6 @@ COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o > > COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o > > COBJS-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o > > COBJS-$(CONFIG_ENV_IS_IN_UBI) += env_ubi.o > > -COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o > > > > # command > > COBJS-$(CONFIG_CMD_AMBAPP) += cmd_ambapp.o > > @@ -214,18 +212,16 @@ COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o > > endif > > > > ifdef CONFIG_SPL_BUILD > > -COBJS-y += cmd_nvedit.o > > -COBJS-y += env_common.o > > COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o > > COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += cmd_nvedit.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_attr.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_callback.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o > > COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_common.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o > > endif > > +COBJS-y += cmd_nvedit.o > > +COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o > > COBJS-$(CONFIG_BOUNCE_BUFFER) += bouncebuf.o > > COBJS-y += console.o > > COBJS-y += dlmalloc.o > > Just move the whole CONFIG_ENV_IS_IN.. section down to where we always > build objects, and update the comments in the Makefile in both spots. > [Zhang Ying] > For common lines(for example: cmd_nvedit.o) that shared by the SPL and > non-SPL, > can we move it to public area? So, we can avoid excessive SPL symbols. Right. Re-order things so we're duplicating as little as possible. There's already a bit of needless duplication going on here. > And a3m071 needs to be updated for CONFIG_SPL_ENV_SUPPORT too. Thanks! > [Zhang Ying] > In include/configs/a3m071.h, there was no CONFIG_SPL_NET_SUPPORT to be > defined. > Are you sure to add CONFIG_SPL_ENV_SUPPORT for it? Yes, it uses the environment as part of CONFIG_SPL_OS support rather than CONFIG_SPL_NET_SUPPORT. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mpc8xx: Correct cast of im_cpm.cp_dparam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2013 06:34 PM, Wolfgang Denk wrote: > Dear Tom Rini, > > In message <1368477117-32669-2-git-send-email-tr...@ti.com> you > wrote: >> We must cast this to unsigned char not unsigned short to avoid >> warnings. > > But this is wrong. We're actually reading a 16 bit value here. Oh derp, I was mis-recalling the type rules here. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkji2AAoJENk4IS6UOR1WoPUP/jaVGG2jSUGwsSWqCeWDuPu3 dWzu7CjqA01/pzhKYcJ/EBHTGuWaE0kQR7EHP0jhWFU+S20jIHaLqrRyznBnaHFJ wsqsmyRhzgBEDq6oj6sKJa2OW+iVy6jkPlK3zRQJy9n9PpqdCW2u6b57dtCFq2tf 0f+GQDqwV2v3l5IOCWJfX5VeIJG1udBfKXGm1zNdEgcM8smJMdJsPuUBfUvUkO6d GSPp+G6DQLIwJpCX6LE5LZGCTbZIm5hPgBqds1PhSgy5AupOPwLIBeAjlxjOJ4JD Pp1pAfE9KSGnKJhJ000/24/74WAPOhvHVIn/9q8DPSFJaL/sze3vtnmrWX2WpXmL kujYQVo89iL7KbJmN/OdEsxVImnp6pSahc+od1sZTZQa+6vuBfu8uoRluEmcJLnf 5lMrqg5b+IUdB/pC7UA+w6RG+RZj930U/G+duBvKuUQSqTpNG9GSXA8FXjRToope MlUNpREU9w+pbUpJUMtbA97INzshGOSHyZvZDz1yFP6gJNBK+V+Tkz2P0zv9JC6V UWdrRcuKBZ+6uteKTc1NCukhx2XH90VdVe1y+OhVT9G+mcbTkQo3KQv4FSi7B8Nu jaxutfTve+FWbDTeHSCw5GqrB/GyB5mB4rdOVN1Q8I8GmuBkK4azKnsbccjkWGTJ oHSCaEruXuTw8CqRvRM/ =XAN7 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Mon, May 13, 2013 at 03:02:08PM -0700, Simon Glass wrote: > Hi Tom, > > The following changes since commit bbd0f7e3ba66d288a2f146f1c7797801e04598ae: > > Move FDT_RAMDISK_OVERHEAD from fdt.h to libfdt_env.h (2013-05-10 > 19:04:50 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86.git master > > for you to fetch changes up to 8f0278eab4410de57ea6a32a8e5a50614a28084f: > > x86: Add coreboot timestamps (2013-05-13 13:33:22 -0700) > > > Doug Anderson (2): > bootstage: Copy bootstage strings post-relocation > Call bootstage_relocate() after malloc is initted > > Simon Glass (17): > x86: Remove unused bios/pci code > x86: Remove unused portion of link script > x86: Remove legacy board init code > x86: Declare global_data pointer when it is used > x86: Implement panic output for coreboot > x86: Rationalise kernel booting logic and bootstage > x86: Add TSC timer > x86: Remove old broken timer implementation > x86: Remove ISR timer > x86: Re-enable PCAT timer 2 for beeping > bootstage: Add stubs for new bootstage functions > x86: Enable bootstage for coreboot > bootstage: Allow marking a particular line of code > x86: Fix warning in cmd_ximg.c when CONFIG_GZIP is not defined > x86: config: Enable LZO for coreboot, remove zlib, gzip > x86: Support adding coreboot timestanps to bootstage > x86: Add coreboot timestamps > > arch/x86/cpu/Makefile | 2 +- > arch/x86/cpu/coreboot/coreboot.c | 13 > arch/x86/cpu/coreboot/timestamp.c | 42 +++- > arch/x86/cpu/cpu.c | 5 ++ > arch/x86/cpu/interrupts.c | 2 + > arch/x86/cpu/timer.c | 17 - > arch/x86/cpu/u-boot.lds| 12 > arch/x86/include/asm/arch-coreboot/timestamp.h | 7 ++ > arch/x86/include/asm/init_helpers.h| 9 --- > arch/x86/include/asm/init_wrappers.h | 42 > arch/x86/include/asm/pci.h | 4 -- > arch/x86/include/asm/u-boot-x86.h | 4 ++ > arch/x86/include/asm/u-boot.h | 32 -- > arch/x86/lib/Makefile | 10 +-- > arch/x86/lib/bios.h| 170 > > arch/x86/lib/board.c | 266 > > arch/x86/lib/bootm.c | 8 --- > arch/x86/lib/cmd_boot.c| 2 + > arch/x86/lib/init_helpers.c| 98 > > arch/x86/lib/init_wrappers.c | 164 > --- > arch/x86/lib/pcat_timer.c | 69 +--- > arch/x86/lib/pci.c | 188 > -- > arch/x86/lib/physmem.c | 2 + > arch/x86/lib/relocate.c| 2 + > arch/x86/lib/timer.c | 116 > - > arch/x86/lib/tsc_timer.c | 107 > +++ > arch/x86/lib/zimage.c | 11 ++-- > common/board_r.c | 1 + > common/bootstage.c | 44 + > common/cmd_ximg.c | 2 + > include/bootstage.h| 54 > include/configs/coreboot.h | 18 +- > 32 files changed, 314 insertions(+), 1209 deletions(-) > delete mode 100644 arch/x86/cpu/timer.c > delete mode 100644 arch/x86/include/asm/init_wrappers.h > delete mode 100644 arch/x86/lib/bios.h > delete mode 100644 arch/x86/lib/board.c > delete mode 100644 arch/x86/lib/init_wrappers.c > delete mode 100644 arch/x86/lib/pci.c > delete mode 100644 arch/x86/lib/timer.c > create mode 100644 arch/x86/lib/tsc_timer.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: gadget: Use unaligned access for wMaxPacketSize
> -Original Message- > From: Vivek Gautam [mailto:gautam.vi...@samsung.com] > Sent: Monday, May 13, 2013 12:24 PM > To: u-boot@lists.denx.de > Cc: gautam.vi...@samsung.com; Lukasz Majewski; Piotr Wilczek; Kyungmin > Park; Lukasz Dalek; Marek Vasut > Subject: [PATCH 2/2] usb: gadget: Use unaligned access for > wMaxPacketSize > > Use get_unaligned() while fetching wMaxPacketSize to avoid voilating > any alignment rules. > > Signed-off-by: Vivek Gautam > Cc: Lukasz Majewski > Cc: Piotr Wilczek > Cc: Kyungmin Park > Cc: Lukasz Dalek > Cc: Marek Vasut > --- > > Just did a build test on u-boot-usb/master branch. > Need to be tested further. > > Based on u-boot-usb/next. > > drivers/usb/gadget/f_mass_storage.c |3 ++- > drivers/usb/gadget/pxa25x_udc.c | 13 +++-- > 2 files changed, 9 insertions(+), 7 deletions(-) > Tested 'f_mass_storage.c' on u-boot/samsung. It works fine with or without this patch on Trats2. Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 2013 Plumber's CFP: Fastboot
Dear Mehaffey, John, On Mon, 13 May 2013 23:51:46 +, Mehaffey, John wrote: > I am proposing a microconference on fastboot at the Linux Plumber's > conference 2013 in New Orleans. The goal is to get to sub 1S boot > times for a large (IVI) system using NAND flash. This pushes the > state of the art, and will require innovative solutions in may areas > of Linux plumbing, including bootloader, kernel init, UBI, and > systemd. Beware that the 'fastboot' you're talking about (making Linux boot fast), especially written this way, may easily be confused with 'fastboot', which is the Android-specific protocol to flash a system through USB (see http://en.wikipedia.org/wiki/Android_software_development#Fastboot). Besides this minor comment, I'm looking forward for the notes of this discussion on this very interesting topic. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM v7: Flush icache when executing a program with go
Tom Rini wanted me to post this again. There is no change from previous
version.
I do agree with Wolfgang Denk that this really SHOULD NOT be arch
specific. The only reason why I made this ARMv7 specific is because
blindly calling invalidate_icache_all() from the go command will cause
loud complains on other arches where the icache is not
supported/enabled. The question is what is the correct solution
- Doing it arch specific like this (or other arch aproach?)
- Change invalidate_icache_all() to be silent if the icache is not
enabled/supported?
- Something else?
---
ARM v7 runs with icache enabled. For reliable results the go command
needs to flush the icache before jumping or it may risk running
cached instructions that differ from what currently is in memory.
---
arch/arm/cpu/armv7/Makefile |1 +
arch/arm/cpu/armv7/cmd_boot.c | 37 +
2 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/armv7/cmd_boot.c
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 4fdbee4..da1b5e8 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -31,6 +31,7 @@ COBJS += cache_v7.o
COBJS += cpu.o
COBJS += syslib.o
+COBJS += cmd_boot.o
ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA20),)
SOBJS += lowlevel_init.o
diff --git a/arch/arm/cpu/armv7/cmd_boot.c b/arch/arm/cpu/armv7/cmd_boot.c
new file mode 100644
index 000..6758a55
--- /dev/null
+++ b/arch/arm/cpu/armv7/cmd_boot.c
@@ -0,0 +1,37 @@
+/*
+ * (C) Copyright 2000-2003
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.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
+ */
+
+/*
+ * Misc boot support
+ */
+#include
+#include
+
+#ifdef CONFIG_CMD_GO
+unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
+char * const argv[])
+{
+ invalidate_icache_all();
+ return entry(argc, argv);
+}
+#endif
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: issues for usb keyboard work with OHCI HCD
Hi Marek, On Tuesday, May 14, 2013 4:13:33 AM, Marek Vasut wrote: > Dear Bo Shen, > > > Hi Marek, > > > > On 5/13/2013 23:12, Marek Vasut wrote: > > > Dear Bo Shen, > > > > > >> Hi All, > > >> > > >> On 5/6/2013 11:01, Bo Shen wrote: > > >>> Hi Marek, > > >>> > > >>> On 5/3/2013 21:40, Marek Vasut wrote: > > Dear Bo Shen, > > > > > Hi All, > > > > > > Now, I test usb host support with Atmel boards, for example, > > > > > > at91sam9x5ek board. > > > > > > When test OHCI USB host with usb keyboard. I meet the following > > > > > > issue. > > > --->8--- > > > U-Boot 2013.04-dirty (May 03 2013 - 11:00:34) > > > > > > CPU: AT91SAM9G35 > > > Crystal frequency: 12 MHz > > > CPU clock: 400 MHz > > > Master clock : 133.333 MHz > > > DRAM: 128 MiB > > > WARNING: Caches not enabled > > > NAND: 256 MiB > > > MMC: mci: 0 > > > In:serial > > > Out: serial > > > Err: serial > > > Net: macb0 > > > Hit any key to stop autoboot: 0 > > > U-Boot> usb start > > > (Re)start USB... > > > USB0: scanning bus 0 for devices... 2 USB Device(s) found > > > > > > scanning usb for storage devices... 0 Storage Device(s) > > > found > > > > > > U-Boot> setenv stdin usbkbd > > > U-Boot> ERROR: sohci_submit_job: ENOMEM > > > ERROR: sohci_submit_job failed > > > ... ... > > > (repeat to print these two error line) > > > > So the USB subsystem is leaking memory? Or do you only have too small > > MALLOC > > area? > > >>> > > >>> I am not sure whether USB subsystem is leaking memory. I am digging it. > > >>> > > >>> This issue is not relative with MALLOC area. > > >>> This issue come out when all ptd[i].usb_dev (the maximum value of i is > > >>> 64) is not NULL. Each time to call td_alloc, it will check whether > > >>> ptd[i].usb_dev is NULL (i from 0 to 63), if not find one of > > >>> ptd[i].usb_dev is NULL, then report ENOMEM. > > >> > > >> All clue for this issue? > > > > > > I assume you mean the TDs are all used up then? Are they not free'd ? > > > > Yes, that's true, all TDs are used. Nowhere free them, so I use > > urb_free_priv() to free urb in sohci_return_job() instead of > > td_submit_job(), then it works well. > > Benoit, you were the last one to plumb in it, right? No. That was for EHCI, not OHCI. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/21] fsl_ifc: add support for different IFC bank count
On May 14, 2013, at 3:59, "Hu Mingkai-B21284"
mailto:b21...@freescale.com>> wrote:
Hi Andy,
Please find my replies in line.
Thanks,
Mingkai
There's no IFC controller instead of eLBC controller on some platforms,
such as MPC8536, P2041, P3041, P4080 etc, so there's no macro definition
for the number of IFC chip select(CONFIG_SYS_FSL_IFC_BANK_COUNT) which
is used in the IFC controller header file fsl_ifc.h on these platforms.
This paragraph is pretty confusing. Is this just explaining that IFC_BANK_COUNT
isn't being defined for devices that don't use IFC? Or is it explaining why you
have to guard fsl_ifc.h with a #ifdef?
[Mingkai] Both. Some devices doesn’t use IFC, thus, there’s no IFC_BANK_COUNT
for these devices. While some common files include fsl_ifc.h, which needs
IFC_BANK_COUNT definition, that’s the reason why I have to guard fsl_ifc.h. I
will change it to the following:
3. Guard fsl_ifc.h with CONFIG_FSL_IFC to eliminate the compile error on some
devices that doesn’t have IFC controller.
That's good, thanks
diff --git a/arch/powerpc/include/asm/fsl_ifc.h
b/arch/powerpc/include/asm/fsl_ifc.h
index ba41b73..debcb6b 100644
--- a/arch/powerpc/include/asm/fsl_ifc.h
+++ b/arch/powerpc/include/asm/fsl_ifc.h
@@ -21,6 +21,7 @@
#ifndef __ASM_PPC_FSL_IFC_H
#define __ASM_PPC_FSL_IFC_H
+#ifdef CONFIG_FSL_IFC
#include
#include
[...]
@@ -907,6 +910,22 @@ struct fsl_ifc_gpcm {
u32 res4[0x1F3];
};
+#ifdef CONFIG_SYS_FSL_IFC_BANK_COUNT
+#if (CONFIG_SYS_FSL_IFC_BANK_COUNT <= 8)
+#define CONFIG_SYS_FSL_IFC_CSPR_RES \
+ (0x25 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_AMASK_RES \
+ (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_CSOR_RES \
+ (0x24 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 3)
+#define CONFIG_SYS_FSL_IFC_FTIM_RES \
+ (0x90 - CONFIG_SYS_FSL_IFC_BANK_COUNT * 0xc)
These aren't really config values. They are values derived from a CONFIG value,
and they only have local scope (so there's no need for the very global scoping
of the names).
Also... Are these correct? 0x25 is a strange amount of gap in register space.
[Mingkai]They’re correct. I’ve test it on T4, C293QDS and P1010RDB platform
when I submitted this patch.
The value 0x25 is caused by the fact that the 0x25 is represents the length of
cspr (148 bytes) in unit 4 bytes.
Here is the magic math: 148 / 4 = 37 = 0x25
All that aside, I think we should just define the register offsets to cover all
existing (or even predicted) registers, and make the gap hard-coded as before.
There's no real advantage to specifying only as many as are implemented, and
this method seems ripe for potential bugs in the future.
[Mingkai] I modified the code as follows,
First define the different register space length in bytes as follows:
#define IFC_CSPR_REG_LEN148
#define IFC_AMASK_REG_LEN 140
#define IFC_CSOR_REG_LEN140
#define IFC_FTIM_REG_LEN576
Then in the struct, use the register space length minus the actual used space
and get the reserved space as the red line indicates.
struct fsl_ifc {
u32 ifc_rev;
u32 res1[0x2];
struct {
u32 cspr_ext;
u32 cspr;
u32 res2;
} cspr_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res3[IFC_CSPR_REG_LEN - sizeof(cspr_cs)];
That's a bit clearer. However, it needs to be u8 if you are going to specify
bytes.
struct {
u32 amask;
u32 res4[0x2];
} amask_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res5[IFC_AMASK_REG_LEN - sizeof(amask_cs)];
struct {
u32 csor;
u32 csor_ext;
u32 res6;
} csor_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res7[IFC_CSOR_REG_LEN - sizeof(csor_cs)];
struct {
u32 ftim[4];
u32 res8[0x8];
} ftim_cs[CONFIG_SYS_FSL_IFC_BANK_COUNT];
u32 res9[IFC_FTIM_REG_LEN - sizeof(ftim_cs)];
}
BTW, the patch can’t be applied to your mpc85xx public tree cleanly, so if you
think this modification is ok, I will submit a new patch based on the latest
git tree base.
Ok, thanks!
Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: > Hi Tom, > > I'm currently busy with other work; on the other hand, careful > rebasing shall require some time, especially the Palmas stuff. > What would be the deadline for a V2 submission? > > Meanwhile could you please have a look at the (already old) > http://patchwork.ozlabs.org/patch/232743/? A simple patch, > shall be needed if we enable USB (for the uEVM along with > our board). In general, what are your plans regarding USB > (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? > And again on I2C (.../patch/233823/): what is you final > opinion? I'm confident that this patch is a major improvement > for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. [snip] > + * TODO: Replace this ugly hardcoding with proper defines + > */ + writel(0x0100, 0x4ae0a310); > >>> > >>> Again, do please. > >> This should be (*scrm)->auxclk0. The problem is that the > >> omap5_scrm_regs struct (holding the auxclk0 member) has to be > >> defined somewhere in the common OMAP5 headers. Sricharan? Or should > >> I hack around? > > > > Add it to the most likely struct in the headers. > The entire struct (I call it omap5_scrm_regs in theory, similar to the > corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of > course I could define only the member that I need, but I guess it is > a (responsible) TI job to define hardware descriptors. Or I'm wrong? > Please advise. If I have time, I could do it myself - it's some 27 > registers, almost identical to the OMAP4, and should go into > arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to . Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Wrong RAM Size on Devkit8000
Hi, I'm currently testing u-boot 2013.04 with SPL on a Devkit8000 with 256MB of RAM. Trouble is, it only detects 128MB of RAM. The x-loader found on the NAND detects 256MB and works perfectly with it. I obviously tried to change the mcfg field of the timings structure to be at MICRON_V_MCFG_165(256 << 20), however, while it obviously detects 256MB of RAM, it then crashes quite badly when booting to a userspace (and actually using that much RAM I guess). It works perfectly fine though with only 128MB of RAM, so I think the timings are ok. -- Boot from the NAND, with stock uboot/x-loader from TimLL --- X-Loader 1.41 Starting OS Bootloader... U-Boot 1.3.3-svn (Mar 16 2012 - 17:38:47) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 DevKit8000 Board + LPDDR/NAND DRAM: 256 MB NAND: 512 MiB Using default environment In:serial Out: serial Err: serial Hit space key to stop autoboot: 0 -- Boot from the MMC, using vanilla u-boot 2013.04 - U-Boot SPL 2013.04 (May 14 2013 - 16:12:21) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04 (May 14 2013 - 16:12:21) OMAP3530-GP ES3.1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz OMAP3 DevKit8000 + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 512 MiB MMC: OMAP SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial ethaddr not set, using Die ID Die ID #5917015470c40101a01e Net: dm9000 Hit any key to stop autoboot: 0 Any ideas on how to solve this? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatwrite problem
Hi Tom,
It has become a bit quiet on this thread, but I just made the changes as I
suggested, including some other fixes. Here is what I did:
> Added a check for blkcnt > 0 in mmc_write_blocks (drivers/mmc.c). By doing
> this in the lowest level function, it also solves a hangup if for instance an
> "mmc write" command is given with a block count being 0.
> Solved a checksum issue in fs/fat/fat.c. The mkcksum has const char arguments
> with a size specifier, like "const char name[8]". In the function, it is
> assumed that sizeof(name) will have the value 8, but this is not the case (at
> least not for the compiler I use and I guess not according to ANSI C). This
> causes "long filename checksum errors" for each fat file listed or written.
> Made some changes to fs/fat/fat_write.c. Fixed testing fat_val for
> 0x/0xfff8 and 0xfff/0xff8 by adding the corresponding fatsize in
> the test (as I read in earlier posts) and some changes in debug output.
I have used this for a few weeks now without any mmc and fat related problems
sofar.
I do have a patch file for this. Should I post this with a "Signed-off-by (etc,
etc)", or would you like to receive and review this patch file yourself first?
Regards,
Ruud
-Oorspronkelijk bericht-
Van: Ruud Commandeur
Verzonden: dinsdag 16 april 2013 11:33
Aan: 'Benoît Thébaudeau'; Tom Rini
CC: u-boot@lists.denx.de; Mats K?rrman
Onderwerp: RE: [U-Boot] fatwrite problem
Hi Everyone,
As far as I noticed, set_cluster can be called quite often with a size being
zero. That can indeed be with a file that has a size being an exact multiple
(including 0) of the clustersize, but also for files that are smaller than the
size of one cluster. In that case, the 1st call to set_cluster has a size being
zero:
> fatwrite mmc 0:1 4200 test3 200
writing test3
set_cluster; clustnum: 1487, startsect: 6104, size 0
set_cluster; clustnum: 1487, startsect: 6104, size 512
set_cluster; clustnum: -6, startsect: 132, size 2048
512 bytes written
This was solved by adding the "if(size)" in set_cluster (otherwise the above
test would fail). However: this does not solve all the problems. If I tried to
write a file of 16 bytes, I still got an error. Looking closer at set_cluster,
the 1st call to disk_write( ) has a size being "size / mydata->sect_size". This
would mean that for any file (or file remainder) smaller than the sector size
(typicaly 512 bytes), the fatwrite would fail.
So to my opinion, the actual cause of the problem is in the function
"disk_write( )", that can't be called with a size being zero. That could be
solved by adding tests before calling set_cluster and/or before calling
disk_write from set_cluster, but the safest (and simplest) would be to add this
piece of code to disk_write:
if(nr_blocks == 0) {
return 0;
}
With this change I have been able to write various file sizes so far without
problems (512 bytes, 2048, 2049, 16, 0).
Another option would be to solve this in the cur_dev->block_write function,
being mmc_bwrite( ) for the mmc device. Since his has a do { } while, it will
always call mmc_write_blocks() even if blkcnt equals zero. Maybe even the
mmc_write_blocks would be the best place to fix this...
I will do some further testing here. Meanwhile, please let me know if this
change would make sense to you, and what would be the best place to put it.
Probably the lowest level function, if you would ask me.
Also I would like to know if it would not cause any oher problems according to
your knowledge.
Regards,
Ruud
-Oorspronkelijk bericht-
Van: Benoît Thébaudeau [mailto:benoit.thebaud...@advansee.com]
Verzonden: vrijdag 12 april 2013 23:18
Aan: Tom Rini
CC: Ruud Commandeur; u-boot@lists.denx.de; Mats K?rrman
Onderwerp: Re: [U-Boot] fatwrite problem
Hi Tom,
On Friday, April 12, 2013 10:42:34 PM, Tom Rini wrote:
> On Fri, Apr 12, 2013 at 09:39:19PM +0200, Beno??t Th??baudeau wrote:
> > Hi Tom, Ruud, Mats,
> >
> > On Friday, April 12, 2013 5:12:31 PM, Tom Rini wrote:
> > > On Fri, Apr 12, 2013 at 05:06:35PM +0200, Ruud Commandeur wrote:
> > > > Hi Mats,
> > > >
> > > > Thanks a lot, this seems to solve my problem. Nothing more actualy than
> > > > adding a "if(size)" around the code block of set_sector( ). I could
> > > > have
> > > > thought of that myself, but was not sure if anything else should be
> > > > done
> > > > in this case...
> > >
> > > Since your change sounds slightly different, can you confirm that it
> > > also solves the problem and if so post it as patch with Signed-off-by
> > > and so forth? Thanks!
> > >
> > > >
> > > > Regards,
> > > >
> > > > Ruud
> > > >
> > > > -Oorspronkelijk bericht-
> > > > Van: Mats K?rrman [mailto:mats.karr...@tritech.se]
> > > > Verzonden: vrijdag 12 april 2013 16:11
> > > > Aan: Ruud Commandeur
> > > > CC: u-boot@lists.denx.de
> > > > Onderwerp: RE: fatwrite problem
> > > >
> > > > Hi Ruud,
> > > >
> > > > Ru
Re: [U-Boot] [PATCH v2 1/4] mx31pdk: copy SPL directly, not using relocate_code.
Hi Albert,
On Tuesday, May 14, 2013 11:50:27 AM, Albert ARIBAUD wrote:
> Signed-off-by: Albert ARIBAUD
> ---
> Changes in v2:
> - dropped relocate_code() call from mx31pdk SPL
>
> board/freescale/mx31pdk/mx31pdk.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/board/freescale/mx31pdk/mx31pdk.c
> b/board/freescale/mx31pdk/mx31pdk.c
> index 49158bd..4f6cfee 100644
> --- a/board/freescale/mx31pdk/mx31pdk.c
> +++ b/board/freescale/mx31pdk/mx31pdk.c
> @@ -39,7 +39,21 @@ DECLARE_GLOBAL_DATA_PTR;
> #ifdef CONFIG_SPL_BUILD
> void board_init_f(ulong bootflag)
> {
> - relocate_code(CONFIG_SPL_TEXT_BASE);
> + /*
> + * copy ourselves from where we are running to where we were
> + * linked at. Use ulong pointers as all addresses involved
> + * are 4-byte-aligned.
> + */
> + ulong *start_ptr, *end_ptr, *link_ptr, *run_ptr, *dst;
> + asm volatile ("ldr %0, =_start" : "=r"(start_ptr));
> + asm volatile ("ldr %0, =_end" : "=r"(end_ptr));
Why not __image_copy_start/end instead? I know that the result will be the same
here, but the naming would be more appropriate. The existing u-boot-spl.lds
still gives access to __image_copy_*.
> + asm volatile ("ldr %0, =board_init_f" : "=r"(link_ptr));
> + asm volatile ("adr %0, board_init_f" : "=r"(run_ptr));
> + for (dst = start_ptr; dst < end_ptr; dst++)
> + *dst = *(dst+(run_ptr-link_ptr));
> + /*
> + * branch to nand_boot's link-time address.
> + */
> asm volatile("ldr pc, =nand_boot");
> }
> #endif
> --
> 1.7.10.4
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] tx25: copy SPL directly, not using relocate_code.
Hi Albert,
On Tuesday, May 14, 2013 11:50:28 AM, Albert ARIBAUD wrote:
> Signed-off-by: Albert ARIBAUD
> ---
> Changes in v2:
> - dropped relocate_code() call from tx25 SPL
>
> board/karo/tx25/tx25.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
> index 2952eba..461e21f 100644
> --- a/board/karo/tx25/tx25.c
> +++ b/board/karo/tx25/tx25.c
> @@ -35,7 +35,21 @@ DECLARE_GLOBAL_DATA_PTR;
> #ifdef CONFIG_SPL_BUILD
> void board_init_f(ulong bootflag)
> {
> - relocate_code(CONFIG_SPL_TEXT_BASE);
> + /*
> + * copy ourselves from where we are running to where we were
> + * linked at. Use ulong pointers as all addresses involved
> + * are 4-byte-aligned.
> + */
> + ulong *start_ptr, *end_ptr, *link_ptr, *run_ptr, *dst;
> + asm volatile ("ldr %0, =_start" : "=r"(start_ptr));
> + asm volatile ("ldr %0, =_end" : "=r"(end_ptr));
Same question as for mx31pdk.
> + asm volatile ("ldr %0, =board_init_f" : "=r"(link_ptr));
> + asm volatile ("adr %0, board_init_f" : "=r"(run_ptr));
> + for (dst = start_ptr; dst < end_ptr; dst++)
> + *dst = *(dst+(run_ptr-link_ptr));
> + /*
> + * branch to nand_boot's link-time address.
> + */
> asm volatile("ldr pc, =nand_boot");
> }
> #endif
> --
> 1.7.10.4
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: do not compile relocate_code() for SPL builds
Hi Albert, On Tuesday, May 14, 2013 11:50:29 AM, Albert ARIBAUD wrote: > Signed-off-by: Albert ARIBAUD > --- > Changes in v2: > - dropped all relocate_code instances from SPL builds > > arch/arm/cpu/arm1136/start.S | 11 +++ > arch/arm/cpu/arm1176/start.S | 11 +-- > arch/arm/cpu/arm720t/start.S | 11 +-- > arch/arm/cpu/arm920t/start.S | 12 +--- > arch/arm/cpu/arm925t/start.S | 11 +-- > arch/arm/cpu/arm926ejs/start.S | 11 +++ > arch/arm/cpu/arm946es/start.S | 11 +-- > arch/arm/cpu/arm_intcm/start.S | 11 +-- > arch/arm/cpu/armv7/start.S |6 ++ > arch/arm/cpu/ixp/start.S | 11 +-- > arch/arm/cpu/pxa/start.S |8 ++-- > arch/arm/cpu/s3c44b0/start.S | 11 +-- > arch/arm/cpu/sa1100/start.S| 11 +-- > 13 files changed, 55 insertions(+), 81 deletions(-) > > diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S > index ccea2d5..1eec2e0 100644 > --- a/arch/arm/cpu/arm1136/start.S > +++ b/arch/arm/cpu/arm1136/start.S > @@ -104,10 +104,6 @@ _TEXT_BASE: > _bss_start_ofs: > .word __bss_start - _start > > -.globl _image_copy_end_ofs > -_image_copy_end_ofs: > - .word __image_copy_end - _start > - This change should be mentioned in the commit message, or moved to a separate patch. [...] Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatwrite problem
On Tue, May 14, 2013 at 05:13:44PM +0200, Ruud Commandeur wrote: > Hi Tom, > > It has become a bit quiet on this thread, but I just made the changes as I > suggested, including some other fixes. Here is what I did: > > > Added a check for blkcnt > 0 in mmc_write_blocks (drivers/mmc.c). By doing > > this in the lowest level function, it also solves a hangup if for instance > > an "mmc write" command is given with a block count being 0. > > > Solved a checksum issue in fs/fat/fat.c. The mkcksum has const char > > arguments with a size specifier, like "const char name[8]". In the > > function, it is assumed that sizeof(name) will have the value 8, but this > > is not the case (at least not for the compiler I use and I guess not > > according to ANSI C). This causes "long filename checksum errors" for each > > fat file listed or written. > > > Made some changes to fs/fat/fat_write.c. Fixed testing fat_val for > > 0x/0xfff8 and 0xfff/0xff8 by adding the corresponding fatsize > > in the test (as I read in earlier posts) and some changes in debug output. > > I have used this for a few weeks now without any mmc and fat related problems > sofar. > > I do have a patch file for this. Should I post this with a "Signed-off-by > (etc, etc)", or would you like to receive and review this patch file yourself > first? Please post it with a Signed-off-by line for review on the list, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 2013 Plumber's CFP: Fastboot
On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John wrote: > Hello All, > > I am proposing a microconference on fastboot at the Linux Plumber's > conference 2013 in New Orleans. The goal is to get to sub 1S boot times for a > large (IVI) system using NAND flash. This pushes the state of the art, and > will require innovative solutions in may areas of Linux plumbing, including > bootloader, kernel init, UBI, and systemd. > > Note that fastboot improvements will (generally) help all architectures so I > am not limiting this to automotive systems. > > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more > information or if you want to submit a topic. > > If you want to reply to this message, please trim the cc list! Why trimming the CC? Changing the CC list is a _very_ bad habit. Anyway, a few notes on UBI fastmap. Before we talk about optimizing it we have to make sure that it is stable. Currently it has not much users because embedded folks are a few kernel releases behind. I expect that we'll face some issues (hey it's software!). Instead of making the code more complicated we have to make very sure that it works well. Fastmap got much more complicated than I thought while developing the first proof of concept implementation. We also have to think more about userland support, e.g. making tools like ubinize fastmap aware... User want ready to use fastmap UBI images and not images which have to be converted by the kernel on the very first boot. Sharing UBI EBA table between U-Boot and the kernel would be a nice feature, but we also have to make sure that we can share the EBA table between two kernels (think of kexec). So, a more general solution is needed. -- Thanks, //richard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: lds: Remove libgcc eabi exception handling tables
Hi Michal, On Mon, 13 May 2013 09:45:12 +0200, Michal Simek wrote: > On 05/10/2013 09:07 PM, Albert ARIBAUD wrote: > > Hi Michal, > > > > On Thu, 9 May 2013 11:35:33 +0200, Michal Simek > > wrote: > > > >> Remove ARM eabi exception handling tables (for frame unwinding). > >> AFAICT, u-boot stubs away the frame unwiding routines, so the tables will > >> more or less just consume space. It should be OK to remove them. > >> > >> Signed-off-by: Edgar E. Iglesias > >> Signed-off-by: Michal Simek > >> --- > >> Other options could be to complete u-boot/arch/arm/lib/* so that > >> libgcc routines with exception handling dont get pulled in. Or > >> to avoid user code (like the mentioned patch) which causes external > >> libgcc functions to get pulled in... > > > > Er... which mentioned patch? > > Ah yeah. Let me give you background. > After adding: > "arm: zynq: U-Boot udelay < 1000 FIX" > (sha1: d54cc007878697a92e7f696b71a3eb203c0386e2) > > we have found that new program header is added to u-boot for zynq. > > Program Header: > 0x7001 off0x000405fc vaddr 0x040385fc paddr 0x040385fc align 2**2 > filesz 0x0020 memsz 0x0020 flags r-- > LOAD off0x8000 vaddr 0x0400 paddr 0x0400 align 2**15 > filesz 0x00041240 memsz 0x00041240 flags rwx >STACK off0x vaddr 0x paddr 0x align 2**2 > filesz 0x memsz 0x flags rwx > > Tracing down this we found that uldivmod is used > 27: 0 NOTYPE GLOBAL DEFAULT UND __aeabi_uldivmod > > Based on that Edgar proposed this patch. Ok, so Michal and I just did some fiddling with zynq builds and *exidx* sections. By default the *exidx* sections are between rodata and data, so removing them causes many apparent changes at the binary level. However, builds of zynq based on ARM master with the patch above vs master with a patch mapping *exidx* sections after BSS gives identical binaries. Thus the RFC has no functional effect. Also, ARM EHABI states that [exception] Tables are not required for ABI compliance at the C/Assembler level but are required for C++. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf So as long as we don't put any C++ code in U-Boot (a prospect that I don't see happening any time soon), this RFC is safe and either is a no-op or removes useless bytes from the binary. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/4] usb: ehci: add weak-aliased functions to portsc & tdi
Dear Kuo-Jung Su,
> 2013/5/13 Marek Vasut :
> > Dear Kuo-Jung Su,
> >
> >> 2013/5/13 Marek Vasut :
> >> > Dear Kuo-Jung Su,
> >> >
> >> >> From: Kuo-Jung Su
> >> >>
> >> >> There is at least one non-EHCI compliant controller (i.e. Faraday
> >> >> EHCI) known to implement a non-standard TDI stuff.
> >> >> Futhermore, it not only leave reserved and CONFIGFLAG registers
> >> >> un-implemented but also has their address spaces removed.
> >> >>
> >> >> And thus, we need weak-aliased functions to both TDI stuff
> >> >> and PORTSC registers for interface abstraction.
> >> >>
> >> >> Signed-off-by: Kuo-Jung Su
> >> >> CC: Marek Vasut
> >> >> ---
> >> >>
> >> >> Changes for v6:
> >> >>- Simplify weak aliased function declaration
> >> >>- Drop redundant line feed
> >> >>
> >> >> Changes for v5:
> >> >>- Split up from Faraday EHCI patch
> >> >>
> >> >> Changes for v2 - v4:
> >> >>- See 'usb: ehci: add Faraday USB 2.0 EHCI support'
> >> >>
> >> >> drivers/usb/host/ehci-hcd.c | 91
> >> >>
> >> >> ++- 1 file changed, 55
> >> >> insertions(+), 36 deletions(-)
> >> >>
> >> >> diff --git a/drivers/usb/host/ehci-hcd.c
> >> >> b/drivers/usb/host/ehci-hcd.c index c816878..ae3f2a4 100644
> >> >> --- a/drivers/usb/host/ehci-hcd.c
> >> >> +++ b/drivers/usb/host/ehci-hcd.c
> >> >> @@ -117,10 +117,44 @@ static struct descriptor {
> >> >>
> >> >> };
> >> >>
> >> >> #if defined(CONFIG_EHCI_IS_TDI)
> >> >>
> >> >> -#define ehci_is_TDI()(1)
> >> >> -#else
> >> >> -#define ehci_is_TDI()(0)
> >> >> +# define ehci_is_TDI() (1)
> >> >
> >> > btw you can remove those braces around (1) and (0) below. But I have
> >> > one more question ...
> >>
> >> Got it, thanks
> >>
> >> > [...]
> >> >
> >> >> @@ -609,13 +644,10 @@ ehci_submit_root(struct usb_device *dev,
> >> >> unsigned long pipe, void *buffer, uint32_t *status_reg;
> >> >>
> >> >> struct ehci_ctrl *ctrl = dev->controller;
> >> >>
> >> >> - if (le16_to_cpu(req->index) >
> >> >> CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) { - printf("The
> >> >> request port(%d) is not configured\n", -
> >> >>
> >> >> le16_to_cpu(req->index) - 1);
> >> >>
> >> >> + status_reg = ehci_get_portsc_register(ctrl->hcor,
> >> >> + le16_to_cpu(req->index) - 1);
> >> >> + if (!status_reg)
> >> >
> >> > What happens here if req->index is zero ?
> >> >
> >> > Hint: the above code always does unsigned comparison ...
> >> >
> >> > I think you should make the second argument of
> >> > ehci_get_portsc_register() unsigned short too (as is req->index in
> >> > struct devrequest).
> >>
> >> Sorry, but I'll prefer 'int' over 'unsigned short', since it looks to me
> >> that the u-boot would set 'req->index' to 0 at startup, which results in
> >> a 'port = -1' to be passed to ehci_get_portsc_register().
> >>
> >> And I think '-1' is a better self-explain value, so I'd like to stick
> >> with 'int'
> >
> > Sure, but then the comparison is signed, not unsigned. Besides, it's
> > unnecessary change to the logic of the code. Or did I miss something ?
>
> 1. There is a bug in ehci_submit_root() of usb ehci:
>
> int ehci_submit_root()
> {
> ..
> if (port > CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
> printf("The request port(%d) is not configured\n", port - 1);
> return -1;
> }
> status_reg = (uint32_t *)&ctrl->hcor->or_portsc[port - 1];
> ..
> }
>
> The 'port' is actually a '0' at start-up, so we actually accessed
> a wrong register.
> But fortunately the wrong register actually points to CONFIGFLAG(0x40)
> with a safe value for the following codes.
>
> 2. One of Vivek Gautam's usb patches has altered the logic of usb host
> upon launching 'usb start', if we report a error upon (port - 1 < 0),
> the current u-boot usb would failed to scan ports. (At least it
> failed at Faraday platforms.)
> However it looks to me that it's o.k to report a error upon (port
> - 1 < 0) at old usb ehci stack.
> (i.e. 10 days ago, in master branch of u-boot)
>
> And thus I add a quick check to PATCH v7.
>
> __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port)
> {
> /*
> * The u-boot would somehow set port=-1 at usb start-up,
> * so this quick fix is necessary.
> */
> if (port < 0)
> port = 0;
Maybe we should return fail, no ? Can you pinpoint where does the req->index
(resp. port) get set to -1 ? And which commit introduced this breakage ?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: issues for usb keyboard work with OHCI HCD
Dear Benoît Thébaudeau, > Hi Marek, > > On Tuesday, May 14, 2013 4:13:33 AM, Marek Vasut wrote: > > Dear Bo Shen, > > > > > Hi Marek, > > > > > > On 5/13/2013 23:12, Marek Vasut wrote: > > > > Dear Bo Shen, > > > > > > > >> Hi All, > > > >> > > > >> On 5/6/2013 11:01, Bo Shen wrote: > > > >>> Hi Marek, > > > >>> > > > >>> On 5/3/2013 21:40, Marek Vasut wrote: > > > Dear Bo Shen, > > > > > > > Hi All, > > > > > > > > Now, I test usb host support with Atmel boards, for example, > > > > > > > > at91sam9x5ek board. > > > > > > > > When test OHCI USB host with usb keyboard. I meet the > > > > following > > > > > > > > issue. > > > > --->8--- > > > > U-Boot 2013.04-dirty (May 03 2013 - 11:00:34) > > > > > > > > CPU: AT91SAM9G35 > > > > Crystal frequency: 12 MHz > > > > CPU clock: 400 MHz > > > > Master clock : 133.333 MHz > > > > DRAM: 128 MiB > > > > WARNING: Caches not enabled > > > > NAND: 256 MiB > > > > MMC: mci: 0 > > > > In:serial > > > > Out: serial > > > > Err: serial > > > > Net: macb0 > > > > Hit any key to stop autoboot: 0 > > > > U-Boot> usb start > > > > (Re)start USB... > > > > USB0: scanning bus 0 for devices... 2 USB Device(s) found > > > > > > > > scanning usb for storage devices... 0 Storage Device(s) > > > > found > > > > > > > > U-Boot> setenv stdin usbkbd > > > > U-Boot> ERROR: sohci_submit_job: ENOMEM > > > > ERROR: sohci_submit_job failed > > > > ... ... > > > > (repeat to print these two error line) > > > > > > So the USB subsystem is leaking memory? Or do you only have too > > > small MALLOC > > > area? > > > >>> > > > >>> I am not sure whether USB subsystem is leaking memory. I am digging > > > >>> it. > > > >>> > > > >>> This issue is not relative with MALLOC area. > > > >>> This issue come out when all ptd[i].usb_dev (the maximum value of i > > > >>> is 64) is not NULL. Each time to call td_alloc, it will check > > > >>> whether ptd[i].usb_dev is NULL (i from 0 to 63), if not find one > > > >>> of ptd[i].usb_dev is NULL, then report ENOMEM. > > > >> > > > >> All clue for this issue? > > > > > > > > I assume you mean the TDs are all used up then? Are they not free'd ? > > > > > > Yes, that's true, all TDs are used. Nowhere free them, so I use > > > urb_free_priv() to free urb in sohci_return_job() instead of > > > td_submit_job(), then it works well. > > > > Benoit, you were the last one to plumb in it, right? > > No. That was for EHCI, not OHCI. Hmmm ... I don't have any OHCI device. Bo, maybe you can try tracing it and fixing it? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: gadget: Use unaligned access for wMaxPacketSize
Dear Vivek Gautam, > Use get_unaligned() while fetching wMaxPacketSize to avoid > voilating any alignment rules. > > Signed-off-by: Vivek Gautam > Cc: Lukasz Majewski > Cc: Piotr Wilczek > Cc: Kyungmin Park > Cc: Lukasz Dalek > Cc: Marek Vasut I'll pick both, thanks. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
Hi Albert,
On Tuesday, May 14, 2013 11:50:30 AM, Albert ARIBAUD wrote:
> Replace all relocate_code routines from ARM start.S files
> with a single instance in file arch/arm/lib/relocate.S.
> For PXA, this requires moving the dcache unlocking code
> from within relocate_code into c_runtime_cpu_setup.
>
> Signed-off-by: Albert ARIBAUD
[...]
> diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S
> index 595778a..f9947de 100644
> --- a/arch/arm/cpu/pxa/start.S
> +++ b/arch/arm/cpu/pxa/start.S
> @@ -167,93 +167,19 @@ reset:
> bl _main
>
>
> /*--*/
> -#ifndef CONFIG_SPL_BUILD
> -/*
> - * void relocate_code(addr_moni)
> - *
> - * This function relocates the monitor code.
> - */
> - .globl relocate_code
> -relocate_code:
> - mov r6, r0 /* save addr of destination */
> -
> -/* Disable the Dcache RAM lock for stack now */
> -#ifdef CONFIG_CPU_PXA25X
> - mov r12, lr
> - bl cpu_init_crit
> - mov lr, r12
> -#endif
> -
> - adr r0, _start
> - subsr9, r6, r0 /* r9 <- relocation offset */
> - beq relocate_done /* skip relocation */
> - mov r1, r6 /* r1 <- scratch for copy_loop */
> - ldr r3, _image_copy_end_ofs
> - add r2, r0, r3 /* r2 <- source end address */
> -
> -copy_loop:
> - ldmia r0!, {r10-r11} /* copy from source address [r0]*/
> - stmia r1!, {r10-r11} /* copy to target address [r1]*/
> - cmp r0, r2 /* until source end address [r2]*/
> - blo copy_loop
> -
> - /*
> - * fix .rel.dyn relocations
> - */
> - ldr r0, _TEXT_BASE /* r0 <- Text base */
> - ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */
> - add r10, r10, r0/* r10 <- sym table in FLASH */
> - ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */
> - add r2, r2, r0 /* r2 <- rel dyn start in FLASH */
> - ldr r3, _rel_dyn_end_ofs/* r3 <- rel dyn end ofs */
> - add r3, r3, r0 /* r3 <- rel dyn end in FLASH */
> -fixloop:
> - ldr r0, [r2]/* r0 <- location to fix up, IN FLASH!
> */
> - add r0, r0, r9 /* r0 <- location to fix up in RAM */
> - ldr r1, [r2, #4]
> - and r7, r1, #0xff
> - cmp r7, #23 /* relative fixup? */
> - beq fixrel
> - cmp r7, #2 /* absolute fixup? */
> - beq fixabs
> - /* ignore unknown type of fixup */
> - b fixnext
> -fixabs:
> - /* absolute fix: set location to (offset) symbol value */
> - mov r1, r1, LSR #4 /* r1 <- symbol index in .dynsym */
> - add r1, r10, r1 /* r1 <- address of symbol in table */
> - ldr r1, [r1, #4]/* r1 <- symbol value */
> - add r1, r1, r9 /* r1 <- relocated sym addr */
> - b fixnext
> -fixrel:
> - /* relative fix: increase location by offset */
> - ldr r1, [r0]
> - add r1, r1, r9
> -fixnext:
> - str r1, [r0]
> - add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
> - cmp r2, r3
> - blo fixloop
> -
> -relocate_done:
> -
> - bx lr
> -
> -_image_copy_end_ofs:
> - .word __image_copy_end - _start
> -_rel_dyn_start_ofs:
> - .word __rel_dyn_start - _start
> -_rel_dyn_end_ofs:
> - .word __rel_dyn_end - _start
> -_dynsym_start_ofs:
> - .word __dynsym_start - _start
> -
> -#endif
>
> .globl c_runtime_cpu_setup
> c_runtime_cpu_setup:
>
> - bx lr
> + /*
> + * Unlock (actually, disable) the cache now that board_init_f
> + * is done. We could do this earlier but we would need to add
> + * a new C runtime hook, whereas c_runtime_cpu_setup already
> + * exists.
> + * As this routine is just a call to cpu_init_crit, let us
> + * tail-optimize and do a simple branch here.
> + */
> + b cpu_init_crit
Shouldn't the "#ifdef CONFIG_CPU_PXA25X" from the original code be kept here?
>
> /*
> *
[...]
> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> new file mode 100644
> index 000..9e91fae
> --- /dev/null
> +++ b/arch/arm/lib/relocate.S
> @@ -0,0 +1,111 @@
> +/*
> + * relocate - common relocation function for ARM U-Boot
> + *
> + * Copyright (c) 2013 Albert ARIBAUD
> + *
> + * 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 opti
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Tom, On 14/05/13 17:52, Tom Rini wrote: > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> I'm currently busy with other work; on the other hand, careful >> rebasing shall require some time, especially the Palmas stuff. >> What would be the deadline for a V2 submission? >> >> Meanwhile could you please have a look at the (already old) >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >> shall be needed if we enable USB (for the uEVM along with >> our board). In general, what are your plans regarding USB >> (.../patch/232742/)? > > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do > you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. > >> And again on I2C (.../patch/233823/): what is you final >> opinion? I'm confident that this patch is a major improvement >> for OMAP4/5 at least. > > I'm inclined to go with it, just need to mentally unswap the i2c notes > in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. > > [snip] >> + * TODO: Replace this ugly hardcoding with proper defines + >> */ + writel(0x0100, 0x4ae0a310); > > Again, do please. This should be (*scrm)->auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? >>> >>> Add it to the most likely struct in the headers. >> The entire struct (I call it omap5_scrm_regs in theory, similar to the >> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of >> course I could define only the member that I need, but I guess it is >> a (responsible) TI job to define hardware descriptors. Or I'm wrong? >> Please advise. If I have time, I could do it myself - it's some 27 >> registers, almost identical to the OMAP4, and should go into >> arch/arm/include/asm/arch-omap5/clocks.h. > > Whomever uses / needs it should do it. I gave the TRM a quick read and > I don't see any conflicts per-se just some reserved areas being named > and vice versa. So rename it to omap_scrm_regs and move to > . Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Otherwise (a struct in omap_common.h) we shall need new scrm-regs.c files for every OMAP flavor. Which way to go? Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] mx31pdk: copy SPL directly, not using relocate_code.
Hi Benoît,
On Tue, 14 May 2013 17:14:12 +0200 (CEST), Benoît Thébaudeau
wrote:
> Hi Albert,
>
> On Tuesday, May 14, 2013 11:50:27 AM, Albert ARIBAUD wrote:
> > Signed-off-by: Albert ARIBAUD
> > ---
> > Changes in v2:
> > - dropped relocate_code() call from mx31pdk SPL
> >
> > board/freescale/mx31pdk/mx31pdk.c | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/freescale/mx31pdk/mx31pdk.c
> > b/board/freescale/mx31pdk/mx31pdk.c
> > index 49158bd..4f6cfee 100644
> > --- a/board/freescale/mx31pdk/mx31pdk.c
> > +++ b/board/freescale/mx31pdk/mx31pdk.c
> > @@ -39,7 +39,21 @@ DECLARE_GLOBAL_DATA_PTR;
> > #ifdef CONFIG_SPL_BUILD
> > void board_init_f(ulong bootflag)
> > {
> > - relocate_code(CONFIG_SPL_TEXT_BASE);
> > + /*
> > +* copy ourselves from where we are running to where we were
> > +* linked at. Use ulong pointers as all addresses involved
> > +* are 4-byte-aligned.
> > +*/
> > + ulong *start_ptr, *end_ptr, *link_ptr, *run_ptr, *dst;
> > + asm volatile ("ldr %0, =_start" : "=r"(start_ptr));
> > + asm volatile ("ldr %0, =_end" : "=r"(end_ptr));
>
> Why not __image_copy_start/end instead? I know that the result will be the
> same
> here, but the naming would be more appropriate. The existing u-boot-spl.lds
> still gives access to __image_copy_*.
Well, yes, the naming seems appropriate, and I thought and said so
myself some time ago. But then, I realize that __image_copy_start and
__image_copy_end are tightly coupled with relocation, and I want to
avoid creating any additional ties between relocation and SPL just when
I am severing them. IOW, I want to keep the option of having a reduced
SPL linker file, distinct from the u-boot one, and where none of
__image_copy_*, __rel_dyn_* or __dynsym_start exist.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: do not compile relocate_code() for SPL builds
Hi Benoît, On Tue, 14 May 2013 17:21:51 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > On Tuesday, May 14, 2013 11:50:29 AM, Albert ARIBAUD wrote: > > Signed-off-by: Albert ARIBAUD > > --- > > Changes in v2: > > - dropped all relocate_code instances from SPL builds > > > > arch/arm/cpu/arm1136/start.S | 11 +++ > > arch/arm/cpu/arm1176/start.S | 11 +-- > > arch/arm/cpu/arm720t/start.S | 11 +-- > > arch/arm/cpu/arm920t/start.S | 12 +--- > > arch/arm/cpu/arm925t/start.S | 11 +-- > > arch/arm/cpu/arm926ejs/start.S | 11 +++ > > arch/arm/cpu/arm946es/start.S | 11 +-- > > arch/arm/cpu/arm_intcm/start.S | 11 +-- > > arch/arm/cpu/armv7/start.S |6 ++ > > arch/arm/cpu/ixp/start.S | 11 +-- > > arch/arm/cpu/pxa/start.S |8 ++-- > > arch/arm/cpu/s3c44b0/start.S | 11 +-- > > arch/arm/cpu/sa1100/start.S| 11 +-- > > 13 files changed, 55 insertions(+), 81 deletions(-) > > > > diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S > > index ccea2d5..1eec2e0 100644 > > --- a/arch/arm/cpu/arm1136/start.S > > +++ b/arch/arm/cpu/arm1136/start.S > > @@ -104,10 +104,6 @@ _TEXT_BASE: > > _bss_start_ofs: > > .word __bss_start - _start > > > > -.globl _image_copy_end_ofs > > -_image_copy_end_ofs: > > - .word __image_copy_end - _start > > - > > This change should be mentioned in the commit message, or moved to a separate > patch. This is not a separate change; __image_copy_end_ofs is one of the offset words used by relocate_code, only for some reason it was not initially placed with the others at the end of the routine; so instead of putting a second pair of conditionals around it, I move it where it should have been in the first place, which also places it within the already added pair of conditionals. > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
Hi Benoît, On Tue, 14 May 2013 18:01:50 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > .globl c_runtime_cpu_setup > > c_runtime_cpu_setup: > > > > - bx lr > > + /* > > +* Unlock (actually, disable) the cache now that board_init_f > > +* is done. We could do this earlier but we would need to add > > +* a new C runtime hook, whereas c_runtime_cpu_setup already > > +* exists. > > +* As this routine is just a call to cpu_init_crit, let us > > +* tail-optimize and do a simple branch here. > > +*/ > > + b cpu_init_crit > > Shouldn't the "#ifdef CONFIG_CPU_PXA25X" from the original code be kept here? Yes, it should indeed. Thanks for spotting this! > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: > Hi Tom, > > On 14/05/13 17:52, Tom Rini wrote: > > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: > >> Hi Tom, > >> > >> I'm currently busy with other work; on the other hand, careful > >> rebasing shall require some time, especially the Palmas stuff. > >> What would be the deadline for a V2 submission? > >> > >> Meanwhile could you please have a look at the (already old) > >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, > >> shall be needed if we enable USB (for the uEVM along with > >> our board). In general, what are your plans regarding USB > >> (.../patch/232742/)? > > > > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do > > you have a patch around for uEVM still? > Not yet (didn't have the opportunity to test, although some uEVMs should > be around at MMS). As you know, a patch shall be needed in the uEVM board > file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. > >> And again on I2C (.../patch/233823/): what is you final > >> opinion? I'm confident that this patch is a major improvement > >> for OMAP4/5 at least. > > > > I'm inclined to go with it, just need to mentally unswap the i2c notes > > in my brain and think it over one more time. > Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. > > [snip] > >> + * TODO: Replace this ugly hardcoding with proper defines + > >> */ + writel(0x0100, 0x4ae0a310); > > > > Again, do please. > This should be (*scrm)->auxclk0. The problem is that the > omap5_scrm_regs struct (holding the auxclk0 member) has to be > defined somewhere in the common OMAP5 headers. Sricharan? Or should > I hack around? > >>> > >>> Add it to the most likely struct in the headers. > >> The entire struct (I call it omap5_scrm_regs in theory, similar to the > >> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of > >> course I could define only the member that I need, but I guess it is > >> a (responsible) TI job to define hardware descriptors. Or I'm wrong? > >> Please advise. If I have time, I could do it myself - it's some 27 > >> registers, almost identical to the OMAP4, and should go into > >> arch/arm/include/asm/arch-omap5/clocks.h. > > > > Whomever uses / needs it should do it. I gave the TRM a quick read and > > I don't see any conflicts per-se just some reserved areas being named > > and vice versa. So rename it to omap_scrm_regs and move to > > . Thanks! > I would argue that this is not very appropriate. Those regs that are > reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; > on the other hand the OMAP5 has some modem clock regs that are reserved > on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 > and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. > Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h > file and I have already done the same for OMAP5 by analogy. I must admit > however that this approach does not correspond to the latest way by which > groups of OMAP hardware regs are defined, prcm in particular - a struct in > omap_common.h, holding only the required regs, no padding and such garbage, > and an init with the physical addresses in a .c file for the particular SoC > (prcm-regs.c). But still the Panda board, for example, uses the old way for > scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and > lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] hush variable expansion & quoting
Quoting is broken (ignored/lost) when there is variable expansions # test "a b" = c; echo $? 1 # v="a b" # test "$v" = c; echo $? 0 # echo "ab" ab # v="ab" # echo "$v" a b Regards Henrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] mx31pdk: copy SPL directly, not using relocate_code.
Hi Albert,
On Tuesday, May 14, 2013 6:13:55 PM, Albert ARIBAUD wrote:
> Hi Benoît,
>
> On Tue, 14 May 2013 17:14:12 +0200 (CEST), Benoît Thébaudeau
> wrote:
>
> > Hi Albert,
> >
> > On Tuesday, May 14, 2013 11:50:27 AM, Albert ARIBAUD wrote:
> > > Signed-off-by: Albert ARIBAUD
> > > ---
> > > Changes in v2:
> > > - dropped relocate_code() call from mx31pdk SPL
> > >
> > > board/freescale/mx31pdk/mx31pdk.c | 16 +++-
> > > 1 file changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/board/freescale/mx31pdk/mx31pdk.c
> > > b/board/freescale/mx31pdk/mx31pdk.c
> > > index 49158bd..4f6cfee 100644
> > > --- a/board/freescale/mx31pdk/mx31pdk.c
> > > +++ b/board/freescale/mx31pdk/mx31pdk.c
> > > @@ -39,7 +39,21 @@ DECLARE_GLOBAL_DATA_PTR;
> > > #ifdef CONFIG_SPL_BUILD
> > > void board_init_f(ulong bootflag)
> > > {
> > > - relocate_code(CONFIG_SPL_TEXT_BASE);
> > > + /*
> > > + * copy ourselves from where we are running to where we were
> > > + * linked at. Use ulong pointers as all addresses involved
> > > + * are 4-byte-aligned.
> > > + */
> > > + ulong *start_ptr, *end_ptr, *link_ptr, *run_ptr, *dst;
> > > + asm volatile ("ldr %0, =_start" : "=r"(start_ptr));
> > > + asm volatile ("ldr %0, =_end" : "=r"(end_ptr));
> >
> > Why not __image_copy_start/end instead? I know that the result will be the
> > same
> > here, but the naming would be more appropriate. The existing u-boot-spl.lds
> > still gives access to __image_copy_*.
>
> Well, yes, the naming seems appropriate, and I thought and said so
> myself some time ago. But then, I realize that __image_copy_start and
> __image_copy_end are tightly coupled with relocation, and I want to
> avoid creating any additional ties between relocation and SPL just when
> I am severing them. IOW, I want to keep the option of having a reduced
> SPL linker file, distinct from the u-boot one, and where none of
> __image_copy_*, __rel_dyn_* or __dynsym_start exist.
OK, that's fine.
Since _end is linker-generated contrary to the other symbols that you use in
those asm lines, have you checked that no R_ARM_ABS32 relocation data is
generated here? OTOH, -pie is not used with SPL, so there should be no
relocation data at all generated here, and the true final addresses should be in
the binary image.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: do not compile relocate_code() for SPL builds
Hi Albert, On Tuesday, May 14, 2013 6:21:02 PM, Albert ARIBAUD wrote: > Hi Benoît, > > On Tue, 14 May 2013 17:21:51 +0200 (CEST), Benoît Thébaudeau > wrote: > > > Hi Albert, > > > > On Tuesday, May 14, 2013 11:50:29 AM, Albert ARIBAUD wrote: > > > Signed-off-by: Albert ARIBAUD > > > --- > > > Changes in v2: > > > - dropped all relocate_code instances from SPL builds > > > > > > arch/arm/cpu/arm1136/start.S | 11 +++ > > > arch/arm/cpu/arm1176/start.S | 11 +-- > > > arch/arm/cpu/arm720t/start.S | 11 +-- > > > arch/arm/cpu/arm920t/start.S | 12 +--- > > > arch/arm/cpu/arm925t/start.S | 11 +-- > > > arch/arm/cpu/arm926ejs/start.S | 11 +++ > > > arch/arm/cpu/arm946es/start.S | 11 +-- > > > arch/arm/cpu/arm_intcm/start.S | 11 +-- > > > arch/arm/cpu/armv7/start.S |6 ++ > > > arch/arm/cpu/ixp/start.S | 11 +-- > > > arch/arm/cpu/pxa/start.S |8 ++-- > > > arch/arm/cpu/s3c44b0/start.S | 11 +-- > > > arch/arm/cpu/sa1100/start.S| 11 +-- > > > 13 files changed, 55 insertions(+), 81 deletions(-) > > > > > > diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S > > > index ccea2d5..1eec2e0 100644 > > > --- a/arch/arm/cpu/arm1136/start.S > > > +++ b/arch/arm/cpu/arm1136/start.S > > > @@ -104,10 +104,6 @@ _TEXT_BASE: > > > _bss_start_ofs: > > > .word __bss_start - _start > > > > > > -.globl _image_copy_end_ofs > > > -_image_copy_end_ofs: > > > - .word __image_copy_end - _start > > > - > > > > This change should be mentioned in the commit message, or moved to a > > separate > > patch. > > This is not a separate change; __image_copy_end_ofs is one of the offset > words used by relocate_code, only for some reason it was not initially > placed with the others at the end of the routine; so instead of putting > a second pair of conditionals around it, I move it where it should have > been in the first place, which also places it within the already added > pair of conditionals. OK. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
Hi Albert, On Tuesday, May 14, 2013 6:32:08 PM, Albert ARIBAUD wrote: > Hi Benoît, > > On Tue, 14 May 2013 18:01:50 +0200 (CEST), Benoît Thébaudeau > wrote: > > > Hi Albert, > > > > .globl c_runtime_cpu_setup > > > c_runtime_cpu_setup: > > > > > > - bx lr > > > + /* > > > + * Unlock (actually, disable) the cache now that board_init_f > > > + * is done. We could do this earlier but we would need to add > > > + * a new C runtime hook, whereas c_runtime_cpu_setup already > > > + * exists. > > > + * As this routine is just a call to cpu_init_crit, let us > > > + * tail-optimize and do a simple branch here. > > > + */ > > > + b cpu_init_crit > > > > Shouldn't the "#ifdef CONFIG_CPU_PXA25X" from the original code be kept > > here? > > Yes, it should indeed. Thanks for spotting this! Have you seen the end of my notes for relocate.S? After all, keeping for later your patches moving to compiler-generated symbols seems to complicate things and to be more error-prone. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: cfi_flash: Fix unaligned accesses to cfi_qry structure
Hello Albert, > From: Albert ARIBAUD [albert.u.b...@aribaud.net] > Sent: Monday, May 13, 2013 10:48 > To: Marek Vasut > Cc: u-boot@lists.denx.de; Masahiro Yamada; tr...@ti.com; Gabbasov, Andrew > Subject: Re: [U-Boot] ARM: cfi_flash: Fix unaligned accesses to cfi_qry > structure > > Hi Marek, > > On Fri, 10 May 2013 14:36:00 +0200, Marek Vasut wrote: > > > Hello Masahiro-san, > > > > By the way, I also had this unalignment access problem for my board. > > > Before finding your patch, I was thinking another way to fix this problem. > > > > > > My idea is to just use 'get_unaligned' and 'put_unaligned' functions > > > instead of introducing special macros. > > > With this way, we don't need to change the fields of struct cfi_qry. > > > > I think we should make sure to use natural alignment as much as possible, > > really. I'm keeping Albert in CC because this is his turf. > > Marek, you invoked me; next time be careful what you wish for. :) > > My rules (not 'of thumb', as they also apply to ARM) regarding > alignment are as follows (yes, it's a more general answer than your > question called for, but the last rules are more directly related): > > 0) Never assume that U-Boot can use native unaligned accesses. Yes, > ARMv7+ can do native unaligned accesses with almost no performance > cost, but U-Boot runs on all sorts of targets (not only ARM), some > allowing unaligned access but with a penalty, and some unable to > perform unaligned access at all. We always run the risk that some code > in U-Boot ends up running on target which will die horribly on some > unaligned access, so to avoid this we must assume and enforce strict > alignment, even for architectures which do not require it, such as > ARMv7+. > > 1) As per rule 0, always enable alignment check -- again, even on > targets which could do without it. This allows catching any unaligned > access, be they accidental (bad pointer arithmetic) or by design > (misaligned field in an otherwise aligned struct). > > 2) Despite rules 0 and 1, always enable native unaligned accesses (IOW, > always use option -munaligned-accesses). That is because without this > option (or more precisely, when -mno-unaligned-accesses is in effect), > the ARM compiler may silently detect misaligned accesses and fix them > using smaller aligned accesses, thus hiding a potential alignment > issue until it bites on some later and unrelated target run. > > 3) always size fields in a structure to their natural size, i.e., if a > field is 16-bits, make it u16 or s16. > > 4) always align fields in a structure to their natural boundaries, > i.e., if a field is 16-bits, align it to an even address. > > 5) if a field absolutely has to be unaligned because of hardware or > standard, then a) document that! and b) access it with explicit > unaligned access macros. > > So in essence, I am opposed to changing fields from 16-bit to 2 x 8-bit > just 'because unaligned'. Either fix the fields' alignment, if at all > possible; and if not, then apply rule 5: document the issue and fix it > using explicit unaligned access macros. > > > Best regards, > > Marek Vasut > > Amicalement, > -- > Albert. Thank you for your review and the very useful list of rules. Although theoretically the cfi_qry structure can be made non-packed and with properly aligned members (and filled in by individual members assignments when reading, rather than just copying byte-to-byte, as it is now), it may make more sense to keep it packed and replicating the actual flash layout as much as possible. This also makes it more similar to what is used in Linux kernel (although it seems to rely on native unaligned access ;-)). So, it seems reasonable to choose to apply rule 5: add comments to cfi_qry strcuture definition and use get_unaligned/put_unaligned for the necessary fields (only for really unaligned members, since some 16-bit fields are properly aligned). I'm sending the version 2 of the patch with this change as a separate message with Subject: [U-Boot][PATCH v2] cfi_flash: Fix unaligned accesses to cfi_qry structure Please, let me know if somebody still prefers making non-packed aligned structure, as described above. Thanks. Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] cfi_flash: Fix unaligned accesses to cfi_qry structure
Packed structure cfi_qry contains unaligned 16- and 32-bits members,
accessing which causes problems when cfi_flash driver is compiled with
-munaligned-access option: flash initialization hangs, probably
due to data error.
Since the structure is supposed to replicate the actual data layout
in CFI Flash chips, the alignment issue can't be fixed in the structure.
So, unaligned fields need using of explicit unaligned access macros.
Signed-off-by: Andrew Gabbasov
---
drivers/mtd/cfi_flash.c | 15 +--
include/mtd/cfi_flash.h | 18 +++---
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 22d8440..f6759a8 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1640,9 +1641,10 @@ static void cfi_reverse_geometry(struct cfi_qry *qry)
u32 tmp;
for (i = 0, j = qry->num_erase_regions - 1; i < j; i++, j--) {
- tmp = qry->erase_region_info[i];
- qry->erase_region_info[i] = qry->erase_region_info[j];
- qry->erase_region_info[j] = tmp;
+ tmp = get_unaligned(&(qry->erase_region_info[i]));
+ put_unaligned(get_unaligned(&(qry->erase_region_info[j])),
+ &(qry->erase_region_info[i]));
+ put_unaligned(tmp, &(qry->erase_region_info[j]));
}
}
@@ -2073,8 +2075,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
info->start[0] = (ulong)map_physmem(base, info->portwidth, MAP_NOCACHE);
if (flash_detect_cfi (info, &qry)) {
- info->vendor = le16_to_cpu(qry.p_id);
- info->ext_addr = le16_to_cpu(qry.p_adr);
+ info->vendor = le16_to_cpu(get_unaligned(&(qry.p_id)));
+ info->ext_addr = le16_to_cpu(get_unaligned(&(qry.p_adr)));
num_erase_regions = qry.num_erase_regions;
if (info->ext_addr) {
@@ -2163,7 +2165,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
break;
}
- tmp = le32_to_cpu(qry.erase_region_info[i]);
+ tmp = le32_to_cpu(get_unaligned(
+ &(qry.erase_region_info[i])));
debug("erase region %u: 0x%08lx\n", i, tmp);
erase_region_count = (tmp & 0x) + 1;
diff --git a/include/mtd/cfi_flash.h b/include/mtd/cfi_flash.h
index 966b5e0..b644b91 100644
--- a/include/mtd/cfi_flash.h
+++ b/include/mtd/cfi_flash.h
@@ -129,12 +129,16 @@ typedef union {
} cfiword_t;
/* CFI standard query structure */
+/* The offsets and sizes of this packed structure members correspond
+ * to the actual layout in CFI Flash chips. Some 16- and 32-bit members
+ * are unaligned and must be accessed with explicit unaligned access macros.
+ */
struct cfi_qry {
u8 qry[3];
- u16 p_id;
- u16 p_adr;
- u16 a_id;
- u16 a_adr;
+ u16 p_id; /* unaligned */
+ u16 p_adr; /* unaligned */
+ u16 a_id; /* unaligned */
+ u16 a_adr; /* unaligned */
u8 vcc_min;
u8 vcc_max;
u8 vpp_min;
@@ -148,10 +152,10 @@ struct cfi_qry {
u8 block_erase_timeout_max;
u8 chip_erase_timeout_max;
u8 dev_size;
- u16 interface_desc;
- u16 max_buf_write_size;
+ u16 interface_desc; /* aligned */
+ u16 max_buf_write_size; /* aligned */
u8 num_erase_regions;
- u32 erase_region_info[NUM_ERASE_REGIONS];
+ u32 erase_region_info[NUM_ERASE_REGIONS]; /* unaligned */
} __attribute__((packed));
struct cfi_pri_hdr {
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra: always build u-boot-nodtb-tegra.bin
From: Stephen Warren
Even when eventually building u-boot-dtb-tegra.bin, separately building
u-boot-nodtb-tegra.bin can be useful, since building it encapsulates the
SPL padding step. If you want to tweak u-boot.dtb and regenerate
u-boot-dtb-tegra.bin, it is then a simple cat operation.
Signed-off-by: Stephen Warren
---
Makefile | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index dbc4b70..50880c9 100644
--- a/Makefile
+++ b/Makefile
@@ -547,18 +547,15 @@ $(obj)u-boot.spr: $(obj)u-boot.img
$(obj)spl/u-boot-spl.bin
cat $(obj)spl/u-boot-spl-pad.img $(obj)u-boot.img > $@
ifneq ($(CONFIG_TEGRA),)
-ifeq ($(CONFIG_OF_SEPARATE),y)
-nodtb=dtb
-dtbfile=$(obj)u-boot.dtb
-else
-nodtb=nodtb
-dtbfile=
-endif
-
-$(obj)u-boot-$(nodtb)-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(dtbfile)
+$(obj)u-boot-nodtb-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O
binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
- cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $(dtbfile) >
$@
+ cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $@
rm $(obj)spl/u-boot-spl-pad.bin
+
+ifeq ($(CONFIG_OF_SEPARATE),y)
+$(obj)u-boot-dtb-tegra.bin: $(obj)u-boot-nodtb-tegra.bin $(obj)u-boot.dtb
+ cat $(obj)u-boot-nodtb-tegra.bin $(obj)u-boot.dtb > $@
+endif
endif
$(obj)u-boot-img.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fdt: allow bootdelay to be specified via device tree
From: Stephen Warren
This can be useful to force bootcmd to execute as soon as U-Boot has
started.
My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with
an image to be written to device boot flash, with the DT config property
"bootcmd" set to contain a command to write that image to flash. In this
scenario, we don't want to allow any stale bootdelay value taken from
the current flash content to affect how long it takes before the
flashing process starts.
Signed-off-by: Stephen Warren
---
common/main.c |5 +
1 file changed, 5 insertions(+)
diff --git a/common/main.c b/common/main.c
index 953ef29..6bfd9f0 100644
--- a/common/main.c
+++ b/common/main.c
@@ -429,6 +429,11 @@ void main_loop (void)
s = getenv ("bootdelay");
bootdelay = s ? (int)simple_strtol(s, NULL, 10) : CONFIG_BOOTDELAY;
+#ifdef CONFIG_OF_CONTROL
+ bootdelay = fdtdec_get_config_int(gd->fdt_blob, "bootdelay",
+ bootdelay);
+#endif
+
debug ("### main_loop entered: bootdelay=%d\n\n", bootdelay);
#if defined(CONFIG_MENU_SHOW)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3, batch 3 01/17] common: Update cmd_bdinfo for PPC
Add board detail function to print more individual board information.
Signed-off-by: York Sun
---
Change since v2: use __weak instead of a weak alias
common/cmd_bdinfo.c |5 +
1 file changed, 5 insertions(+)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 85279d5..210cddf 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -84,6 +84,10 @@ static void print_mhz(const char *name, unsigned long hz)
}
#if defined(CONFIG_PPC)
+void __weak board_detail(void)
+{
+ /* Please define boot_detail() for your platform */
+}
int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
@@ -169,6 +173,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
printf("IP addr = %s\n", getenv("ipaddr"));
printf("baudrate= %6u bps\n", bd->bi_baudrate);
print_num("relocaddr", gd->relocaddr);
+ board_detail();
return 0;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix env in mmc with redundant compile error
Am Montag, 13. Mai 2013, 14:14:46 schrieben Sie: > The commit d196bd8 (env_mmc: add support for redundant environment) > introduce the following compile error when enable reduandant > environment support with MMC > ---8<--- > env_mmc.c:149: error: 'env_t' has no member named 'flags' > env_mmc.c:248: error: 'env_t' has no member named 'flags' > env_mmc.c:248: error: 'env_t' has no member named 'flags' > env_mmc.c:250: error: 'env_t' has no member named 'flags' > env_mmc.c:250: error: 'env_t' has no member named 'flags' > env_mmc.c:252: error: 'env_t' has no member named 'flags' > env_mmc.c:252: error: 'env_t' has no member named 'flags' > env_mmc.c:254: error: 'env_t' has no member named 'flags' > env_mmc.c:254: error: 'env_t' has no member named 'flags' > env_mmc.c:267: error: 'env_t' has no member named 'flags' > make[1]: *** [env_mmc.o] Error 1 > --->8--- > > Add this patch to fix it > > Signed-off-by: Bo Shen > --- > include/environment.h |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/environment.h b/include/environment.h > index 4c6a37b..460ccb4 100644 > --- a/include/environment.h > +++ b/include/environment.h > @@ -75,6 +75,12 @@ > # endif > #endif /* CONFIG_ENV_IS_IN_FLASH */ > > +#if defined(CONFIG_ENV_IS_IN_MMC) > +# ifdef CONFIG_ENV_OFFSET_REDUND > +# define CONFIG_SYS_REDUNDAND_ENVIRONMENT > +# endif > +#endif > + > #if defined(CONFIG_ENV_IS_IN_NAND) > # if defined(CONFIG_ENV_OFFSET_OOB) > # ifdef CONFIG_ENV_OFFSET_REDUND > s/reduandant/redundant/ Reviewed-by: Michael Heimpold ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] mx31pdk: copy SPL directly, not using relocate_code.
Hi Benoît,
On Tue, 14 May 2013 19:10:10 +0200 (CEST), Benoît Thébaudeau
wrote:
> Hi Albert,
>
> On Tuesday, May 14, 2013 6:13:55 PM, Albert ARIBAUD wrote:
> > Hi Benoît,
> >
> > On Tue, 14 May 2013 17:14:12 +0200 (CEST), Benoît Thébaudeau
> > wrote:
> >
> > > Hi Albert,
> > >
> > > On Tuesday, May 14, 2013 11:50:27 AM, Albert ARIBAUD wrote:
> > > > Signed-off-by: Albert ARIBAUD
> > > > ---
> > > > Changes in v2:
> > > > - dropped relocate_code() call from mx31pdk SPL
> > > >
> > > > board/freescale/mx31pdk/mx31pdk.c | 16 +++-
> > > > 1 file changed, 15 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/board/freescale/mx31pdk/mx31pdk.c
> > > > b/board/freescale/mx31pdk/mx31pdk.c
> > > > index 49158bd..4f6cfee 100644
> > > > --- a/board/freescale/mx31pdk/mx31pdk.c
> > > > +++ b/board/freescale/mx31pdk/mx31pdk.c
> > > > @@ -39,7 +39,21 @@ DECLARE_GLOBAL_DATA_PTR;
> > > > #ifdef CONFIG_SPL_BUILD
> > > > void board_init_f(ulong bootflag)
> > > > {
> > > > - relocate_code(CONFIG_SPL_TEXT_BASE);
> > > > + /*
> > > > +* copy ourselves from where we are running to where we were
> > > > +* linked at. Use ulong pointers as all addresses involved
> > > > +* are 4-byte-aligned.
> > > > +*/
> > > > + ulong *start_ptr, *end_ptr, *link_ptr, *run_ptr, *dst;
> > > > + asm volatile ("ldr %0, =_start" : "=r"(start_ptr));
> > > > + asm volatile ("ldr %0, =_end" : "=r"(end_ptr));
> > >
> > > Why not __image_copy_start/end instead? I know that the result will be the
> > > same
> > > here, but the naming would be more appropriate. The existing
> > > u-boot-spl.lds
> > > still gives access to __image_copy_*.
> >
> > Well, yes, the naming seems appropriate, and I thought and said so
> > myself some time ago. But then, I realize that __image_copy_start and
> > __image_copy_end are tightly coupled with relocation, and I want to
> > avoid creating any additional ties between relocation and SPL just when
> > I am severing them. IOW, I want to keep the option of having a reduced
> > SPL linker file, distinct from the u-boot one, and where none of
> > __image_copy_*, __rel_dyn_* or __dynsym_start exist.
>
> OK, that's fine.
>
> Since _end is linker-generated contrary to the other symbols that you use in
> those asm lines, have you checked that no R_ARM_ABS32 relocation data is
> generated here? OTOH, -pie is not used with SPL, so there should be no
> relocation data at all generated here, and the true final addresses should be
> in
> the binary image.
Indeed, SPL is meant to be loaded at its link-time address -- or, in the
case of mx31pdk and tx25, loaded in a read buffer then moved by itself
to its link-time address. In no case is SPL supposed to be relocated.
You can verify with readelf -r that no relocation records are generated
for SPL builds.
> Best regards,
> Benoît
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
Hi Benoît, On Tue, 14 May 2013 19:17:46 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > On Tuesday, May 14, 2013 6:32:08 PM, Albert ARIBAUD wrote: > > Hi Benoît, > > > > On Tue, 14 May 2013 18:01:50 +0200 (CEST), Benoît Thébaudeau > > wrote: > > > > > Hi Albert, > > > > > > .globl c_runtime_cpu_setup > > > > c_runtime_cpu_setup: > > > > > > > > - bx lr > > > > + /* > > > > +* Unlock (actually, disable) the cache now that board_init_f > > > > +* is done. We could do this earlier but we would need to add > > > > +* a new C runtime hook, whereas c_runtime_cpu_setup already > > > > +* exists. > > > > +* As this routine is just a call to cpu_init_crit, let us > > > > +* tail-optimize and do a simple branch here. > > > > +*/ > > > > + b cpu_init_crit > > > > > > Shouldn't the "#ifdef CONFIG_CPU_PXA25X" from the original code be kept > > > here? > > > > Yes, it should indeed. Thanks for spotting this! > > Have you seen the end of my notes for relocate.S? After all, keeping for later > your patches moving to compiler-generated symbols seems to complicate things > and > to be more error-prone. (that's unrelated to the PXA25X stuff above, right?) I don't think deferring the compiler-generated symbols patches complicates things, as anyway, they would only apply after this patch (so as to apply only on a single instance of relocate_code) so there's no way they could simplify things occurring before them. OTOH, they do simplify the code of relocate_code. That's why I put them in a separate series dealing with optimizing relocate_code. I'll post this second series right away, and let people decide whether both series should be merged in a single one. > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] arm: factorize relocate_code routine
Hi Albert, On Tuesday, May 14, 2013 8:51:58 PM, Albert ARIBAUD wrote: > Hi Benoît, > > On Tue, 14 May 2013 19:17:46 +0200 (CEST), Benoît Thébaudeau > wrote: > > > Hi Albert, > > > > On Tuesday, May 14, 2013 6:32:08 PM, Albert ARIBAUD wrote: > > > Hi Benoît, > > > > > > On Tue, 14 May 2013 18:01:50 +0200 (CEST), Benoît Thébaudeau > > > wrote: > > > > > > > Hi Albert, > > > > > > > > .globl c_runtime_cpu_setup > > > > > c_runtime_cpu_setup: > > > > > > > > > > - bx lr > > > > > + /* > > > > > + * Unlock (actually, disable) the cache now that board_init_f > > > > > + * is done. We could do this earlier but we would need to add > > > > > + * a new C runtime hook, whereas c_runtime_cpu_setup already > > > > > + * exists. > > > > > + * As this routine is just a call to cpu_init_crit, let us > > > > > + * tail-optimize and do a simple branch here. > > > > > + */ > > > > > + b cpu_init_crit > > > > > > > > Shouldn't the "#ifdef CONFIG_CPU_PXA25X" from the original code be kept > > > > here? > > > > > > Yes, it should indeed. Thanks for spotting this! > > > > Have you seen the end of my notes for relocate.S? After all, keeping for > > later > > your patches moving to compiler-generated symbols seems to complicate > > things and > > to be more error-prone. > > (that's unrelated to the PXA25X stuff above, right?) Yes. > I don't think deferring the compiler-generated symbols patches > complicates things, as anyway, they would only apply after this > patch (so as to apply only on a single instance of relocate_code) so > there's no way they could simplify things occurring before them. > > OTOH, they do simplify the code of relocate_code. That's why I put them > in a separate series dealing with optimizing relocate_code. I'll post > this second series right away, and let people decide whether both > series should be merged in a single one. Yes, this is what I meant. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 2013 Plumber's CFP: Fastboot
> From: richard -rw- weinberger [richard.weinber...@gmail.com] > Sent: Tuesday, May 14, 2013 8:10 AM > To: Mehaffey, John > Cc: tim.b...@am.sony.com; w...@denx.de; mz...@0pointer.net; > kay.siev...@vrfy.org; Pomerantz, Brian; yo...@cs.msu.su; > u-boot@lists.denx.de; genivi-...@mail.genivi.org; > systemd-de...@lists.freedesktop.org; celinux-...@lists.celinuxforum.org; > linux-ker...@vger.kernel.org; linux-embed...@vger.kernel.org > Subject: Re: 2013 Plumber's CFP: Fastboot > > On Tue, May 14, 2013 at 1:51 AM, Mehaffey, John > wrote: > > Hello All, > > > > I am proposing a microconference on fastboot at the Linux Plumber's > > conference 2013 in New Orleans. The goal is to get to sub 1S boot times for > > a large (IVI) system using NAND flash. This pushes the state of the art, > > and will require innovative solutions in may areas of Linux plumbing, > > including bootloader, kernel init, UBI, and systemd. > > > > Note that fastboot improvements will (generally) help all architectures so > > I am not limiting this to automotive systems. > > > > Please visit http://wiki.linuxplumbersconf.org/2013:fastboot for more > > information or if you want to submit a topic. > > > > If you want to reply to this message, please trim the cc list! > > Why trimming the CC? Changing the CC list is a _very_ bad habit. Thanks for the advice. > Anyway, a few notes on UBI fastmap. > Before we talk about optimizing it we have to make sure that it is stable. > Currently it has not much users because embedded folks are a few > kernel releases behind. > I expect that we'll face some issues (hey it's software!). Instead of > making the code more complicated we have to > make very sure that it works well. > Fastmap got much more complicated than I thought while developing the > first proof of concept implementation. This is good software practice, but is out of scope for this uconf. Fastmap will be getting more usage in the future as systems deploy using it. I think that low-hanging fruit to speed things up, such as Brian's RB-tree lookup, can proceed in parallel with testing and stabilization (hey, it's open-source software :) > We also have to think more about userland support, e.g. making tools > like ubinize fastmap aware... > User want ready to use fastmap UBI images and not images which have to > be converted by the kernel on the very first boot. > > Sharing UBI EBA table between U-Boot and the kernel would be a nice > feature, but we also have to make sure > that we can share the EBA table between two kernels (think of kexec). > So, a more general solution is needed. > > -- > Thanks, > //richard Thanks for your feedback, I agree that these are things that should also be looked at! -mehaf ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: allow bootdelay to be specified via device tree
Hi Stephen, On Tue, May 14, 2013 at 11:02 AM, Stephen Warren wrote: > From: Stephen Warren > > This can be useful to force bootcmd to execute as soon as U-Boot has > started. > > My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with > an image to be written to device boot flash, with the DT config property > "bootcmd" set to contain a command to write that image to flash. In this > scenario, we don't want to allow any stale bootdelay value taken from > the current flash content to affect how long it takes before the > flashing process starts. > > Signed-off-by: Stephen Warren Nice idea. Acked-by: Simon Glass Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request v2: u-boot-blackfin
On Tue, May 14, 2013 at 02:20:46PM +0800, Sonic Zhang wrote:
> Hi Tom,
>
> Please pull the following patches from u-boot-blackfin into your tree.
> In this second pull request:
> - CONFIG_CMD_SOFTSWITCH document is added to the README file.
> - The tools/patman folder is synced with upstream master.
> - 3 missing patches were sent to the mailing list.
>
> Thanks
>
> The following changes since commit bbd0f7e3ba66d288a2f146f1c7797801e04598ae:
>
> Move FDT_RAMDISK_OVERHEAD from fdt.h to libfdt_env.h (2013-05-10
> 19:04:50 -0400)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-blackfin.git master
>
> for you to fetch changes up to da34aae5fba36c1f1989fdd41fffa723f300eaad:
>
> bfin: Move gpio support for bf54x and bf60x into the generic driver
> folder. (2013-05-13 16:30:27 +0800)
>
>
> Bob Liu (3):
> blackfin: reduce size of u-boot.ldr in bf548-ezkit default config.
> blackfin: add baudrate to bdinfo
> blackfin: bf609: add softswitch config command
>
> Marek Vasut (1):
> blackfin: The buf variable in bfin_mac.c is not used and produces
> warning,
>
> Mike Frysinger (1):
> Blackfin: adjust asm constraints with NMI workaround
>
> Scott Jiang (3):
> bfin: Remove spi dma function in bf5xx.
> bfin: discard invalid data and clear RXS in bf5xx spi driver
> bf609: add SPI register base address
>
> Sonic Zhang (14):
> blackfin: Change the member's type in dma structures.
> blackfin: limit the max memory dma peripheral transfer size to 4 bytes.
> blackfin: run core1 from L1 code sram start address in uboot
> init code on core 0
> blackfin: Set correct early debug serial baudrate.
> blackfin: Correct early serial mess output in BYPASS boot mode.
> blackfin: bf609: implement soft switch
> blackfin: Fit u-boot image size into limited nor flash on blackfin.
> blackfin: Enable early print via the generic serial API.
> blackfin: Add memory virtual console to blackfin serial driver.
> blackfin: Uart divisor should be set after their values are generated.
> blackfin: Move blackfin watchdog driver out of the blackfin arch folder.
> blackfin: Move blackfin serial driver out of blackfin arch folder.
> blackfin: Add comments for watchdog event initialization.
> bfin: Move gpio support for bf54x and bf60x into the generic
> driver folder.
>
> README | 1 +
> arch/blackfin/cpu/Makefile | 4 +-
> arch/blackfin/cpu/cpu.c| 32 +-
> arch/blackfin/cpu/gpio.c | 145 +--
> arch/blackfin/cpu/initcode.c | 71 ++--
> arch/blackfin/cpu/start.S | 29 +-
> arch/blackfin/include/asm/clock.h | 78
> arch/blackfin/include/asm/dma.h| 24 +-
> arch/blackfin/include/asm/gpio.h | 62 +--
> arch/blackfin/include/asm/mach-bf561/BF561_def.h | 2 +
> arch/blackfin/include/asm/mach-bf609/BF609_def.h | 5 +
> arch/blackfin/include/asm/portmux.h| 5 -
> arch/blackfin/{cpu => include/asm}/serial.h| 23 +-
> arch/blackfin/{cpu => include/asm}/serial1.h | 48 +--
> arch/blackfin/{cpu => include/asm}/serial4.h | 27 +-
> arch/blackfin/include/asm/soft_switch.h| 18 +
> arch/blackfin/lib/board.c | 6 +-
> arch/blackfin/lib/clocks.c | 12 +-
> arch/blackfin/lib/string.c | 9 +-
> board/bf609-ezkit/soft_switch.c| 171
> board/bf609-ezkit/soft_switch.h| 80
> common/Makefile| 1 +
> common/cmd_softswitch.c| 41 ++
> doc/README.watchdog| 3 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/adi_gpio2.c | 440
> +
> drivers/net/bfin_mac.c | 2 -
> drivers/serial/Makefile| 1 +
> .../cpu/serial.c => drivers/serial/serial_bfin.c | 110 --
> drivers/spi/bfin_spi.c | 105 +
> drivers/watchdog/Makefile | 1 +
> .../cpu/watchdog.c => drivers/watchdog/bfin_wdt.c | 7 +-
> include/configs/bf527-ezkit.h | 12 +-
> include/configs/bf537-stamp.h | 10 +-
> include/configs/bf548-ezkit.h | 25 +-
> include/configs/bf561-ezkit.h | 5 +
> include/configs/bf609-ezkit.h | 10 +
> include/configs/bfin_adi_common.h | 14 +-
> include/watchdog.h | 3 +-
> 39 fi
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi Tom, Just a couple of things to clarify below. > On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >> Hi Tom, >> >> On 14/05/13 17:52, Tom Rini wrote: >> > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: >> >> Hi Tom, >> >> >> >> I'm currently busy with other work; on the other hand, careful >> >> rebasing shall require some time, especially the Palmas stuff. >> >> What would be the deadline for a V2 submission? >> >> >> >> Meanwhile could you please have a look at the (already old) >> >> http://patchwork.ozlabs.org/patch/232743/? A simple patch, >> >> shall be needed if we enable USB (for the uEVM along with >> >> our board). In general, what are your plans regarding USB >> >> (.../patch/232742/)? >> > >> > Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but >> do >> > you have a patch around for uEVM still? >> Not yet (didn't have the opportunity to test, although some uEVMs should >> be around at MMS). As you know, a patch shall be needed in the uEVM >> board >> file along with the common USB stuff. > > Yeah, I can test it as well if you write it up, and may find the time if > you point me in the right direction. OK, shall do it. > >> >> And again on I2C (.../patch/233823/): what is you final >> >> opinion? I'm confident that this patch is a major improvement >> >> for OMAP4/5 at least. >> > >> > I'm inclined to go with it, just need to mentally unswap the i2c notes >> > in my brain and think it over one more time. >> Just applied 233823 to current u-boot-ti master. Works fine. > > OK, thanks. Just to avoid confusion: I applied it and tested on a locally cloned version of u-boot-ti, not upstream (don't laugh please; just want to clarify for those who don't know that it is your job). > >> > [snip] >> Currently the scrm struct is defined for OMAP4 in the >> asm/arch-omap4/clocks.h >> file and I have already done the same for OMAP5 by analogy. I must admit >> however that this approach does not correspond to the latest way by >> which >> groups of OMAP hardware regs are defined, prcm in particular - a struct >> in >> omap_common.h, holding only the required regs, no padding and such >> garbage, >> and an init with the physical addresses in a .c file for the particular >> SoC >> (prcm-regs.c). But still the Panda board, for example, uses the old way >> for >> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old >> and >> lazy ;) ). > > Yes, I'm OK starting off with moving things into omap_common.h as-is and > then updating them a bit later ala pcrm-regs.c. Who is starting off, me or you? ;) > > -- > Tom > BR, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/10] Add Marvell Dove and SolidRun CuBox
Sebastian Hesselbarth writes: > This patch set add support for the Marvell Dove 88AP510 SoC and > the SolidRun CuBox board based on that SoC. The patch set is divided > into the four following sections: [...] What's the state of this? I tried applying your patch series on top of current master and getting it to work on a CuBox Pro (2GiB SDRAM instead of 1GiB), but with no success so far. I changed kwbimage.cfg to match dramregs_cubox_2gb.txt in Rabeeh's tree and fixed arch/arm/cpu/armv7/dove/timer.c to work with the generic global_data (introduced by baa1e53 and 50b1fa3). However there seems to be something else missing or broken as there's no output whatsoever on the serial console after booting the new image via UART. The same boot procedure works fine with an image built using Rabeeh's tree. Sascha pgppssB6CIeJy.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 00/10] PXE support updates
On Sun, Dec 2, 2012 at 9:00 PM, Rob Herring wrote: > From: Rob Herring > > This is a series of various enhancements and fixes for u-boot pxe support. > These patches are a result of testing with server side tools like Cobbler > and ubuntu MAAS. > > Rob > > Rob Herring (10): > pxe: Use ethact setting for pxe > pxe: make string parameters const > pxe: fix handling of different localboot values > bootz: un-staticize do_bootz > pxe: use bootz instead of bootm when enabled > pxe: always display a menu when present > pxe: simplify menu display and selection > pxe: add support for ontimeout token > pxe: add support for per arch and SoC default paths > pxe: add ipappend support > > common/cmd_bootm.c |2 +- > common/cmd_pxe.c | 210 > > include/command.h |2 + > 3 files changed, 132 insertions(+), 82 deletions(-) Is someone going to pick these patches up? The single comment by Wolfgang I've addressed. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] Optimize ARM relocation
*** NOTE: this series applies over the 'Factorize
ARM relocate_code instances' series.
This series optimizes relocation by ensuring ARM
binaries only use one type of relocation record,
R_ARM_RELATIVE., then optimizing relocation code
accordingly.
The only known case where relocation records other
than R_ARM_RELATIVE are generated is when a reference
is made to a symbol defined in the linker script, e.g.
__image_copy_start, __image_copy_end, __rel_dyn_start,
__rel_dyn_end, and __dynsym_start.
Moving the definition of these symbols from the linker
scripts into a C module causes their references' types
to become R_ARM_RELATIVE.
First, arch/arm/lib/bss.c is replaced by a more generic
arch/arm/lib/sections.c where all section symbols will
be defined.
Second, __image_copy_start and __image_copy_end symbols
are moved from linker scripts to arch/arm/lib/sections.c
Third, __rel_dyn_start, __rel_dyn_end and __synsym_start
are moved from linker scripts into arch/arm/lib/sections.c
Fourth, a check is added to the build system to ensure
that ELF U-Boot binaries only use R_ARM_RELATIVE records.
Last, relocate_code is optimized
Albert ARIBAUD (5):
arm: generalize lib/bss.c into lib/sections.c
arm: make __image_copy_{start,end} compiler-generated
arm: make relocation symbols compiler-generated
arm: ensure u-boot only uses relative relocations
arm: optimize relocate_code routine
Makefile |7
arch/arm/config.mk |5 +++
arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 ++-
arch/arm/cpu/ixp/u-boot.lds| 24 ++--
arch/arm/cpu/u-boot.lds| 25 ++---
arch/arm/lib/Makefile |2 +-
arch/arm/lib/relocate.S| 64 +---
arch/arm/lib/{bss.c => sections.c} |9 -
board/actux1/u-boot.lds| 24 ++--
board/actux2/u-boot.lds| 24 ++--
board/actux3/u-boot.lds| 24 ++--
board/dvlhost/u-boot.lds | 24 ++--
board/freescale/mx31ads/u-boot.lds | 24 ++--
13 files changed, 183 insertions(+), 79 deletions(-)
rename arch/arm/lib/{bss.c => sections.c} (77%)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] arm: generalize lib/bss.c into lib/sections.c
File arch/arm/lib/bss.c was initially defined for BSS only,
but is now going to also contain definitions for other
section-boundary-related symbols, so rename it for better
accuracy.
Also, remove useless 'used' attributes.
Signed-off-by: Albert ARIBAUD
---
arch/arm/lib/Makefile |2 +-
arch/arm/lib/{bss.c => sections.c} |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename arch/arm/lib/{bss.c => sections.c} (92%)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 30e3290..dbad5c1 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -43,7 +43,7 @@ SOBJS-y += relocate.o
ifndef CONFIG_SYS_GENERIC_BOARD
COBJS-y+= board.o
endif
-COBJS-y += bss.o
+COBJS-y += sections.o
COBJS-y+= bootm.o
COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
diff --git a/arch/arm/lib/bss.c b/arch/arm/lib/sections.c
similarity index 92%
rename from arch/arm/lib/bss.c
rename to arch/arm/lib/sections.c
index 99eda59..e52fec9 100644
--- a/arch/arm/lib/bss.c
+++ b/arch/arm/lib/sections.c
@@ -35,5 +35,5 @@
* aliasing warnings.
*/
-char __bss_start[0] __attribute__((used, section(".__bss_start")));
-char __bss_end[0] __attribute__((used, section(".__bss_end")));
+char __bss_start[0] __attribute__((section(".__bss_start")));
+char __bss_end[0] __attribute__((section(".__bss_end")));
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] arm: ensure u-boot only uses relative relocations
Add a Makefile target ('checkarmreloc') which
fails of the ELF binary contains relocation records
of types other than R_ARM_RELATIVE.
Signed-off-by: Albert ARIBAUD
---
Makefile |7 +++
arch/arm/config.mk |5 +
2 files changed, 12 insertions(+)
diff --git a/Makefile b/Makefile
index c52f0f1..9aa5755 100644
--- a/Makefile
+++ b/Makefile
@@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE)
$(MAKE) -C $@ all
endif # config.mk
+# ARM relocations should all be R_ARM_RELATIVE.
+checkarmreloc: $(obj)u-boot
+ @if test "R_ARM_RELATIVE" != \
+ "`readelf -r $(obj)u-boot | cut -d ' ' -f 4 | grep R_ARM | sort
-u`"; \
+ then echo "$(obj)u-boot contains relocations other than \
+ R_ARM_RELATIVE"; false; fi
+
$(VERSION_FILE):
@mkdir -p $(dir $(VERSION_FILE))
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 461899e..5b7a602 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -106,3 +106,8 @@ ifeq ($(GAS_BUG_12532),y)
PLATFORM_RELFLAGS += -fno-optimize-sibling-calls
endif
endif
+
+# check that only R_ARM_RELATIVE relocations are generated
+ifneq ($(CONFIG_SPL_BUILD),y)
+ALL-y += checkarmreloc
+endif
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] arm: optimize relocate_code routine
Use section symbols directly
Drop support for R_ARM_ABS32 record types
Eliminate unneeded intermediate registers
Optimize relocation table iteration
Signed-off-by: Albert ARIBAUD
---
arch/arm/lib/relocate.S | 45 +++--
1 file changed, 15 insertions(+), 30 deletions(-)
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 818735c..75ee3b4 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -37,51 +37,36 @@
* This function relocates the monitor code.
*/
ENTRY(relocate_code)
- mov r6, r0 /* save addr of destination */
- ldr r0, =__image_copy_start /* r0 <- source start address */
- subsr9, r6, r0 /* r9 <- relocation offset */
+ ldr r1, =__image_copy_start /* r1 <- source start address */
+ subsr9, r0, r1 /* r9 <- relocation offset */
beq relocate_done /* skip relocation */
- mov r1, r6 /* r1 <- scratch for copy loop */
ldr r2, =__image_copy_end /* r2 <- source end address */
copy_loop:
- ldmia r0!, {r10-r11} /* copy from source address [r0]*/
- stmia r1!, {r10-r11} /* copy to target address [r1]*/
- cmp r0, r2 /* until source end address [r2]*/
+ ldmia r1!, {r10-r11} /* copy from source address [r1]*/
+ stmia r0!, {r10-r11} /* copy to target address [r0]*/
+ cmp r1, r2 /* until source end address [r2]*/
blo copy_loop
/*
* fix .rel.dyn relocations
*/
- ldr r10, =__dynsym_start/* r10 <- sym table ofs */
ldr r2, =__rel_dyn_start/* r2 <- rel dyn start ofs */
ldr r3, =__rel_dyn_end /* r3 <- rel dyn end ofs */
fixloop:
- ldr r0, [r2]/* r0 <- SRC location to fix up */
- add r0, r0, r9 /* r0 <- DST location to fix up */
- ldr r1, [r2, #4]
- and r7, r1, #0xff
- cmp r7, #23 /* relative fixup? */
- beq fixrel
- cmp r7, #2 /* absolute fixup? */
- beq fixabs
- /* ignore unknown type of fixup */
- b fixnext
-fixabs:
- /* absolute fix: set location to (offset) symbol value */
- mov r1, r1, LSR #4 /* r1 <- symbol index in .dynsym */
- add r1, r10, r1 /* r1 <- address of symbol in table */
- ldr r1, [r1, #4]/* r1 <- symbol value */
- add r1, r1, r9 /* r1 <- relocated sym addr */
- b fixnext
-fixrel:
+ ldmia r2!, {r0-r1}/* (r0,r1) <- (SRC location,fixup) */
+ and r1, r1, #0xff /* r1 <- fixup type */
+ cmp r1, #23 /* relative fixup? */
+ bne fixnext
+
/* relative fix: increase location by offset */
- ldr r1, [r0]
- add r1, r1, r9
+ add r0, r0, r9 /* r0 <- DST location to fix up */
+ ldr r1, [r0]/* r1 <- content to fix up */
+ add r1, r1, r9 /* fix up */
+ str r1, [r0]/* write back fixed-up content */
+
fixnext:
- str r1, [r0]
- add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
cmp r2, r3
blo fixloop
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] arm: make relocation symbols compiler-generated
This change is only done where needed: some linker
scripts may contain relocation symbols yet remain
unchanged.
__rel_dyn_start, __rel_dyn_end and __dynsym_start
each requires its own output section; putting them
in relocation sections changes the sections' nature
which breaks relocation.
Signed-off-by: Albert ARIBAUD
---
arch/arm/cpu/ixp/u-boot.lds| 18 +++---
arch/arm/cpu/u-boot.lds| 18 +++---
arch/arm/lib/relocate.S| 16 +++-
arch/arm/lib/sections.c|3 +++
board/actux1/u-boot.lds| 18 +++---
board/actux2/u-boot.lds| 18 +++---
board/actux3/u-boot.lds| 18 +++---
board/dvlhost/u-boot.lds | 18 +++---
board/freescale/mx31ads/u-boot.lds | 18 +++---
9 files changed, 111 insertions(+), 34 deletions(-)
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 514c6ec..933928a 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -60,14 +60,26 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
+ }
+
+ .dynsym_start :
+ {
+ *(.__dynsym_start)
}
.dynsym : {
- __dynsym_start = .;
*(.dynsym)
}
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 8950f5a..4ba2c38 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -62,14 +62,26 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
+ }
+
+ .dynsym_start :
+ {
+ *(.__dynsym_start)
}
.dynsym : {
- __dynsym_start = .;
*(.dynsym)
}
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 2f22c8c..818735c 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -54,12 +54,9 @@ copy_loop:
/*
* fix .rel.dyn relocations
*/
- ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */
- add r10, r10, r9/* r10 <- sym table in FLASH */
- ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */
- add r2, r2, r9 /* r2 <- rel dyn start in FLASH */
- ldr r3, _rel_dyn_end_ofs/* r3 <- rel dyn end ofs */
- add r3, r3, r9 /* r3 <- rel dyn end in FLASH */
+ ldr r10, =__dynsym_start/* r10 <- sym table ofs */
+ ldr r2, =__rel_dyn_start/* r2 <- rel dyn start ofs */
+ ldr r3, =__rel_dyn_end /* r3 <- rel dyn end ofs */
fixloop:
ldr r0, [r2]/* r0 <- SRC location to fix up */
add r0, r0, r9 /* r0 <- DST location to fix up */
@@ -98,11 +95,4 @@ relocate_done:
bxlr
#endif
-_rel_dyn_start_ofs:
- .word __rel_dyn_start - relocate_code
-_rel_dyn_end_ofs:
- .word __rel_dyn_end - relocate_code
-_dynsym_start_ofs:
- .word __dynsym_start - relocate_code
-
ENDPROC(relocate_code)
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 03e846f..d065942 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -39,3 +39,6 @@ char __bss_start[0] __attribute__((section(".__bss_start")));
char __bss_end[0] __attribute__((section(".__bss_end")));
char __image_copy_start[0] __attribute__((section(".__image_copy_start")));
char __image_copy_end[0] __attribute__((section(".__image_copy_end")));
+char __rel_dyn_start[0] __attribute__((section(".__rel_dyn_start")));
+char __rel_dyn_end[0] __attribute__((section(".__rel_dyn_end")));
+char __dynsym_start[0] __attribute__((section(".__dynsym_start")));
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index 80db9ff..f9b8c54 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -68,14 +68,26 @@ SECTIONS
*(.__image_copy_end)
}
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
.rel.dyn : {
- __rel_dyn_start = .;
*(.rel*)
- __rel_dyn_end = .;
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
+ }
+
+ .dynsym_start :
+ {
+ *(.__dynsym_start)
}
.dynsym : {
- __dynsym_start = .;
*(.dynsym)
[U-Boot] [PATCH 2/5] arm: make __image_copy_{start, end} compiler-generated
This change is only done where needed: some linker
scripts may contain __image_copy_{start,end} yet
remain unchanged.
Also, __image_copy_end needs its own section; putting
it in relocation sections changes the sections's nature
which breaks relocation.
Signed-off-by: Albert ARIBAUD
---
arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 +-
arch/arm/cpu/ixp/u-boot.lds|6 +-
arch/arm/cpu/u-boot.lds|7 +--
arch/arm/lib/relocate.S|7 ++-
arch/arm/lib/sections.c|2 ++
board/actux1/u-boot.lds|6 +-
board/actux2/u-boot.lds|6 +-
board/actux3/u-boot.lds|6 +-
board/dvlhost/u-boot.lds |6 +-
board/freescale/mx31ads/u-boot.lds |6 +-
10 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
index cf55bf7..367c805 100644
--- a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
+++ b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
@@ -31,6 +31,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
+ *(.__image_copy_start)
arch/arm/cpu/arm920t/start.o (.text*)
/* the EP93xx expects to find the pattern 'CRUS' at 0x1000 */
. = 0x1000;
@@ -56,7 +57,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end)
+ }
__bss_start = .;
.bss : { *(.bss*) }
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 553589c..514c6ec 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -31,6 +31,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
+ *(.__image_copy_start)
arch/arm/cpu/ixp/start.o(.text*)
*(.text*)
}
@@ -54,7 +55,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end)
+ }
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index d9bbee3..8950f5a 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -33,7 +33,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
- __image_copy_start = .;
+ *(.__image_copy_start)
CPUDIR/start.o (.text*)
*(.text*)
}
@@ -57,7 +57,10 @@ SECTIONS
. = ALIGN(4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end)
+ }
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 9e91fae..2f22c8c 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -39,12 +39,11 @@
ENTRY(relocate_code)
mov r6, r0 /* save addr of destination */
- ldr r0, =_start
+ ldr r0, =__image_copy_start /* r0 <- source start address */
subsr9, r6, r0 /* r9 <- relocation offset */
beq relocate_done /* skip relocation */
mov r1, r6 /* r1 <- scratch for copy loop */
- ldr r3, _image_copy_end_ofs
- add r2, r0, r3 /* r2 <- source end address */
+ ldr r2, =__image_copy_end /* r2 <- source end address */
copy_loop:
ldmia r0!, {r10-r11} /* copy from source address [r0]*/
@@ -99,8 +98,6 @@ relocate_done:
bxlr
#endif
-_image_copy_end_ofs:
- .word __image_copy_end - relocate_code
_rel_dyn_start_ofs:
.word __rel_dyn_start - relocate_code
_rel_dyn_end_ofs:
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index e52fec9..03e846f 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -37,3 +37,5 @@
char __bss_start[0] __attribute__((section(".__bss_start")));
char __bss_end[0] __attribute__((section(".__bss_end")));
+char __image_copy_start[0] __attribute__((section(".__image_copy_start")));
+char __image_copy_end[0] __attribute__((section(".__image_copy_end")));
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index ef4a25b..80db9ff 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -30,6 +30,7 @@ SECTIONS
. = ALIGN (4);
.text : {
+ *(.__image_copy_start)
arch/arm/cpu/ixp/start.o(.text*)
net/libnet.o(.text*)
board/actux1/libactux1.o(.text*)
@@ -62,7 +63,10 @@ SECTIONS
. = ALIGN (4);
- __image_copy_end = .;
+ .image_copy_end :
+ {
+ *(.__image_copy_end)
+ }
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/board/actux2/u-boot.lds b/board/actux2/u-boot.lds
index
Re: [U-Boot] [PATCH 0/5] Optimize ARM relocation
On Tue, 14 May 2013 22:02:55 +0200, Albert ARIBAUD wrote: > *** NOTE: this series applies over the 'Factorize > ARM relocate_code instances' series. > > This series optimizes relocation by ensuring ARM > binaries only use one type of relocation record, > R_ARM_RELATIVE., then optimizing relocation code > accordingly. > > The only known case where relocation records other > than R_ARM_RELATIVE are generated is when a reference > is made to a symbol defined in the linker script, e.g. > __image_copy_start, __image_copy_end, __rel_dyn_start, > __rel_dyn_end, and __dynsym_start. > > Moving the definition of these symbols from the linker > scripts into a C module causes their references' types > to become R_ARM_RELATIVE. > > First, arch/arm/lib/bss.c is replaced by a more generic > arch/arm/lib/sections.c where all section symbols will > be defined. > > Second, __image_copy_start and __image_copy_end symbols > are moved from linker scripts to arch/arm/lib/sections.c > > Third, __rel_dyn_start, __rel_dyn_end and __synsym_start > are moved from linker scripts into arch/arm/lib/sections.c > > Fourth, a check is added to the build system to ensure > that ELF U-Boot binaries only use R_ARM_RELATIVE records. > > Last, relocate_code is optimized Hmm, it seems I need to see my work posted on the list to discover how I could have done it better... I just noticed that if ARM binaries only have R_ARM_RELATIVE record types, then all the .dynsym sections can actually be dropped from the binaries. So, if I reorder the series and put patch 5/5 first, then I can eliminate patch 3/5, or more to the point, replace it with one which eliminates all dynsym stuff from linker scripts, further reducing code size. That'll go in V2... Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/10] PXE support updates
Hi Rob, On Tue, May 14, 2013 at 2:48 PM, Rob Herring wrote: > On Sun, Dec 2, 2012 at 9:00 PM, Rob Herring wrote: >> From: Rob Herring >> >> This is a series of various enhancements and fixes for u-boot pxe support. >> These patches are a result of testing with server side tools like Cobbler >> and ubuntu MAAS. >> >> Rob >> >> Rob Herring (10): >> pxe: Use ethact setting for pxe >> pxe: make string parameters const >> pxe: fix handling of different localboot values >> bootz: un-staticize do_bootz >> pxe: use bootz instead of bootm when enabled >> pxe: always display a menu when present >> pxe: simplify menu display and selection >> pxe: add support for ontimeout token >> pxe: add support for per arch and SoC default paths >> pxe: add ipappend support >> >> common/cmd_bootm.c |2 +- >> common/cmd_pxe.c | 210 >> >> include/command.h |2 + >> 3 files changed, 132 insertions(+), 82 deletions(-) > > Is someone going to pick these patches up? The single comment by > Wolfgang I've addressed. Yes... I'll pick these up... apologies for the delays. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/14/2013 03:42 PM, Lubomir Popov wrote: > Hi Tom, > > Just a couple of things to clarify below. > >> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: >>> Hi Tom, >>> >>> On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: > Hi Tom, > > I'm currently busy with other work; on the other hand, > careful rebasing shall require some time, especially the > Palmas stuff. What would be the deadline for a V2 > submission? > > Meanwhile could you please have a look at the (already old) > http://patchwork.ozlabs.org/patch/232743/? A simple patch, > shall be needed if we enable USB (for the uEVM along with > our board). In general, what are your plans regarding USB > (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but >>> do you have a patch around for uEVM still? >>> Not yet (didn't have the opportunity to test, although some >>> uEVMs should be around at MMS). As you know, a patch shall be >>> needed in the uEVM board file along with the common USB stuff. >> >> Yeah, I can test it as well if you write it up, and may find the >> time if you point me in the right direction. > OK, shall do it. Thanks! [snip] [snip] >>> Currently the scrm struct is defined for OMAP4 in the >>> asm/arch-omap4/clocks.h file and I have already done the same >>> for OMAP5 by analogy. I must admit however that this approach >>> does not correspond to the latest way by which groups of OMAP >>> hardware regs are defined, prcm in particular - a struct in >>> omap_common.h, holding only the required regs, no padding and >>> such garbage, and an init with the physical addresses in a .c >>> file for the particular SoC (prcm-regs.c). But still the Panda >>> board, for example, uses the old way for scrm. Therefore I did >>> it the same for OMAP5, which was easier (I'm old and lazy ;) >>> ). >> >> Yes, I'm OK starting off with moving things into omap_common.h >> as-is and then updating them a bit later ala pcrm-regs.c. > Who is starting off, me or you? ;) Since your series needs it (so we aren't writing to magic locations which isn't allowed), you please. Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkqBgAAoJENk4IS6UOR1WFVcQAIo9DgrABUaAwOTfYFXVlGQ6 /MFyQvtwFYtEwW1xtDZ8RWuv1zGI26IIw4XH+xhspj50w7ma9lji575U/tyQCtrN G6xMW8bH/8Cxj+kFUcgeNXSqAF0OLOz8Rvow9dSW2RpnOu3yOPKnvgxjV974x595 IfBK26Xo5ldR6qX12EIwAfHZVRow97Kk25LOBoqR+qxTBrtKPWzywXyvTi94qY/b jcy9L17AQQvNWQofps7noDsFM+acWlQxsTkjbdkynDu8gIQC0JZ8cEUPZ9XsYg+D 8SvXeY5ntCEOwxvB2TZ2GNC9/J5fVXMmewrexH1AdjsO1d0529ZjCX0995whV2pJ xCYi0FAtXKW0fm1gitMXZ0J/pHzNdsr1s+rV0iUtppbhh9mQ+NQplXVPevB0UrWH 1UHHxe1Hsc5ZJHJRvvFyVAo9ySdZ85zrS6+TlMwfjK1LWtQmPJ0DA1Cddz8m/BI+ 6ebQ36qgJuO990YhQ9GlfOV1rjp3RhrCmb+JKwjMN0OahnfAEvp4osCvbMClDXqT VL83+gP1lKJ47B2VfuyqXW+ETBV6hhLprItj8wx+0sJx0rNKc98Q61pO8XSPZwoE 8hWzqeY7Dmlp2QxQ3ZyD5w5+DECGbj7ihCICkjquwHSB5v1R4R1XIwlV/3cd/Mm4 SMnFtv8rUQsfzi48bGt4 =lJAv -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] lcd: add functions to setup up simplefb device tree
On Mon, May 13, 2013 at 7:33 PM, Stephen Warren wrote: > simple-framebuffer is a new device tree binding that describes a pre- > configured frame-buffer memory region and its format. The Linux kernel > contains a driver that supports this binding. Implement functions to > create a DT node (or fill in an existing node) with parameters that > describe the framebuffer format that U-Boot is using. > > This will be immediately used by the Raspberry Pi board in U-Boot, and > likely will be used by the Samsung ARM ChromeBook support soon too. It > could well be used by many other boards (e.g. Tegra boards with built-in > LCD panels, which aren't yet supported by the Linux kernel). > > Signed-off-by: Stephen Warren Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere
On Mon, May 13, 2013 at 03:12:07PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini wrote: > > On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote: > > > >> Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes > >> different boards compile different versions of the source code, meaning > >> that we must build all boards to check for failures. It is easy to misspell > >> an #ifdef and there is not as much checking of this by the compiler. > >> Multiple > >> dependent #ifdefs are harder to do than with if..then..else. Variable > >> declarations must be #idefed as well as the code that uses them, often much > >> later in the file/function. #ifdef indents don't match code indents and > >> have their own separate indent feature. Overall, excessive use of #idef > >> hurts readability and makes the code harder to modify and refactor. For > >> people coming newly into the code base, #ifdefs can be a big barrier. > >> > >> The use of #ifdef in U-Boot has possibly got a little out of hand. In an > >> attempt to turn the tide, this series includes a patch which provides a way > >> to make CONFIG macros available to C code without using the preprocessor. > >> This makes it possible to use standard C conditional features such as > >> if/then instead of #ifdef. A README update exhorts compliance. > > > > OK, this is true. Looking over the series, a number of the patches are > > just general fixes / improvements that don't depend on the autoconf_... > > work. Lets split this out now and take them in now as they seem like > > reviewable by inspection code. > > Well sorry I didn't make time to get this done last time. I can do > this now or... > > > > > For the approach itself, I'm not sure which is best here. In a lot of > > cases we're trading an #ifdef for adding a level of indent to already > > pretty indented code and that feels like a wash, in terms of readability > > to me. We probably need to re-factor some of the code in question there > > too for readability, then see about using autoconf_... type things, or > > maybe something else. > > I think you are saying to do the rearrangement and clean-up first, > then add autoconf afterwards. I can do that but really I am wondering > what you think of the autoconf concept? The Kconfig stuff is related > here too, but first I would like to decide on what to do with the > #ifdefs. I think a lot of our #ifdefery is a problem of code that's in need of some love and re-org and cleaning and updating. One of the old style rules I still try and follow is that after a few levels of indent code doesn't read well. Also big nested #ifdefs don't read well. So we're trading one in for the other. But your series showed a lot of places where we can re-factor things to improve readability. So lets go that way. Then we can see if there's still things to improve on, and what dead code we still have around. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere
Hi Tom, On Tue, May 14, 2013 at 2:21 PM, Tom Rini wrote: > On Mon, May 13, 2013 at 03:12:07PM -0700, Simon Glass wrote: >> Hi Tom, >> >> On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini wrote: >> > On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote: >> > >> >> Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes >> >> different boards compile different versions of the source code, meaning >> >> that we must build all boards to check for failures. It is easy to >> >> misspell >> >> an #ifdef and there is not as much checking of this by the compiler. >> >> Multiple >> >> dependent #ifdefs are harder to do than with if..then..else. Variable >> >> declarations must be #idefed as well as the code that uses them, often >> >> much >> >> later in the file/function. #ifdef indents don't match code indents and >> >> have their own separate indent feature. Overall, excessive use of #idef >> >> hurts readability and makes the code harder to modify and refactor. For >> >> people coming newly into the code base, #ifdefs can be a big barrier. >> >> >> >> The use of #ifdef in U-Boot has possibly got a little out of hand. In an >> >> attempt to turn the tide, this series includes a patch which provides a >> >> way >> >> to make CONFIG macros available to C code without using the preprocessor. >> >> This makes it possible to use standard C conditional features such as >> >> if/then instead of #ifdef. A README update exhorts compliance. >> > >> > OK, this is true. Looking over the series, a number of the patches are >> > just general fixes / improvements that don't depend on the autoconf_... >> > work. Lets split this out now and take them in now as they seem like >> > reviewable by inspection code. >> >> Well sorry I didn't make time to get this done last time. I can do >> this now or... >> >> > >> > For the approach itself, I'm not sure which is best here. In a lot of >> > cases we're trading an #ifdef for adding a level of indent to already >> > pretty indented code and that feels like a wash, in terms of readability >> > to me. We probably need to re-factor some of the code in question there >> > too for readability, then see about using autoconf_... type things, or >> > maybe something else. >> >> I think you are saying to do the rearrangement and clean-up first, >> then add autoconf afterwards. I can do that but really I am wondering >> what you think of the autoconf concept? The Kconfig stuff is related >> here too, but first I would like to decide on what to do with the >> #ifdefs. > > I think a lot of our #ifdefery is a problem of code that's in need of > some love and re-org and cleaning and updating. One of the old style > rules I still try and follow is that after a few levels of indent code > doesn't read well. Also big nested #ifdefs don't read well. So we're > trading one in for the other. But your series showed a lot of places > where we can re-factor things to improve readability. So lets go that > way. Then we can see if there's still things to improve on, and what > dead code we still have around. So are you saying that you are keen on the autoconf idea? > > -- > Tom Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] arm: make relocation symbols compiler-generated
Hi Albert, On Tuesday, May 14, 2013 10:02:58 PM, Albert ARIBAUD wrote: > This change is only done where needed: some linker > scripts may contain relocation symbols yet remain > unchanged. > > __rel_dyn_start, __rel_dyn_end and __dynsym_start > each requires its own output section; putting them > in relocation sections changes the sections' nature > which breaks relocation. > > Signed-off-by: Albert ARIBAUD [...] > diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S > index 2f22c8c..818735c 100644 > --- a/arch/arm/lib/relocate.S > +++ b/arch/arm/lib/relocate.S > @@ -54,12 +54,9 @@ copy_loop: > /* >* fix .rel.dyn relocations >*/ > - ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */ > - add r10, r10, r9/* r10 <- sym table in FLASH */ > - ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */ > - add r2, r2, r9 /* r2 <- rel dyn start in FLASH */ > - ldr r3, _rel_dyn_end_ofs/* r3 <- rel dyn end ofs */ > - add r3, r3, r9 /* r3 <- rel dyn end in FLASH */ > + ldr r10, =__dynsym_start/* r10 <- sym table ofs */ > + ldr r2, =__rel_dyn_start/* r2 <- rel dyn start ofs */ > + ldr r3, =__rel_dyn_end /* r3 <- rel dyn end ofs */ 'ofs' -> 'in FLASH' in the comments of the 3 lines above. > fixloop: > ldr r0, [r2]/* r0 <- SRC location to fix up */ > add r0, r0, r9 /* r0 <- DST location to fix up */ > @@ -98,11 +95,4 @@ relocate_done: > bxlr > #endif > > -_rel_dyn_start_ofs: > - .word __rel_dyn_start - relocate_code > -_rel_dyn_end_ofs: > - .word __rel_dyn_end - relocate_code > -_dynsym_start_ofs: > - .word __dynsym_start - relocate_code > - > ENDPROC(relocate_code) [...] Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere
On Tue, May 14, 2013 at 02:27:32PM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, May 14, 2013 at 2:21 PM, Tom Rini wrote: > > On Mon, May 13, 2013 at 03:12:07PM -0700, Simon Glass wrote: > >> Hi Tom, > >> > >> On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini wrote: > >> > On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote: > >> > > >> >> Many parts of the U-Boot code base are sprinkled with #ifdefs. This > >> >> makes > >> >> different boards compile different versions of the source code, meaning > >> >> that we must build all boards to check for failures. It is easy to > >> >> misspell > >> >> an #ifdef and there is not as much checking of this by the compiler. > >> >> Multiple > >> >> dependent #ifdefs are harder to do than with if..then..else. Variable > >> >> declarations must be #idefed as well as the code that uses them, often > >> >> much > >> >> later in the file/function. #ifdef indents don't match code indents and > >> >> have their own separate indent feature. Overall, excessive use of #idef > >> >> hurts readability and makes the code harder to modify and refactor. For > >> >> people coming newly into the code base, #ifdefs can be a big barrier. > >> >> > >> >> The use of #ifdef in U-Boot has possibly got a little out of hand. In an > >> >> attempt to turn the tide, this series includes a patch which provides a > >> >> way > >> >> to make CONFIG macros available to C code without using the > >> >> preprocessor. > >> >> This makes it possible to use standard C conditional features such as > >> >> if/then instead of #ifdef. A README update exhorts compliance. > >> > > >> > OK, this is true. Looking over the series, a number of the patches are > >> > just general fixes / improvements that don't depend on the autoconf_... > >> > work. Lets split this out now and take them in now as they seem like > >> > reviewable by inspection code. > >> > >> Well sorry I didn't make time to get this done last time. I can do > >> this now or... > >> > >> > > >> > For the approach itself, I'm not sure which is best here. In a lot of > >> > cases we're trading an #ifdef for adding a level of indent to already > >> > pretty indented code and that feels like a wash, in terms of readability > >> > to me. We probably need to re-factor some of the code in question there > >> > too for readability, then see about using autoconf_... type things, or > >> > maybe something else. > >> > >> I think you are saying to do the rearrangement and clean-up first, > >> then add autoconf afterwards. I can do that but really I am wondering > >> what you think of the autoconf concept? The Kconfig stuff is related > >> here too, but first I would like to decide on what to do with the > >> #ifdefs. > > > > I think a lot of our #ifdefery is a problem of code that's in need of > > some love and re-org and cleaning and updating. One of the old style > > rules I still try and follow is that after a few levels of indent code > > doesn't read well. Also big nested #ifdefs don't read well. So we're > > trading one in for the other. But your series showed a lot of places > > where we can re-factor things to improve readability. So lets go that > > way. Then we can see if there's still things to improve on, and what > > dead code we still have around. > > So are you saying that you are keen on the autoconf idea? I'm saying lets clean up the code and see if we still need something like autoconf. It seems to provide the most benefit in terms of readability in places that could read a lot better with some clean up and refactoring before we add new tools to the pile. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] arm: ensure u-boot only uses relative relocations
Hi Albert,
On Tuesday, May 14, 2013 10:02:59 PM, Albert ARIBAUD wrote:
> Add a Makefile target ('checkarmreloc') which
> fails of the ELF binary contains relocation records
> of types other than R_ARM_RELATIVE.
>
> Signed-off-by: Albert ARIBAUD
> ---
> Makefile |7 +++
> arch/arm/config.mk |5 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index c52f0f1..9aa5755 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE)
> $(MAKE) -C $@ all
> endif# config.mk
>
> +# ARM relocations should all be R_ARM_RELATIVE.
> +checkarmreloc: $(obj)u-boot
> + @if test "R_ARM_RELATIVE" != \
> + "`readelf -r $(obj)u-boot | cut -d ' ' -f 4 | grep R_ARM | sort
> -u`"; \
^
or $$< to avoid a duplicate?
> + then echo "$(obj)u-boot contains relocations other than \
^
or $$< too, or no $(obj) prefix at all for this
message?
> + R_ARM_RELATIVE"; false; fi
> +
> $(VERSION_FILE):
> @mkdir -p $(dir $(VERSION_FILE))
> @( localvers='$(shell $(TOPDIR)/tools/setlocalversion
> $(TOPDIR))' ; \
> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> index 461899e..5b7a602 100644
> --- a/arch/arm/config.mk
> +++ b/arch/arm/config.mk
> @@ -106,3 +106,8 @@ ifeq ($(GAS_BUG_12532),y)
> PLATFORM_RELFLAGS += -fno-optimize-sibling-calls
> endif
> endif
> +
> +# check that only R_ARM_RELATIVE relocations are generated
> +ifneq ($(CONFIG_SPL_BUILD),y)
> +ALL-y+= checkarmreloc
> +endif
> --
> 1.7.10.4
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere
On Tue, May 14, 2013 at 3:15 PM, Tom Rini wrote: > On Tue, May 14, 2013 at 02:27:32PM -0700, Simon Glass wrote: >> Hi Tom, >> >> On Tue, May 14, 2013 at 2:21 PM, Tom Rini wrote: >> > On Mon, May 13, 2013 at 03:12:07PM -0700, Simon Glass wrote: >> >> Hi Tom, >> >> >> >> On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini wrote: >> >> > On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote: >> >> > >> >> >> Many parts of the U-Boot code base are sprinkled with #ifdefs. This >> >> >> makes >> >> >> different boards compile different versions of the source code, meaning >> >> >> that we must build all boards to check for failures. It is easy to >> >> >> misspell >> >> >> an #ifdef and there is not as much checking of this by the compiler. >> >> >> Multiple >> >> >> dependent #ifdefs are harder to do than with if..then..else. Variable >> >> >> declarations must be #idefed as well as the code that uses them, often >> >> >> much >> >> >> later in the file/function. #ifdef indents don't match code indents and >> >> >> have their own separate indent feature. Overall, excessive use of #idef >> >> >> hurts readability and makes the code harder to modify and refactor. For >> >> >> people coming newly into the code base, #ifdefs can be a big barrier. >> >> >> >> >> >> The use of #ifdef in U-Boot has possibly got a little out of hand. In >> >> >> an >> >> >> attempt to turn the tide, this series includes a patch which provides >> >> >> a way >> >> >> to make CONFIG macros available to C code without using the >> >> >> preprocessor. >> >> >> This makes it possible to use standard C conditional features such as >> >> >> if/then instead of #ifdef. A README update exhorts compliance. >> >> > >> >> > OK, this is true. Looking over the series, a number of the patches are >> >> > just general fixes / improvements that don't depend on the autoconf_... >> >> > work. Lets split this out now and take them in now as they seem like >> >> > reviewable by inspection code. >> >> >> >> Well sorry I didn't make time to get this done last time. I can do >> >> this now or... >> >> >> >> > >> >> > For the approach itself, I'm not sure which is best here. In a lot of >> >> > cases we're trading an #ifdef for adding a level of indent to already >> >> > pretty indented code and that feels like a wash, in terms of readability >> >> > to me. We probably need to re-factor some of the code in question there >> >> > too for readability, then see about using autoconf_... type things, or >> >> > maybe something else. >> >> >> >> I think you are saying to do the rearrangement and clean-up first, >> >> then add autoconf afterwards. I can do that but really I am wondering >> >> what you think of the autoconf concept? The Kconfig stuff is related >> >> here too, but first I would like to decide on what to do with the >> >> #ifdefs. >> > >> > I think a lot of our #ifdefery is a problem of code that's in need of >> > some love and re-org and cleaning and updating. One of the old style >> > rules I still try and follow is that after a few levels of indent code >> > doesn't read well. Also big nested #ifdefs don't read well. So we're >> > trading one in for the other. But your series showed a lot of places >> > where we can re-factor things to improve readability. So lets go that >> > way. Then we can see if there's still things to improve on, and what >> > dead code we still have around. >> >> So are you saying that you are keen on the autoconf idea? > > I'm saying lets clean up the code and see if we still need something > like autoconf. It seems to provide the most benefit in terms of > readability in places that could read a lot better with some clean up > and refactoring before we add new tools to the pile. > Yet another great advantage of autoconf is that it ensures a consistent combination of the configuration options, with the status quo it is so easy to make a mistake and create a deficient configuration. --vb > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v3] Please pull u-boot-mpc85xx.git
The following changes since commit a661b99dbc35e725f229a7b8e189ca21304ba026: Merge branch 'master' of git://git.denx.de/u-boot-x86 (2013-05-13 18:17:39 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to f63d638dad5dd13f445d1e87ce824d4a7cd61f79: T4240/eth: fix SGMII card PHY address (2013-05-14 16:13:25 -0500) Tested on 85xx and 83xx. Andy Fleming (2): powerpc/mpc85xx: Add definitions for HDBCR registers e6500: Move L1 enablement after L2 enablement Ed Swarthout (1): powerpc/t4qds: Fix disabling remote I2C connection Roy Zang (4): T4/serdes: fix the serdes clock frequency T4/SerDes: correct the SATA index T4/USB: Add USB 2.0 UTMI dual phy support T4/usb: move usb 2.0 utmi dual phy init code to cpu_init.c Sandeep Singh (1): powerpc/B4860: Corrected FMAN1 operating frequency print at u-boot Shaohui Xie (7): powerpc/t4240qds: Fix SPI flash type powerpc/t4240qds: fix XAUI card PHY address Fman/t4240: some fix for 10G XAUI powerpc/85xx: add missing QMAN frequency calculation net/phy: add VSC8574 support T4240/net: use QSGMII card PHY address by default T4240/eth: fix SGMII card PHY address Shengzhou Liu (3): t4240qds/eth: fixup ethernet for t4240qds net/fm: fixup ethernet for mEMAC powerpc/85xx: fix build error introduced by serdes_get_prtcl York Sun (14): powerpc/mpc85xx: Update corenet global utility block registers powerpc/t4240qds: Update DDR timing table powerpc/mpc8xxx: Fix DDR 3-way interleaving powerpc/mpc85xx: Fix portal setup powerpc/t4240qds: Add voltage ID support powerpc/corenet2: Print SerDes protocol in decimal powerpc/mpc85xx: Fix PIR parsing for chassis2 powerpc/t4240: Fix SerDes protocol arrays with const prefix powerpc/mpc85xx: Add T4160 SoC powerpc/t4240qds: Move SoC define into boards.cfg powerpc: Add T4160QDS powerpc/mpc85xx: Update workaround for DDR erratum A-004934 powerpc/mpc8xxx: Allow board file to override DDR address assignment powerpc/b4860qds: Assign DDR address in board file arch/powerpc/cpu/mpc85xx/Makefile |3 + arch/powerpc/cpu/mpc85xx/cpu_init.c| 22 ++ arch/powerpc/cpu/mpc85xx/ddr-gen3.c|2 +- arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c |2 +- arch/powerpc/cpu/mpc85xx/portals.c | 36 ++- arch/powerpc/cpu/mpc85xx/release.S | 14 +- arch/powerpc/cpu/mpc85xx/speed.c | 12 + arch/powerpc/cpu/mpc85xx/start.S | 102 +++ arch/powerpc/cpu/mpc85xx/t4240_serdes.c| 150 +- arch/powerpc/cpu/mpc8xxx/cpu.c |1 + arch/powerpc/cpu/mpc8xxx/ddr/main.c| 26 +- arch/powerpc/include/asm/config_mpc85xx.h | 36 ++- arch/powerpc/include/asm/immap_85xx.h | 66 - arch/powerpc/include/asm/processor.h | 11 + board/freescale/b4860qds/ddr.c | 72 + board/freescale/t4qds/ddr.c| 56 ++-- board/freescale/t4qds/eth.c| 356 +++- board/freescale/t4qds/t4240qds_qixis.h |2 +- board/freescale/t4qds/t4qds.c | 237 +++- boards.cfg |9 +- drivers/net/fm/Makefile|1 + drivers/net/fm/eth.c |2 + drivers/net/fm/fm.h|2 + drivers/net/fm/init.c | 31 +++ drivers/net/fm/t4240.c | 14 +- drivers/net/phy/vitesse.c | 67 + include/configs/T4240QDS.h |1 - include/configs/t4qds.h| 42 ++- include/fm_eth.h |4 +- include/phy.h |2 + 30 files changed, 1154 insertions(+), 227 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx6qsabreauto: Add i2c to mx6qsabreauto board
Hello Renato, When sending patches for Freescale i.MX boards please add Fabio in Cc (just did). On Tue, May 14, 2013 at 1:01 AM, Renato Frias wrote: > Add i2c2 and 3 to mx6qsabreauto board, i2c3 is multiplexed > use gpio to set steering. > > Signed-off-by: Renato Frias Code seems fine, I don't have the board so I cannot test. Reviewed-by: Otavio Salvador -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere
On Tue, May 14, 2013 at 03:22:04PM -0700, Vadim Bendebury wrote: > On Tue, May 14, 2013 at 3:15 PM, Tom Rini wrote: > > On Tue, May 14, 2013 at 02:27:32PM -0700, Simon Glass wrote: > >> Hi Tom, > >> > >> On Tue, May 14, 2013 at 2:21 PM, Tom Rini wrote: > >> > On Mon, May 13, 2013 at 03:12:07PM -0700, Simon Glass wrote: > >> >> Hi Tom, > >> >> > >> >> On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini wrote: > >> >> > On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote: > >> >> > > >> >> >> Many parts of the U-Boot code base are sprinkled with #ifdefs. This > >> >> >> makes > >> >> >> different boards compile different versions of the source code, > >> >> >> meaning > >> >> >> that we must build all boards to check for failures. It is easy to > >> >> >> misspell > >> >> >> an #ifdef and there is not as much checking of this by the compiler. > >> >> >> Multiple > >> >> >> dependent #ifdefs are harder to do than with if..then..else. Variable > >> >> >> declarations must be #idefed as well as the code that uses them, > >> >> >> often much > >> >> >> later in the file/function. #ifdef indents don't match code indents > >> >> >> and > >> >> >> have their own separate indent feature. Overall, excessive use of > >> >> >> #idef > >> >> >> hurts readability and makes the code harder to modify and refactor. > >> >> >> For > >> >> >> people coming newly into the code base, #ifdefs can be a big barrier. > >> >> >> > >> >> >> The use of #ifdef in U-Boot has possibly got a little out of hand. > >> >> >> In an > >> >> >> attempt to turn the tide, this series includes a patch which > >> >> >> provides a way > >> >> >> to make CONFIG macros available to C code without using the > >> >> >> preprocessor. > >> >> >> This makes it possible to use standard C conditional features such as > >> >> >> if/then instead of #ifdef. A README update exhorts compliance. > >> >> > > >> >> > OK, this is true. Looking over the series, a number of the patches > >> >> > are > >> >> > just general fixes / improvements that don't depend on the > >> >> > autoconf_... > >> >> > work. Lets split this out now and take them in now as they seem like > >> >> > reviewable by inspection code. > >> >> > >> >> Well sorry I didn't make time to get this done last time. I can do > >> >> this now or... > >> >> > >> >> > > >> >> > For the approach itself, I'm not sure which is best here. In a lot of > >> >> > cases we're trading an #ifdef for adding a level of indent to already > >> >> > pretty indented code and that feels like a wash, in terms of > >> >> > readability > >> >> > to me. We probably need to re-factor some of the code in question > >> >> > there > >> >> > too for readability, then see about using autoconf_... type things, or > >> >> > maybe something else. > >> >> > >> >> I think you are saying to do the rearrangement and clean-up first, > >> >> then add autoconf afterwards. I can do that but really I am wondering > >> >> what you think of the autoconf concept? The Kconfig stuff is related > >> >> here too, but first I would like to decide on what to do with the > >> >> #ifdefs. > >> > > >> > I think a lot of our #ifdefery is a problem of code that's in need of > >> > some love and re-org and cleaning and updating. One of the old style > >> > rules I still try and follow is that after a few levels of indent code > >> > doesn't read well. Also big nested #ifdefs don't read well. So we're > >> > trading one in for the other. But your series showed a lot of places > >> > where we can re-factor things to improve readability. So lets go that > >> > way. Then we can see if there's still things to improve on, and what > >> > dead code we still have around. > >> > >> So are you saying that you are keen on the autoconf idea? > > > > I'm saying lets clean up the code and see if we still need something > > like autoconf. It seems to provide the most benefit in terms of > > readability in places that could read a lot better with some clean up > > and refactoring before we add new tools to the pile. > > > > Yet another great advantage of autoconf is that it ensures a > consistent combination of the configuration options, with the status > quo it is so easy to make a mistake and create a deficient > configuration. There are things I like about the concept, but I really want to see the problem areas in question made more readable as it will both help in general, and if we do make this conversion later, make the conversion easier as we'll hopefully kill off some of the nested and tricky ifdefs. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add support for Congatec Conga-QEVAl board
Hello Leo,
On Tue, May 14, 2013 at 6:53 AM, SARTRE Leo wrote:
> Add minimal support (only boot from mmc device) for the Congatec
> Conga-QEVAl Evaluation Carrier Board with a conga-Qmx6 module.
>
> Signed-off-by: Leo Sartre
Please add Stefano (i.MX custodian) to Cc when sending i.MX patches.
> diff --git a/board/congatec/cgtqmx6/Makefile b/board/congatec/cgtqmx6/Makefile
I'd use cgtgmx6eval as it is indeed Carrier Board specific.
...
> +++ b/board/congatec/cgtqmx6/README
> @@ -0,0 +1,28 @@
> +U-Boot for the Congatec Conga-QEVAl Evaluation Carrier board
> +
> +This file contains information for the port of U-Boot to the Congatec
> +Conga-QEVAl Evaluation Carrier board.
> +
> +1. Boot source, boot from SD card
> +-
> +
> +This version of u-boot works only on the SD card. By default, the
> +Congatec board can boot only from the SPI-NOR.
> +But, with the u-boot version provided with the board you can write boot
> +registers to force the board to reboot and boot from the SD slot. If
> +"bmode" command is not available from your pre-installed u-boot, these
> +instruction will produce the same effect:
> +
> +conga-QMX6 U-Boot > mw.l 0x20d8040 0x3850
> +conga-QMX6 U-Boot > mw.l 0x020d8044 0x1000
> +conga-QMX6 U-Boot > reset
> +resetting ...
> +
> +The the board will reboot and, if you burnt your SD correctly the
> +board will use u-boot that live into the SD
..., if you have written your SD correctly ...
> +To copy the resulting u-boot.imx to the SD card:
> +
> + sudo dd if=u-boot.imx of=/dev/xxx bs=512 seek=2&&sudo sync
I'd not add 'sudo' prefix. Some people may run it as root already or
have given rights to write to the block device. Please remove the '&&
sudo sync' from it as well.
> +Note: Replace xxx with the device representing the SD card in your system.
> diff --git a/board/congatec/cgtqmx6/cgtqmx6.c
> b/board/congatec/cgtqmx6/cgtqmx6.c
> new file mode 100644
> index 000..d05d529
> --- /dev/null
> +++ b/board/congatec/cgtqmx6/cgtqmx6.c
> @@ -0,0 +1,185 @@
> +/*
> + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This file is based on mx6qsabrelite.c
> + * Copyright (C) 2013, Adeneo Embedded
> + * Leo Sartre,
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
> + PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |\
> + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
> +
> +#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
> + PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW |\
> + PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
> +
> +int dram_init(void)
> +{
> + gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
> +
> + return 0;
> +}
> +
> +iomux_v3_cfg_t const uart2_pads[] = {
> + MX6_PAD_EIM_D26__UART2_TXD | MUX_PAD_CTRL(UART_PAD_CTRL),
> + MX6_PAD_EIM_D27__UART2_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
> +};
> +
> +iomux_v3_cfg_t const usdhc2_pads[] = {
> + MX6_PAD_SD2_CLK__USDHC2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD2_CMD__USDHC2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD2_DAT0__USDHC2_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD2_DAT1__USDHC2_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD2_DAT2__USDHC2_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD2_DAT3__USDHC2_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_GPIO_4__GPIO_1_4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> +};
> +
> +iomux_v3_cfg_t const usdhc4_pads[] = {
> + MX6_PAD_SD4_CLK__USDHC4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD4_CMD__USDHC4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD4_DAT0__USDHC4_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD4_DAT1__USDHC4_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD4_DAT2__USDHC4_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD4_DAT3__USDHC4_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> + MX6_PAD_SD4_D
[U-Boot] [PATCH] sandbox: block driver using host file/device as backing store
A simple "host" block driver using any host file/device
as backing store.
The mapping is established using the "sb bind" command
Signed-off-by: Henrik Nordstrom
---
common/cmd_sandbox.c | 10 +++-
disk/part.c| 20 ++-
drivers/block/Makefile | 1 +
drivers/block/sandbox.c| 130 +
include/config_fallbacks.h | 3 +-
include/configs/sandbox.h | 2 +
include/part.h | 3 ++
7 files changed, 150 insertions(+), 19 deletions(-)
create mode 100644 drivers/block/sandbox.c
diff --git a/common/cmd_sandbox.c b/common/cmd_sandbox.c
index 206a486..492d569 100644
--- a/common/cmd_sandbox.c
+++ b/common/cmd_sandbox.c
@@ -32,9 +32,16 @@ static int do_sandbox_ls(cmd_tbl_t *cmdtp, int flag, int
argc,
return do_ls(cmdtp, flag, argc, argv, FS_TYPE_SANDBOX);
}
+static int do_sandbox_bind(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ return host_dev_bind(atoi(argv[1]), argv[2]);
+}
+
static cmd_tbl_t cmd_sandbox_sub[] = {
U_BOOT_CMD_MKENT(load, 3, 0, do_sandbox_load, "", ""),
U_BOOT_CMD_MKENT(ls, 3, 0, do_sandbox_ls, "", ""),
+ U_BOOT_CMD_MKENT(bind, 3, 0, do_sandbox_bind, "", ""),
};
static int do_sandbox(cmd_tbl_t *cmdtp, int flag, int argc,
@@ -59,5 +66,6 @@ U_BOOT_CMD(
sb, 6, 1, do_sandbox,
"Miscellaneous sandbox commands",
"load host [ ] - load a file from
host\n"
- "sb ls host - save a file to host"
+ "ls host - save a file to host\n"
+ "bind dev - bind \"host\" device to file"
);
diff --git a/disk/part.c b/disk/part.c
index d73625c..648839b 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -59,6 +59,9 @@ static const struct block_drvr block_drvr[] = {
#if defined(CONFIG_SYSTEMACE)
{ .name = "ace", .get_dev = systemace_get_dev, },
#endif
+#if defined(CONFIG_SANDBOX)
+ { .name = "host", .get_dev = host_get_dev, },
+#endif
{ },
};
@@ -462,23 +465,6 @@ int get_device_and_partition(const char *ifname, const
char *dev_part_str,
int part;
disk_partition_t tmpinfo;
- /*
-* For now, we have a special case for sandbox, since there is no
-* real block device support.
-*/
- if (0 == strcmp(ifname, "host")) {
- *dev_desc = NULL;
- info->start = info->size = info->blksz = 0;
- info->bootable = 0;
- strcpy((char *)info->type, BOOT_PART_TYPE);
- strcpy((char *)info->name, "Sandbox host");
-#ifdef CONFIG_PARTITION_UUIDS
- info->uuid[0] = 0;
-#endif
-
- return 0;
- }
-
/* If no dev_part_str, use bootdevice environment variable */
if (!dev_part_str || !strlen(dev_part_str) ||
!strcmp(dev_part_str, "-"))
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index f1ebdcc..2d2fb55 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_SATA_SIL) += sata_sil.o
COBJS-$(CONFIG_IDE_SIL680) += sil680.o
COBJS-$(CONFIG_SCSI_SYM53C8XX) += sym53c8xx.o
COBJS-$(CONFIG_SYSTEMACE) += systemace.o
+COBJS-$(CONFIG_SANDBOX) += sandbox.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/block/sandbox.c b/drivers/block/sandbox.c
new file mode 100644
index 000..185cee8
--- /dev/null
+++ b/drivers/block/sandbox.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright (C) 2013 Henrik Nordstrom
+ *
+ * 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
+#include
+#include
+#include
+
+#ifndef CONFIG_HOST_MAX_DEVICES
+#define CONFIG_HOST_MAX_DEVICES 4
+#endif
+
+static struct host_block_dev {
+ block_dev_desc_t blk_dev;
+ char *filename;
+ int fd;
+} host_devices[CONFIG_HOST_MAX_DEVICES];
+
+static struct host_block_dev *
+find_host_device(int dev)
+{
+ if (dev >= 0 && dev < CONFIG_HOST_MAX_DEVICES)
+ return &host_devices[dev];
+
+ printf("Invalid host device number\n");
+ return NULL;
+}
+
+static unsigned long host_block_read(int dev, unsigned long start,
+lbaint_t blkcnt, void *buffer)
Re: [U-Boot] [PATCH 5/5] arm: optimize relocate_code routine
Hi Albert,
On Tuesday, May 14, 2013 10:03:00 PM, Albert ARIBAUD wrote:
> Use section symbols directly
> Drop support for R_ARM_ABS32 record types
> Eliminate unneeded intermediate registers
> Optimize relocation table iteration
>
> Signed-off-by: Albert ARIBAUD
> ---
> arch/arm/lib/relocate.S | 45 +++--
> 1 file changed, 15 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> index 818735c..75ee3b4 100644
> --- a/arch/arm/lib/relocate.S
> +++ b/arch/arm/lib/relocate.S
> @@ -37,51 +37,36 @@
> * This function relocates the monitor code.
> */
> ENTRY(relocate_code)
> - mov r6, r0 /* save addr of destination */
>
> - ldr r0, =__image_copy_start /* r0 <- source start address */
> - subsr9, r6, r0 /* r9 <- relocation offset */
> + ldr r1, =__image_copy_start /* r1 <- source start address */
> + subsr9, r0, r1 /* r9 <- relocation offset */
> beq relocate_done /* skip relocation */
> - mov r1, r6 /* r1 <- scratch for copy loop */
> ldr r2, =__image_copy_end /* r2 <- source end address */
>
> copy_loop:
> - ldmia r0!, {r10-r11} /* copy from source address [r0]*/
> - stmia r1!, {r10-r11} /* copy to target address [r1]*/
> - cmp r0, r2 /* until source end address [r2]*/
> + ldmia r1!, {r10-r11} /* copy from source address [r1]*/
> + stmia r0!, {r10-r11} /* copy to target address [r0]*/
> + cmp r1, r2 /* until source end address [r2]*/
> blo copy_loop
>
> /*
>* fix .rel.dyn relocations
>*/
> - ldr r10, =__dynsym_start/* r10 <- sym table ofs */
> ldr r2, =__rel_dyn_start/* r2 <- rel dyn start ofs */
> ldr r3, =__rel_dyn_end /* r3 <- rel dyn end ofs */
> fixloop:
> - ldr r0, [r2]/* r0 <- SRC location to fix up */
> - add r0, r0, r9 /* r0 <- DST location to fix up */
> - ldr r1, [r2, #4]
> - and r7, r1, #0xff
> - cmp r7, #23 /* relative fixup? */
> - beq fixrel
> - cmp r7, #2 /* absolute fixup? */
> - beq fixabs
> - /* ignore unknown type of fixup */
> - b fixnext
> -fixabs:
> - /* absolute fix: set location to (offset) symbol value */
> - mov r1, r1, LSR #4 /* r1 <- symbol index in .dynsym */
> - add r1, r10, r1 /* r1 <- address of symbol in table */
> - ldr r1, [r1, #4]/* r1 <- symbol value */
> - add r1, r1, r9 /* r1 <- relocated sym addr */
> - b fixnext
> -fixrel:
> + ldmia r2!, {r0-r1}/* (r0,r1) <- (SRC location,fixup) */
> + and r1, r1, #0xff /* r1 <- fixup type */
> + cmp r1, #23 /* relative fixup? */
> + bne fixnext
> +
> /* relative fix: increase location by offset */
> - ldr r1, [r0]
> - add r1, r1, r9
> + add r0, r0, r9 /* r0 <- DST location to fix up */
> + ldr r1, [r0]/* r1 <- content to fix up */
> + add r1, r1, r9 /* fix up */
> + str r1, [r0]/* write back fixed-up content */
> +
> fixnext:
> - str r1, [r0]
> - add r2, r2, #8 /* each rel.dyn entry is 8 bytes */
> cmp r2, r3
> blo fixloop
The final state of relocate.S is correct in this series, but it is not correct
at the end of "[PATCH v2 4/4] arm: factorize relocate_code routine" as I pointed
out in the part of my review that you cut in your first reply.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Optimize ARM relocation
Hi Albert, On Tuesday, May 14, 2013 10:16:01 PM, Albert ARIBAUD wrote: > On Tue, 14 May 2013 22:02:55 +0200, Albert ARIBAUD > wrote: > > > *** NOTE: this series applies over the 'Factorize > > ARM relocate_code instances' series. > > > > This series optimizes relocation by ensuring ARM > > binaries only use one type of relocation record, > > R_ARM_RELATIVE., then optimizing relocation code > > accordingly. > > > > The only known case where relocation records other > > than R_ARM_RELATIVE are generated is when a reference > > is made to a symbol defined in the linker script, e.g. > > __image_copy_start, __image_copy_end, __rel_dyn_start, > > __rel_dyn_end, and __dynsym_start. > > > > Moving the definition of these symbols from the linker > > scripts into a C module causes their references' types > > to become R_ARM_RELATIVE. > > > > First, arch/arm/lib/bss.c is replaced by a more generic > > arch/arm/lib/sections.c where all section symbols will > > be defined. > > > > Second, __image_copy_start and __image_copy_end symbols > > are moved from linker scripts to arch/arm/lib/sections.c > > > > Third, __rel_dyn_start, __rel_dyn_end and __synsym_start > > are moved from linker scripts into arch/arm/lib/sections.c > > > > Fourth, a check is added to the build system to ensure > > that ELF U-Boot binaries only use R_ARM_RELATIVE records. > > > > Last, relocate_code is optimized > > Hmm, it seems I need to see my work posted on the list to discover how > I could have done it better... I just noticed that if ARM binaries only > have R_ARM_RELATIVE record types, then all the .dynsym sections can > actually be dropped from the binaries. So, if I reorder the series and > put patch 5/5 first, then I can eliminate patch 3/5, or more to the > point, replace it with one which eliminates all dynsym stuff from linker > scripts, further reducing code size. That'll go in V2... Indeed. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/4] usb: ehci: add weak-aliased functions to portsc & tdi
2013/5/14 Marek Vasut :
> Dear Kuo-Jung Su,
>
>> 2013/5/13 Marek Vasut :
>> > Dear Kuo-Jung Su,
>> >
>> >> 2013/5/13 Marek Vasut :
>> >> > Dear Kuo-Jung Su,
>> >> >
>> >> >> From: Kuo-Jung Su
>> >> >>
>> >> >> There is at least one non-EHCI compliant controller (i.e. Faraday
>> >> >> EHCI) known to implement a non-standard TDI stuff.
>> >> >> Futhermore, it not only leave reserved and CONFIGFLAG registers
>> >> >> un-implemented but also has their address spaces removed.
>> >> >>
>> >> >> And thus, we need weak-aliased functions to both TDI stuff
>> >> >> and PORTSC registers for interface abstraction.
>> >> >>
>> >> >> Signed-off-by: Kuo-Jung Su
>> >> >> CC: Marek Vasut
>> >> >> ---
>> >> >>
>> >> >> Changes for v6:
>> >> >>- Simplify weak aliased function declaration
>> >> >>- Drop redundant line feed
>> >> >>
>> >> >> Changes for v5:
>> >> >>- Split up from Faraday EHCI patch
>> >> >>
>> >> >> Changes for v2 - v4:
>> >> >>- See 'usb: ehci: add Faraday USB 2.0 EHCI support'
>> >> >>
>> >> >> drivers/usb/host/ehci-hcd.c | 91
>> >> >>
>> >> >> ++- 1 file changed, 55
>> >> >> insertions(+), 36 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/usb/host/ehci-hcd.c
>> >> >> b/drivers/usb/host/ehci-hcd.c index c816878..ae3f2a4 100644
>> >> >> --- a/drivers/usb/host/ehci-hcd.c
>> >> >> +++ b/drivers/usb/host/ehci-hcd.c
>> >> >> @@ -117,10 +117,44 @@ static struct descriptor {
>> >> >>
>> >> >> };
>> >> >>
>> >> >> #if defined(CONFIG_EHCI_IS_TDI)
>> >> >>
>> >> >> -#define ehci_is_TDI()(1)
>> >> >> -#else
>> >> >> -#define ehci_is_TDI()(0)
>> >> >> +# define ehci_is_TDI() (1)
>> >> >
>> >> > btw you can remove those braces around (1) and (0) below. But I have
>> >> > one more question ...
>> >>
>> >> Got it, thanks
>> >>
>> >> > [...]
>> >> >
>> >> >> @@ -609,13 +644,10 @@ ehci_submit_root(struct usb_device *dev,
>> >> >> unsigned long pipe, void *buffer, uint32_t *status_reg;
>> >> >>
>> >> >> struct ehci_ctrl *ctrl = dev->controller;
>> >> >>
>> >> >> - if (le16_to_cpu(req->index) >
>> >> >> CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) { - printf("The
>> >> >> request port(%d) is not configured\n", -
>> >> >>
>> >> >> le16_to_cpu(req->index) - 1);
>> >> >>
>> >> >> + status_reg = ehci_get_portsc_register(ctrl->hcor,
>> >> >> + le16_to_cpu(req->index) - 1);
>> >> >> + if (!status_reg)
>> >> >
>> >> > What happens here if req->index is zero ?
>> >> >
>> >> > Hint: the above code always does unsigned comparison ...
>> >> >
>> >> > I think you should make the second argument of
>> >> > ehci_get_portsc_register() unsigned short too (as is req->index in
>> >> > struct devrequest).
>> >>
>> >> Sorry, but I'll prefer 'int' over 'unsigned short', since it looks to me
>> >> that the u-boot would set 'req->index' to 0 at startup, which results in
>> >> a 'port = -1' to be passed to ehci_get_portsc_register().
>> >>
>> >> And I think '-1' is a better self-explain value, so I'd like to stick
>> >> with 'int'
>> >
>> > Sure, but then the comparison is signed, not unsigned. Besides, it's
>> > unnecessary change to the logic of the code. Or did I miss something ?
>>
>> 1. There is a bug in ehci_submit_root() of usb ehci:
>>
>> int ehci_submit_root()
>> {
>> ..
>> if (port > CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
>> printf("The request port(%d) is not configured\n", port - 1);
>> return -1;
>> }
>> status_reg = (uint32_t *)&ctrl->hcor->or_portsc[port - 1];
>> ..
>> }
>>
>> The 'port' is actually a '0' at start-up, so we actually accessed
>> a wrong register.
>> But fortunately the wrong register actually points to CONFIGFLAG(0x40)
>> with a safe value for the following codes.
>>
>> 2. One of Vivek Gautam's usb patches has altered the logic of usb host
>> upon launching 'usb start', if we report a error upon (port - 1 < 0),
>> the current u-boot usb would failed to scan ports. (At least it
>> failed at Faraday platforms.)
>> However it looks to me that it's o.k to report a error upon (port
>> - 1 < 0) at old usb ehci stack.
>> (i.e. 10 days ago, in master branch of u-boot)
>>
>> And thus I add a quick check to PATCH v7.
>>
>> __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port)
>> {
>> /*
>> * The u-boot would somehow set port=-1 at usb start-up,
>> * so this quick fix is necessary.
>> */
>> if (port < 0)
>> port = 0;
>
> Maybe we should return fail, no ?
No, it would make the 'usb start' to terminate immediately,
and results in a port scan failure to at least Faraday EHCI.
> Can you pinpoint where does the req->index
> (resp. port) get set to -1 ?
Later I'll try to find out where we have 'req->index' set as a '0' in
'usb start'.
> And which commit introduced this breakage ?
I believe it's there long ago, we just fortunately bypass the error at o
Re: [U-Boot] [PATCH 1/2] mx6qsabreauto: Add i2c to mx6qsabreauto board
On Tue, May 14, 2013 at 7:27 PM, Otavio Salvador wrote: > Hello Renato, > > When sending patches for Freescale i.MX boards please add Fabio in Cc > (just did). > > On Tue, May 14, 2013 at 1:01 AM, Renato Frias wrote: >> Add i2c2 and 3 to mx6qsabreauto board, i2c3 is multiplexed >> use gpio to set steering. >> >> Signed-off-by: Renato Frias > > Code seems fine, I don't have the board so I cannot test. > > Reviewed-by: Otavio Salvador Both patches look good for me as well: Reviewed-by: Fabio Estevam Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix env in mmc with redundant compile error
Hi Michael, On 5/15/2013 02:16, Michael Heimpold wrote: Am Montag, 13. Mai 2013, 14:14:46 schrieben Sie: The commit d196bd8 (env_mmc: add support for redundant environment) introduce the following compile error when enable reduandant environment support with MMC ---8<--- env_mmc.c:149: error: 'env_t' has no member named 'flags' env_mmc.c:248: error: 'env_t' has no member named 'flags' env_mmc.c:248: error: 'env_t' has no member named 'flags' env_mmc.c:250: error: 'env_t' has no member named 'flags' env_mmc.c:250: error: 'env_t' has no member named 'flags' env_mmc.c:252: error: 'env_t' has no member named 'flags' env_mmc.c:252: error: 'env_t' has no member named 'flags' env_mmc.c:254: error: 'env_t' has no member named 'flags' env_mmc.c:254: error: 'env_t' has no member named 'flags' env_mmc.c:267: error: 'env_t' has no member named 'flags' make[1]: *** [env_mmc.o] Error 1 --->8--- Add this patch to fix it Signed-off-by: Bo Shen --- include/environment.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/environment.h b/include/environment.h index 4c6a37b..460ccb4 100644 --- a/include/environment.h +++ b/include/environment.h @@ -75,6 +75,12 @@ # endif #endif/* CONFIG_ENV_IS_IN_FLASH */ +#if defined(CONFIG_ENV_IS_IN_MMC) +# ifdef CONFIG_ENV_OFFSET_REDUND +# define CONFIG_SYS_REDUNDAND_ENVIRONMENT +# endif +#endif + #if defined(CONFIG_ENV_IS_IN_NAND) # if defined(CONFIG_ENV_OFFSET_OOB) # ifdef CONFIG_ENV_OFFSET_REDUND s/reduandant/redundant/ Thanks for figure out this, I will correct it in next version. Reviewed-by: Michael Heimpold In next version, I will add your Reviewed-by tag. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mmc: fix env in mmc with redundant compile error
The commit d196bd8 (env_mmc: add support for redundant environment) introduce the following compile error when enable redundant environment support with MMC ---8<--- env_mmc.c:149: error: 'env_t' has no member named 'flags' env_mmc.c:248: error: 'env_t' has no member named 'flags' env_mmc.c:248: error: 'env_t' has no member named 'flags' env_mmc.c:250: error: 'env_t' has no member named 'flags' env_mmc.c:250: error: 'env_t' has no member named 'flags' env_mmc.c:252: error: 'env_t' has no member named 'flags' env_mmc.c:252: error: 'env_t' has no member named 'flags' env_mmc.c:254: error: 'env_t' has no member named 'flags' env_mmc.c:254: error: 'env_t' has no member named 'flags' env_mmc.c:267: error: 'env_t' has no member named 'flags' make[1]: *** [env_mmc.o] Error 1 --->8--- Add this patch to fix it Signed-off-by: Bo Shen Reviewed-by: Michael Heimpold --- Changes in v2: - s/reduandant/redundant in commit message include/environment.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/environment.h b/include/environment.h index 4c6a37b..460ccb4 100644 --- a/include/environment.h +++ b/include/environment.h @@ -75,6 +75,12 @@ # endif #endif /* CONFIG_ENV_IS_IN_FLASH */ +#if defined(CONFIG_ENV_IS_IN_MMC) +# ifdef CONFIG_ENV_OFFSET_REDUND +# define CONFIG_SYS_REDUNDAND_ENVIRONMENT +# endif +#endif + #if defined(CONFIG_ENV_IS_IN_NAND) # if defined(CONFIG_ENV_OFFSET_OOB) # ifdef CONFIG_ENV_OFFSET_REDUND -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT
> > endif > > > > ifdef CONFIG_SPL_BUILD > > -COBJS-y += cmd_nvedit.o > > -COBJS-y += env_common.o > > COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o > > COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += cmd_nvedit.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_attr.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_callback.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o > > -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o > > COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_common.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o > > +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o > > endif > > +COBJS-y += cmd_nvedit.o > > +COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o > > COBJS-$(CONFIG_BOUNCE_BUFFER) += bouncebuf.o > > COBJS-y += console.o > > COBJS-y += dlmalloc.o > > Just move the whole CONFIG_ENV_IS_IN.. section down to where we always > build objects, and update the comments in the Makefile in both spots. > [Zhang Ying] > For common lines(for example: cmd_nvedit.o) that shared by the SPL and > non-SPL, > can we move it to public area? So, we can avoid excessive SPL symbols. Right. Re-order things so we're duplicating as little as possible. There's already a bit of needless duplication going on here. [Zhang Ying] Ok, we had moved CONFIG_ENV_IS_IN.. section to public area in another patch just submitted :"move the common makefile line out of the CONFIG_SPL_BUILD ifdef". Please review. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/4] usb: ehci: add weak-aliased functions to portsc & tdi
2013/5/15 Kuo-Jung Su :
> 2013/5/14 Marek Vasut :
>> Dear Kuo-Jung Su,
>>
>>> 2013/5/13 Marek Vasut :
>>> > Dear Kuo-Jung Su,
>>> >
>>> >> 2013/5/13 Marek Vasut :
>>> >> > Dear Kuo-Jung Su,
>>> >> >
>>> >> >> From: Kuo-Jung Su
>>> >> >>
>>> >> >> There is at least one non-EHCI compliant controller (i.e. Faraday
>>> >> >> EHCI) known to implement a non-standard TDI stuff.
>>> >> >> Futhermore, it not only leave reserved and CONFIGFLAG registers
>>> >> >> un-implemented but also has their address spaces removed.
>>> >> >>
>>> >> >> And thus, we need weak-aliased functions to both TDI stuff
>>> >> >> and PORTSC registers for interface abstraction.
>>> >> >>
>>> >> >> Signed-off-by: Kuo-Jung Su
>>> >> >> CC: Marek Vasut
>>> >> >> ---
>>> >> >>
>>> >> >> Changes for v6:
>>> >> >>- Simplify weak aliased function declaration
>>> >> >>- Drop redundant line feed
>>> >> >>
>>> >> >> Changes for v5:
>>> >> >>- Split up from Faraday EHCI patch
>>> >> >>
>>> >> >> Changes for v2 - v4:
>>> >> >>- See 'usb: ehci: add Faraday USB 2.0 EHCI support'
>>> >> >>
>>> >> >> drivers/usb/host/ehci-hcd.c | 91
>>> >> >>
>>> >> >> ++- 1 file changed, 55
>>> >> >> insertions(+), 36 deletions(-)
>>> >> >>
>>> >> >> diff --git a/drivers/usb/host/ehci-hcd.c
>>> >> >> b/drivers/usb/host/ehci-hcd.c index c816878..ae3f2a4 100644
>>> >> >> --- a/drivers/usb/host/ehci-hcd.c
>>> >> >> +++ b/drivers/usb/host/ehci-hcd.c
>>> >> >> @@ -117,10 +117,44 @@ static struct descriptor {
>>> >> >>
>>> >> >> };
>>> >> >>
>>> >> >> #if defined(CONFIG_EHCI_IS_TDI)
>>> >> >>
>>> >> >> -#define ehci_is_TDI()(1)
>>> >> >> -#else
>>> >> >> -#define ehci_is_TDI()(0)
>>> >> >> +# define ehci_is_TDI() (1)
>>> >> >
>>> >> > btw you can remove those braces around (1) and (0) below. But I have
>>> >> > one more question ...
>>> >>
>>> >> Got it, thanks
>>> >>
>>> >> > [...]
>>> >> >
>>> >> >> @@ -609,13 +644,10 @@ ehci_submit_root(struct usb_device *dev,
>>> >> >> unsigned long pipe, void *buffer, uint32_t *status_reg;
>>> >> >>
>>> >> >> struct ehci_ctrl *ctrl = dev->controller;
>>> >> >>
>>> >> >> - if (le16_to_cpu(req->index) >
>>> >> >> CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) { - printf("The
>>> >> >> request port(%d) is not configured\n", -
>>> >> >>
>>> >> >> le16_to_cpu(req->index) - 1);
>>> >> >>
>>> >> >> + status_reg = ehci_get_portsc_register(ctrl->hcor,
>>> >> >> + le16_to_cpu(req->index) - 1);
>>> >> >> + if (!status_reg)
>>> >> >
>>> >> > What happens here if req->index is zero ?
>>> >> >
>>> >> > Hint: the above code always does unsigned comparison ...
>>> >> >
>>> >> > I think you should make the second argument of
>>> >> > ehci_get_portsc_register() unsigned short too (as is req->index in
>>> >> > struct devrequest).
>>> >>
>>> >> Sorry, but I'll prefer 'int' over 'unsigned short', since it looks to me
>>> >> that the u-boot would set 'req->index' to 0 at startup, which results in
>>> >> a 'port = -1' to be passed to ehci_get_portsc_register().
>>> >>
>>> >> And I think '-1' is a better self-explain value, so I'd like to stick
>>> >> with 'int'
>>> >
>>> > Sure, but then the comparison is signed, not unsigned. Besides, it's
>>> > unnecessary change to the logic of the code. Or did I miss something ?
>>>
>>> 1. There is a bug in ehci_submit_root() of usb ehci:
>>>
>>> int ehci_submit_root()
>>> {
>>> ..
>>> if (port > CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
>>> printf("The request port(%d) is not configured\n", port - 1);
>>> return -1;
>>> }
>>> status_reg = (uint32_t *)&ctrl->hcor->or_portsc[port - 1];
>>> ..
>>> }
>>>
>>> The 'port' is actually a '0' at start-up, so we actually accessed
>>> a wrong register.
>>> But fortunately the wrong register actually points to CONFIGFLAG(0x40)
>>> with a safe value for the following codes.
>>>
>>> 2. One of Vivek Gautam's usb patches has altered the logic of usb host
>>> upon launching 'usb start', if we report a error upon (port - 1 < 0),
>>> the current u-boot usb would failed to scan ports. (At least it
>>> failed at Faraday platforms.)
>>> However it looks to me that it's o.k to report a error upon (port
>>> - 1 < 0) at old usb ehci stack.
>>> (i.e. 10 days ago, in master branch of u-boot)
>>>
>>> And thus I add a quick check to PATCH v7.
>>>
>>> __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port)
>>> {
>>> /*
>>> * The u-boot would somehow set port=-1 at usb start-up,
>>> * so this quick fix is necessary.
>>> */
>>> if (port < 0)
>>> port = 0;
>>
>> Maybe we should return fail, no ?
>
> No, it would make the 'usb start' to terminate immediately,
> and results in a port scan failure to at least Faraday EHCI.
>
>> Can you pinpoint where does the req->index
>> (resp. port) get set to -1 ?
>
> Later I'll try to find out where we
[U-Boot] [PATCH v3] common/Makefile: Add new symbol CONFIG_SPL_ENV_SUPPORT for environment in SPL
From: Ying Zhang There will need the environment in SPL for reasons other than network support (in particular, hwconfig contains info for how to set up DDR). Add a new symbol CONFIG_SPL_ENV_SUPPORT to replace CONFIG_SPL_NET_SUPPORT for environment in common/Makefile. Signed-off-by: Ying Zhang --- Compared with the previous version, add symbol CONFIG_SPL_ENV_SUPPORT in include/configs/a3m071.h. README |3 +++ common/Makefile | 19 +-- include/configs/a3m071.h |1 + include/configs/am335x_evm.h |1 + include/configs/pcm051.h |1 + 5 files changed, 15 insertions(+), 10 deletions(-) diff --git a/README b/README index 5bf4afa..daf1fa1 100644 --- a/README +++ b/README @@ -2985,6 +2985,9 @@ FIT uImage format: CONFIG_SPL_LIBGENERIC_SUPPORT Support for lib/libgeneric.o in SPL binary + CONFIG_SPL_ENV_SUPPORT + Support for the environment operating in SPL binary + CONFIG_SPL_PAD_TO Image offset to which the SPL should be padded before appending the SPL payload. By default, this is defined as diff --git a/common/Makefile b/common/Makefile index 0429a3c..43daaa8 100644 --- a/common/Makefile +++ b/common/Makefile @@ -44,7 +44,6 @@ COBJS-$(CONFIG_SYS_GENERIC_BOARD) += board_r.o COBJS-y += cmd_boot.o COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o COBJS-y += cmd_help.o -COBJS-y += cmd_nvedit.o COBJS-y += cmd_version.o # environment @@ -67,7 +66,6 @@ COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o COBJS-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o COBJS-$(CONFIG_ENV_IS_IN_UBI) += env_ubi.o -COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o # command COBJS-$(CONFIG_CMD_AMBAPP) += cmd_ambapp.o @@ -215,18 +213,16 @@ COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o endif ifdef CONFIG_SPL_BUILD -COBJS-y += cmd_nvedit.o -COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o COBJS-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += cmd_nvedit.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_attr.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_callback.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_common.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_flags.o -COBJS-$(CONFIG_SPL_NET_SUPPORT) += env_nowhere.o COBJS-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o +# environment +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_common.o +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_attr.o +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_flags.o +COBJS-$(CONFIG_SPL_ENV_SUPPORT) += env_callback.o endif +# core command +COBJS-y += cmd_nvedit.o +# environment +COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o COBJS-$(CONFIG_BOUNCE_BUFFER) += bouncebuf.o COBJS-y += console.o COBJS-y += dlmalloc.o diff --git a/include/configs/a3m071.h b/include/configs/a3m071.h index e9af825..8f29229 100644 --- a/include/configs/a3m071.h +++ b/include/configs/a3m071.h @@ -426,6 +426,7 @@ #define CONFIG_SPL_BSS_MAX_SIZE(64 << 10) #define CONFIG_SPL_OS_BOOT +#define CONFIG_SPL_ENV_SUPPORT /* Place patched DT blob (fdt) at this address */ #define CONFIG_SYS_SPL_ARGS_ADDR 0x0180 diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index ef00306..f47d3d1 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -325,6 +325,7 @@ #define CONFIG_SPL_GPIO_SUPPORT #define CONFIG_SPL_YMODEM_SUPPORT #define CONFIG_SPL_NET_SUPPORT +#define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRING "AM335x U-Boot SPL" #define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_SPI_SUPPORT diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h index d0ea74e..926842f 100644 --- a/include/configs/pcm051.h +++ b/include/configs/pcm051.h @@ -224,6 +224,7 @@ #define CONFIG_SPL_GPIO_SUPPORT #define CONFIG_SPL_YMODEM_SUPPORT #define CONFIG_SPL_NET_SUPPORT +#define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRING "pcm051 U-Boot SPL" #define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_SPI_SUPPORT -- 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 v6 2/4] usb: ehci: add weak-aliased functions to portsc & tdi
Dear Kuo-Jung Su,
> 2013/5/15 Kuo-Jung Su :
> > 2013/5/14 Marek Vasut :
> >> Dear Kuo-Jung Su,
> >>
> >>> 2013/5/13 Marek Vasut :
> >>> > Dear Kuo-Jung Su,
> >>> >
> >>> >> 2013/5/13 Marek Vasut :
> >>> >> > Dear Kuo-Jung Su,
> >>> >> >
> >>> >> >> From: Kuo-Jung Su
> >>> >> >>
> >>> >> >> There is at least one non-EHCI compliant controller (i.e. Faraday
> >>> >> >> EHCI) known to implement a non-standard TDI stuff.
> >>> >> >> Futhermore, it not only leave reserved and CONFIGFLAG registers
> >>> >> >> un-implemented but also has their address spaces removed.
> >>> >> >>
> >>> >> >> And thus, we need weak-aliased functions to both TDI stuff
> >>> >> >> and PORTSC registers for interface abstraction.
> >>> >> >>
> >>> >> >> Signed-off-by: Kuo-Jung Su
> >>> >> >> CC: Marek Vasut
> >>> >> >> ---
> >>> >> >>
> >>> >> >> Changes for v6:
> >>> >> >>- Simplify weak aliased function declaration
> >>> >> >>- Drop redundant line feed
> >>> >> >>
> >>> >> >> Changes for v5:
> >>> >> >>- Split up from Faraday EHCI patch
> >>> >> >>
> >>> >> >> Changes for v2 - v4:
> >>> >> >>- See 'usb: ehci: add Faraday USB 2.0 EHCI support'
> >>> >> >>
> >>> >> >> drivers/usb/host/ehci-hcd.c | 91
> >>> >> >>
> >>> >> >> ++- 1 file changed, 55
> >>> >> >> insertions(+), 36 deletions(-)
> >>> >> >>
> >>> >> >> diff --git a/drivers/usb/host/ehci-hcd.c
> >>> >> >> b/drivers/usb/host/ehci-hcd.c index c816878..ae3f2a4 100644
> >>> >> >> --- a/drivers/usb/host/ehci-hcd.c
> >>> >> >> +++ b/drivers/usb/host/ehci-hcd.c
> >>> >> >> @@ -117,10 +117,44 @@ static struct descriptor {
> >>> >> >>
> >>> >> >> };
> >>> >> >>
> >>> >> >> #if defined(CONFIG_EHCI_IS_TDI)
> >>> >> >>
> >>> >> >> -#define ehci_is_TDI()(1)
> >>> >> >> -#else
> >>> >> >> -#define ehci_is_TDI()(0)
> >>> >> >> +# define ehci_is_TDI() (1)
> >>> >> >
> >>> >> > btw you can remove those braces around (1) and (0) below. But I
> >>> >> > have one more question ...
> >>> >>
> >>> >> Got it, thanks
> >>> >>
> >>> >> > [...]
> >>> >> >
> >>> >> >> @@ -609,13 +644,10 @@ ehci_submit_root(struct usb_device *dev,
> >>> >> >> unsigned long pipe, void *buffer, uint32_t *status_reg;
> >>> >> >>
> >>> >> >> struct ehci_ctrl *ctrl = dev->controller;
> >>> >> >>
> >>> >> >> - if (le16_to_cpu(req->index) >
> >>> >> >> CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) { - printf("The
> >>> >> >> request port(%d) is not configured\n", -
> >>> >> >>
> >>> >> >> le16_to_cpu(req->index) - 1);
> >>> >> >>
> >>> >> >> + status_reg = ehci_get_portsc_register(ctrl->hcor,
> >>> >> >> + le16_to_cpu(req->index) - 1);
> >>> >> >> + if (!status_reg)
> >>> >> >
> >>> >> > What happens here if req->index is zero ?
> >>> >> >
> >>> >> > Hint: the above code always does unsigned comparison ...
> >>> >> >
> >>> >> > I think you should make the second argument of
> >>> >> > ehci_get_portsc_register() unsigned short too (as is req->index in
> >>> >> > struct devrequest).
> >>> >>
> >>> >> Sorry, but I'll prefer 'int' over 'unsigned short', since it looks
> >>> >> to me that the u-boot would set 'req->index' to 0 at startup, which
> >>> >> results in a 'port = -1' to be passed to
> >>> >> ehci_get_portsc_register().
> >>> >>
> >>> >> And I think '-1' is a better self-explain value, so I'd like to
> >>> >> stick with 'int'
> >>> >
> >>> > Sure, but then the comparison is signed, not unsigned. Besides, it's
> >>> > unnecessary change to the logic of the code. Or did I miss something
> >>> > ?
> >>>
> >>> 1. There is a bug in ehci_submit_root() of usb ehci:
> >>> int ehci_submit_root()
> >>> {
> >>>
> >>> ..
> >>> if (port > CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS) {
> >>>
> >>> printf("The request port(%d) is not configured\n", port -
> >>> 1); return -1;
> >>>
> >>> }
> >>> status_reg = (uint32_t *)&ctrl->hcor->or_portsc[port - 1];
> >>> ..
> >>>
> >>> }
> >>>
> >>> The 'port' is actually a '0' at start-up, so we actually accessed
> >>>
> >>> a wrong register.
> >>>
> >>> But fortunately the wrong register actually points to
> >>> CONFIGFLAG(0x40)
> >>>
> >>> with a safe value for the following codes.
> >>>
> >>> 2. One of Vivek Gautam's usb patches has altered the logic of usb host
> >>>
> >>> upon launching 'usb start', if we report a error upon (port - 1 <
> >>> 0), the current u-boot usb would failed to scan ports. (At least
> >>> it
> >>>
> >>> failed at Faraday platforms.)
> >>>
> >>> However it looks to me that it's o.k to report a error upon (port
> >>>
> >>> - 1 < 0) at old usb ehci stack.
> >>>
> >>> (i.e. 10 days ago, in master branch of u-boot)
> >>>
> >>> And thus I add a quick check to PATCH v7.
> >>>
> >>> __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int
> >>> p
Re: [U-Boot] [PATCH] ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit
Dear Axel Lin, > cpu_init_crit() can be skipped, but the code is still enabled requiring a > platform to supply lowlevel_init(). > > Signed-off-by: Axel Lin Nice CC list, it'd be the best if you CCed the ARM maintainer too though ;-) > --- > arch/arm/cpu/arm720t/start.S | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S > index 9facc7e..9f0e3f9 100644 > --- a/arch/arm/cpu/arm720t/start.S > +++ b/arch/arm/cpu/arm720t/start.S > @@ -244,6 +244,7 @@ c_runtime_cpu_setup: > * > */ > > +#ifndef CONFIG_SKIP_LOWLEVEL_INIT > cpu_init_crit: > > #if !defined(CONFIG_TEGRA) > @@ -258,6 +259,7 @@ cpu_init_crit: > #endif > > mov pc, lr > +#endif /* CONFIG_SKIP_LOWLEVEL_INIT */ > > > #ifndef CONFIG_SPL_BUILD Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
