<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#943634;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="SV" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US">Yes, that definitely looks wrong. Fortunately for us, we are only using SoCs based on Cortex A53 so far so it is not something that has affected us (yet)…<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US">Oh, and for some more messy fun, take a look at tune-cortexa32.inc. Cortex A32 uses ARMv8 but only supports aarch32. However, the tune file says to use aarch64, which makes
me believe that no one is actually using that tune file… I gave up trying to correct is as it is not currently possible to configure a tune to use ARMv8 without aarch64 and I don’t know if it is worth the effort until someone actually has a SoC based on Cortex
A32 they want to build for.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US">//Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Martin Jansa <martin.jansa@gmail.com>
<br>
<b>Sent:</b> den 17 april 2019 10:33<br>
<b>To:</b> Andre McCurdy <armccurdy@gmail.com><br>
<b>Cc:</b> Adrian Bunk <bunk@stusta.de>; Peter Kjellerstedt <peter.kjellerstedt@axis.com>; OE Core mailing list <openembedded-core@lists.openembedded.org><br>
<b>Subject:</b> Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">It's not caused by this change (not the previous one I believe), but today I've noticed that aarch64 tunes don't set TUNE_PKGARCH correctly.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">e.g. with raspberrypi3-64 which since this commit:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://github.com/agherzan/meta-raspberrypi/commit/9cc89cb7341d633b6fc3a92b937b5560d26257a1">https://github.com/agherzan/meta-raspberrypi/commit/9cc89cb7341d633b6fc3a92b937b5560d26257a1</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">uses conf/machine/include/tune-cortexa53.inc I was expecting it to use cortexa53 specific TUNE_PKGARCH (and stop messing with other MACHINEs which are using aarch64 package feed).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There is indeed:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">DEFAULTTUNE="cortexa53"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and mcpu=cortex-a53+crc in CC:<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">export CC="aarch64-webos-linux-gcc -mcpu=cortex-a53+crc --sysroot=/OE/build/luneos-warrior/webos-ports/tmp-glibc/work/aarch64-webos-linux/zlib/1.2.11-r0/recipe-sysroot"<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ARMPKGARCH="cortexa53"<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"># $TUNE_PKGARCH_32<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:29<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">TUNE_PKGARCH_32="cortexa53"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">#<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># $TUNE_PKGARCH_64<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:23<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># "aarch64${ARMPKGSFX_ENDIAN_64}"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">TUNE_PKGARCH_64="aarch64"<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"># "<a href="mailto:$%7b@bb.utils.contains('TUNE_FEATURES',%20'aarch64',%20'$%7bTUNE_PKGARCH_64%7d',%20'$%7bTUNE_PKGARCH_32%7d'%20,d)%7d">${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}</a>"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">TUNE_PKGARCH="aarch64"<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">so the packages built with -mcpu=cortex-a53+crc (and rpi overrides) end in the same TUNE_PKGARCH as other MACHINEs which include e.g.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">conf/machine/include/arm/arch-arm64.inc and DEFAULTTUNE="aarch64" which surprisingly uses aarch64 in both TUNE_PKGARCH_32/64:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"># "<a href="mailto:$%7b@bb.utils.contains('TUNE_FEATURES',%20'aarch64',%20'$%7bTUNE_PKGARCH_64%7d',%20'$%7bTUNE_PKGARCH_32%7d'%20,d)%7d">${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}</a>"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">TUNE_PKGARCH="aarch64"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">#<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># $TUNE_PKGARCH_32<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:29<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">TUNE_PKGARCH_32="aarch64"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">#<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># $TUNE_PKGARCH_64<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># set /OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:23<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"># "aarch64${ARMPKGSFX_ENDIAN_64}"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">TUNE_PKGARCH_64="aarch64"<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Looks like aarch64 are even bigger mess than arm tunes already :/.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Apr 3, 2019 at 10:48 PM Andre McCurdy <<a href="mailto:armccurdy@gmail.com">armccurdy@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">On Wed, Apr 3, 2019 at 1:24 PM Adrian Bunk <<a href="mailto:bunk@stusta.de" target="_blank">bunk@stusta.de</a>> wrote:<br>
> On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote:<br>
> > On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk <<a href="mailto:bunk@stusta.de" target="_blank">bunk@stusta.de</a>> wrote:<br>
> > > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote:<br>
> > > >...<br>
> > > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t"<br>
> > > > which is the convention used throughout all the tune files.<br>
> > > >...<br>
> > ><br>
> > > Unfortunately this is not true.<br>
> > ><br>
> > > OE has both armv7a and armv7at tunes.<br>
> > ><br>
> > > There is no armv7a without Thumb support,<br>
> > > so no -march=armv7-at exists in gcc.<br>
> > ><br>
> > > Both armv7a and armv7at tunes pass the same march to gcc,<br>
> > > but [1] is not true:<br>
> > > Default to using the Thumb-2 instruction set for armv7a and above.<br>
> > ><br>
> > > The hardware supports Thumb-2 in any case, the actual difference between<br>
> > > the armv7a and armv7at OE tunes is whether OE tells the compiler to<br>
> > > generate ARM or Thumb-2 code.<br>
> > ><br>
> > > OE has both armv6 and armv6t tunes.<br>
> > ><br>
> > > There is no armv6 without Thumb support<br>
> > > so no -march=armv6t exists in gcc.<br>
> > ><br>
> > > Some v6 support only Thumb-1 and some v6 support also Thumb-2,<br>
> > > so what gcc does have is an -march=armv6t2.<br>
> > > But OE lacks tunes for that.<br>
> > ><br>
> > > For matching the gcc options it would be correct to remove all<br>
> > > armv6t and armv7at tunes that have no coresponding gcc options,<br>
> > > and add armv6t2 tunes.<br>
> ><br>
> > Aligning the tuning options exposed via the machine config files to<br>
> > those supported by gcc seems like a worthy goal... but would be a big<br>
> > upheaval at this point.<br>
> ><br>
> > Note that the problem isn't specific to ARM. There are similar issues<br>
> > for x86, but there we seem happy to provide a very minimal abstraction<br>
> > with no attempt to track gcc. e.g. "corei7" hasn't been a documented<br>
> > -march option since gcc 4.8 and we (somewhat arbitrarily) map it to<br>
> > -march=nehalem to hide that fact from end users.<br>
> ><br>
> > So the high level question seems to be: should DEFAULTTUNE even<br>
> > attempt to provide a full featured mapping to the options provided by<br>
> > gcc? Are we happy to expose a limited subset without a 1:1 mapping for<br>
> > the options we do expose (current ARM approach) or is it better for<br>
> > DEFAULTTUNE to hide away all the complexity of the options provided by<br>
> > gcc (current x86 approach).<br>
><br>
> The current 32bit ARM[1] approach seems to be an attempt<br>
> of a 1:1 mapping.<br>
><br>
> For ARMv8 it is already obvious that DEFAULTTUNE is not long-term<br>
> maintainable, and duplicating all the gcc rules regarding feature<br>
> flags[2] also sounds like a pointless exercise.<br>
><br>
> What are actually the benefits of DEFAULTTUNE with all the tune files,<br>
> compared to just let the user provide a string that is passed to -march?<br>
<br>
Restricting the user to a certain set of DEFAULTTUNE options means<br>
there will always be a valid mapping from DEFAULTTUNE to<br>
PACKAGE_EXTRA_ARCHS.<br>
<br>
If we let the user pass an arbitrary string to -march then we lose the<br>
ability to determine that (for example) it's safe for a<br>
"armv7athf-vfpv3" machine to pull from a "armv7athf-vfpv3d16" package<br>
feed.<br>
<br>
Whether or not anyone in the real world actually maintains a generic<br>
package feed and pulls from it from multiple machine specific builds<br>
(verses setting up separate package feeds for each DEFAULTTUNE they<br>
care about) would be an interesting question...<br>
<br>
> cu<br>
> Adrian<br>
><br>
> [1] ARM <= v7, not the differing 32bit ABI of ARMv8<br>
> [2] example:<br>
> 'fp16fml'<br>
> Enable FP16 fmla extension. This also enables FP16 extensions and<br>
> floating-point instructions. This option is enabled by default for<br>
> '-march=armv8.4-a'. Use of this option with architectures prior to<br>
> Armv8.2-A is not supported.<br>
><br>
><br>
> --<br>
><br>
> "Is there not promise of rain?" Ling Tan asked suddenly out<br>
> of the darkness. There had been need of rain for many days.<br>
> "Only a promise," Lao Er said.<br>
> Pearl S. Buck - Dragon Seed<br>
><br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>