On 2014-11-14 15:01, Simon Glass wrote: > Hi Victor, > > On 13 November 2014 09:29, Victor Ascroft <victorascr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot