On 2014-11-14 15:01, Simon Glass wrote:
Hi Victor,
On 13 November 2014 09:29, Victor Ascroft victorascroft@gmail.com wrote:
Hello,
I am working with a Cortex A5 Freescale Vybrid Processor. Since a thumb build leads to a saving of almost 1 MB for my u-boot image and consequently to faster serial downloads I have been looking at this. Currently enabling this option leads to a hang.
After some debugging I have narrowed the place of hang to "ldr pc, =board_init_r" in arch/arm/lib/crt0.S. My debugging procedure was to put a branch to a small function which just printed a small message with puts, just before the ldr instruction and then a printing a small message with puts just at the start of board_init_r in common/board_r.c . For a non thumb build, the two messages get printed and I can boot to the u-boot prompt. For a thumb build, only the first message before the ldr instruction gets printed.
In crt0.S bl debug_print ldr pc, =board_init_r
In board_init_r puts("In board_init_r\n"); // Right at start
void debug_print(void) { // Defined in board file puts("Debug print\n"); }
My assembly knowledge is limited and after some consultation with a senior colleague, he told me things to check.
An object dump of the crt0.o shows a branch to an even address. For thumb, this is expected to be odd. To just try out, I did a change as below ldr r3, =board_init_r add r3, #1 bx r3
No change with this. My expectation was the compiler/linker/assembler would take care of the requirements, with the CONFIG_SYS_THUMB_BUILD. Frankly speaking I am not sure if this is the complete issue or only a part of it. I have seen patches with regards to OMAP send in by Aneesh V, which made changes of the form .type fn_name, %function to all the low level assembly functions, but, I couldn't dig up much more or variants thereof. Basically, from what I understand, this takes care of specifying .thumb_func for a thumb function or so to speak.
Any pointers?
I tried this on a peach_pi (Samsung Chromebook 2 13") and it worked OK for me. The code sequence you refer to came out as below for me.
23e01e10 <clbss_l>: 23e01e10: e1500001 cmp r0, r1 23e01e14: 35802000 strcc r2, [r0] 23e01e18: 32800004 addcc r0, r0, #4 23e01e1c: 3afffffb bcc 23e01e10 <clbss_l> 23e01e20: fa000dec blx 23e055d8 <coloured_LED_init> 23e01e24: fb000deb blx 23e055da <red_led_on> 23e01e28: e1a00009 mov r0, r9 23e01e2c: e5991030 ldr r1, [r9, #48] ; 0x30 23e01e30: e59ff008 ldr pc, [pc, #8] ; 23e01e40 <clbss_l+0x30> 23e01e34: 02073800 .word 0x02073800 23e01e38: 23e41eb0 .word 0x23e41eb0 23e01e3c: 23e77bf0 .word 0x23e77bf0 23e01e40: 23e057a9 .word 0x23e057a9
The 'ldr pc' line is loading from 23e01e40 which does have an odd address.
What toolchain are you using? I tried with gcc 4.8.2 - including linaro's 2013.10 release.
In arch/arm/cpu/armv7/config.mk there is a fallback to armv5 from armv7-a, and this may cause it to generate Thumb code instead of Thumb 2. But you should get errors if that happens.
It's hard to debug with such limited visibility. But if I put a puts() at the start of board_init_r(), I see it on the serial console.
Just checked that on Vybrid, it actually looks good too:
3f408f58 <clbss_l>: 3f408f58: e1500001 cmp r0, r1 3f408f5c: 35802000 strcc r2, [r0] 3f408f60: 32800004 addcc r0, r0, #4 3f408f64: 3afffffb bcc 3f408f58 <clbss_l> 3f408f68: fb000da8 blx 3f40c612 <coloured_LED_init> 3f408f6c: fa000da8 blx 3f40c614 <red_led_on> 3f408f70: e1a00009 mov r0, r9 3f408f74: e599102c ldr r1, [r9, #44] ; 0x2c 3f408f78: e59ff008 ldr pc, [pc, #8] ; 3f408f88 <clbss_l+0x30> 3f408f7c: 3f07ff50 .word 0x3f07ff50 3f408f80: 3f44c9d0 .word 0x3f44c9d0 3f408f84: 3f482fc0 .word 0x3f482fc0 3f408f88: 3f40c7c5 .word 0x3f40c7c5
According to the map, this is the address of board_init_r .text.board_init_r
0x000000003f40c7c4 0x10 common/built-in.o
0x000000003f40c7c4 board_init_r
Currently I use GCC from a old Yocto/Angstrom build linger around. It's a Linaro 2013.09 GCC 4.7.4.
I will have a look into it what exactly happens here.
-- Stefan
Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot