ARM CPU version question

ARM CPU version question

[Steve Pavao]

What’s the recommended way to be able to propogate target-specific compile-time CPU tune information to affect the build of a source file in my own custom layer?

For example, if I’m building for an arm6-based target, I’d like to be able to have the __ARM_ARCH_6__ symbol be available when the Yocto system builds my custom layer.  The BSP for such a target obviously defines this symbol when building its files for such a target.  Is there an easy way to propagate this information to my own custom layer, to affect my own sources?  Maybe my recipe needs to include certain conf files from other layers such as meta or the BSP layer?

Currently, I notice that architecture-level symbols are available to my custom layer at compile time, such as __aarch64_ and __arm__, but not CPU tune information, such as __ARM_ARCH_6__.

- Steve Pavao
Korg R&D

Re: ARM CPU version question

[Andre McCurdy]

On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao <stevep@korgrd.com> wrote:
> What’s the recommended way to be able to propogate target-specific compile-time CPU tune information to affect the build of a source file in my own custom layer?
>
> For example, if I’m building for an arm6-based target, I’d like to be able to have the __ARM_ARCH_6__ symbol be available when the Yocto system builds my custom layer.  The BSP for such a target obviously defines this symbol when building its files for such a target.  Is there an easy way to propagate this information to my own custom layer, to affect my own sources?  Maybe my recipe needs to include certain conf files from other layers such as meta or the BSP layer?

This kind of macro is typically defined internally by gcc, depending
on the -mcpu etc options passed on the gcc command line, ie options
which are included in the ${CC} definition setup by OE.

Therefore all you normally need to do is ensure that the Makefiles etc
for the components in your custom layer all correctly respect OE's
definition of ${CC}.

A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
"$(CROSS_COMPILE)gcc") and lose the original value passed via the
environment.

> Currently, I notice that architecture-level symbols are available to my custom layer at compile time, such as __aarch64_ and __arm__, but not CPU tune information, such as __ARM_ARCH_6__.

The exact set of macros defined by gcc will vary depending on exactly
which ARMv6 CPU you are targeting (and to some extent, which version
of gcc you are using). If you have code which needs to be enabled for
any ARMv6 target then you may have to test multiple macros. For
example see the way in which openssl defines __ARM_ARCH__

  https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h

> - Steve Pavao
> Korg R&D
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: ARM CPU version question

[Steve Pavao]

[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]

Hi Andre,

> On Mar 19, 2018, at 5:32 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> 
> On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao <stevep@korgrd.com> wrote:
>> What’s the recommended way to be able to propogate target-specific compile-time CPU tune information to affect the build of a source file in my own custom layer?
>> 
>> For example, if I’m building for an arm6-based target, I’d like to be able to have the __ARM_ARCH_6__ symbol be available when the Yocto system builds my custom layer.  The BSP for such a target obviously defines this symbol when building its files for such a target.  Is there an easy way to propagate this information to my own custom layer, to affect my own sources?  Maybe my recipe needs to include certain conf files from other layers such as meta or the BSP layer?
> 
> This kind of macro is typically defined internally by gcc, depending
> on the -mcpu etc options passed on the gcc command line, ie options
> which are included in the ${CC} definition setup by OE.
> 
> Therefore all you normally need to do is ensure that the Makefiles etc
> for the components in your custom layer all correctly respect OE's
> definition of ${CC}.
> 
> A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
> "$(CROSS_COMPILE)gcc") and lose the original value passed via the
> environment.
> 
>> Currently, I notice that architecture-level symbols are available to my custom layer at compile time, such as __aarch64_ and __arm__, but not CPU tune information, such as __ARM_ARCH_6__.
> 
> The exact set of macros defined by gcc will vary depending on exactly
> which ARMv6 CPU you are targeting (and to some extent, which version
> of gcc you are using). If you have code which needs to be enabled for
> any ARMv6 target then you may have to test multiple macros. For
> example see the way in which openssl defines __ARM_ARCH__
> 
>  https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h <https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h>

Thank you very much for your insight, Andre !

I think I may have discovered a specific situation which is causing the problem to occur for me.  It seems it occurs because I am trying to build a kernel module under the recipes-kernel directory in my custom layer.   A colleague pointed out to me that meta/classes/module.bbclass explicitly unsets CFLAGS and a bunch of other macros in this situation.

Maybe I need to put in some custom shell syntax in my recipe, to export __ARM_ARCH_6__ or to directly define the compiler macro when needed, based on the value of the TARGET variable.  I wonder if there is a better recommended solution than this, though.

BTW, my kernel module contains conditionally-compiled code for initializing the ARM PMU correctly for each CPU case.

- Steve




[-- Attachment #2: Type: text/html, Size: 3962 bytes --]

Re: ARM CPU version question

[Khem Raj]

On 3/19/18 4:35 PM, Steve Pavao wrote:
> Hi Andre,
> 
>> On Mar 19, 2018, at 5:32 PM, Andre McCurdy <armccurdy@gmail.com 
>> <mailto:armccurdy@gmail.com>> wrote:
>>
>> On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao <stevep@korgrd.com 
>> <mailto:stevep@korgrd.com>> wrote:
>>> What’s the recommended way to be able to propogate target-specific 
>>> compile-time CPU tune information to affect the build of a source 
>>> file in my own custom layer?
>>>
>>> For example, if I’m building for an arm6-based target, I’d like to be 
>>> able to have the __ARM_ARCH_6__ symbol be available when the Yocto 
>>> system builds my custom layer.  The BSP for such a target obviously 
>>> defines this symbol when building its files for such a target.  Is 
>>> there an easy way to propagate this information to my own custom 
>>> layer, to affect my own sources?  Maybe my recipe needs to include 
>>> certain conf files from other layers such as meta or the BSP layer?
>>
>> This kind of macro is typically defined internally by gcc, depending
>> on the -mcpu etc options passed on the gcc command line, ie options
>> which are included in the ${CC} definition setup by OE.
>>
>> Therefore all you normally need to do is ensure that the Makefiles etc
>> for the components in your custom layer all correctly respect OE's
>> definition of ${CC}.
>>
>> A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
>> "$(CROSS_COMPILE)gcc") and lose the original value passed via the
>> environment.
>>
>>> Currently, I notice that architecture-level symbols are available to 
>>> my custom layer at compile time, such as __aarch64_ and __arm__, but 
>>> not CPU tune information, such as __ARM_ARCH_6__.
>>
>> The exact set of macros defined by gcc will vary depending on exactly
>> which ARMv6 CPU you are targeting (and to some extent, which version
>> of gcc you are using). If you have code which needs to be enabled for
>> any ARMv6 target then you may have to test multiple macros. For
>> example see the way in which openssl defines __ARM_ARCH__
>>
>> https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h
> 
> Thank you very much for your insight, Andre !
> 
> I think I may have discovered a specific situation which is causing the 
> problem to occur for me.  It seems it occurs because I am trying to 
> build a kernel module under the recipes-kernel directory in my custom 
> layer.   A colleague pointed out to me 
> that meta/classes/module.bbclass explicitly unsets CFLAGS and a bunch of 
> other macros in this situation.
> 

it wasn't clear if you were compiling external kmods. Now that sets it 
straight.

> Maybe I need to put in some custom shell syntax in my recipe, to export 
> __ARM_ARCH_6__ or to directly define the compiler macro when needed, 
> based on the value of the TARGET variable.  I wonder if there is a 
> better recommended solution than this, though.

kernel modules are built using kernel flags for best results, thats why 
you see that we do not enforce general cflags since they may be 
enforcing userspace ABI options into kernel, which is not right. Further 
more kernel build system constructs its own compiler commandline from 
kbuild.

You could add something like CONFIG_CPU_32v6K=y or CONFIG_CPU_32v6=y
to your kernel .config and that should provide you with right flags 
during your kernel module compilation step.
> 
> BTW, my kernel module contains conditionally-compiled code for 
> initializing the ARM PMU correctly for each CPU case.
> 
> - Steve
> 
> 
> 
> 

Re: ARM CPU version question

[Andre McCurdy]

On Mon, Mar 19, 2018 at 4:35 PM, Steve Pavao <stevep@korgrd.com> wrote:
>
> I think I may have discovered a specific situation which is causing the
> problem to occur for me.  It seems it occurs because I am trying to build a
> kernel module under the recipes-kernel directory in my custom layer.   A
> colleague pointed out to me that meta/classes/module.bbclass explicitly
> unsets CFLAGS and a bunch of other macros in this situation.

OK, but note that the kernel (and kernel modules) are quite different
to user space in the way that CFLAGS and -mcpu etc are setup. For code
which runs in user space, these options are set by the OE build
environment, based on the machine config. For code which runs in
kernel space, these options come from the kernel build system, based
on the kernel config.

ie it's quite correct for module.bbclass to unset CFLAGS etc - it
prevents OE's flags for user space contaminating or conflicting with
the flags set by the kernel build system.

> Maybe I need to put in some custom shell syntax in my recipe, to export
> __ARM_ARCH_6__ or to directly define the compiler macro when needed, based
> on the value of the TARGET variable.  I wonder if there is a better
> recommended solution than this, though.

__ARM_ARCH_6__ is one of the macros normally set internally by gcc, so
you shouldn't be trying to set it manually.

Instead, you should probably either:

1) Update your code to test for defined(__ARM_ARCH_6__) ||
defined(__ARM_ARCH_6K__), since according to:

  https://github.com/torvalds/linux/blob/master/arch/arm/Makefile#L65

the kernel will either pass -march=armv6 or -march=armv6k for ARMv6
targets (depending on whether or not your kernel config enables
CONFIG_CPU_32v6K).

2) Update your code to test the generic ARMv6 macro set by the kernel
build system, ie (__LINUX_ARM_ARCH__ == 6), which should catch all
ARMv6 targets.


> BTW, my kernel module contains conditionally-compiled code for initializing
> the ARM PMU correctly for each CPU case.
>