> bitbake is still just a parser of the metadata and executor of our
> tasks, it doesn't (and shouldn't) need to know anything about arm silicons.
You precisely formulated my latest thoughts in one sentence. :-)
Cheers,
Zoran
___
On Tue, Jun 18, 2019 at 9:03 PM Martin Jansa wrote:
>
> On Tu
On Tue, Jun 18, 2019 at 08:47:32PM +0200, Zoran Stojsavljevic wrote:
> > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > (not "armv7a").
>
> I think this is impossible for the current state of YOCTO affairs. I
> do not think bitbake is able to determine type of arm sil
> Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> (not "armv7a").
I think this is impossible for the current state of YOCTO affairs. I
do not think bitbake is able to determine type of arm silicon, since
it needs to implement the following instruction somewhere beneath (
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 c
On Mon, Jun 17, 2019 at 10:48 AM 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 cau
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 process
> 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).
Sorry, my bad. A15 still belongs to armv7. And now I see/understand
why you removed "ar
See this oe-core commit (from 2.6 Thud):
commit c88304a78e528596ca481cabe273749c286c352a
Author: Andre McCurdy
Date: Fri May 18 15:50:40 2018 -0700
arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above
which enabled Thumb2 by default, if you want to disable it as it was
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 (N
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 ca
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
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
yo
12 matches
Mail list logo
