From mboxrd@z Thu Jan 1 00:00:00 1970 From: Victor Ascroft Date: Sat, 15 Nov 2014 11:08:22 +0530 Subject: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD In-Reply-To: <5466E41F.3030308@gmail.com> References: <5464DC59.2040707@gmail.com> <20141114162643.53b09a8f@lilith> <5466E41F.3030308@gmail.com> Message-ID: <5466E6CE.7000707@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/15/2014 10:56 AM, Victor Ascroft wrote: > On 11/15/2014 07:26 AM, Simon Glass wrote: >> Hi Albert, >> >> On 14 November 2014 08:26, Albert ARIBAUD wrote: >>> Hello Simon, >>> >>> On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass >>> wrote: >>>> Hi Victor, >>>> >>>> On 13 November 2014 09:29, Victor Ascroft 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 http://launchpad.net/linaro-toolchain-binaries/trunk/2012.09/+download/gcc-linaro-arm-linux-gnueabihf-2012.09-20120921_linux.tar.bz2 Sorry I gave the link for the soft floating one by mistake :(. > > 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 : >>>> 23e01e10: e1500001 cmp r0, r1 >>>> 23e01e14: 35802000 strcc r2, [r0] >>>> 23e01e18: 32800004 addcc r0, r0, #4 >>>> 23e01e1c: 3afffffb bcc 23e01e10 >>>> 23e01e20: fa000dec blx 23e055d8 >>>> 23e01e24: fb000deb blx 23e055da >>>> 23e01e28: e1a00009 mov r0, r9 >>>> 23e01e2c: e5991030 ldr r1, [r9, #48] ; 0x30 >>>> 23e01e30: e59ff008 ldr pc, [pc, #8] ; 23e01e40 >>>> >>>> 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. >