Lecture01_IntroToLinuxAndEmbeddedSystems.pptx

Editor's Notes

• #1: Hello and welcome to this Linux for Embedded Systems lecture. This is the first lecture of the course.
• #2: We will begin by looking at the structure of the course.
• #3: The Embedded Linux Course is organized into several modules, each comprising theoretical lectures, practical labs, and exercises.   The course teaches students how to build a custom Linux distribution that supports development of embedded systems, as well as provides them with the experience of programming device drivers. These outcomes are intended as the industry requires engineers with the skills to configure and customize the Linux kernel for custom-developed hardware. There is also a need in the industry for custom configuration of Linux distributions for embedded applications, which seldom match general-purpose Linux distributions such as Ubuntu or Debian.   Module 1 provides a brief introduction to Linux for embedded systems and defines what embedded systems are, as well as provides some real-world examples of their usage.   Module 2 goes over the Linux-based embedded system component stack. This provides details on a variety of components that are found in embedded Linux systems, such as the bootloader, kernel, root file system, device tree, system programs, and applications.
• #4: Module 3 covers the anatomy of a Linux-based system. This goes into detail on the internals of a Linux kernel, the device tree, and system programs.   Module 4 looks at the configuration and build process of an embedded Linux system. This includes different tools that are useful for assisting the process such as Yocto.   Module 5 entails a range of topics from the central processing unit and input/output (CPU-I/O) interface to the virtual file system and finally introduces Linux kernel modules.
• #5: Module 6 delves into the communication between kernel and user space, more specifically looking at the module-level communication point of view, as well as the user-level communication point of view.   Module 7 is a demo that will run through building a ranging sensor kernel module that can be deployed onto a Linux-embedded system and used for a number of tasks.   Module 8 covers the important ability to debug and profile applications/hardware to identify issues or bottlenecks, as well as improve efficiency and power consumption.   A number of these lectures will be complemented with lab exercises that will take the student through a practical usage of the theory.
• #6: Next is a small introduction to embedded systems.
• #7: There are many ways to define an embedded system. One possible definition is to describe it as a special-purpose computer that is designed for a specific application or purpose. An embedded system is a computer; it has a processor, memory, and input/output (I/O) devices. However, it is not the same as a conventional, general-purpose computer such as a laptop or desktop. The processor, memory, and I/O devices that power an embedded system are carefully selected to provide the minimum amount of resources needed to fulfil the requirement of a specific application. This is in contrast with conventional, general-use computers, where the resources are determined by the user’s budget: having a higher budget allows spending on more capable processers, larger memory, and faster mass storage.   For example, if an embedded system must execute control algorithms for an internal combustion engine, its I/Os will be custom designed to allow interfacing with the sensors (e.g., temperature and pressure sensors) and actuators (e.g., injectors, candles, and throttle).   Its memory will be tailored to accommodate only the control algorithm, and its processor will be selected to guarantee correct timing behavior for the algorithm. This embedded computer will seldom be expandable, and if a new application is developed, part of the embedded computer will probably have to be redesigned.
• #8: It helps to consider an embedded system as two main parts. The first part is the application, which is the software that provides the user with the needed service (e.g., to calibrate the amount of fuel to inject in the combustion chambers correctly, and the proper ignition timing to satisfy a given torque request). The second part is the underlying platform, which is the combination of basic software and hardware that provides the application with the resources it needs to perform its task.   The software level abstracts the hardware details by providing high-level, easy-to-use functions. This provides access to the resources through system programs. An example of this is the “ls” command, which lists the content of a directory. It also enables efficient access to the resources provided by the hardware through the operating system. An example of this is the CPU’s real-time scheduling and device driver management.   The software segment can be broken down even further into the bootloader, the operating system, and the system programs.
• #9: The bootloader is a program that is to be executed upon start-up of the device. Its duty is to initialize the hardware to enable the execution of the operating system and the system programs.   The operating system oversees defining an abstraction of the hardware to make it more user-friendly and efficient.   The system programs are a set of utilities that allow the application to access the resources provided by the platform.
• #10: There are numerous operating systems available in the modern day, refined and tailored to fulfilling different needs. The needs of the application in question must be the first consideration when choosing a suitable operating system. If an application exhibits real-time requirements (i.e., the ability to show deterministic behavior that always performs allocated tasks by a given set of deadlines), then a real-time operating system is required (e.g., Arm RTX and FreeRTOS). Conversely, if an application needs support for multi-core processing and high-end graphics, then a different class of operating systems, such as Linux or Android, should be considered.
• #11: Why is Linux so widely used on embedded systems?
• #12: Today, Linux can be found in embedded systems of many sizes, from mobile phones, home appliances, or vehicles infotainment to the International Space Station.   Linux’s popularity is due to a number of factors. First, it is open source. This means that anyone can access the Linux source code, study it, and modify it in order to tailor it to their specific requirements.   Another contributing factor to Linux’s popularity is its strong and committed community that helps to maintain and update Linux regularly. This community is made up of companies, individuals, academics, and hobbyists.   Something that is very useful for engineers is the flexibility of Linux. It can support just about any hardware architecture you can think of: Arm, x86, PowerPC, the list goes on.   Given its deployment in millions of devices across the world, its code is constantly tested and put into practical scenarios. This means that its usage legacy is always becoming more and more robust.   It is also supported by a huge ecosystem of software that consists of both runtime software (e.g., graphics libraries, networking stacks, or device drivers) and development tools (e.g., compilers, debuggers, or profilers).   Finally, it is royalty-free, meaning that no payment is required if a product using Linux is manufactured and sold. This makes Linux very appealing for industries with a large user base, such as consumer or automotive products.
• #13: Looking into the evolution of Linux, it was announced on August 26, 1991, by a then unknown Linus Torvalds. Within a few years, it developed a huge user base and supporting community. Today, different kernel categories exist to reflect different maturity levels of the code-base. These categories are prepatch, mainline, and long term. Prepatch or “RC” kernels are pre-releases that are maintained and released by Linus Torvalds. Mainline kernels are maintained by Linus Torvalds and are where all the new features are introduced. These are typically released every two to three months. Finally, long-term kernels are older releases that are subject to “long-term maintenance”. Important bug fixes are applied to these kernels.   From an industrial perspective, the long-term kernel is particularly relevant. These kernel code-bases undergo bug fixes for two to five years. This gives industrial designers confidence that the code in the device they are creating will be regularly maintained and fixed for a relatively long period of time. This helps avoid the problem of early obsolescence.
• #14: There are countless examples of real-world Linux-based embedded system applications.   Linux is particularly suited for in-flight entertainment because of its lightweight nature. It is simple, not weighed down by accompanying programs, and it is easily adaptable to many environments.
• #15: It is used for electronic boards that display information, in this case, in a Café. As we can see here, the screen displays the messages that Linux produces during boot-up. In particular, we can recognize a kernel panic, as the kernel is not able to find the root file system.
• #16: Even gas station pumps make use of it! In this picture, the screen displays the messages of the Linux bootloader. This gas station is powered by the Linux Ubuntu distribution with Kernel 2.6.35.   These are just a few examples, but get you thinking about just how many applications there are for Linux on embedded systems.   This concludes the first lecture on Linux for Embedded Systems. In the next module, we will take a closer look at a Linux component stack often used in embedded systems.