Building your OS platform for multiple architectures with the Yocto ProjectAGL AMM Jan-Simon MöllerOct 2017 AGL Release Manager

Introduction, Topics

IntroductionDipl.-Ing. Jan-Simon Möller

jsmoeller@linuxfoundation.org

'DL9PF' on #freenode

AGL Release Manager, EG CIAT Lead

This talk is about:● Building your OS platform (e.g. Automotive Grade Linux)

– with the Yocto Project– for multiple architectures

● Intel, ● ARM32, ● ARM64/AARCH64

– for multiple boards– from the same codebase– … add yours...– ...and still stay sane

Why at all ?

Example: Automotive Grade Linux

Multiple boards ?● But hey, aren't they the same ARCH ?!

– x86-64● qemux86-64, intel-corei7-64

– ARM 32bit● porter, rpi3, dra7xx-evm, cyclone5, beaglebone, i.mx6

– ARM 64bit / AArch64● m3ulcb, dragonboard-410c

Save time by reusing artifacts !● Yocto builds can take a long time● We can save time by making

effective use of theShared-State-Cache

Save space by sharing artifacts● If we do builds as single silos,

we waste a lot of space● For each developer● On the servers● More $MB means more I/O and thus more time

Ideas ?

Why not group by ARCH ?● We would have 3 target builds then (one per ARCH)● Desktop distro's work that way already … wink, wink● good idea, but:

– Boards ship with a BSP– BSP's today ship with preselections

● some should actually be left-out for the DISTRO to decide (instead of the BSP)

● one of these is the default COMPILER TUNE_FLAGS ● another one is the IMAGE_FSTYPE to output

ARM 32bit default compiler flags● dra7xx-evm:

– TUNE_FEATURES="arm armv7a vfp thumb neon callconvention-hard"

– TUNE_CCARGS=" -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard"

● porter

– TUNE_FEATURES="arm armv7ve vfp neon callconvention-hard cortexa15"

– TUNE_CCARGS=" -march=armv7ve -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a15"

● raspberrypi3:

– TUNE_FEATURES="arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7"

– TUNE_CCARGS=" -march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7"

ARM 64bit default compiler flags● dragonboard-410C:

– DEFAULTTUNE="aarch64"

– TUNE_FEATURES="aarch64"

– TUNE_CCARGS="" # should probably be -march=armv8-a, but implied through compiler default● m3ulcb

– DEFAULTTUNE="cortexa57-cortexa53"

– TUNE_FEATURES="aarch64 cortexa57-cortexa53"

– TUNE_CCARGS=" -march=armv8-a -mtune=cortex-a57.cortex-a53" # big.LITTLE● rpi3-64 )* :

– DEFAULTTUNE="aarch64"

– TUNE_FEATURES="aarch64"

– TUNE_CCARGS=""

x86-64 default compiler flags● qemux86-64:

– DEFAULTTUNE="core2-64"

– TUNE_FEATURES="m64 core2"

– TUNE_CCARGS=" -m64 -march=core2 -mtune=core2 -mfpmath=sse -msse3"● intel-corei7-64:

– DEFAULTTUNE="corei7-64"

– TUNE_FEATURES="m64 corei7"

– TUNE_CCARGS=" -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2"

Is it possible to ...● group boards by arch ?

– NO. Each board sets different flags● save time by reusing artifacts ?

– NO. Different flags mean different artifacts● share artifacts across boards ?

– No. Different flags mean different artifacts

What can we do ?

Use DEFAULTTUNE for each ARCH● ARM32

– high profile:● DEFAULTTUNE_arm="armv7vethf-neon-vfpv4"● TUNE_FEATURES="arm armv7ve vfp thumb neon vfpv4 callconvention-hard"● Resulting in:● TUNE_CCARGS=" -march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard"

– requires at least a cortex-a15 -class CPU (VirtualizationExtensions)– Is basically equal to what ARMv8-a supports in 32bit mode (AARCH32)

Use DEFAULTTUNE for each ARCH● ARM32

– medium profile:● DEFAULTTUNE="armv7athf-neon" # vfpv1/2/3 implied for armv7-a with neon● TUNE_FEATURES="arm armv7a vfp neon callconvention-hard"● TUNE_CCARGS=" -march=armv7-a -mfpu=neon -mfloat-abi=hard"

– This requires at least a cortex-a8 -class CPU– It does *not enable* the virtualization extensions and does *not* use vfpv4– It is *very compatible* in terms of broad CPU support for ARM 32bit.

Use DEFAULTTUNE for each ARCH● AArch64:

– DEFAULTTUNE="aarch64"– TUNE_FEATURES="aarch64"– TUNE_CCARGS="-march=armv8-a"

– no default -mtune

Use DEFAULTTUNE for each ARCH● x86-64:

– DEFAULTTUNE="corei7-64"– TUNE_FEATURES="m64 corei7"– TUNE_CCARGS=" -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2"

– INCLUDING qemux86-64 and bump – QEMU_EXTRAOPTIONS_corei7-64 = " -cpu Nehalem,check=false"

Outcome:● 4 default compilation targets with common flags● we can share most packages● build times reduced● reuse of artifacts maximised

What else is to do ?

Issues● The cflags are just one example:

– BSP patches to core components Yikes ! Boo !● kernel recipe + own linux-libc-headers● wayland/weston● gstreamer● own/separate u-boot

– For maximum reuse, we need to maximise the # of shared components

Next steps ?

Profiles and package feeds● A 'core' profile will contain all components that make up a bootable

image – including security framework and automotive components

● On-top of this 'core' there can be other profiles that reuse the binary artifacts and only ship the new components:– telematics– demo-ui (+wayland-weston)

● demo-ui-html5 (+webengine)● demo-ui-qt5 (+qt5)● demu-ui-gtk (+gtk)

Profiles and package feeds● Package feeds represent these profiles and allow

– boards to boot the minimal 'core' and select/install a profile– the SDK can reuse the rpm feed to install the dependencies

● likely Q1 / 18

Questions ?