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