Open Source Summit Europe 2022

When you first flip the switch or push the button, after the first electrons start flowing and crystals start vibrating, before any Linux dmesg lines appear on any screen, there is a fundamental chicken and egg question we must answer before the CPUs in our Beaglebone or Raspberry Pi can start executing our code. How do embedded processors find and run the code they need to begin executing code? Join Bryan as he goes through each stage of the bootup process for an AM62 and the constraints we must work around when we first start configuring the clocks, starting the power controllers, initializing DDR, loading the firmware, and everything else we need before we can start the Linux kernel and securely wakeup our embedded system. At the end of this session you will be familiar with the role of each bootloader and each step of how Texas Instruments’ AM62 family of SoCs loads, verifies, and uses each bootloader stage as the CPUs work their way to the Linux prompt and running your embedded applications.

The sad truth is that when developing an application, we spend most of the time debugging. The case of embedded Linux is even more complicated than traditional systems, because we need to take into account the hardware interactions. In this session, Marta is going to do a gentle introduction to embedded Linux debugging. It will start with tips on approach and planning, then move to tools. Getting printfs and similar reliably from different software layers will be the first topic (including the kernel, userspace, using physical serial ports and more). Then Marta will introduce embedded debuggers, with different GDB use-cases. Finally, she will cover most popular tools like strace, perf, Wireshark and share secrets of kernel special files.

Nowadays ARM system boot flows are becoming more and more complex. Especially 64-Bit systems rely on the ARM Trusted Firmware (TF-A) and the provided system services to implement CPU power management, system suspend and other SoC specific functions. This talk will give an overview on how an ARM system starts at the reset vector, boots up the different firmware parts and finally arrives within the linux boot-up procedure. We will also touch the topic of OP-TEE and the services provided by the TF-A, i.e. PSCI and SCMI.

This presentation will introduce the building blocks that provide the foundation of tracing in Linux, such as ftrace, kprobes, uprobes, tracepoints and ptrace. It will cover how these concepts are used by tracing tools available for Linux today with some tracing examples for demonstration.

The RPi 400 are ideal candidates that can replace workstations in class rooms. Running a 4 c-core ARM64 processor, 4GiB of memory, a network adapater and video connectors built in a small 'keyboard' casing make them ideal replacements for class room workstations. However the SD cards that these SBCs boot from are very fragile. Booting from USB sticks would be better, but having them boot remotely over the network would also solve the management problem. In this presentation Pascal will talk you to the process of engineering a solution that will allow the RPi 400 but also other Raspberry Pi's to boot from the network. The PIs will bootstrap using bootp and tftpboot and then connect an iSCSI root disk to boot from. In the talk I will discuss issue we faced like how to keep the kernel and initrd up-to-date after doing an OS upgrade. The whole solution is automated with Ansible so one can quickly roll out tens of RPi 400's. The icing on the cake is central user management with a NFS based home share and centralized user management either by FreeIPA or Active Directory with Samba.

DRI, DRM, KMS, FB, EGL, Wayland, V4L2: The Linux graphics stack can be very confusing and intimidating. Unfortunately, the first contact is usually when a system is not performing as expected and needs to be debugged. This situation can easily occur for embedded systems with a graphical user interface. Due to hardware resource constraints, handling the large amount of data involved in graphics makes it necessary to use optimized hardware paths to fulfill (soft) real-time system requirements such as a certain frame rate. Understanding these acronyms and the components that constitute the graphics stack is necessary for working with the internals on embedded systems. This is essential for optimizing a system's graphics performance or investigating observed performance issues, and communicating findings to others. To make the Linux graphics stack less scary, Michael will take you by the hand and give you a guided tour. We will find out, which software components are involved in the Linux graphics stack, and discuss which APIs are used to interact with these components and which should be avoided. Furthermore, we will look at the tools and methods which can be used for debugging.

The sad truth is that when developing an application, we spend most of the time debugging. The case of embedded Linux is even more complicated than traditional systems, because we need to take into account the hardware interactions. In this session, Marta is going to do a gentle introduction to embedded Linux debugging. It will start with tips on approach and planning, then move to tools. Getting printfs and similar reliably from different software layers will be the first topic (including the kernel, userspace, using physical serial ports and more). Then Marta will introduce embedded debuggers, with different GDB use-cases. Finally, she will cover most popular tools like strace, perf, Wireshark and share secrets of kernel special files.

When you first flip the switch or push the button, after the first electrons start flowing and crystals start vibrating, before any Linux dmesg lines appear on any screen, there is a fundamental chicken and egg question we must answer before the CPUs in our Beaglebone or Raspberry Pi can start executing our code. How do embedded processors find and run the code they need to begin executing code? Join Bryan as he goes through each stage of the bootup process for an AM62 and the constraints we must work around when we first start configuring the clocks, starting the power controllers, initializing DDR, loading the firmware, and everything else we need before we can start the Linux kernel and securely wakeup our embedded system. At the end of this session you will be familiar with the role of each bootloader and each step of how Texas Instruments’ AM62 family of SoCs loads, verifies, and uses each bootloader stage as the CPUs work their way to the Linux prompt and running your embedded applications.

This presentation will introduce the building blocks that provide the foundation of tracing in Linux, such as ftrace, kprobes, uprobes, tracepoints and ptrace. It will cover how these concepts are used by tracing tools available for Linux today with some tracing examples for demonstration.