public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 1/2] armv7: enable Thumb build for armv7
Date: Wed, 16 Mar 2011 14:09:59 +0530	[thread overview]
Message-ID: <4D80775F.4000907@ti.com> (raw)
In-Reply-To: <20110315115447.GE3819@bee.dooz.org>

On Tuesday 15 March 2011 05:24 PM, Lo?c Minier wrote:
> On Tue, Mar 15, 2011, Aneesh V wrote:
>> Please note that I am enabling armv7-a in the second patch in omap4
>> config.mk file. The reason I didn't do this here was some ARMv7 SoCs do
>> not want to use -march=armv7-a even if the compiler supports it. Tegra2
>> is an example. Please see the below from Tegra2 config.mk:
>>
>> # Use ARMv4 for Tegra2 - initial code runs on the AVP, which is an ARM7TDI.
>> PLATFORM_CPPFLAGS += -march=armv4
>
>   Good point, I wonder whether it would make sense to have
>   arch/arm/cpu/armv7/config.mk default to -march=armv7 and Tegra2 to

Sounds reasonable. I will do that.

>   override this with -march=armv4.  Maybe this code doesn't belong under
>   armv7 though; or perhaps -march=armv4 should only be set when building
>   a subset of the files rather than by default.

I don't understand it either. Maybe, the early boot code runs on one
processor and the rest run on another processor all in the same SoC.

>> This being the case I would have had to define another CONFIG flag if I
>> had to add -march=armv7-a in arch/arm/cpu/armv7/config.mk. I thought it
>> un-necessary and instead put it in the SoC specific file. So, Tegra2
>> can continue to use -march=armv4 and will get Thumb-1 if they enable
>> CONFIG_SYS_THUMB_BUILD. Or do you think we should define something like
>> CONFIG_SYS_MARCH_ARMV7
>
>   Up to you, but I would expect that code udner arch/arm/cpu/armv7/ would
>   build with -march=armv7 (maybe not -a though), with specific overrides

I tried -march=armv7 yesterday. I am getting several errors from the
assembly files. Particularly, it doesn't support high registers, spsr
etc. Looks like it defaults to the armv7-m variant(just my guess)

>   where that's not the case; it would feel a bit odd to me to have this
>   as a "config" option.

Yes, me too didn't like having a CONFIG option for this. But that
doesn't seem to be needed either as it can be over-ridden in the SoC
directory.

Albert,
Your thoughts on this?

best regards,
Aneesh

  reply	other threads:[~2011-03-16  8:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-14 13:27 [U-Boot] [RFC PATCH 1/2] armv7: enable Thumb build for armv7 Aneesh V
2011-03-14 13:27 ` [U-Boot] [RFC PATCH 2/2] OMAP4: enable Thumb2 support for OMAP4 Aneesh V
2011-03-14 16:11 ` [U-Boot] [RFC PATCH 1/2] armv7: enable Thumb build for armv7 Loïc Minier
2011-03-15  4:01   ` Aneesh V
2011-03-15 11:54     ` Loïc Minier
2011-03-16  8:39       ` Aneesh V [this message]
2011-03-16 17:25         ` Albert ARIBAUD
2011-03-17  7:30           ` Aneesh V
2011-03-24 14:45             ` 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=4D80775F.4000907@ti.com \
    --to=aneesh@ti.com \
    --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