[OE-core] arm tune files status summary

[Khem Raj]

On 07/29/2011 06:28 AM, Phil Blundell wrote:
> There are quite a lot of different sub-threads going on at the moment
> regarding the various breakages associated with the recent arm tuning
> file patch.  Here's a summary of what I think are all the current issues
> and their status.
>
> 1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf causing
> rootfs construction to fail.
>
> Paul and Koen both posted (essentially identical) patches for this and
> it looks as though Paul's has been applied.  So, the original breakage
> should be resolved but it isn't entirely clear what this line in
> bitbake.conf was trying to accomplish in the first place.  I think
> someone still needs to conduct an audit to establish whether there are
> any circumstances where PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} does
> need setting to ${TARGET_ARCH} and, if so, make that happen.
>
> 2. endianness confusion in armv5/armv6 tune files.
>
> I posted a patch for this.  It doesn't look like it's been applied yet
> but it's in the archives for anybody who wants it.  Only big-endian
> configs would be affected anyway and I think those are something of a
> fringe pursuit.

I am testing this patch

>
> 3. eglibc unbuildable on qemuarm
>
> This is happening because qemuarm selects arm926ejs tuning, which in
> turn selects armv5te, and the current arrangement of tune files forces
> Thumb-state on if you ask to tune for a T-variant architecture.  The old
> "ARM_INSTRUCTION_SET" variable which used to override the ISA selection
> seems not to be respected anymore.  This is unfortunate because there is
> assembler code in eglibc which isn't Thumb-1 aware and hence can't be
> built under -mthumb.
>
> A short-term workaround would be to hack tune-arm926ejs.inc to select
> the TUNE_FEATURES for armv5e rather than armv5te.  But this is clearly
> not a good solution in general and, other than changing the underlying
> policy of inferring ISA choice from architecture name, it's not obvious
> what the right way of solving it is.
>
> This particular issue causes sufficiently gross breakage that I would
> have expected it to show up on the Yocto autobuilder run before the
> patch was merged.  I'm not quite sure why it apparently didn't fail
> there but maybe the autobuilder doesn't actually test qemuarm at
> present.

I have posted a patch for this

>
> 4. can't build ARM-state code for ARMv4T architecture.
>
> This is another facet of the above; there is currently no way to say
> that you want to select -march=armv4t without also enabling -mthumb.
> This makes it impossible to build interworking-capable ARM-state code
> for v4T.

yeah this is kind of fundamental problem. We need to differentiate 
between having thumb feature and really using it.
>
> 5. cortex tuning not working
>
> Various of the cortex files had a spelling mistake which would cause the
> TUNE_FEATURES never to actually match anything.  This is a trivial fix
> and I sent a patch for it yesterday.  I don't think it's been merged
> yet.

I am testing this patch

>
> 6. distros no longer able to select ARM vs Thumb state either globally
> or per package

My thinking is that default should always be ARM mode and then distros
can say TUNE_FEATURES += "usethumb" then tune infra can check for both
i.e. having thumb in machines and distros asking for it before adding
-mthumb to CCARGS
>
> This is really another manifestation of the issue in #3.  But the point
> here isn't so much that builds are failing, rather that we seem to have
> lost the ability to have a single switch that the DISTRO can flip to
> build the entire world (or individual packages) as Thumb rather than
> ARM.  For Thumb-1 in particular the tradeoffs are sufficiently
> complicated that I don't think there is ever going to be a globally
> "right" answer.
>
> I think that's all I know of.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core