[yocto] 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 at gmail.com 
>> <mailto:armccurdy at gmail.com>> wrote:
>>
>> On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao <stevep at korgrd.com 
>> <mailto:stevep at 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
> 
> 
> 
>