Building your OS platform for multiple architectures with...
Transcript of Building your OS platform for multiple architectures with...
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
'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 ?