Open Source Summit Europe 2024

Lessons learned, benefits and some drawbacks learned from utilizing Embedded Linux, Yocto Project and other parts of Opensource software stack in development, production and maintenance of Mobile Robots for special operations. A history of the Polish mobile robots has begun in 1999 with a prototype INSPECTOR robot designed and build by Łukasiewicz Research Network – Industrial Research Institute for Automation and Measurements PIAP. Since about 2010 the robots became digital and started to use Linux and build systems. The talk covers some practical aspects of design and implementation of ARM and x86 Explosive Ordnance Disposal (EOD) mobile robots, the industry transformation and response to Embedded Linux and Yocto Project software stack from a perspective of small engineering team chasing a constantly shifting targets. An insight, successes and failures throughout more than 10 years of utilizing Embedded Linux, Yocto Project, real-time aspects of the operating system and additional topics such as software update, system monitoring, safety critical operations and data encryption and safety will be also covered.

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.

In this talk we will give you a comprehensive overview of the complex task of building a high-performance DC vehicle charging station. We will show you how the EVerest project addresses a diverse set of challenges across all areas of the required software stack. EVerest abstracts away the complexities of reliably communicating with vehicles of all makes and models to enable successful charging sessions with robust implementations of the relevant communication protocols, such as ISO 15118-2/20 and DIN 70121 including Plug & Charge. Communication with backend systems of different providers can be achieved through the OCPP 2.0.1 and 1.6 standards. We will also explain how error handling and reporting are managed in a system running a diverse set of EVerest modules. Additionally we will discuss our strategy for generating comprehensive documentation for a project that spans multiple actively developed repositories. EVerest is an Apache 2.0 licensed project within LF Energy. It was initiated by PIONIX GmbH to support the electrification of the mobility sector.

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!

In this session, the status of the elinux wiki will be discussed, along with ideas for expanding and updating the content for the site. The elinux wiki has served as a resource for embedded Linux developers for almost 18 years. The wiki contains a lot of great material, including slides and videos for almost every embedded Linux Conference. In this session, Tim will discuss the wiki, and we'll brainstorm ideas for rejuvenating the site, and utilizing it as an effective community resource. Rewards will be available if you make an edit to the wiki during the BOF!! Let's work together to improve this valuable resource!

Linux in space must be highly reliable and autonomous, both because of the hostile external environment, the physical unavailability of the system, and the limited data flow and direct system administration capabilities. Radiation and other external influences lead to sudden shutdowns and system reboots. Also, data stored in storage devices are at risk of radiation and physical effects. Therefore, the design of a satellite always considers which parts of the system to duplicate or otherwise insure and how to ensure the system's ability to detect an error and recover. In the design of Linux4Space, we have encountered various approaches to solving the problem (from "we have two SD cards, and one is sure to last six months" to "fully duplicated storage and CPU with error detection"). We have reviewed the designs of other satellites and systems. In this paper, we provide some specific examples from natural satellites and summarize everything we have been able to find and track down for various other solutions, examples, and demonstrations.

"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.

Automotive Grade Linux released the Quirky Quillback version of the UCB in February and Royal Ricefish is coming in the Summer of 2024. The latest release includes an update to the Yocto project LTS version 5.0. We will give an update on the latest AGL features included in the Ricefish release. We also want to share some lessons learned from upgrading from the 4.0 to 5.0 versions of the Yocto Project.

Building robust audio policies on embedded systems that integrate well with upstream APIs and components such as PipeWire and PulseAudio has been a challenging task for a long time. In many implementations, custom hardware DSP management components are built, bypassing existing upstream functionality, making integration and maintenance harder than they need to be. In this talk, George will explain how many of these difficulties can be overcome by integrating management directly into WirePlumber, the default session manager of PipeWire, and how existing functionality can be factored in to build complex solutions with ease. Emphasis will be given also on how recent developments in WirePlumber have improved this particular use case.

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.