[U-Boot] Query on CONFIG_SYS_THUMB_BUILD

[Stefan Agner]

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