Adoption of AGL as the embedded OS of choice for running IVI, instrumentation and telematics software by automotive manufacturers is accelerating. Several 2018 model year cars from Toyota have systems based on the AGL core and the number of manufacturers using AGL base in their cars is growing, with Hyundai and Mercedes Benz next on the list to ship models running AGL based software. Through the end of January 2019, over 7,000,000 vehicles have shipped running software based on AGL. To ensure system and application stability, manufacturers usually develop on and run an AGL code base that will be one or two releases behind the most current AGL release available.
Making Cars Faster
Why is AGL so important? Software engineering and development teams are able to leverage AGL’s common code, which provides around 70% of the structural code for IVI, telematics and instrumentation as the starting point, rather than developing it all from scratch, saving months if not years of time and cost. AGL’s unified code base or UCB provides the foundation upon which features and options specific to an individual manufacturer, vehicle model or line are developed and added to their own code base.
As the de facto toolset and build infrastructure for development of Linux based embedded systems, Yocto is the ideal solution to use to develop automotive software as cars are in reality, a rather large embedded system with wheels.
A Compendium of AGL and Yocto Resources
Our most recent blog post focused on Yocto as a tooling and build infrastructure for the definition and creation of ready to run images for embedded products. In the closing section, Yocto Beyond IoT, we briefly discussed creating Automotive Grade Linux (AGL) based images using Yocto.
In this post we continue with our focus on AGL development and have assembled for your reference a number of links to some of the most useful resources that will help accelerate your AGL development efforts. In addition to pointing to AGL/Yocto focused software resources, we thought it would also be helpful to point to some of the development boards used to build systems for IVI, telematics and instrumentation applications along with their associated AGL BSPs.
Once you have installed and setup Yocto on your Linux OS development system it is probably advisable to try and build a few runnable images to make sure all the components are working properly. This can be accomplished using the reference distribution for embedded devices, aka Poky.
Getting Started with AGL
We suggest that before you run a build for a specific development board you might want to start by creating an image to run on QEMU based on the most up-to-date AGL distribution to validate your Yocto and AGL meta and build configurations are correct. A full description of the meta-agl layer is available on OpenEmbedded Layers Index and build instructions can be accessed directly on the AGL Wiki.
It should be noted that the build instructions provided on the AGL Wiki still reflect the previous AGL release v6.0 (Funky Flounder). To build an image with the latest AGL v7.0 release (Grump Guppy) requires using one of two downloads:
-
- “Latest Stable Release for Guppy 7.0.0” which is a stable tested release or;
- “Latest on Guppy Branch” which is the latest non-release development code
Once the download is complete, your AGL source will include the ‘meta-agl’ layer mentioned above as well as several other meta-agl layers (e.g. meta-agl-demo) needed for building the AGL demo. Depending on your preference follow the steps below:
To Download “Latest Stable Release for Guppy 7.0.0”:
To Download “Latest on Guppy Branch” (might be unstable):
Using the AGL Grumpy Guppy 7.0 release will add significant new functionality to an image enabling developers, for example, to implement voice control for their own applications built on top of AGL. Some of the more significant capabilities in the release include:
-
- Open source speech recognition APIs
- Device profiles for telematics and instrument cluster
- Integration with simultaneous display on IVI system and instrument cluster
- Multiple display capability including rear seat entertainment
- Wide range of hardware board support including the addition of Raspberry Pi
- SmartDeviceLink ready for easy integration and access to smartphone applications (automakers can also choose to integrate Apple CarPlay or Android Auto on top of the AGL platform)
- Application Services APIs for navigation, voice recognition, bluetooth, audio, tuner and CAN signaling
- Near Field Communication (NFC) and identity management capabilities including multilingual support
- Over-The-Air (OTA) upgrade capabilities
- Security frameworks with role-based-access control
Building a full-up AGL demo image including the GUI with complete functionality for QEMU requires that you setup a build environment with your specific AGL features, to accomplish this the meta-agl/scripts/aglsetup.sh script is provided. The aglsetup.sh script allows you to specify AGL target machine type as well as additional AGL features. Since we are building an AGL demo image for QEMU, use the command below. Once the command completes you’ll be placed in a ‘./build’ directly parallel to the location of your AGL download.
Now that the AGL build environment is setup for our target, build the AGL demo image for QEMU using ‘bitbake’:
Once complete, your image is ready for execution. You image will be located in ./build/tmp/deploy/images/qemux86-64/agl-demo-platform-qemux86-64.vmdk.xz, follow the instructions in the AGL site for running QEMU images.
AGL and Yocto Compatible Development Boards
The development of new software based features and functionality for connected cars requires significantly more effort than simply writing the code. Hardware and software engineers have to work in close collaboration to ensure that the existing code base and new code adding new features/functionality will run on the existing in-car computing resources.
Introduction of new features, such as lane keeping, may push in-car network bandwidth utilization beyond existing limits and consume additional CPU cycles, leaving little to no overhead for the rest of the features. Engineers will determine if a new hardware/CPU platform is required to meet these increased demands. Planning for new hardware/CPU platforms requires significant effort to locate and research automotive specific development boards OS and development tool compatibility. Many development boards are designed and built both by silicon vendors or board vendors that specialize in embedded systems. So below are some resources we’ve brought together for your use.
A comprehensive list of Linux compatible development boards for embedded development can be found on Embedded Linux under the heading Hardware Pages.
In addition to the above resource, the following table details a good cross section of the automotive focused System-on-a-Chip (SOCs) and their associated development boards with BSPs that are Yocto compatible. Each development board reference below links to either a vendor’s page or to the Embedded Linux page provided above.
System on a Chip (SOC) | Development Board |
Renesas R-Car E2 | Renesas E2 |
Renesas R-Car D3 | Renesas D3 |
Renesas R-Car M3 | Renesas M3 |
Renesas R-Car H3 and M3 | Renesas H3 Starter Kit |
Renesas H3 Salvator-X | |
TI AM335x | Sitara AM335x Starter Kit |
BeagleBone Black | |
x86-64 PC | Intel NUC |
Qualcomm Snapdragon 820 | S820Am v2 Automotive Development Platform |
Broadcom BCM283x | Raspberry Pi 3 B |
Raspberry Pi 2 Model B | |
Raspberry Pi Model B | |
NVIDIA Tegra X1 | NVIDIA DRIVE CX |
NVIDIA Jetson TX1 | |
NVIDIA Tegra X2 | NVIDIA Jetson TX2 |
NVIDIA Drive Xavier | NVIDIA Driver PX Xavier |
NXP i.MX6 | Toradex Apalis iMX6 |
Boundary Devices i.MX6 Boards | |
Toradex Colibri iMX6 | |
Toradex Colibri iMX6ULL | |
NXP SABRE Board for Smart Devices | |
Garz & Fricke | |
Kontron SMARC-sAMX6i | |
NXP i.MX7 | Toradex Colibri iMX7 |
NXP Warp 7 | |
NXP i.MX8 | NXP i.MX 8QMax LPDDR4 |
Toradex Apalis iMX8 | |
NXP Vybrid | Toradex Colibri VF50 |
Toradex Colibri VF61 |
All of the links to resources provided in this post should cut down on some of the research time needed to locate and understand some of the options available to automotive developers for their AGL/Yocto hardware and software development initiatives.