From: Martin Jansa <martin.jansa@gmail.com>
To: Arno Steffens <star@gmx.li>
Cc: Yocto Project <yocto@yoctoproject.org>
Subject: Re: cortexa9t2hf instead of cortexa9hf
Date: Tue, 18 Jun 2019 19:13:45 +0200 [thread overview]
Message-ID: <20190618171345.GB1501@jama> (raw)
In-Reply-To: <trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
[-- Attachment #1: Type: text/plain, Size: 5671 bytes --]
On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> Thanks for explaining this.
> I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects.
> And mixing this causes time to switch processor mode. So, as I am not an expert in this and can't decide what ist best on per function base and speed is of highest priority, I think I better should use not thumb(2).
>
> So, do I get it right that with this cortexa9t2hf I just have the option to compile it for thumb2? But without using a dedicated compiler option it generates same "standard" arm code and the difference is just to adapt all the Makefiles for this suffix.
>
> According to Martin I can get the previous setting by just set ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I lose other kinds of optimisation. (I am just a user not an expert in arm architecture).
I didn't say anything about changing the DEFAULTTUNE.
Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
(not "armv7a").
> On the other hand for those like me it is better go the standard way. Once I am sure compiler results will not become worse (see above) I go for the pain and renaming my toolchain/makefiles/stuff.
The results should be almost the same, maybe slightly better, depends on
the actual code as Khem mentioned.
But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
then you should probably spend the time on your tooling instead of
replacing one hardcoded value with another.
Cheers,
>
> Thanks for you taking the time.
> Arno
>
> > Hello Arno,
> >
> > Let me try to explain my point of view. Since here (my best guess) we
> > have some asynchronous bitbake code which went South upon introducing
> > T2 HW extension.
> >
> > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > media coprocessor) exists in both of them. In other words:
> > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> >
> > Point [2]:
> > > bitbake gives me in 2.5:
> > > TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > TARGET_FPU = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU = "hard"
> >
> > These two lines are the same: you are able to use 32b arm mode, 16bit
> > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > extension as well. The Cortex in both cases is A9.
> >
> > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > and I have no idea if this is done intentionally or not.
> >
> > Because of that I copied Alex and Ross to CC: into email, so they
> > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> >
> > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > should return "armv7" as TUNE FEATURE.
> >
> > Best Regards,
> > Zoran
> > _______
> >
> >
> > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star@gmx.li> wrote:
> > >
> > > Hello Zoran,
> > > thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> > > But I want to keep all compatible to my previous tool-chain and settings.
> > > The only file where I can found this "cortexa9t2hf" is
> > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> > > Or have I been wrong the time before?
> > >
> > > bitbake gives me in 2.5:
> > >
> > > TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > TARGET_FPU = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU = "hard"
> > >
> > > so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> > > Arno
> > >
> > > >
> > > > Hello Arno,
> > > >
> > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > try (as my best) to answer your question.
> > > >
> > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > >
> > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > question is what is T2? T2 is addition to the previous architecture
> > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > >
> > > > Hope this helps,
> > > >
> > > > Zoran
> > > > _______
> > > >
> > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star@gmx.li> wrote:
> > > > >
> > > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > > > Target system is a Zynq7020 system.
> > > > > --
> > > > > _______________________________________________
> > > > > yocto mailing list
> > > > > yocto@yoctoproject.org
> > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > >
> >
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
next prev parent reply other threads:[~2019-06-18 17:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 12:03 cortexa9t2hf instead of cortexa9hf Arno Steffens
2019-06-17 12:17 ` Zoran Stojsavljevic
2019-06-17 13:00 ` Arno Steffens
2019-06-17 14:05 ` Zoran Stojsavljevic
2019-06-17 17:47 ` Arno Steffens
2019-06-18 16:16 ` Khem Raj
2019-06-18 17:13 ` Martin Jansa [this message]
2019-06-18 18:47 ` Zoran Stojsavljevic
2019-06-18 19:03 ` Martin Jansa
2019-06-18 20:55 ` Zoran Stojsavljevic
2019-06-17 14:29 ` Martin Jansa
2019-06-17 17:33 ` Zoran Stojsavljevic
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=20190618171345.GB1501@jama \
--to=martin.jansa@gmail.com \
--cc=star@gmx.li \
--cc=yocto@yoctoproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.