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
next prev parent 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