Anurag Pandey’s Post

The booting process of Embedded Linux is a streamlined sequence of steps that a device undergoes to load the Linux kernel and initialize the system. This process is tailored to the constraints and requirements of embedded systems, which often have limited resources and are designed for specific tasks. 🖋 Power-On and Hardware Initialization: When the device is powered on, the CPU begins executing instructions from a predefined location in the ROM. This initial code, part of the system's firmware, is responsible for basic hardware setup, such as initializing the clock, memory, and essential peripherals. 🖋 Primary Bootloader: The primary bootloader, a small piece of code in ROM, loads a more sophisticated secondary bootloader from a predefined storage location. This stage is minimal due to space constraints in ROM. 🖋 Secondary Bootloader: The secondary bootloader, like U-Boot, offers advanced features. It further initializes the hardware, sets up the memory map, and can load the kernel from various sources. This stage allows for configuration and customization of the boot process. 🖋 Loading the Kernel: The bootloader loads the Linux kernel into memory, decompressing it if necessary. It then passes control to the kernel, along with system information. 🖋 Kernel Initialization: The kernel initializes the CPU, memory, and hardware components, sets up subsystems, and mounts the root filesystem. 🖋 Init Process: The kernel starts the init process, the first user-space process, which is responsible for starting other processes and initializing the user-space environment. 🖋 User-Space Initialization: The init process executes scripts and launches services to set up the user environment, including network interfaces and system daemons. 🖋 Application Startup: Finally, control is handed over to the primary application(s) of the device, which may start automatically based on the system configuration. This process is highly customizable and varies across different embedded systems, tailored to the specific needs of each device. #embeddedlinux #embeddedsystems

A simple and clear explanation of the complete booting sequence for Embedded Linux, presented by Jegan Amirthalingam! Take a look to have an idea of the primary and secondary bootloader, and all further processes until the call to init! #embeddedsystems #linux #embeddedlinux

Embedded devices often use special operating systems, such as 𝗙𝗿𝗲𝗲𝗥𝗧𝗢𝗦 and 𝗘𝗺𝗯𝗲𝗱𝗱𝗲𝗱 𝗟𝗶𝗻𝘂𝘅. How do you decide which one is the right fit for your application? 𝗙𝗿𝗲𝗲𝗥𝗧𝗢𝗦 is designed as a minimalist real-time operating system for microcontrollers, emphasizing simplicity and responsiveness. 𝗘𝗺𝗯𝗲𝗱𝗱𝗲𝗱 𝗟𝗶𝗻𝘂𝘅, on the other hand, is built on the Linux kernel, offering a feature-rich environment that supports complex applications, typically running on more powerful microprocessors. Our blog will guide you more on topic.

Deciding between Embedded Linux and FreeRTOS for your next project? Here’s a quick comparison to help you choose the best fit. 𝗙𝗿𝗲𝗲𝗥𝗧𝗢𝗦: - 𝗥𝗲𝗮𝗹-𝘁𝗶𝗺𝗲 performance. - Ideal for simple 𝗰𝗼𝗻𝘁𝗿𝗼𝗹 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 like appliance controllers. - 𝗟𝗼𝘄 𝗽𝗼𝘄𝗲𝗿, fast boot, perfect for battery-operated devices. - Straightforward to develop for, especially if you’re familiar with C and microcontroller environments. 𝗘𝗺𝗯𝗲𝗱𝗱𝗲𝗱 𝗟𝗶𝗻𝘂𝘅: - Supports 𝗰𝗼𝗺𝗽𝗹𝗲𝘅 𝗽𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴 tasks. - Great for applications needing robust networking or multimedia. - Versatile, with 𝗲𝘅𝘁𝗲𝗻𝘀𝗶𝘃𝗲 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝘀𝘂𝗽𝗽𝗼𝗿𝘁. - Steeper learning curve but offers more flexibility and scalability for complex applications. Have you worked with either of these operating systems? What was your experience like, and which would you recommend for specific applications? #EmbeddedSystems #FreeRTOS #EmbeddedLinux For further details, read our blog below.

