From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] Query on CONFIG_SYS_THUMB_BUILD
Date: Sun, 16 Nov 2014 08:50:41 +0100 [thread overview]
Message-ID: <20141116085041.57855d91@lilith> (raw)
In-Reply-To: <CAPnjgZ2QXjCydu0G+MqkZg0r7FYNpkG034v-D93Yg08iXr7dsQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2014-11-16 7:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141116085041.57855d91@lilith \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox