[U-Boot] Query on CONFIG_SYS_THUMB_BUILD

[Victor Ascroft]

On 11/15/2014 07:26 AM, Simon Glass wrote:
> Hi Albert,
> 
> On 14 November 2014 08:26, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
>> Hello Simon,
>>
>> On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass <sjg at chromium.org>
>> 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?
>>
>> Victor,
>>
>> In addition to Simon's question below on the toolchain, I would like to
>> know which commit you're trying to build.

I am using u-boot 2014.10, but, I have a modified branch which supports my hardware
and I also have changes for having USB Host and Client support for the Vybrid platform.

The toolchain I am using is gcc-linaro-arm-linux-gnueabihf-2012.09-20120921

http://www.codesourcery.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

I have downloaded it from the above link.

>>
>>> 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.
>>
>> Simon,
>>
>> I believe you've built crt0.S for ARM, not Thumb.
> 
> Yes, but I suspect that is a function of the build system. I checked
> the rest of U-Boot and most of it (including SPL) is Thumb 2. I
> suppose we could use Thumb 2 for crt0.S if all the instructions are
> supported.

Yes Simon, you had it for ARM. I also believed it is a function of the
build system. But, does crt0.S have to be in Thumb2? Thumb interop is 
not enough with ARM and Thumb co-existing?
 
Does CONFIG_SYS_THUMB_BUILD require any specific changes to the build
system. I was under the impression, the configuration would take care
of it. I can do any changes are required, but, I have no knowledge of
it. 
> 
> Regards,
> Simon
> 

Regards,
Victor.