[U-Boot] Query on CONFIG_SYS_THUMB_BUILD

[Simon Glass]

Hi Victor,

On 18 November 2014 03:32, Victor Ascroft <victorascroft at 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 at aribaud.net> wrote:
>>> Hello Simon,
>>>
>>> On Sat, 15 Nov 2014 15:10:47 -0700, Simon Glass <sjg at chromium.org>
>>> wrote:
>>>> Hi Albert,
>>>>
>>>> On 15 November 2014 05:30, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
>>>>> Hello Simon,
>>>>>
>>>>> On Fri, 14 Nov 2014 18:56:07 -0700, Simon Glass <sjg at 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