Open Source Summit Europe 2024

Most embedded development boards can run Linux from traditional distros like Debian to custom Yocto systems. But have you ever wondered what it would take to run Android Open Source Project (AOSP) on these developer boards? Well, wonder no more. This talk will walk you through it. Using a ARM based Texas Instruments evaluation board as example, we will start from TI's Yocto SDK then download AOSP and study all the changes needed in order to boot to the Android home screen. We will cover: - Bootloader (U-Boot) modifications required for Android boot flow - Linux kernel versus Android Common Kernel (ACK) - User space changes - Android's build system - Additional changes to add more advanced features

This presentation is the story of Honda's first in-house software development of IVI(In-Vehicle Infotainment) software. Reasons why Honda promotes in-house software development, Building an in-house software development team that started with two people, All development process from scratch, There is no silver bullet that will solve many problems. However, we were able to success the launced this model based on Honda's DNA of Waigaya, A00, and 120% quality products. The key point for this is the use of AOSP(Android Open Source Project) and some OSS. This presentation will show how a traditional automotive OEM like Honda was able to create an in-house software development team, and how it used OSS, including AOSP. By applying OpenChain(ISO/IEC 5230) self-certification and SPDX Lite to our development process, we were able to solve many problems and get a higher starting point. However, vehicles have difficult requirements, so we will tell you the points to minimize customization of OSS.

This Birds of a Feather meeting is an opportunity for all developers working with embedded Android to come together and share ideas, grumbles and clever hacks. Some of the topics you might like to talk about include these: * Building AOSP * Creating and maintaining board support packages * Integration with Android Studio * Testing and debugging * Security, SELinux, secomp, sandboxing Come along if you find *any* of this stuff interesting!

"Which device prototype or a development board do you suggest?" - got to be one of the most frequently asked question in the embedded workspace. Last year EOSS/ELC'23 was no different and we ran into similar questions around Android development boards. That planted the idea of enabling a community around the development boards or devices that provide decent AOSP (Android Open Source Project) support.

So we started working on The Devboards for Android community initiative https://devboardsforandroid.linaro.org to enable a collaborative space for AOSP system developers. We briefly talked about it at the Android Microconf at LPC'23 as well.

Overall idea of this project is to provide an umbrella space for collaboration and consolidate all the resources about the devices that are known to support AOSP reliably. For each supported device, links are made available to the kernel source, local manifests, device specific files and binaries (like bootloader, firmware, HALs) and documentation. We hope that this initiative will be instrumental in sharing and co-developing features like generic HALs across multiple devices and possibly enabling the supported devices with LAVA CI in the future.

This presentation will show a step-by-step guide from hardware design to a fully functional Linux system. Initial considerations in the hardware design phase will help simplify the bringup. This includes designing for testability and incorporating features that make debugging easier, such as having accessible test points and providing instrumentation, such as a serial console and a JTAG interface. The next phase involves the bootloader, which is the first software component to run on the system. At this stage, we can use JTAG for early debugging to get some text output and eventually a console. The transition to the Linux kernel involves strategies that may include using JTAG again for early kernel debugging, followed by using printk and KDB for later diagnostics. The final phase involves the root file system and userspace tools that help bring up the rest of the peripherals. This final section of the presentation shows some userspace diagnostic and debugging tools for successfully getting a Linux-based system up and running.

More and more applications of embedded linux systems require them to ensure that only trusted software is started on the device. This means that verified boot procedures need to be employed to verify the software running on the device. This talk will highlight the necesssary components to cryptographically verify the bootloader, kernel and filesystem. It will also show how these components can be integrated using the OpenEmbedded build system. Bootloader verification will be covered by providing examples to use the signing.bbclass in Yocto in conjunction with the NXP CST tool to sign a bootloader, kernel verification is covered by a to be upstreamed fitimage class and filesystem verification will be shown with a dm-verity class example for Yocto. Additionally the talk will highlight common pitfalls when deploying locked down embedded systems encountered during project work. We will also cover the case of using GPLv3 licenses on locked down devices.