From mboxrd@z Thu Jan 1 00:00:00 1970 From: Victor Ascroft Date: Tue, 18 Nov 2014 09:02:46 +0530 Subject: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD In-Reply-To: References: <5464DC59.2040707@gmail.com> <20141114162643.53b09a8f@lilith> <20141115133033.0ccbc688@lilith> <20141116085041.57855d91@lilith> Message-ID: <546ABDDE.3090702@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 Monday 17 November 2014 11:58 AM, Simon Glass wrote: > Hi Albert, > > On 16 November 2014 07:50, Albert ARIBAUD wrote: >> Hello Simon, >> >> On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass >> wrote: >>> Hi Albert, >>> >>> On 15 November 2014 05:30, Albert ARIBAUD wrote: >>>> Hello Simon, >>>> >>>> On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass >>>> 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