[U-Boot] [PATCH v4 0/6] Enable Thumb build for ARM platforms
Thumb is an alternate instruction set available in many ARM processors. Below is a detailed description from ARM specs:
"The Thumb instruction set is a re-encoded subset of the ARM instruction set. Thumb instructions execute in their own processor state, with the architecture defining the mechanisms required to transition between ARM and Thumb states. The key difference is that Thumb instructions are half the size of ARM instructions(16 bits compared with 32 bits). Greater code density can usually be achieved by using the Thumb instruction set in preference to the ARM instruction set, at a cost of some reduction in performance"
"In ARMv6T2, Thumb-2 technology is introduced. This technology makes it possible to extend the original Thumb instruction set with many 32-bit instructions. The range of 32-bit Thumb instructions included in ARMv6T2 permits Thumb code to achieve performance similar to ARM code, with code density better than that of earlier Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide almost identical functionality"
This series adds Thumb support in U-Boot and enables it for OMAP4. It also fixes issues faced while booting OMAP4 with Thumb-2 images of U-Boot and SPL.
Thumb mode is becoming increasingly relevant for U-Boot with the advent of SPL. It's very important to keep SPL size smaller considering the internal RAM size constraints on many platforms. On OMAP4 the size reduction enables us to use SPL on secure devices that have smaller internal RAM available for non-secure world.
To enable support for new platforms you just need to add CONFIG_SYS_THUMB_BUILD in your config file.
Tool-chains tried: 1. Sourcery G++ Lite 2010q1-202 arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709
2. Linaro 4.6-2012.01 arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 4.6.3 20120105 (prerelease) GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22
Code-size reduction: Image ARM build Thumb build % Reduction u-boot.bin 190408 144676 24.01% u-boot-spl.bin 33200 25096 24.40%
Performance(timestamp just before the main loop): ARM build Thumb build % Reduction 898510us 878247us -2.25%
Performance actually improved marginally for the Thumb build, maybe because of the reduced image sizes.
Aneesh V (6): arm: adapt asm/linkage.h from Linux armv7: add appropriate headers for assembly functions ARM: enable Thumb build armv7: Use -march=armv7-a and thereby enable Thumb-2 omap4+: Avoid using __attribute__ ((__packed__)) OMAP4: enable Thumb build
README | 8 +++++ arch/arm/config.mk | 22 +++++++++---- arch/arm/cpu/armv7/config.mk | 7 +++- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/mx6/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 14 ++++---- arch/arm/cpu/armv7/omap-common/reset.S | 5 ++- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 41 ++++++++++++----------- arch/arm/cpu/armv7/s5pc1xx/cache.S | 10 +++-- arch/arm/cpu/armv7/s5pc1xx/reset.S | 5 ++- arch/arm/cpu/armv7/start.S | 13 ++++--- arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/u8500/lowlevel.S | 9 +++-- arch/arm/include/asm/arch-omap4/mux_omap4.h | 2 +- arch/arm/include/asm/arch-omap5/mux_omap5.h | 2 +- arch/arm/include/asm/linkage.h | 7 ++++ include/configs/omap4_common.h | 2 + include/linux/linkage.h | 7 +++- 18 files changed, 106 insertions(+), 63 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h
This will add ARM specific over-rides for the defines from linux/linkage.h
Signed-off-by: Aneesh V aneesh@ti.com --- Not adding the defines for __ALIGN and __ALIGN_STR because it's not clear why alignment is set to 0 (single byte alignment).
Creates a checkpatch error that can not be avoided
Changes in v4: - Use STT_FUNC in the definition of ENDPROC in include/linux/linkage.h that is more portable than the '*function' versions. Now, remove the definition of ENDPROC from the arm linkage.h
Changes in v3: - None
Changes in v2: - Newly added --- arch/arm/include/asm/linkage.h | 7 +++++++ include/linux/linkage.h | 7 ++++++- 2 files changed, 13 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h
diff --git a/arch/arm/include/asm/linkage.h b/arch/arm/include/asm/linkage.h new file mode 100644 index 0000000..dbe4b4e --- /dev/null +++ b/arch/arm/include/asm/linkage.h @@ -0,0 +1,7 @@ +#ifndef __ASM_LINKAGE_H +#define __ASM_LINKAGE_H + +#define __ALIGN .align 0 +#define __ALIGN_STR ".align 0" + +#endif diff --git a/include/linux/linkage.h b/include/linux/linkage.h index ed4cf6c..7b749bb 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -44,8 +44,13 @@ #define SYMBOL_NAME_LABEL(X) X: #endif
+#ifndef __ALIGN #define __ALIGN .align 4 +#endif + +#ifndef __ALIGN_STR #define __ALIGN_STR ".align 4" +#endif
#ifdef __ASSEMBLY__
@@ -67,7 +72,7 @@
#ifndef ENDPROC #define ENDPROC(name) \ - .type name, @function; \ + .type name STT_FUNC; \ END(name) #endif
On Thursday 08 March 2012 12:20:17 Aneesh V wrote:
This will add ARM specific over-rides for the defines from linux/linkage.h
Tested-by: Mike Frysinger vapier@gentoo.org -mike
On Sunday 11 March 2012 07:31 AM, Mike Frysinger wrote:
On Thursday 08 March 2012 12:20:17 Aneesh V wrote:
This will add ARM specific over-rides for the defines from linux/linkage.h
Tested-by: Mike Frysingervapier@gentoo.org -mike
Thanks Mike.
Use ENTRY and ENDPROC with assembly functions to ensure necessary assembler directives for all functions.
Signed-off-by: Aneesh V aneesh@ti.com --- Changes in v4: - None
Changes in v3: - None
Changes in V2: - Newly added --- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/mx6/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 14 ++++---- arch/arm/cpu/armv7/omap-common/reset.S | 5 ++- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 41 ++++++++++++----------- arch/arm/cpu/armv7/s5pc1xx/cache.S | 10 +++-- arch/arm/cpu/armv7/s5pc1xx/reset.S | 5 ++- arch/arm/cpu/armv7/start.S | 13 ++++--- arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/u8500/lowlevel.S | 9 +++-- 10 files changed, 61 insertions(+), 51 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 01f6d75..5344410 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -22,6 +22,7 @@ #include <config.h> #include <asm/arch/imx-regs.h> #include <generated/asm-offsets.h> +#include <linux/linkage.h>
/* * L2CC Cache setup/invalidation/disable @@ -312,8 +313,7 @@
.section ".text.init", "x"
-.globl lowlevel_init -lowlevel_init: +ENTRY(lowlevel_init) #if defined(CONFIG_MX51) ldr r0, =GPIO1_BASE_ADDR ldr r1, [r0, #0x0] @@ -334,6 +334,7 @@ lowlevel_init:
/* r12 saved upper lr*/ mov pc,lr +ENDPROC(lowlevel_init)
/* Board level setting value */ W_DP_OP_864: .word DP_OP_864 diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S b/arch/arm/cpu/armv7/mx6/lowlevel_init.S index 1864356..acadef2 100644 --- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx6/lowlevel_init.S @@ -18,7 +18,8 @@ */ .section ".text.init", "x"
-.globl lowlevel_init -lowlevel_init: +#include <linux/linkage.h>
+ENTRY(lowlevel_init) mov pc, lr +ENDPROC(lowlevel_init) diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S index 35f38ac..ccc6bb6 100644 --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S @@ -27,9 +27,9 @@ */
#include <asm/arch/omap.h> +#include <linux/linkage.h>
-.global save_boot_params -save_boot_params: +ENTRY(save_boot_params) /* * See if the rom code passed pointer is valid: * It is not valid if it is not in non-secure SRAM @@ -76,10 +76,9 @@ save_boot_params: strb r2, [r3, #CH_FLAGS_OFFSET] 1: bx lr +ENDPROC(save_boot_params)
- -.globl lowlevel_init -lowlevel_init: +ENTRY(lowlevel_init) /* * Setup a temporary stack */ @@ -95,12 +94,13 @@ lowlevel_init: */ bl s_init pop {ip, pc} +ENDPROC(lowlevel_init)
-.globl set_pl310_ctrl_reg -set_pl310_ctrl_reg: +ENTRY(set_pl310_ctrl_reg) PUSH {r4-r11, lr} @ save registers - ROM code may pollute @ our registers LDR r12, =0x102 @ Set PL310 control register - value in R0 .word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5 @ call ROM Code API to set control register POP {r4-r11, pc} +ENDPROC(set_pl310_ctrl_reg) diff --git a/arch/arm/cpu/armv7/omap-common/reset.S b/arch/arm/cpu/armv7/omap-common/reset.S index 838b122..179a476 100644 --- a/arch/arm/cpu/armv7/omap-common/reset.S +++ b/arch/arm/cpu/armv7/omap-common/reset.S @@ -22,9 +22,9 @@ */
#include <config.h> +#include <linux/linkage.h>
-.global reset_cpu -reset_cpu: +ENTRY(reset_cpu) ldr r1, rstctl @ get addr for global reset @ reg ldr r3, rstbit @ sw reset bit @@ -36,3 +36,4 @@ rstctl: .word PRM_RSTCTRL rstbit: .word PRM_RSTCTRL_RESET +ENDPROC(reset_cpu) diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S b/arch/arm/cpu/armv7/omap3/lowlevel_init.S index c42c5dd..ebf69fa 100644 --- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S @@ -31,22 +31,22 @@ #include <version.h> #include <asm/arch/mem.h> #include <asm/arch/clocks_omap3.h> +#include <linux/linkage.h>
_TEXT_BASE: .word CONFIG_SYS_TEXT_BASE /* sdram load addr from config.mk */
#ifdef CONFIG_SPL_BUILD -.global save_boot_params -save_boot_params: +ENTRY(save_boot_params) ldr r4, =omap3_boot_device ldr r5, [r0, #0x4] and r5, r5, #0xff str r5, [r4] bx lr +ENDPROC(save_boot_params) #endif
-.global omap3_gp_romcode_call -omap3_gp_romcode_call: +ENTRY(omap3_gp_romcode_call) PUSH {r4-r12, lr} @ Save all registers from ROM code! MOV r12, r0 @ Copy the Service ID in R12 MOV r0, r1 @ Copy parameter to R0 @@ -55,6 +55,7 @@ omap3_gp_romcode_call: .word 0xe1600070 @ SMC #0 to enter monitor - hand assembled @ because we use -march=armv5 POP {r4-r12, pc} +ENDPROC(omap3_gp_romcode_call)
/* * Funtion for making PPA HAL API calls in secure devices @@ -62,8 +63,7 @@ omap3_gp_romcode_call: * R0 - Service ID * R1 - paramer list */ -.global do_omap3_emu_romcode_call -do_omap3_emu_romcode_call: +ENTRY(do_omap3_emu_romcode_call) PUSH {r4-r12, lr} @ Save all registers from ROM code! MOV r12, r0 @ Copy the Secure Service ID in R12 MOV r3, r1 @ Copy the pointer to va_list in R3 @@ -76,14 +76,14 @@ do_omap3_emu_romcode_call: .word 0xe1600071 @ SMC #1 to call PPA service - hand assembled @ because we use -march=armv5 POP {r4-r12, pc} +ENDPROC(do_omap3_emu_romcode_call)
#if !defined(CONFIG_SYS_NAND_BOOT) && !defined(CONFIG_SYS_NAND_BOOT) /************************************************************************** * cpy_clk_code: relocates clock code into SRAM where its safer to execute * R1 = SRAM destination address. *************************************************************************/ -.global cpy_clk_code - cpy_clk_code: +ENTRY(cpy_clk_code) /* Copy DPLL code into SRAM */ adr r0, go_to_speed /* get addr of clock setting code */ mov r2, #384 /* r2 size to copy (div by 32 bytes) */ @@ -95,6 +95,7 @@ next2: cmp r0, r2 /* until source end address [r2] */ bne next2 mov pc, lr /* back to caller */ +ENDPROC(cpy_clk_code)
/* *************************************************************************** * go_to_speed: -Moves to bypass, -Commits clock dividers, -puts dpll at speed @@ -109,8 +110,7 @@ next2: * L3 when its not in self refresh seems bad for it. Normally, this * code runs from flash before SDR is init so that should be ok. ****************************************************************************/ -.global go_to_speed - go_to_speed: +ENTRY(go_to_speed) stmfd sp!, {r4 - r6}
/* move into fast relock bypass */ @@ -171,6 +171,7 @@ wait2: nop ldmfd sp!, {r4 - r6} mov pc, lr /* back to caller, locked */ +ENDPROC(go_to_speed)
_go_to_speed: .word go_to_speed
@@ -211,8 +212,7 @@ pll_div_val5:
#endif
-.globl lowlevel_init -lowlevel_init: +ENTRY(lowlevel_init) ldr sp, SRAM_STACK str ip, [sp] /* stash old link register */ mov ip, lr /* save link reg across call */ @@ -230,6 +230,7 @@ lowlevel_init:
/* back to arch calling code */ mov pc, lr +ENDPROC(lowlevel_init)
/* the literal pools origin */ .ltorg @@ -480,22 +481,22 @@ per_36x_dpll_param: .word 26000, 432, 12, 9, 16, 9, 4, 3, 1 .word 38400, 360, 15, 9, 16, 5, 4, 3, 1
-.globl get_36x_mpu_dpll_param -get_36x_mpu_dpll_param: +ENTRY(get_36x_mpu_dpll_param) adr r0, mpu_36x_dpll_param mov pc, lr +ENDPROC(get_36x_mpu_dpll_param)
-.globl get_36x_iva_dpll_param -get_36x_iva_dpll_param: +ENTRY(get_36x_iva_dpll_param) adr r0, iva_36x_dpll_param mov pc, lr +ENDPROC(get_36x_iva_dpll_param)
-.globl get_36x_core_dpll_param -get_36x_core_dpll_param: +ENTRY(get_36x_core_dpll_param) adr r0, core_36x_dpll_param mov pc, lr +ENDPROC(get_36x_core_dpll_param)
-.globl get_36x_per_dpll_param -get_36x_per_dpll_param: +ENTRY(get_36x_per_dpll_param) adr r0, per_36x_dpll_param mov pc, lr +ENDPROC(get_36x_per_dpll_param) diff --git a/arch/arm/cpu/armv7/s5pc1xx/cache.S b/arch/arm/cpu/armv7/s5pc1xx/cache.S index c7d6221..000192c 100644 --- a/arch/arm/cpu/armv7/s5pc1xx/cache.S +++ b/arch/arm/cpu/armv7/s5pc1xx/cache.S @@ -25,20 +25,22 @@
.align 5
+#include <linux/linkage.h> + #ifndef CONFIG_SYS_L2CACHE_OFF -.global v7_outer_cache_enable -v7_outer_cache_enable: +ENTRY(v7_outer_cache_enable) push {r0, r1, r2, lr} mrc 15, 0, r3, cr1, cr0, 1 orr r3, r3, #2 mcr 15, 0, r3, cr1, cr0, 1 pop {r1, r2, r3, pc} +ENDPROC(v7_outer_cache_enable)
-.global v7_outer_cache_disable -v7_outer_cache_disable: +ENTRY(v7_outer_cache_disable) push {r0, r1, r2, lr} mrc 15, 0, r3, cr1, cr0, 1 bic r3, r3, #2 mcr 15, 0, r3, cr1, cr0, 1 pop {r1, r2, r3, pc} +ENDPROC(v7_outer_cache_disable) #endif diff --git a/arch/arm/cpu/armv7/s5pc1xx/reset.S b/arch/arm/cpu/armv7/s5pc1xx/reset.S index 70fa146..c7a41d0 100644 --- a/arch/arm/cpu/armv7/s5pc1xx/reset.S +++ b/arch/arm/cpu/armv7/s5pc1xx/reset.S @@ -22,12 +22,12 @@ */
#include <asm/arch/cpu.h> +#include <linux/linkage.h>
#define S5PC100_SWRESET 0xE0200000 #define S5PC110_SWRESET 0xE0102000
-.globl reset_cpu -reset_cpu: +ENTRY(reset_cpu) ldr r1, =S5PC100_PRO_ID ldr r2, [r1] ldr r4, =0x00010000 @@ -45,3 +45,4 @@ reset_cpu: str r2, [r1] _loop_forever: b _loop_forever +ENDPROC(reset_cpu) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index ef08a55..261835b 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -33,6 +33,7 @@ #include <config.h> #include <version.h> #include <asm/system.h> +#include <linux/linkage.h>
.globl _start _start: b reset @@ -172,8 +173,7 @@ call_board_init_f: * after relocating the monitor code. * */ - .globl relocate_code -relocate_code: +ENTRY(relocate_code) mov r4, r0 /* save addr_sp */ mov r5, r1 /* save addr of gd */ mov r6, r2 /* save addr of destination */ @@ -289,6 +289,7 @@ jump_2_ram:
_board_init_r_ofs: .word board_init_r - _start +ENDPROC(relocate_code)
/************************************************************************* * @@ -298,8 +299,7 @@ _board_init_r_ofs: * CONFIG_SYS_ICACHE_OFF is defined. * *************************************************************************/ -.globl cpu_init_cp15 -cpu_init_cp15: +ENTRY(cpu_init_cp15) /* * Invalidate L1 I/D */ @@ -325,7 +325,7 @@ cpu_init_cp15: #endif mcr p15, 0, r0, c1, c0, 0 mov pc, lr @ back to my caller - +ENDPROC(cpu_init_cp15)
#ifndef CONFIG_SKIP_LOWLEVEL_INIT /************************************************************************* @@ -336,7 +336,7 @@ cpu_init_cp15: * setup memory timing * *************************************************************************/ -cpu_init_crit: +ENTRY(cpu_init_crit) /* * Jump to board specific initialization... * The Mask ROM will have already initialized @@ -347,6 +347,7 @@ cpu_init_crit: bl lowlevel_init @ go setup pll,mux,memory mov lr, ip @ restore link mov pc, lr @ back to my caller +ENDPROC(cpu_init_crit) #endif
#ifndef CONFIG_SPL_BUILD diff --git a/arch/arm/cpu/armv7/tegra2/lowlevel_init.S b/arch/arm/cpu/armv7/tegra2/lowlevel_init.S index 6b86647..d117f23 100644 --- a/arch/arm/cpu/armv7/tegra2/lowlevel_init.S +++ b/arch/arm/cpu/armv7/tegra2/lowlevel_init.S @@ -25,10 +25,10 @@
#include <config.h> #include <version.h> +#include <linux/linkage.h>
.align 5 -.global reset_cpu -reset_cpu: +ENTRY(reset_cpu) ldr r1, rstctl @ get addr for global reset @ reg ldr r3, [r1] @@ -39,3 +39,4 @@ _loop_forever: b _loop_forever rstctl: .word PRM_RSTCTRL +ENDPROC(reset_cpu) diff --git a/arch/arm/cpu/armv7/u8500/lowlevel.S b/arch/arm/cpu/armv7/u8500/lowlevel.S index cffdfd1..289cfb0 100644 --- a/arch/arm/cpu/armv7/u8500/lowlevel.S +++ b/arch/arm/cpu/armv7/u8500/lowlevel.S @@ -20,16 +20,17 @@ */
#include <config.h> +#include <linux/linkage.h>
-.globl lowlevel_init -lowlevel_init: +ENTRY(lowlevel_init) mov pc, lr +ENDPROC(lowlevel_init)
.align 5 -.globl reset_cpu -reset_cpu: +ENTRY(reset_cpu) ldr r0, =CFG_PRCMU_BASE ldr r1, =0x1 str r1, [r0, #0x228] _loop_forever: b _loop_forever +ENDPROC(reset_cpu)
Acked-by: Mike Frysinger vapier@gentoo.org -mike
Enable Thumb build and ARM-Thumb interworking based on the new config flag CONFIG_SYS_THUMB_BUILD
Signed-off-by: Aneesh V aneesh@ti.com --- Changes in v4: - Use ':=' instead of '+=' when computed make variables are involved
Changes in v3: - None
Changes from V1 to V2: - None
Changes from RFC to V1: - Fixed review comments from Tom Rini trini@ti.com --- README | 8 ++++++++ arch/arm/config.mk | 22 +++++++++++++++------- 2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/README b/README index 8964672..bdb428e 100644 --- a/README +++ b/README @@ -426,6 +426,14 @@ The following options need to be configured: Select high exception vectors of the ARM core, e.g., do not clear the V bit of the c1 register of CP15.
+ CONFIG_SYS_THUMB_BUILD + + Use this flag to build U-Boot using the Thumb instruction + set for ARM architectures. Thumb instruction set provides + better code density. For ARM architectures that support + Thumb2 this flag will result in Thumb2 code generated by + GCC. + - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..d4fa1f8 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -33,25 +33,33 @@ endif
PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: -PF_CPPFLAGS_ARM := $(call cc-option,-marm,) +# Choose between ARM/Thumb instruction sets +ifeq ($(CONFIG_SYS_THUMB_BUILD),y) +PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ + $(call cc-option,-marm,)\ + $(call cc-option,-mno-thumb-interwork,)\ + ) +else +PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \ + $(call cc-option,-mno-thumb-interwork,) +endif
# Try if EABI is supported, else fall back to old API, # i. e. for example: # - with ELDK 4.2 (EABI supported), use: -# -mabi=aapcs-linux -mno-thumb-interwork +# -mabi=aapcs-linux # - with ELDK 4.1 (gcc 4.x, no EABI), use: -# -mabi=apcs-gnu -mno-thumb-interwork +# -mabi=apcs-gnu # - with ELDK 3.1 (gcc 3.x), use: -# -mapcs-32 -mno-thumb-interwork +# -mapcs-32 PF_CPPFLAGS_ABI := $(call cc-option,\ - -mabi=aapcs-linux -mno-thumb-interwork,\ + -mabi=aapcs-linux,\ $(call cc-option,\ -mapcs-32,\ $(call cc-option,\ -mabi=apcs-gnu,\ )\ - ) $(call cc-option,-mno-thumb-interwork,)\ + )\ ) PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI)
Acked-by: Mike Frysinger vapier@gentoo.org -mike
On Sunday 11 March 2012 07:32 AM, Mike Frysinger wrote:
Acked-by: Mike Frysingervapier@gentoo.org -mike
Thanks Mike.
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh V aneesh@ti.com --- I believe armv7-a is fine for all the SoCs except Tegra2 and I see that Tegra2 is already making the necessary exception in .../armv7/tegra2/config.mk
Let me know if any other SoC has a problem with armv7-a
Changes in V4: - Replaced "+=" with ":=" for make variable that involves computation
Changes in V3: - None
Changes from V1 to V2: - None
Changes from RFC to V1: - Enabled armv7-a from armv7/config.mk instead of from omap config.mk files --- arch/arm/cpu/armv7/config.mk | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk index 83ddf10..6d4b13c 100644 --- a/arch/arm/cpu/armv7/config.mk +++ b/arch/arm/cpu/armv7/config.mk @@ -22,8 +22,11 @@ # PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
-# Make ARMv5 to allow more compilers to work, even though its v7a. -PLATFORM_CPPFLAGS += -march=armv5 +# If armv7-a is not supported by GCC fall-back to armv5, which is +# supported by more tool-chains +PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5) +PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7) + # ========================================================================= # # Supply options according to compiler version
* Aneesh V wrote:
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh V aneesh@ti.com
I believe armv7-a is fine for all the SoCs except Tegra2 and I see that Tegra2 is already making the necessary exception in .../armv7/tegra2/config.mk
Let me know if any other SoC has a problem with armv7-a
I haven't been able to boot any Tegra2 boards with this patch applied. I'm guessing that some exceptions for Tegra2 code are still missing, though they shouldn't work with armv5 either since the AVP is armv4 only. For now I've conditionalized the -march=armv7-a on !CONFIG_TEGRA2.
Maybe somebody else can shed some light on this. Or perhaps this will be resolved with Allen's patches anyway?
Thierry
On 05/23/2012 09:01 AM, Thierry Reding wrote:
- Aneesh V wrote:
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh V aneesh@ti.com --- I believe armv7-a is fine for all the SoCs except Tegra2 and I see that Tegra2 is already making the necessary exception in .../armv7/tegra2/config.mk
Let me know if any other SoC has a problem with armv7-a
I haven't been able to boot any Tegra2 boards with this patch applied. I'm guessing that some exceptions for Tegra2 code are still missing, though they shouldn't work with armv5 either since the AVP is armv4 only. For now I've conditionalized the -march=armv7-a on !CONFIG_TEGRA2.
I have the following patch locally, courtesy of Allen Martin. Allen, are you going to (or did you) post the final version here?
diff --git a/arch/arm/cpu/armv7/tegra2/config.mk b/arch/arm/cpu/armv7/tegra2/config.mk index fe9ef5b..f3ba6f5 100644 --- a/arch/arm/cpu/armv7/tegra2/config.mk +++ b/arch/arm/cpu/armv7/tegra2/config.mk @@ -24,10 +24,12 @@ # MA 02111-1307 USA #
-# Tegra has an ARMv4T CPU which runs board_init_f(), so we must build this -# file with compatible flags +# Tegra has an ARMv4T CPU which runs board_init_f(), so we must build these +# files with compatible flags ifdef CONFIG_TEGRA2 CFLAGS_arch/arm/lib/board.o += -march=armv4t +CFLAGS_common/cmd_nvedit.o += -march=armv4t +CFLAGS_lib/string.o += -march=armv4t endif
USE_PRIVATE_LIBGCC = yes
* Stephen Warren wrote:
On 05/23/2012 09:01 AM, Thierry Reding wrote:
- Aneesh V wrote:
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh V aneesh@ti.com --- I believe armv7-a is fine for all the SoCs except Tegra2 and I see that Tegra2 is already making the necessary exception in .../armv7/tegra2/config.mk
Let me know if any other SoC has a problem with armv7-a
I haven't been able to boot any Tegra2 boards with this patch applied. I'm guessing that some exceptions for Tegra2 code are still missing, though they shouldn't work with armv5 either since the AVP is armv4 only. For now I've conditionalized the -march=armv7-a on !CONFIG_TEGRA2.
I have the following patch locally, courtesy of Allen Martin. Allen, are you going to (or did you) post the final version here?
Allen's final patch did make it into the Tegra tree and I can confirm that the issue is gone now. Thanks.
Thierry
Dear Aneesh V,
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh V aneesh@ti.com
For some reason, this patch breaks USB EHCI on mx51 efika boards. The board just freezes instead of detecting USB devices. Reverting this patch fixes the issue.
Note I use gcc 4.7.1 (!), might be compiler issue?
Tom, can you try on one of your beagle-dogs please? :)
Best regards, Marek Vasut
Hello,
On 2012/07/07, at 8:02, Marek Vasut wrote:
Dear Aneesh V,
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh V aneesh@ti.com
For some reason, this patch breaks USB EHCI on mx51 efika boards. The board just freezes instead of detecting USB devices. Reverting this patch fixes the issue.
Note I use gcc 4.7.1 (!), might be compiler issue?
Tom, can you try on one of your beagle-dogs please? :)
Just for your information, I doubt unaligned access causes this problem.
My investigation is here, http://lists.denx.de/pipermail/u-boot/2012-June/127020.html My patch [PATCH] arm: armv7: add compile option -mno-unaligned-access if available http://lists.denx.de/pipermail/u-boot/2012-July/127260.html
Hi Marek,
On 07/06/2012 04:32 PM, Tetsuyuki Kobayashi wrote:
Hello,
On 2012/07/07, at 8:02, Marek Vasut wrote:
Dear Aneesh V,
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh Vaneesh@ti.com
For some reason, this patch breaks USB EHCI on mx51 efika boards. The board just freezes instead of detecting USB devices. Reverting this patch fixes the issue.
Note I use gcc 4.7.1 (!), might be compiler issue?
Tom, can you try on one of your beagle-dogs please? :)
Just for your information, I doubt unaligned access causes this problem.
My investigation is here, http://lists.denx.de/pipermail/u-boot/2012-June/127020.html My patch [PATCH] arm: armv7: add compile option -mno-unaligned-access if available http://lists.denx.de/pipermail/u-boot/2012-July/127260.html
This makes sense. You might want to try this patch. Also, to be sure that it's nothing to do with Thumb you can make sure you are not enabling CONFIG_SYS_THUMB_BUILD.
best regards, Aneesh
Dear Aneesh V,
Hi Marek,
On 07/06/2012 04:32 PM, Tetsuyuki Kobayashi wrote:
Hello,
On 2012/07/07, at 8:02, Marek Vasut wrote:
Dear Aneesh V,
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh Vaneesh@ti.com
For some reason, this patch breaks USB EHCI on mx51 efika boards. The board just freezes instead of detecting USB devices. Reverting this patch fixes the issue.
Note I use gcc 4.7.1 (!), might be compiler issue?
Tom, can you try on one of your beagle-dogs please? :)
Just for your information, I doubt unaligned access causes this problem.
My investigation is here, http://lists.denx.de/pipermail/u-boot/2012-June/127020.html My patch [PATCH] arm: armv7: add compile option -mno-unaligned-access if
available
This makes sense. You might want to try this patch. Also, to be sure that it's nothing to do with Thumb you can make sure you are not enabling CONFIG_SYS_THUMB_BUILD.
Ok, I think the patch should be applied then ?
but what if the option isn't available?
best regards, Aneesh
Best regards, Marek Vasut
Hi Marek,
On Sat, 7 Jul 2012 09:59:52 +0200, Marek Vasut marek.vasut@gmail.com wrote:
Dear Aneesh V,
Hi Marek,
On 07/06/2012 04:32 PM, Tetsuyuki Kobayashi wrote:
Hello,
On 2012/07/07, at 8:02, Marek Vasut wrote:
Dear Aneesh V,
Enable -march=armv7-a for armv7 platforms if the tool-chain supports it. This in turn results in Thumb-2 code generated for these platforms if CONFIG_SYS_THUMB_BUILD is enabled.
Signed-off-by: Aneesh Vaneesh@ti.com
For some reason, this patch breaks USB EHCI on mx51 efika boards. The board just freezes instead of detecting USB devices. Reverting this patch fixes the issue.
Note I use gcc 4.7.1 (!), might be compiler issue?
Tom, can you try on one of your beagle-dogs please? :)
Just for your information, I doubt unaligned access causes this problem.
My investigation is here, http://lists.denx.de/pipermail/u-boot/2012-June/127020.html My patch [PATCH] arm: armv7: add compile option -mno-unaligned-access if
available
This makes sense. You might want to try this patch. Also, to be sure that it's nothing to do with Thumb you can make sure you are not enabling CONFIG_SYS_THUMB_BUILD.
Ok, I think the patch should be applied then ?
but what if the option isn't available?
If I am not mistaken, from an analysis standpoint, on compilers where the option is unavailable, there is no issue regarding alignment; and from a solution standpoint... We'll need to add the option only when cross-compiler version is known to honor it.
Best regards, Marek Vasut
Amicalement,
Avoid using __attribute__ ((__packed__)) unless it's absolutely necessary. "packed" will remove alignment requirements for the respective objects and may cause alignment issues unless alignment is also enforced using a pragma.
Here, these packed attributes were causing alignment faults in Thumb build.
Signed-off-by: Aneesh V aneesh@ti.com ---
Changes in v4: - None
Changes in v3: - Newly added --- arch/arm/include/asm/arch-omap4/mux_omap4.h | 2 +- arch/arm/include/asm/arch-omap5/mux_omap5.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap4/mux_omap4.h b/arch/arm/include/asm/arch-omap4/mux_omap4.h index 30bfad7..4de7c70 100644 --- a/arch/arm/include/asm/arch-omap4/mux_omap4.h +++ b/arch/arm/include/asm/arch-omap4/mux_omap4.h @@ -34,7 +34,7 @@ struct pad_conf_entry {
u16 val;
-} __attribute__ ((packed)); +};
#ifdef CONFIG_OFF_PADCONF #define OFF_PD (1 << 12) diff --git a/arch/arm/include/asm/arch-omap5/mux_omap5.h b/arch/arm/include/asm/arch-omap5/mux_omap5.h index b8c2185..af6874f 100644 --- a/arch/arm/include/asm/arch-omap5/mux_omap5.h +++ b/arch/arm/include/asm/arch-omap5/mux_omap5.h @@ -34,7 +34,7 @@ struct pad_conf_entry {
u16 val;
-} __attribute__ ((__packed__)); +};
#ifdef CONFIG_OFF_PADCONF #define OFF_PD (1 << 12)
Signed-off-by: Aneesh V aneesh@ti.com --- Changes in v4: - None
Changes in v3: - None
Changes from V1 to V2: - None
Changes from RFC to V1: - None --- include/configs/omap4_common.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index a989721..01b4d6c 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -287,4 +287,6 @@
#define CONFIG_SYS_ENABLE_PADS_ALL
+#define CONFIG_SYS_THUMB_BUILD + #endif /* __CONFIG_OMAP4_COMMON_H */
Tom, Albert,
Does this series look good?
On Thursday 08 March 2012 10:50 PM, Aneesh V wrote:
Thumb is an alternate instruction set available in many ARM processors. Below is a detailed description from ARM specs:
"The Thumb instruction set is a re-encoded subset of the ARM instruction set. Thumb instructions execute in their own processor state, with the architecture defining the mechanisms required to transition between ARM and Thumb states. The key difference is that Thumb instructions are half the size of ARM instructions(16 bits compared with 32 bits). Greater code density can usually be achieved by using the Thumb instruction set in preference to the ARM instruction set, at a cost of some reduction in performance"
"In ARMv6T2, Thumb-2 technology is introduced. This technology makes it possible to extend the original Thumb instruction set with many 32-bit instructions. The range of 32-bit Thumb instructions included in ARMv6T2 permits Thumb code to achieve performance similar to ARM code, with code density better than that of earlier Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide almost identical functionality"
This series adds Thumb support in U-Boot and enables it for OMAP4. It also fixes issues faced while booting OMAP4 with Thumb-2 images of U-Boot and SPL.
Thumb mode is becoming increasingly relevant for U-Boot with the advent of SPL. It's very important to keep SPL size smaller considering the internal RAM size constraints on many platforms. On OMAP4 the size reduction enables us to use SPL on secure devices that have smaller internal RAM available for non-secure world.
To enable support for new platforms you just need to add CONFIG_SYS_THUMB_BUILD in your config file.
Tool-chains tried:
- Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709
- Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 4.6.3 20120105 (prerelease) GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22
Code-size reduction: Image ARM build Thumb build % Reduction u-boot.bin 190408 144676 24.01% u-boot-spl.bin 33200 25096 24.40%
Performance(timestamp just before the main loop): ARM build Thumb build % Reduction 898510us 878247us -2.25%
Performance actually improved marginally for the Thumb build, maybe because of the reduced image sizes.
Aneesh V (6): arm: adapt asm/linkage.h from Linux armv7: add appropriate headers for assembly functions ARM: enable Thumb build armv7: Use -march=armv7-a and thereby enable Thumb-2 omap4+: Avoid using __attribute__ ((__packed__)) OMAP4: enable Thumb build
README | 8 +++++ arch/arm/config.mk | 22 +++++++++---- arch/arm/cpu/armv7/config.mk | 7 +++- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/mx6/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 14 ++++---- arch/arm/cpu/armv7/omap-common/reset.S | 5 ++- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 41 ++++++++++++----------- arch/arm/cpu/armv7/s5pc1xx/cache.S | 10 +++-- arch/arm/cpu/armv7/s5pc1xx/reset.S | 5 ++- arch/arm/cpu/armv7/start.S | 13 ++++--- arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/u8500/lowlevel.S | 9 +++-- arch/arm/include/asm/arch-omap4/mux_omap4.h | 2 +- arch/arm/include/asm/arch-omap5/mux_omap5.h | 2 +- arch/arm/include/asm/linkage.h | 7 ++++ include/configs/omap4_common.h | 2 + include/linux/linkage.h | 7 +++- 18 files changed, 106 insertions(+), 63 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h
Tom, Albert,
Does this series look good?
Hi Aneesh,
The assembly files (like arch/arm/cpu/armv7/start.S) are still compiled ARM 32 with this patch series, but they call into C files that are compiled -mthumb. Shouldn't the branches be changed into thumb state changing branches (bx/blx) ? In particular I'm looking at the call into board_init_f()
-Allen
On Thursday 08 March 2012 10:50 PM, Aneesh V wrote:
Thumb is an alternate instruction set available in many ARM processors. Below is a detailed description from ARM specs:
"The Thumb instruction set is a re-encoded subset of the ARM instruction set. Thumb instructions execute in their own processor state, with the architecture defining the mechanisms required to transition between ARM and Thumb states. The key difference is that Thumb instructions are half the size of ARM instructions(16 bits compared with 32 bits). Greater code density can usually be achieved by using the Thumb instruction set in preference to the ARM instruction set, at a cost of some reduction in performance"
"In ARMv6T2, Thumb-2 technology is introduced. This technology makes it possible to extend the original Thumb instruction set with many 32-bit instructions. The range of 32-bit Thumb instructions included in ARMv6T2 permits Thumb code to achieve performance similar to ARM code, with code density better than that of earlier Thumb code. From ARMv6T2, the ARM and Thumb instruction sets provide almost identical functionality"
This series adds Thumb support in U-Boot and enables it for OMAP4. It also fixes issues faced while booting OMAP4 with Thumb-2 images of U-Boot and SPL.
Thumb mode is becoming increasingly relevant for U-Boot with the advent of SPL. It's very important to keep SPL size smaller considering the internal RAM size constraints on many platforms. On OMAP4 the size reduction enables us to use SPL on secure devices that have smaller internal RAM available for non-secure world.
To enable support for new platforms you just need to add CONFIG_SYS_THUMB_BUILD in your config file.
Tool-chains tried:
- Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709
- Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 4.6.3 20120105 (prerelease) GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC
2012.01) 2.22
Code-size reduction: Image ARM build Thumb build % Reduction u-boot.bin 190408 144676 24.01% u-boot-spl.bin 33200 25096 24.40%
Performance(timestamp just before the main loop): ARM build Thumb build % Reduction 898510us 878247us -2.25%
Performance actually improved marginally for the Thumb build, maybe because of the reduced image sizes.
Aneesh V (6): arm: adapt asm/linkage.h from Linux armv7: add appropriate headers for assembly functions ARM: enable Thumb build armv7: Use -march=armv7-a and thereby enable Thumb-2 omap4+: Avoid using __attribute__ ((__packed__)) OMAP4: enable Thumb build
README | 8 +++++ arch/arm/config.mk | 22 +++++++++---- arch/arm/cpu/armv7/config.mk | 7 +++- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/mx6/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 14 ++++---- arch/arm/cpu/armv7/omap-common/reset.S | 5 ++- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 41 ++++++++++++--
arch/arm/cpu/armv7/s5pc1xx/cache.S | 10 +++-- arch/arm/cpu/armv7/s5pc1xx/reset.S | 5 ++- arch/arm/cpu/armv7/start.S | 13 ++++--- arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 5 ++- arch/arm/cpu/armv7/u8500/lowlevel.S | 9 +++-- arch/arm/include/asm/arch-omap4/mux_omap4.h | 2 +- arch/arm/include/asm/arch-omap5/mux_omap5.h | 2 +- arch/arm/include/asm/linkage.h | 7 ++++ include/configs/omap4_common.h | 2 + include/linux/linkage.h | 7 +++- 18 files changed, 106 insertions(+), 63 deletions(-) create mode 100644 arch/arm/include/asm/linkage.h
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
nvpublic
Allen Martin AMartin@nvidia.com writes:
Tom, Albert,
Does this series look good?
Hi Aneesh,
The assembly files (like arch/arm/cpu/armv7/start.S) are still compiled ARM 32 with this patch series, but they call into C files that are compiled -mthumb. Shouldn't the branches be changed into thumb state changing branches (bx/blx) ? In particular I'm looking at the call into board_init_f()
The linker should take care of that.
On Thu, Mar 08, 2012 at 10:50:16PM +0530, Aneesh V wrote:
[snip]
Tool-chains tried:
- Sourcery G++ Lite 2010q1-202
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1 GNU ld (Sourcery G++ Lite 2010q1-202) - binutils 2.19.51.20090709
- Linaro 4.6-2012.01
arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 4.6.3 20120105 (prerelease) GNU ld (crosstool-NG linaro-1.13.1-2012.01-20120125 - Linaro GCC 2012.01) 2.22
So, the (normally?) required to work toolchains are ELDK 5.1 and ELDK 4.2. 5.1 is fine but with 4.2 (gcc 4.2.2) we get two warnings for every file about interworking/thumb not being supported. Further, the resulting binary doesn't boot.
However, is this really a problem? I don't imagine folks using ELDK 4.2-era tools on OMAP5, and I have a tough time imaging them using it for OMAP4.
Dear Tom Rini,
In message 20120315202316.GA6855@bill-the-cat you wrote:
So, the (normally?) required to work toolchains are ELDK 5.1 and ELDK 4.2. 5.1 is fine but with 4.2 (gcc 4.2.2) we get two warnings for every file about interworking/thumb not being supported. Further, the resulting binary doesn't boot.
However, is this really a problem? I don't imagine folks using ELDK 4.2-era tools on OMAP5, and I have a tough time imaging them using it for OMAP4.
I don't consider it a big problem (just a bit sad) if ELDK 4.2 cannot be used for building these. However, I think it is not acceptable tobuild known-to-be-broken images. If the tool chain is too old, this shall result in a clear error message and abort of the build.
Why is thumb mode needed for these boards? Just because of image size?
Best regards,
Wolfgang Denk
On Thu, Mar 15, 2012 at 1:46 PM, Wolfgang Denk wd@denx.de wrote:
Dear Tom Rini,
In message 20120315202316.GA6855@bill-the-cat you wrote:
So, the (normally?) required to work toolchains are ELDK 5.1 and ELDK 4.2. 5.1 is fine but with 4.2 (gcc 4.2.2) we get two warnings for every file about interworking/thumb not being supported. Further, the resulting binary doesn't boot.
However, is this really a problem? I don't imagine folks using ELDK 4.2-era tools on OMAP5, and I have a tough time imaging them using it for OMAP4.
I don't consider it a big problem (just a bit sad) if ELDK 4.2 cannot be used for building these. However, I think it is not acceptable tobuild known-to-be-broken images. If the tool chain is too old, this shall result in a clear error message and abort of the build.
Is an #error in a common omap4/5 file sufficient or does it need to be sooner than that?
Why is thumb mode needed for these boards? Just because of image size?
Basically, yes. Without thumb mode we're very close (and sometimes spilling over) the size limit. Thumb takes us away from that and is a small speed increase (due to smaller sized files).
Dear Tom Rini,
In message CA+M6bXkBodKLkkqFseqo=BeNuL62W-MUSgsTEYgV4WLEvf1GtA@mail.gmail.com you wrote:
I don't consider it a big problem (just a bit sad) if ELDK 4.2 cannot be used for building these. However, I think it is not acceptable tobuild known-to-be-broken images. If the tool chain is too old, this shall result in a clear error message and abort of the build.
Is an #error in a common omap4/5 file sufficient or does it need to be sooner than that?
If it can be tested there, it can probably also tested before we start building at all?
Why is thumb mode needed for these boards? Just because of image size?
Basically, yes. Without thumb mode we're very close (and sometimes spilling over) the size limit. Thumb takes us away from that and is a small speed increase (due to smaller sized files).
size limit means size limit for the SPL due to limitations of the ROM boot loader resp. the available RAM size?
Best regards,
Wolfgang Denk
On Thu, Mar 15, 2012 at 10:01:50PM +0100, Wolfgang Denk wrote:
Dear Tom Rini,
In message CA+M6bXkBodKLkkqFseqo=BeNuL62W-MUSgsTEYgV4WLEvf1GtA@mail.gmail.com you wrote:
I don't consider it a big problem (just a bit sad) if ELDK 4.2 cannot be used for building these. However, I think it is not acceptable tobuild known-to-be-broken images. If the tool chain is too old, this shall result in a clear error message and abort of the build.
Is an #error in a common omap4/5 file sufficient or does it need to be sooner than that?
If it can be tested there, it can probably also tested before we start building at all?
I suspect no just because the kernel does this in <linux/compiler-gcc[45].h>
Why is thumb mode needed for these boards? Just because of image size?
Basically, yes. Without thumb mode we're very close (and sometimes spilling over) the size limit. Thumb takes us away from that and is a small speed increase (due to smaller sized files).
size limit means size limit for the SPL due to limitations of the ROM boot loader resp. the available RAM size?
On OMAP4 we have (after a quick peek around) 56KB SRAM but we only have 40KB of that as non-secure SRAM for use by SPL.
On Thu, Mar 15, 2012 at 02:12:51PM -0700, Tom Rini wrote:
On Thu, Mar 15, 2012 at 10:01:50PM +0100, Wolfgang Denk wrote:
Dear Tom Rini,
In message CA+M6bXkBodKLkkqFseqo=BeNuL62W-MUSgsTEYgV4WLEvf1GtA@mail.gmail.com you wrote:
I don't consider it a big problem (just a bit sad) if ELDK 4.2 cannot be used for building these. However, I think it is not acceptable tobuild known-to-be-broken images. If the tool chain is too old, this shall result in a clear error message and abort of the build.
Is an #error in a common omap4/5 file sufficient or does it need to be sooner than that?
If it can be tested there, it can probably also tested before we start building at all?
I suspect no just because the kernel does this in <linux/compiler-gcc[45].h>
I take it back, we can do that if we bring in the archprepare rule logic that the kernel has. I'll go down this path now...
Dear Tom Rini,
In message 20120315222118.GC6855@bill-the-cat you wrote:
If it can be tested there, it can probably also tested before we start building at all?
I suspect no just because the kernel does this in <linux/compiler-gcc[45].h>
I take it back, we can do that if we bring in the archprepare rule logic that the kernel has. I'll go down this path now...
Thanks. That's much better.
Best regards,
Wolfgang Denk
Tom, <snip..>
Is an #error in a common omap4/5 file sufficient or does it need
to be
sooner than that?
If it can be tested there, it can probably also tested before we
start
building at all?
I suspect no just because the kernel does this in <linux/compiler-gcc[45].h>
I take it back, we can do that if we bring in the archprepare rule logic that the kernel has. I'll go down this path now...
Today though out of 40KB of non secure SRAM on OMAP4 we cannot use more than 32KB of SRAM in EMU devices because of romcode restrictions.
OMAP5 is not a problem where we have sufficient Non SECURE SRAM.
Just to understand, are we now required to introduce #error macro in OMAP4 to get this through ?
Thanks, Sricharan
On Fri, Mar 16, 2012 at 12:48 AM, Sricharan R r.sricharan@ti.com wrote:
Tom, <snip..>
Is an #error in a common omap4/5 file sufficient or does it need
to be
sooner than that?
If it can be tested there, it can probably also tested before we
start
building at all?
I suspect no just because the kernel does this in <linux/compiler-gcc[45].h>
I take it back, we can do that if we bring in the archprepare rule logic that the kernel has. I'll go down this path now...
Today though out of 40KB of non secure SRAM on OMAP4 we cannot use more than 32KB of SRAM in EMU devices because of romcode restrictions.
Ah, I forgot about the romcode. But other devices allow for more yes (since the currently enforced limit is 38kB) ?
OMAP5 is not a problem where we have sufficient Non SECURE SRAM.
Just to understand, are we now required to introduce #error macro in OMAP4 to get this through ?
No, I just need to post the patches I have that introduce a gcc version check prior to building. It's lifted in part from the kernel, but our Makefiles are too different for the kernel way to just work :(
Hi,
Just to understand, are we now required to introduce #error macro in OMAP4 to get this through ?
No, I just need to post the patches I have that introduce a gcc version check prior to building. It's lifted in part from the kernel, but our Makefiles are too different for the kernel way to just work :(
Thanks Tom!
-- Tom
Added from Linux - commit fde7d9049e55ab85a390be7f415d74c9f62dd0f9
Signed-off-by: Tom Rini trini@ti.com --- config.mk | 6 +++++- tools/gcc-version.sh | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 1 deletions(-) create mode 100755 tools/gcc-version.sh
diff --git a/config.mk b/config.mk index ddaa477..8f4a253 100644 --- a/config.mk +++ b/config.mk @@ -104,7 +104,7 @@ HOSTCFLAGS += -pedantic
######################################################################### # -# Option checker (courtesy linux kernel) to ensure +# Option checker, gcc version (courtesy linux kernel) to ensure # only supported compiler options are used # CC_OPTIONS_CACHE_FILE := $(OBJTREE)/include/generated/cc_options.mk @@ -126,6 +126,10 @@ cc-option = $(strip $(if $(findstring $1,$(CC_OPTIONS)),$1,\ $(if $(call cc-option-sys,$1),$1,$2))) endif
+# cc-version +# Usage gcc-ver := $(call cc-version) +cc-version = $(shell $(SHELL) $(SRCTREE)/tools/gcc-version.sh $(CC)) + # # Include the make variables (CC, etc...) # diff --git a/tools/gcc-version.sh b/tools/gcc-version.sh new file mode 100755 index 0000000..debecb5 --- /dev/null +++ b/tools/gcc-version.sh @@ -0,0 +1,32 @@ +#!/bin/sh +# +# gcc-version [-p] gcc-command +# +# Prints the gcc version of `gcc-command' in a canonical 4-digit form +# such as `0295' for gcc-2.95, `0303' for gcc-3.3, etc. +# +# With the -p option, prints the patchlevel as well, for example `029503' for +# gcc-2.95.3, `030301' for gcc-3.3.1, etc. +# + +if [ "$1" = "-p" ] ; then + with_patchlevel=1; + shift; +fi + +compiler="$*" + +if [ ${#compiler} -eq 0 ]; then + echo "Error: No compiler specified." + printf "Usage:\n\t$0 <gcc-command>\n" + exit 1 +fi + +MAJOR=$(echo __GNUC__ | $compiler -E -xc - | tail -n 1) +MINOR=$(echo __GNUC_MINOR__ | $compiler -E -xc - | tail -n 1) +if [ "x$with_patchlevel" != "x" ] ; then + PATCHLEVEL=$(echo __GNUC_PATCHLEVEL__ | $compiler -E -xc - | tail -n 1) + printf "%02d%02d%02d\n" $MAJOR $MINOR $PATCHLEVEL +else + printf "%02d%02d\n" $MAJOR $MINOR +fi
This rule confirms that if we're on ARM and we have enabled THUMB builds that we have a new enough toolchain to produce a working binary.
Signed-off-by: Tom Rini trini@ti.com --- Makefile | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile index 11aac21..b7f5848 100644 --- a/Makefile +++ b/Makefile @@ -515,7 +515,7 @@ updater:
# Explicitly make _depend in subdirs containing multiple targets to prevent # parallel sub-makes creating .depend files simultaneously. -depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) \ +depend dep: checkthumb $(TIMESTAMP_FILE) $(VERSION_FILE) \ $(obj)include/autoconf.mk \ $(obj)include/generated/generic-asm-offsets.h \ $(obj)include/generated/asm-offsets.h @@ -548,6 +548,15 @@ SYSTEM_MAP = \ $(obj)System.map: $(obj)u-boot @$(call SYSTEM_MAP,$<) > $(obj)System.map
+checkthumb: + @if test "$(ARCH)" = "arm" -a "$(CONFIG_SYS_THUMB_BUILD)" = "y"; then \ + if test $(call cc-version) -lt 0404; then \ + echo -n '*** Your GCC does not produce working '; \ + echo 'binaries in THUMB mode.'; \ + echo '*** Your board is configured for THUMB mode.'; \ + false; \ + fi ; \ + fi # # Auto-generate the autoconf.mk file (which is included by all makefiles) #
On Friday 16 March 2012 11:27:48 Tom Rini wrote:
--- a/Makefile +++ b/Makefile
# Explicitly make _depend in subdirs containing multiple targets to prevent # parallel sub-makes creating .depend files simultaneously. -depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) \ +depend dep: checkthumb $(TIMESTAMP_FILE) $(VERSION_FILE) \ $(obj)include/autoconf.mk \ $(obj)include/generated/generic-asm-offsets.h \ $(obj)include/generated/asm-offsets.h @@ -548,6 +548,15 @@ SYSTEM_MAP = \ $(obj)System.map: $(obj)u-boot @$(call SYSTEM_MAP,$<) > $(obj)System.map
+checkthumb:
- @if test "$(ARCH)" = "arm" -a "$(CONFIG_SYS_THUMB_BUILD)" = "y"; then \
if test $(call cc-version) -lt 0404; then \echo -n '*** Your GCC does not produce working '; \echo 'binaries in THUMB mode.'; \echo '*** Your board is configured for THUMB mode.'; \false; \fi ; \- fi
couldn't you do: arch/arm/config.mk:ALL-$(CONFIG_SYS_THUMB_BUILD) += checkthumb -mike
On Fri, Mar 16, 2012 at 12:07:23PM -0400, Mike Frysinger wrote:
On Friday 16 March 2012 11:27:48 Tom Rini wrote:
--- a/Makefile +++ b/Makefile
# Explicitly make _depend in subdirs containing multiple targets to prevent # parallel sub-makes creating .depend files simultaneously. -depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) \ +depend dep: checkthumb $(TIMESTAMP_FILE) $(VERSION_FILE) \ $(obj)include/autoconf.mk \ $(obj)include/generated/generic-asm-offsets.h \ $(obj)include/generated/asm-offsets.h @@ -548,6 +548,15 @@ SYSTEM_MAP = \ $(obj)System.map: $(obj)u-boot @$(call SYSTEM_MAP,$<) > $(obj)System.map
+checkthumb:
- @if test "$(ARCH)" = "arm" -a "$(CONFIG_SYS_THUMB_BUILD)" = "y"; then \
if test $(call cc-version) -lt 0404; then \echo -n '*** Your GCC does not produce working '; \echo 'binaries in THUMB mode.'; \echo '*** Your board is configured for THUMB mode.'; \false; \fi ; \- fi
couldn't you do: arch/arm/config.mk:ALL-$(CONFIG_SYS_THUMB_BUILD) += checkthumb
I thought I had tried that and it didn't work, but.. it does. Thanks.
This rule confirms that if we're on ARM and we have enabled THUMB builds that we have a new enough toolchain to produce a working binary.
Changes in v2: - Switch to ALL-$(CONFIG_SYS_THUMB_BUILD) in arch/arm/config.mk (Mike F) - Simplfy checkthumb test after doing the above
Signed-off-by: Tom Rini trini@ti.com --- Makefile | 7 +++++++ arch/arm/config.mk | 1 + 2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile index 11aac21..5af4ced 100644 --- a/Makefile +++ b/Makefile @@ -548,6 +548,13 @@ SYSTEM_MAP = \ $(obj)System.map: $(obj)u-boot @$(call SYSTEM_MAP,$<) > $(obj)System.map
+checkthumb: + @if test $(call cc-version) -lt 0404; then \ + echo -n '*** Your GCC does not produce working '; \ + echo 'binaries in THUMB mode.'; \ + echo '*** Your board is configured for THUMB mode.'; \ + false; \ + fi # # Auto-generate the autoconf.mk file (which is included by all makefiles) # diff --git a/arch/arm/config.mk b/arch/arm/config.mk index d4fa1f8..367baa2 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -43,6 +43,7 @@ else PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \ $(call cc-option,-mno-thumb-interwork,) endif +ALL-$(CONFIG_SYS_THUMB_BUILD) += checkthumb
# Try if EABI is supported, else fall back to old API, # i. e. for example:
On Friday 16 March 2012 12:34:35 Tom Rini wrote:
--- a/Makefile +++ b/Makefile
+checkthumb:
- @if test $(call cc-version) -lt 0404; then \
echo -n '*** Your GCC does not produce working '; \
fwiw, `echo -n` isn't portable. `printf` is.
echo 'binaries in THUMB mode.'; \echo '*** Your board is configured for THUMB mode.'; \false; \- fi
would be nice if we could refactor our .mk's somehow to keep arch and board specific ones out of the top level Makefile. but we can't today :(.
Acked-by: Mike Frysinger vapier@gentoo.org -mike
participants (13)
-
Albert ARIBAUD -
Allen Martin -
Aneesh V -
Marek Vasut -
Mike Frysinger -
Måns Rullgård -
R, Sricharan -
Sricharan R
-
Stephen Warren -
Tetsuyuki Kobayashi -
Thierry Reding -
Tom Rini -
Wolfgang Denk