Hi Albert, On 16 November 2014 07:50, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hello Simon, > > On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass <s...@chromium.org> > wrote: >> Hi Albert, >> >> On 15 November 2014 05:30, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: >> > Hello Simon, >> > >> > On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