why blacklist file in linux /etc/modprobe.d/blacklist.conf file is used in Linux to prevent specific kernel modules from being loaded automatically. Here's an overview of its purpose and how it is used: Purpose: The blacklist.conf file contains a list of kernel modules that should not be loaded automatically by the system. This is useful for preventing the loading of modules that might cause conflicts, are unnecessary, or are known to cause issues on specific hardware. Structure and Usage: The file consists of lines that specify modules to be blacklisted, typically using the blacklist directive. Example entry: blacklist nouveau This entry prevents the nouveau module (an open-source NVIDIA driver) from being loaded. Creating and Editing: You can create or edit the /etc/modprobe.d/blacklist.conf file using a text editor. For example, to blacklist a module named example_module, you would add: blacklist example_module Effect on System: When the system boots or when modprobe is used to load modules, it will refer to the blacklist to avoid loading the specified modules. This helps in customizing the module loading behavior according to specific needs or preferences. Examples of Common Use Cases: Preventing Conflicts: If two modules provide similar functionality, you might blacklist one to prevent conflicts. Disabling Unwanted Modules: For instance, if you use proprietary drivers for your GPU, you might blacklist the open-source drivers. Improving System Stability: If a particular module is known to cause instability on your hardware, you can blacklist it. In short, /etc/modprobe.d/blacklist.conf is a configuration file used to specify kernel modules that should not be loaded by the system, providing a way to prevent conflicts, disable unwanted modules, and improve system stability.

Here is how your RTOS threads the tasks and runs them efficiently! Load balancing is the process to distribute the workload across cores for multiprocessing in a multicore system. To make it better, dynamic load balancing involves continuous evaluation and modification of threads at runtime. This means the scheduler continuously evaluates how well the tasks are getting done and move them which lets the system handle the critical tasks well instead of blocking the core. This is implemented inherently on some of the RTOS such as Embedded Linux (that comes with a huge overhead of doing this) or can be implemented by the developer on the RTOS level for their own system. There are several benefits of this, the system gets used to the entirety of its capability, the output of high priority tasks gets lot more predictable. The hardware and software faults can be avoided in the cases when a core is stuck somewhere or fail completely. And of course you can expand the system for future by adding more cores to the same algorithm (not mentioning Apple in every post :) but you know it, Macbook is a big iPhone). The downside is all your cores fighting for the same resource, memory contention, etc. which requires very efficient design of critical sections, mutexes/semaphores and IPC mechanisms. The task prioritization also has to be super sleek to pre-empt cores for crucial tasks and resuming them on the same state. I was reading this interesting article on PX5 that looks pretty good at all of these. Link in the first comment for those interested!

Linux Boot Process Explained Almost every software engineer has used Linux before, but only a handful know how its Boot Process works :) Let's dive in. The diagram below shows the steps. Step 1 - When we turn on the power, BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) firmware is loaded from non-volatile memory, and executes POST (Power On Self Test). Step 2 - BIOS/UEFI detects the devices connected to the system, including CPU, RAM, and storage. Step 3 - Choose a booting device to boot the OS from. This can be the hard drive, the network server, or CD ROM. Step 4 - BIOS/UEFI runs the boot loader (GRUB), which provides a menu to choose the OS or the kernel functions. Step 5 - After the kernel is ready, we now switch to the user space. The kernel starts up systemd as the first user-space process, which manages the processes and services, probes all remaining hardware, mounts filesystems, and runs a desktop environment. Step 6 - systemd activates the default. target unit by default when the system boots. Other analysis units are executed as well. Step 7 - The system runs a set of startup scripts and configure the environment. Step 8 - The users are presented with a login window. The system is now ready.

Embedded operating systems come in various types, tailored to different requirements and industries: 1. Real-Time Operating Systems (RTOS): Designed to manage tasks with precise timing constraints, RTOS ensures timely execution of critical tasks. Examples include FreeRTOS, QNX, and VxWorks. 2. Linux-based Embedded Operating Systems: Leveraging the Linux kernel, these operating systems offer flexibility, scalability, and extensive community support. Popular options include Embedded Linux, Yocto Project, and Buildroot. 3. Bare-Metal Embedded Operating Systems: These lightweight systems run directly on hardware without an intervening operating system layer, providing maximum control and efficiency. Examples include FreeRTOS, eCos, and Contiki. 4. Proprietary Embedded Operating Systems: Developed by companies for specific hardware and applications, proprietary systems offer tailored solutions with optimized performance and features. Examples include ThreadX, Nucleus RTOS, and μC/OS. 5. Mobile Operating Systems for Embedded Systems: Adaptations of mainstream mobile OS like Android and iOS optimized for embedded devices, offering rich features and ecosystem integration. Each type has its advantages and is chosen based on factors such as performance requirements, resource constraints, development complexity, and licensing considerations.

🚀 Layers of a Linux-Based Embedded System🚀 There are many layers that power Linux-based embedded systems? Let's discover them all. 💻🌐 1. Hardware Foundation:   - At its core, we have the hardware – the engine of innovation, comprising processors, memory, and various peripherals. 2. Bootloader Brilliance:   - The bootloader kicks things off, orchestrating the hardware's symphony and ushering in the Linux kernel. 3. Linux Kernel Magic:   - Behold the Linux kernel, the maestro conducting the orchestra. It manages resources, supports networking, and oversees processes with finesse. 4. Structured File Systems:   - Enter the file system, a meticulous organizer of data on storage devices. It lays the groundwork for the system's file hierarchy. 5. Root File System Rock:   - The root file system is the bedrock, housing crucial system files and directories – the essence of the entire structure. 6. Powerful System Libraries:   - Meet the supporting cast – system libraries like glibc, offering essential functions and services that applications rely on. 7. Middleware Marvels:   - Middleware steps in, providing abstractions and services. Think D-Bus for communication and ALSA for audio support. 8. Frameworks: Building Blocks for Apps:   - Application frameworks like Qt and GTK provide a structured environment for developing applications – the face of innovation. 9. End-User Bliss:   - It all culminates in user space applications – the web browsers, media players, and utilities that make our devices truly useful. 10. Init Systems:   - The init system takes the stage, initializing the system and managing processes. systemd and SysV init orchestrate this symphony. 11. Device Drivers Dance:   - Device drivers take a bow, enabling seamless communication between the kernel and hardware peripherals. 12. Network Stack Connection:   - Last but not least, the network stack facilitates connectivity, letting our devices communicate intelligently over networks. Understanding these layers opens the door to a world of possibilities in embedded systems. From processors to user-friendly applications, each layer plays a pivotal role in shaping our technological landscape. 🌐✨ These information are from ARM's course 👇🔍 #EmbeddedSystems #Linux #TechnologyExploration 🚀

⛓ Understanding "Device Tree" in Linux: Simplifying Hardware Descriptions ⛓ 🔍 What is a Device Tree? :: A device tree is a data structure used in Linux to describe the hardware components of a system. Think of it as a blueprint that outlines all the devices, their properties, and how they are connected. 🌳 Why a Tree? :: Just like a family tree, a device tree has a hierarchical structure:-- ▪ Root Node : The starting point, representing the entire system. ▪ Nodes : Represent individual hardware components like CPUs, memory, and peripherals. ▪ Properties : Each node contains key-value pairs detailing the component's characteristics (e.g., a CPU node might include properties like model and speed). ⚙️ Key Features :: ▪ Unified Description : It provides a standard way to describe hardware, making the system more modular and easier to manage. ▪ Compatibility : Device trees are OS-agnostic, ensuring compatibility across different systems and projects. ▪ Non-Detectable Hardware : Especially useful for hardware that can't be auto-detected by the operating system, ensuring all components are correctly identified and utilized. 🔧 How It Works :: ▪ Creation : A device tree is created, often by hardware manufacturers, to describe the system's components. ▪ Loading : When the system boots, a bootloader loads the device tree into memory. ▪ Utilization : The operating system reads the device tree to understand the hardware layout and configure itself accordingly. 💡 Example :: Consider a simple device tree for a system with a CPU, memory, and a UART (serial port). Each of these would be a node in the tree, with properties detailing their specifications. In essence, the device tree is a powerful tool that simplifies hardware management in Linux, ensuring systems are configured correctly and efficiently. Whether you're developing new hardware or optimizing existing systems, understanding device trees is crucial for modern Linux development. #Linux #DeviceTree #Hardware #TechExplained #LinuxDevelopment #EmbeddedSystems