* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
@ 2014-11-13 16:29 Victor Ascroft
2014-11-13 20:53 ` Wolfgang Denk
2014-11-14 14:01 ` Simon Glass
0 siblings, 2 replies; 27+ messages in thread
From: Victor Ascroft @ 2014-11-13 16:29 UTC (permalink / raw)
To: u-boot
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?
Thanks & Regards,
Sanchayan Maity.
^ permalink raw reply [flat|nested] 27+ messages in thread* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-13 16:29 [U-Boot] Query on CONFIG_SYS_THUMB_BUILD Victor Ascroft @ 2014-11-13 20:53 ` Wolfgang Denk 2014-11-14 4:30 ` Victor Ascroft 2014-11-14 14:01 ` Simon Glass 1 sibling, 1 reply; 27+ messages in thread From: Wolfgang Denk @ 2014-11-13 20:53 UTC (permalink / raw) To: u-boot Dear Victor Ascroft, In message <5464DC59.2040707@gmail.com> you wrote: > > 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. Saving 1 MB? So how big is your U-Boot image, then? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de It is important to note that probably no large operating system using current design technology can withstand a determined and well- coordinated attack, and that most such documented penetrations have been remarkably easy. - B. Hebbard, "A Penetration Analysis of the Michigan Terminal System", Operating Systems Review, Vol. 14, No. 1, June 1980, pp. 7-20 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-13 20:53 ` Wolfgang Denk @ 2014-11-14 4:30 ` Victor Ascroft 2014-11-14 5:43 ` Wolfgang Denk 0 siblings, 1 reply; 27+ messages in thread From: Victor Ascroft @ 2014-11-14 4:30 UTC (permalink / raw) To: u-boot Hello, On 11/14/2014 02:23 AM, Wolfgang Denk wrote: > Dear Victor Ascroft, > > In message <5464DC59.2040707@gmail.com> you wrote: >> >> 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. > > Saving 1 MB? So how big is your U-Boot image, then? To be exact For a thumb build: 363288 bytes For a non thumb build: 482072 bytes > > > Best regards, > > Wolfgang Denk > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-14 4:30 ` Victor Ascroft @ 2014-11-14 5:43 ` Wolfgang Denk 2014-11-14 6:10 ` Victor Ascroft 0 siblings, 1 reply; 27+ messages in thread From: Wolfgang Denk @ 2014-11-14 5:43 UTC (permalink / raw) To: u-boot Dear Victor, In message <54658577.3090807@gmail.com> you wrote: > > >> 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 > . > > > > Saving 1 MB? So how big is your U-Boot image, then? > > To be exact > > For a thumb build: > 363288 bytes > > For a non thumb build: > 482072 bytes That saves 118784 bytes or 116 KiB. This is still a lot, but far from the dramatic "1 MB" you claimed... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-14 5:43 ` Wolfgang Denk @ 2014-11-14 6:10 ` Victor Ascroft 0 siblings, 0 replies; 27+ messages in thread From: Victor Ascroft @ 2014-11-14 6:10 UTC (permalink / raw) To: u-boot On 11/14/2014 11:13 AM, Wolfgang Denk wrote: > Dear Victor, > > In message <54658577.3090807@gmail.com> you wrote: >> >>>> 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 >> . >>> >>> Saving 1 MB? So how big is your U-Boot image, then? >> >> To be exact >> >> For a thumb build: >> 363288 bytes >> >> For a non thumb build: >> 482072 bytes > > That saves 118784 bytes or 116 KiB. This is still a lot, but far from > the dramatic "1 MB" you claimed... Argh...Sorry my bad. I made a mistake there in interpreting the KB and MB. > > Best regards, > > Wolfgang Denk > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-13 16:29 [U-Boot] Query on CONFIG_SYS_THUMB_BUILD Victor Ascroft 2014-11-13 20:53 ` Wolfgang Denk @ 2014-11-14 14:01 ` Simon Glass 2014-11-14 15:26 ` Albert ARIBAUD ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Simon Glass @ 2014-11-14 14:01 UTC (permalink / raw) To: u-boot 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. Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-14 14:01 ` Simon Glass @ 2014-11-14 15:26 ` Albert ARIBAUD 2014-11-15 1:56 ` Simon Glass 2014-11-18 12:10 ` Stefan Agner 2014-11-18 16:07 ` Stefan Agner 2 siblings, 1 reply; 27+ messages in thread From: Albert ARIBAUD @ 2014-11-14 15:26 UTC (permalink / raw) To: u-boot Hello Simon, On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass <sjg@chromium.org> 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? Victor, In addition to Simon's question below on the toolchain, I would like to know which commit you're trying to build. > 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. > Regards, > Simon > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-14 15:26 ` Albert ARIBAUD @ 2014-11-15 1:56 ` Simon Glass 2014-11-15 5:26 ` Victor Ascroft 2014-11-15 12:30 ` Albert ARIBAUD 0 siblings, 2 replies; 27+ messages in thread From: Simon Glass @ 2014-11-15 1:56 UTC (permalink / raw) To: u-boot Hi Albert, On 14 November 2014 08:26, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: > Hello Simon, > > On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass <sjg@chromium.org> > 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? > > Victor, > > In addition to Simon's question below on the toolchain, I would like to > know which commit you're trying to build. > >> 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. Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-15 1:56 ` Simon Glass @ 2014-11-15 5:26 ` Victor Ascroft 2014-11-15 5:38 ` Victor Ascroft 2014-11-15 12:30 ` Albert ARIBAUD 1 sibling, 1 reply; 27+ messages in thread From: Victor Ascroft @ 2014-11-15 5:26 UTC (permalink / raw) To: u-boot On 11/15/2014 07:26 AM, Simon Glass wrote: > Hi Albert, > > On 14 November 2014 08:26, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: >> Hello Simon, >> >> On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass <sjg@chromium.org> >> 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? >> >> 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-15 5:26 ` Victor Ascroft @ 2014-11-15 5:38 ` Victor Ascroft 0 siblings, 0 replies; 27+ messages in thread From: Victor Ascroft @ 2014-11-15 5:38 UTC (permalink / raw) To: u-boot 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 <albert.u.boot@aribaud.net> wrote: >>> Hello Simon, >>> >>> On Fri, 14 Nov 2014 07:01:59 -0700, Simon Glass <sjg@chromium.org> >>> 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? >>> >>> 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 <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. > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-15 1:56 ` Simon Glass 2014-11-15 5:26 ` Victor Ascroft @ 2014-11-15 12:30 ` Albert ARIBAUD 2014-11-15 22:10 ` Simon Glass 1 sibling, 1 reply; 27+ messages in thread From: Albert ARIBAUD @ 2014-11-15 12:30 UTC (permalink / raw) To: u-boot Hello Simon, On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <sjg@chromium.org> wrote: > > 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. Ok. Just in case, I'll run a check on whether crt0.S can be assembled for Thumb and still wrk as expected. :) Do you have a list of source files which still build for ARM under CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for consistence, except probably... exception :) entry points -- and even these should be able to run in full Thumb 2. > Regards, > Simon Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-15 12:30 ` Albert ARIBAUD @ 2014-11-15 22:10 ` Simon Glass 2014-11-16 7:50 ` Albert ARIBAUD 0 siblings, 1 reply; 27+ messages in thread From: Simon Glass @ 2014-11-15 22:10 UTC (permalink / raw) To: u-boot Hi Albert, On 15 November 2014 05:30, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: > Hello Simon, > > On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <sjg@chromium.org> > wrote: > >> > 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. > > Ok. Just in case, I'll run a check on whether crt0.S can be assembled > for Thumb and still wrk as expected. :) > > Do you have a list of source files which still build for ARM under > CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for > consistence, except probably... exception :) entry points -- and even > these should be able to run in full Thumb 2. No I don't have a list, but it might be all assembler files. I don't see why cro0.S would be special. Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-15 22:10 ` Simon Glass @ 2014-11-16 7:50 ` Albert ARIBAUD 2014-11-17 6:28 ` Simon Glass 0 siblings, 1 reply; 27+ messages in thread From: Albert ARIBAUD @ 2014-11-16 7:50 UTC (permalink / raw) To: u-boot Hello Simon, On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass <sjg@chromium.org> wrote: > Hi Albert, > > On 15 November 2014 05:30, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: > > Hello Simon, > > > > On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <sjg@chromium.org> > > wrote: > > > >> > 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. > > > > Ok. Just in case, I'll run a check on whether crt0.S can be assembled > > for Thumb and still wrk as expected. :) > > > > Do you have a list of source files which still build for ARM under > > CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for > > consistence, except probably... exception :) entry points -- and even > > these should be able to run in full Thumb 2. > > No I don't have a list, but it might be all assembler files. I don't > see why cro0.S would be special. Ok, so after some research, .S files voluntarily not assembled in Thumb mode when -mthumb is defined in gcc because of this: Answer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237 (summary: -mthumb for gcc means 'use thumb2', while it means 'use dumb, 16-bit, thumb1' for GNU as, so this option is voluntarily not passed on to GNU as. You have to use .thumb in the .S file instead.) Second: getting a successful, though quick'n'dirty, build with vectors.S assembled in Thumb-2 mode needed surprisingly little change in vectors.S. I tried this with mx53loco, and it only required: - adding '.syntax unified'; - adding a .thumb directive -- *after* the vectors per se, which must still be assembled in ARM mode because current hardware always executes exceptions vectors in ARM mode (1); - using '.balign' instead of '.balignl' which causes the assembler to complain that it cannot fit an integer number of '0xdeadbeef' in the filling space; - making macro get_bad_stack use lr instead of r13, which Thumb does not allow in 'msr spsr,' instructions; - adding '.thumb_func' to all routines so that the linker makes all references to them odd and therefore, cause the CPU to enforce Thumb mode when branching to them. (1) although you *could* produce an ARM-based SoC that runs in Thumb mode by default. In this case, you'd have to make the vectors themselves Thumb too. Third: getting a successful *run* of the resulting file will require some work which I'm not going to do without a good incentive :) -- and so does producing a clean vectors.S, i.e. one which will assemble correctly for both ARM and Thumb. > Regards, > Simon Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-16 7:50 ` Albert ARIBAUD @ 2014-11-17 6:28 ` Simon Glass 2014-11-18 3:32 ` Victor Ascroft 0 siblings, 1 reply; 27+ messages in thread From: Simon Glass @ 2014-11-17 6:28 UTC (permalink / raw) To: u-boot Hi Albert, On 16 November 2014 07:50, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: > Hello Simon, > > On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass <sjg@chromium.org> > wrote: >> Hi Albert, >> >> On 15 November 2014 05:30, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: >> > Hello Simon, >> > >> > On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <sjg@chromium.org> >> > wrote: >> > >> >> > 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. >> > >> > Ok. Just in case, I'll run a check on whether crt0.S can be assembled >> > for Thumb and still wrk as expected. :) >> > >> > Do you have a list of source files which still build for ARM under >> > CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for >> > consistence, except probably... exception :) entry points -- and even >> > these should be able to run in full Thumb 2. >> >> No I don't have a list, but it might be all assembler files. I don't >> see why cro0.S would be special. > > Ok, so after some research, .S files voluntarily not assembled in Thumb > mode when -mthumb is defined in gcc because of this: > > Answer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237 > > (summary: -mthumb for gcc means 'use thumb2', while it means 'use > dumb, 16-bit, thumb1' for GNU as, so this option is voluntarily not > passed on to GNU as. You have to use .thumb in the .S file instead.) > > Second: getting a successful, though quick'n'dirty, build with vectors.S > assembled in Thumb-2 mode needed surprisingly little change in > vectors.S. I tried this with mx53loco, and it only required: > > - adding '.syntax unified'; > > - adding a .thumb directive -- *after* the vectors per se, which > must still be assembled in ARM mode because current hardware > always executes exceptions vectors in ARM mode (1); > > - using '.balign' instead of '.balignl' which causes the > assembler to complain that it cannot fit an integer > number of '0xdeadbeef' in the filling space; > > - making macro get_bad_stack use lr instead of r13, which > Thumb does not allow in 'msr spsr,' instructions; > > - adding '.thumb_func' to all routines so that the linker makes > all references to them odd and therefore, cause the CPU to > enforce Thumb mode when branching to them. > > (1) although you *could* produce an ARM-based SoC that runs in > Thumb mode by default. In this case, you'd have to make the > vectors themselves Thumb too. > > Third: getting a successful *run* of the resulting file will require > some work which I'm not going to do without a good incentive :) -- and > so does producing a clean vectors.S, i.e. one which will assemble > correctly for both ARM and Thumb. That doesn't sound too trciky, but I agree it's not a huge deal. I suppose the main benefit is consistency, since the code size improvement would be small. Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-17 6:28 ` Simon Glass @ 2014-11-18 3:32 ` Victor Ascroft 2014-11-18 4:59 ` Simon Glass 0 siblings, 1 reply; 27+ messages in thread From: Victor Ascroft @ 2014-11-18 3:32 UTC (permalink / raw) To: u-boot On Monday 17 November 2014 11:58 AM, Simon Glass wrote: > Hi Albert, > > On 16 November 2014 07:50, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: >> Hello Simon, >> >> On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass <sjg@chromium.org> >> wrote: >>> Hi Albert, >>> >>> On 15 November 2014 05:30, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: >>>> Hello Simon, >>>> >>>> On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <sjg@chromium.org> >>>> wrote: >>>> >>>>>> 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. >>>> Ok. Just in case, I'll run a check on whether crt0.S can be assembled >>>> for Thumb and still wrk as expected. :) >>>> >>>> Do you have a list of source files which still build for ARM under >>>> CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for >>>> consistence, except probably... exception :) entry points -- and even >>>> these should be able to run in full Thumb 2. >>> No I don't have a list, but it might be all assembler files. I don't >>> see why cro0.S would be special. >> Ok, so after some research, .S files voluntarily not assembled in Thumb >> mode when -mthumb is defined in gcc because of this: >> >> Answer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237 >> >> (summary: -mthumb for gcc means 'use thumb2', while it means 'use >> dumb, 16-bit, thumb1' for GNU as, so this option is voluntarily not >> passed on to GNU as. You have to use .thumb in the .S file instead.) >> >> Second: getting a successful, though quick'n'dirty, build with vectors.S >> assembled in Thumb-2 mode needed surprisingly little change in >> vectors.S. I tried this with mx53loco, and it only required: >> >> - adding '.syntax unified'; >> >> - adding a .thumb directive -- *after* the vectors per se, which >> must still be assembled in ARM mode because current hardware >> always executes exceptions vectors in ARM mode (1); >> >> - using '.balign' instead of '.balignl' which causes the >> assembler to complain that it cannot fit an integer >> number of '0xdeadbeef' in the filling space; >> >> - making macro get_bad_stack use lr instead of r13, which >> Thumb does not allow in 'msr spsr,' instructions; >> >> - adding '.thumb_func' to all routines so that the linker makes >> all references to them odd and therefore, cause the CPU to >> enforce Thumb mode when branching to them. >> >> (1) although you *could* produce an ARM-based SoC that runs in >> Thumb mode by default. In this case, you'd have to make the >> vectors themselves Thumb too. >> >> Third: getting a successful *run* of the resulting file will require >> some work which I'm not going to do without a good incentive :) -- and >> so does producing a clean vectors.S, i.e. one which will assemble >> correctly for both ARM and Thumb. So to use the thumb build correctly, all the .S files have to be changed to use thumb instructions, by specifying the .thumb option? -Regards, Victor. > That doesn't sound too trciky, but I agree it's not a huge deal. I > suppose the main benefit is consistency, since the code size > improvement would be small. > > Regards, > Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-18 3:32 ` Victor Ascroft @ 2014-11-18 4:59 ` Simon Glass 0 siblings, 0 replies; 27+ messages in thread From: Simon Glass @ 2014-11-18 4:59 UTC (permalink / raw) To: u-boot Hi Victor, On 18 November 2014 03:32, Victor Ascroft <victorascroft@gmail.com> wrote: > > On Monday 17 November 2014 11:58 AM, Simon Glass wrote: >> Hi Albert, >> >> On 16 November 2014 07:50, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: >>> Hello Simon, >>> >>> On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass <sjg@chromium.org> >>> wrote: >>>> Hi Albert, >>>> >>>> On 15 November 2014 05:30, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: >>>>> Hello Simon, >>>>> >>>>> On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <sjg@chromium.org> >>>>> wrote: >>>>> >>>>>>> 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. >>>>> Ok. Just in case, I'll run a check on whether crt0.S can be assembled >>>>> for Thumb and still wrk as expected. :) >>>>> >>>>> Do you have a list of source files which still build for ARM under >>>>> CONFIG_SYS_THUMB_BUILD? I' would prefer all of the code to be thumb for >>>>> consistence, except probably... exception :) entry points -- and even >>>>> these should be able to run in full Thumb 2. >>>> No I don't have a list, but it might be all assembler files. I don't >>>> see why cro0.S would be special. >>> Ok, so after some research, .S files voluntarily not assembled in Thumb >>> mode when -mthumb is defined in gcc because of this: >>> >>> Answer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237 >>> >>> (summary: -mthumb for gcc means 'use thumb2', while it means 'use >>> dumb, 16-bit, thumb1' for GNU as, so this option is voluntarily not >>> passed on to GNU as. You have to use .thumb in the .S file instead.) >>> >>> Second: getting a successful, though quick'n'dirty, build with vectors.S >>> assembled in Thumb-2 mode needed surprisingly little change in >>> vectors.S. I tried this with mx53loco, and it only required: >>> >>> - adding '.syntax unified'; >>> >>> - adding a .thumb directive -- *after* the vectors per se, which >>> must still be assembled in ARM mode because current hardware >>> always executes exceptions vectors in ARM mode (1); >>> >>> - using '.balign' instead of '.balignl' which causes the >>> assembler to complain that it cannot fit an integer >>> number of '0xdeadbeef' in the filling space; >>> >>> - making macro get_bad_stack use lr instead of r13, which >>> Thumb does not allow in 'msr spsr,' instructions; >>> >>> - adding '.thumb_func' to all routines so that the linker makes >>> all references to them odd and therefore, cause the CPU to >>> enforce Thumb mode when branching to them. >>> >>> (1) although you *could* produce an ARM-based SoC that runs in >>> Thumb mode by default. In this case, you'd have to make the >>> vectors themselves Thumb too. >>> >>> Third: getting a successful *run* of the resulting file will require >>> some work which I'm not going to do without a good incentive :) -- and >>> so does producing a clean vectors.S, i.e. one which will assemble >>> correctly for both ARM and Thumb. > So to use the thumb build correctly, all the .S files have to be changed to use > thumb instructions, by specifying the .thumb option? No this is purely an optional idea. For me, the current Thumb support works fine on Exynos 54xx (which is Cortex A7/A15). The issue you are seeing may be specific to the A5 CPU, or your platform/toolchain. You could perhaps try a newer toolchain (e.g. linaro). crt0.S does not need to be in Thumb code. You could also check that -mthumb-interwork is defined correctly. You can use 'make V=1 ...' to see full verbose output. You could also disassemble the code sequence as I did to check it. I am assuming you have changed nothing else between building with Thumb and ARM. Regards, Simon ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-14 14:01 ` Simon Glass 2014-11-14 15:26 ` Albert ARIBAUD @ 2014-11-18 12:10 ` Stefan Agner 2014-11-18 16:07 ` Stefan Agner 2 siblings, 0 replies; 27+ messages in thread From: Stefan Agner @ 2014-11-18 12:10 UTC (permalink / raw) To: u-boot 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-14 14:01 ` Simon Glass 2014-11-14 15:26 ` Albert ARIBAUD 2014-11-18 12:10 ` Stefan Agner @ 2014-11-18 16:07 ` Stefan Agner 2014-11-18 18:37 ` Stefan Agner 2 siblings, 1 reply; 27+ messages in thread From: Stefan Agner @ 2014-11-18 16:07 UTC (permalink / raw) To: u-boot 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. Ok, turns out the problem with Thumb2 only appear when using CONFIG_USE_ARCH_MEMCPY (hence added Matthias to CC). Does peach_pi still works with that config enabled? On the Vybrid board we use that to speed up NAND access, with the current NAND driver, data get copied by the CPU. In setup_reloc, common/board_f.c, probably the first use of memcpy, things started to get weird. The code after memcpy doesn't get executed, I think something with the stack goes wrong, but not really sure what happens. -- Stefan > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-18 16:07 ` Stefan Agner @ 2014-11-18 18:37 ` Stefan Agner 2014-11-19 6:42 ` Albert ARIBAUD 0 siblings, 1 reply; 27+ messages in thread From: Stefan Agner @ 2014-11-18 18:37 UTC (permalink / raw) To: u-boot On 2014-11-18 17:07, Stefan Agner wrote: > 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. > > Ok, turns out the problem with Thumb2 only appear when using > CONFIG_USE_ARCH_MEMCPY (hence added Matthias to CC). Does peach_pi still > works with that config enabled? On the Vybrid board we use that to speed > up NAND access, with the current NAND driver, data get copied by the > CPU. > > In setup_reloc, common/board_f.c, probably the first use of memcpy, > things started to get weird. The code after memcpy doesn't get executed, > I think something with the stack goes wrong, but not really sure what > happens. It seems that this memcpy implementation is not able to be run in ARM mode when called from Thumb2 code. Checked the Linux kernel, since that's where that file comes from, they compile a Thumb2 version of that file when compiling the kernel in Thumb2 mode. With some changes I also managed to compile that file in Thumb2 in U-Boot: diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f0eafd6..ddbc8dc 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -30,6 +30,8 @@ PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ $(call cc-option,-marm,)\ $(call cc-option,-mno-thumb-interwork,)\ ) +AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it) +PF_CPPFLAGS_ARM += $(AFLAGS_AUTOIT) else PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \ $(call cc-option,-mno-thumb-interwork,) diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S index f655256..fcf028c 100644 --- a/arch/arm/lib/memcpy.S +++ b/arch/arm/lib/memcpy.S @@ -12,11 +12,14 @@ #include <asm/assembler.h> -#define W(instr) instr +#define W(instr) instr.w #define LDR1W_SHIFT 0 #define STR1W_SHIFT 0 +#define CALGN(code...) + + .macro ldr1w ptr reg abort W(ldr) \reg, [\ptr], #4 .endm @@ -57,12 +60,15 @@ /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */ + .syntax unified + .thumb + .thumb_func .globl memcpy memcpy: - +/* cmp r0, r1 moveq pc, lr - +*/ enter r4, lr subs r2, r2, #4 diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h index 76564ac..41a0dac 100644 --- a/include/configs/colibri_vf.h +++ b/include/configs/colibri_vf.h @@ -53,7 +53,10 @@ #define CONFIG_CMD_NAND #define CONFIG_NAND_VF610_NFC #define CONFIG_SYS_NAND_SELF_INIT + +#define CONFIG_SYS_THUMB_BUILD #define CONFIG_USE_ARCH_MEMCPY + #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_BASE NFC_BASE_ADDR The main change here is the implicit-it/auto-it functionality. For me it works when enabling that globally. Is it harmful to enable that globally? The other changes need a proper ifdef, but should be ok I guess. -- Stefan > > -- > Stefan > >> _______________________________________________ >> U-Boot mailing list >> U-Boot at lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-18 18:37 ` Stefan Agner @ 2014-11-19 6:42 ` Albert ARIBAUD 2014-11-19 6:58 ` Wolfgang Denk 0 siblings, 1 reply; 27+ messages in thread From: Albert ARIBAUD @ 2014-11-19 6:42 UTC (permalink / raw) To: u-boot Hello Stefan, On Tue, 18 Nov 2014 19:37:18 +0100, Stefan Agner <stefan@agner.ch> wrote: > diff --git a/arch/arm/config.mk b/arch/arm/config.mk > index f0eafd6..ddbc8dc 100644 > --- a/arch/arm/config.mk > +++ b/arch/arm/config.mk > @@ -30,6 +30,8 @@ PF_CPPFLAGS_ARM := $(call cc-option, -mthumb > -mthumb-interwork,\ > $(call cc-option,-marm,)\ > $(call cc-option,-mno-thumb-interwork,)\ > ) > +AFLAGS_AUTOIT :=$(call > as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it) > +PF_CPPFLAGS_ARM += $(AFLAGS_AUTOIT) > else > PF_CPPFLAGS_ARM := $(call cc-option,-marm,) \ > $(call cc-option,-mno-thumb-interwork,) > The main change here is the implicit-it/auto-it functionality. For me it > works when enabling that globally. Is it harmful to enable that > globally? The other changes need a proper ifdef, but should be ok I > guess. -mimplicit-it=always will have no effect on ARM builds as it defaults to 'arm', meaning that IT instructions are already optional in ARM mode, and switching to 'always' changes the behavior only for Thumb mode. For -mauto-it, it is not documented in the gas documentation online or in my current as' --target-help. I'll dig this deeper today, but barring any scream from me, the change above is fine globally in U-Boot. > -- > Stefan Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-19 6:42 ` Albert ARIBAUD @ 2014-11-19 6:58 ` Wolfgang Denk 2014-11-19 16:31 ` Bill Pringlemeir 0 siblings, 1 reply; 27+ messages in thread From: Wolfgang Denk @ 2014-11-19 6:58 UTC (permalink / raw) To: u-boot Dear Albert, In message <20141119074214.3d414ce6@lilith> you wrote: > > For -mauto-it, it is not documented in the gas documentation online or > in my current as' --target-help. I'll dig this deeper today, but barring > any scream from me, the change above is fine globally in U-Boot. Apparently this [1] is where it is coming from; no further documentation there, though. [1] https://sourceware.org/ml/binutils/2009-05/msg00132.html Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "If people are good only because they fear punishment, and hope for reward, then we are a sorry lot indeed." - Albert Einstein ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-19 6:58 ` Wolfgang Denk @ 2014-11-19 16:31 ` Bill Pringlemeir 2014-11-19 17:48 ` Albert ARIBAUD 0 siblings, 1 reply; 27+ messages in thread From: Bill Pringlemeir @ 2014-11-19 16:31 UTC (permalink / raw) To: u-boot On 19 Nov 2014, wd at denx.de wrote: > Dear Albert, > > In message <20141119074214.3d414ce6@lilith> you wrote: >> >> For -mauto-it, it is not documented in the gas documentation online >> or in my current as' --target-help. I'll dig this deeper today, but >> barring any scream from me, the change above is fine globally in >> U-Boot. > Apparently this [1] is where it is coming from; no further > documentation there, though. > [1] https://sourceware.org/ml/binutils/2009-05/msg00132.html I would think that if this worked they would make it automatic and not an option. Probably this is only in certain binutils/as. With 4.6.3 and 4.9.1 I do not have this option, [foo.S] .syntax unified .thumb foo: cmp r0, #5 movne r1,#6 moveq r1,#2 bx lr bar: cmp r0, #10 movhi r1,#3 movls r1,#7 moveq r1,#11 bx lr $ arm-none-linux-gnueabi.gcc4.6.3/bin/arm-none-linux-gnueabi-as -mcpu=cortex-a5 -mimplicit-it=always foo.S -o foo.o $ arm-none-linux-gnueabi-vybrid-4.9.1/bin/arm-none-linux-gnueabi-as -mcpu=cortex-a5 -mimplicit-it=always foo.S -o foo.o Both give 'objdump -S foo.o', foo.o: file format elf32-littlearm Disassembly of section .text: 00000000 <foo>: 0: 2805 cmp r0, #5 2: bf14 ite ne 4: 2106 movne r1, #6 6: 2102 moveq r1, #2 8: 4770 bx lr 0000000a <bar>: a: 280a cmp r0, #10 c: bf8c ite hi e: 2103 movhi r1, #3 10: 2107 movls r1, #7 12: bf08 it eq 14: 210b moveq r1, #11 16: 4770 bx lr I think before the patch there would be 'it' values before each and every condition. In fact, if you change 'bar' to, bar: cmp r0, #10 movhi r1,#3 movlo r1,#7 moveq r1,#11 bx lr You get three 'IT' conditions as 'HI' and 'LO' are not opposite. The patch seem to detect things that are the exact opposite. The 'bar' above ends up with '11' in r1 if the value is zero, but it temporarily '7'. The 2nd bar will only place 11 in r1. Fwiw, Bill Pringlemeir. Ref: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Conditional_Execution ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-19 16:31 ` Bill Pringlemeir @ 2014-11-19 17:48 ` Albert ARIBAUD 2014-11-19 18:34 ` Bill Pringlemeir 0 siblings, 1 reply; 27+ messages in thread From: Albert ARIBAUD @ 2014-11-19 17:48 UTC (permalink / raw) To: u-boot Hello Bill, On Wed, 19 Nov 2014 11:31:05 -0500, Bill Pringlemeir <bpringlemeir@nbsps.com> wrote: > On 19 Nov 2014, wd at denx.de wrote: > > > Dear Albert, > > > > In message <20141119074214.3d414ce6@lilith> you wrote: > >> > >> For -mauto-it, it is not documented in the gas documentation online > >> or in my current as' --target-help. I'll dig this deeper today, but > >> barring any scream from me, the change above is fine globally in > >> U-Boot. > > > Apparently this [1] is where it is coming from; no further > > documentation there, though. > > > [1] https://sourceware.org/ml/binutils/2009-05/msg00132.html > > I would think that if this worked they would make it automatic and not > an option. Probably this is only in certain binutils/as. > > With 4.6.3 and 4.9.1 I do not have this option, Which option do you mean? -mimplicit-it or -mauto-it? > [foo.S] > .syntax unified > .thumb > foo: > cmp r0, #5 > movne r1,#6 > moveq r1,#2 > bx lr > bar: > cmp r0, #10 > movhi r1,#3 > movls r1,#7 > moveq r1,#11 > bx lr > > $ arm-none-linux-gnueabi.gcc4.6.3/bin/arm-none-linux-gnueabi-as > -mcpu=cortex-a5 -mimplicit-it=always foo.S -o foo.o > $ arm-none-linux-gnueabi-vybrid-4.9.1/bin/arm-none-linux-gnueabi-as > -mcpu=cortex-a5 -mimplicit-it=always foo.S -o foo.o > > Both give 'objdump -S foo.o', > foo.o: file format elf32-littlearm > > Disassembly of section .text: > > 00000000 <foo>: > 0: 2805 cmp r0, #5 > 2: bf14 ite ne > 4: 2106 movne r1, #6 > 6: 2102 moveq r1, #2 > 8: 4770 bx lr > > 0000000a <bar>: > a: 280a cmp r0, #10 > c: bf8c ite hi > e: 2103 movhi r1, #3 > 10: 2107 movls r1, #7 > 12: bf08 it eq > 14: 210b moveq r1, #11 > 16: 4770 bx lr > > I think before the patch there would be 'it' values before each and > every condition. In fact, if you change 'bar' to, > > bar: > cmp r0, #10 > movhi r1,#3 > movlo r1,#7 > moveq r1,#11 > bx lr > > You get three 'IT' conditions as 'HI' and 'LO' are not opposite. The > patch seem to detect things that are the exact opposite. The 'bar' > above ends up with '11' in r1 if the value is zero, but it temporarily > '7'. The 2nd bar will only place 11 in r1. > > Fwiw, > Bill Pringlemeir. > > Ref: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Conditional_Execution All this is about -mimplicit-it, which *is* documented, *is* consistently present in common toolchains AFAICT and is and (as) logcical (as it can be when dealing with backward compatibility of command lines etc). However, my problem is not with -mimplicit-it; it is with -mauto-it. My gut feeling is that -mauto-it is a predecessor of -mimplicit-it. Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-19 17:48 ` Albert ARIBAUD @ 2014-11-19 18:34 ` Bill Pringlemeir 2014-11-20 12:04 ` Albert ARIBAUD 0 siblings, 1 reply; 27+ messages in thread From: Bill Pringlemeir @ 2014-11-19 18:34 UTC (permalink / raw) To: u-boot >>> In message <20141119074214.3d414ce6@lilith> you^H^H^H Stefan wrote: >>>> For -mauto-it, it is not documented in the gas documentation online >>>> or in my current as' --target-help. I'll dig this deeper today, but >>>> barring any scream from me, the change above is fine globally in >>>> U-Boot. >> On 19 Nov 2014, wd at denx.de wrote: >>> Apparently this [1] is where it is coming from; no further >>> documentation there, though. >> >>> [1] https://sourceware.org/ml/binutils/2009-05/msg00132.html > On Wed, 19 Nov 2014 11:31:05 -0500, Bill Pringlemeir >> I would think that if this worked they would make it automatic and >> not an option. Probably this is only in certain binutils/as. >> >> With 4.6.3 and 4.9.1 I do not have this option, On 19 Nov 2014, albert.u.boot at aribaud.net wrote: > Which option do you mean? -mimplicit-it or -mauto-it? '-mauto-it' , which I think if it is working correctly would be rolled into '-mimplicit-it' as it generates better code (for an assembler :). I followed the thread above and the patch originator says he needs to fix section issues and the 'command line options' and he would follow up the proposed patch. I guess at some version each and every '<inst>xx' was converted to 'it xx\n<inst>' where <inst> is some conditional instruction. For the patch above, '-mauto-it' teaches the assembler to glob them together into 'itet...' type conditions. The Thumb2 supports up to four conditions (and negated condition) instructions. On my version of the tools (I think it is gcc; but maybe binutils), if I use '-mauto-it' it gives an unknown option error. I think that Linux does a probe of this feature and passes it (-mauto-it) if the assembler accepts it. So, if we add to u-boot we should probably take care that the ARM 'as' can take the option. I also see posts on the web of people complaining of this option in other code bases. Fwiw, Bill. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-19 18:34 ` Bill Pringlemeir @ 2014-11-20 12:04 ` Albert ARIBAUD 2014-11-20 16:34 ` Bill Pringlemeir 0 siblings, 1 reply; 27+ messages in thread From: Albert ARIBAUD @ 2014-11-20 12:04 UTC (permalink / raw) To: u-boot Hello Bill, On Wed, 19 Nov 2014 13:34:34 -0500, Bill Pringlemeir <bpringlemeir@nbsps.com> wrote: > > > >>> In message <20141119074214.3d414ce6@lilith> you^H^H^H Stefan wrote: > > >>>> For -mauto-it, it is not documented in the gas documentation online > >>>> or in my current as' --target-help. I'll dig this deeper today, but > >>>> barring any scream from me, the change above is fine globally in > >>>> U-Boot. > > >> On 19 Nov 2014, wd at denx.de wrote: > > >>> Apparently this [1] is where it is coming from; no further > >>> documentation there, though. > >> > >>> [1] https://sourceware.org/ml/binutils/2009-05/msg00132.html > > > On Wed, 19 Nov 2014 11:31:05 -0500, Bill Pringlemeir > > >> I would think that if this worked they would make it automatic and > >> not an option. Probably this is only in certain binutils/as. > >> > >> With 4.6.3 and 4.9.1 I do not have this option, > > > On 19 Nov 2014, albert.u.boot at aribaud.net wrote: > > > Which option do you mean? -mimplicit-it or -mauto-it? > > '-mauto-it' , which I think if it is working correctly would be rolled > into '-mimplicit-it' as it generates better code (for an assembler :). > I followed the thread above and the patch originator says he needs to > fix section issues and the 'command line options' and he would follow up > the proposed patch. I am getting lost, even when reading (quickly, I admit) the patch that adds it; I don't see what -mauto-it does exactly. Can you summarize and clarify the effects of -mimplicit-it (I guess I know this one but it's never a bad thing to get a second opinion), -mauto-it and their interaction? > I guess at some version each and every '<inst>xx' was converted to 'it > xx\n<inst>' where <inst> is some conditional instruction. For the patch > above, '-mauto-it' teaches the assembler to glob them together into > 'itet...' type conditions. The Thumb2 supports up to four conditions > (and negated condition) instructions. > > On my version of the tools (I think it is gcc; but maybe binutils), if I > use '-mauto-it' it gives an unknown option error. I think that Linux > does a probe of this feature and passes it (-mauto-it) if the assembler > accepts it. So, if we add to u-boot we should probably take care that > the ARM 'as' can take the option. I also see posts on the web of people > complaining of this option in other code bases. Are they complaining that the option is passed on to an as which does not know it, or that the option is known but does something wrong? (I'm still having a hard time understanding whether -mauto-it is an accepted new feature that is slow to get integrated or the remnant of an old proposal which did not make it.) > Fwiw, > Bill. Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-20 12:04 ` Albert ARIBAUD @ 2014-11-20 16:34 ` Bill Pringlemeir 2014-11-21 12:22 ` Albert ARIBAUD 0 siblings, 1 reply; 27+ messages in thread From: Bill Pringlemeir @ 2014-11-20 16:34 UTC (permalink / raw) To: u-boot > On Wed, 19 Nov 2014 13:34:34 -0500, Bill Pringlemeir > <bpringlemeir@nbsps.com> wrote: >>>>> In message <20141119074214.3d414ce6@lilith> Albert wrote: >>>>>> For -mauto-it, it is not documented in the gas documentation >>>>>> online or in my current as' --target-help. I'll dig this deeper >>>>>> today, but barring any scream from me, the change above is fine >>>>>> globally in U-Boot. >>>> On 19 Nov 2014, wd at denx.de wrote: >> >>>>> Apparently this [1] is where it is coming from; no further >>>>> documentation there, though. >>>> >>>>> [1] https://sourceware.org/ml/binutils/2009-05/msg00132.html >> >>> On Wed, 19 Nov 2014 11:31:05 -0500, Bill Pringlemeir >> >>>> I would think that if this worked they would make it automatic and >>>> not an option. Probably this is only in certain binutils/as. >>>> With 4.6.3 and 4.9.1 I do not have this option, >> On 19 Nov 2014, albert.u.boot at aribaud.net wrote: >>> Which option do you mean? -mimplicit-it or -mauto-it? >> '-mauto-it' , which I think if it is working correctly would be >> rolled into '-mimplicit-it' as it generates better code (for an >> assembler :). I followed the thread above and the patch originator >> says he needs to fix section issues and the 'command line options' >> and he would follow up the proposed patch. On 20 Nov 2014, albert.u.boot at aribaud.net wrote: > I am getting lost, even when reading (quickly, I admit) the patch that > adds it; I don't see what -mauto-it does exactly. Can you summarize > and clarify the effects of -mimplicit-it (I guess I know this one but > it's never a bad thing to get a second opinion), -mauto-it and their > interaction? I guess you know how the 'IT' works. The Ubuntu/Debian people give a good explanation in a few paragraphs, https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Conditional_Execution My trying to explain this may have confused thing... Here is Wolfgang's reference, https://sourceware.org/ml/binutils/2009-05/msg00132.html Here is a 2nd reference, https://sourceware.org/ml/binutils/2009-06/msg00162.html Originally Daniel Gutson used '-mauto-it' and then it was converted to '-mimplicit-it'. I am not sure if '-mauto-it' exists in the wild. I have never heard of that option before seeing this email thread. Also my assembler says, Assembler messages: Error: unrecognized option -mauto-it I have built with the most recent binutils, gcc4.9.1 using crosstool-ng. Maybe only some non-mainline tools picked up this '-mauto-it' patch. I don't think it hurts to support '-mauto-it', but an assembler test should be done to see if it accepts the option. hth, Bill Pringlemeir. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [U-Boot] Query on CONFIG_SYS_THUMB_BUILD 2014-11-20 16:34 ` Bill Pringlemeir @ 2014-11-21 12:22 ` Albert ARIBAUD 0 siblings, 0 replies; 27+ messages in thread From: Albert ARIBAUD @ 2014-11-21 12:22 UTC (permalink / raw) To: u-boot Hello Bill, On Thu, 20 Nov 2014 11:34:45 -0500, Bill Pringlemeir <bpringlemeir@nbsps.com> wrote: > Originally Daniel Gutson used '-mauto-it' and then it was converted to > '-mimplicit-it'. Ok, so I was right in my gut(son)[1] feeling that -mauto-it was a predecessor of -mimplicit-it -- and actually only in the first iteration(s) of the patch that would have introduced it. > I am not sure if '-mauto-it' exists in the wild. I have never heard of > that option before seeing this email thread. Also my assembler says, > > Assembler messages: > Error: unrecognized option -mauto-it > > I have built with the most recent binutils, gcc4.9.1 using crosstool-ng. > Maybe only some non-mainline tools picked up this '-mauto-it' patch. I > don't think it hurts to support '-mauto-it', but an assembler test > should be done to see if it accepts the option. I've gone through the binutils git tree, and -mauto-it is mentioned only in a patch that fixes the gas /docs/ which erroneously mentioned -mauto-it where it should have mentioned -mimplicit-it. Hence, I think we should not test for -mauto-it at all, and not mention it even. Stefan, can you resubmit without the -mauto-it part, and renaming AFLAGS_AUTOIT into AFLAGS_IMPLICIT_IT? > hth, > Bill Pringlemeir. Amicalement, -- Albert. [1] I am never ashamed of doing lame puns. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2014-11-21 12:22 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-13 16:29 [U-Boot] Query on CONFIG_SYS_THUMB_BUILD Victor Ascroft 2014-11-13 20:53 ` Wolfgang Denk 2014-11-14 4:30 ` Victor Ascroft 2014-11-14 5:43 ` Wolfgang Denk 2014-11-14 6:10 ` Victor Ascroft 2014-11-14 14:01 ` Simon Glass 2014-11-14 15:26 ` Albert ARIBAUD 2014-11-15 1:56 ` Simon Glass 2014-11-15 5:26 ` Victor Ascroft 2014-11-15 5:38 ` Victor Ascroft 2014-11-15 12:30 ` Albert ARIBAUD 2014-11-15 22:10 ` Simon Glass 2014-11-16 7:50 ` Albert ARIBAUD 2014-11-17 6:28 ` Simon Glass 2014-11-18 3:32 ` Victor Ascroft 2014-11-18 4:59 ` Simon Glass 2014-11-18 12:10 ` Stefan Agner 2014-11-18 16:07 ` Stefan Agner 2014-11-18 18:37 ` Stefan Agner 2014-11-19 6:42 ` Albert ARIBAUD 2014-11-19 6:58 ` Wolfgang Denk 2014-11-19 16:31 ` Bill Pringlemeir 2014-11-19 17:48 ` Albert ARIBAUD 2014-11-19 18:34 ` Bill Pringlemeir 2014-11-20 12:04 ` Albert ARIBAUD 2014-11-20 16:34 ` Bill Pringlemeir 2014-11-21 12:22 ` Albert ARIBAUD
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox