Forem: Darshan Rathod

Explaining the Linux Device Tree for Embedded Engineers From DTS Source to a Running Kernel

Darshan Rathod — Thu, 19 Feb 2026 10:49:12 +0000

If you work with ARM or embedded Linux, you’ve almost certainly touched a .dts file, toggled a status = "okay" somewhere, rebuilt, and moved on—without fully internalizing what’s really happening. For many embedded engineers, the device tree feels like a magical incantation between “the board” and “the kernel.”

This post walks through the full story, end‑to‑end: what the device tree is, how DTS becomes DTB, what the bootloader and kernel do with it, and a concrete I2C sensor example you can map to your own board.

1. Why the device tree exists
On PCs, hardware discovery is dynamic: ACPI, PCI, and the BIOS/UEFI tell the OS what’s present. On microcontrollers and many SoCs, the opposite is true: peripherals live at fixed addresses with hard‑wired interrupts, and the board designer decides which ones are actually used.

Hardcoding all of that into kernel C files does not scale when:

You have multiple boards built around the same SoC.
You spin board revisions and move peripherals to different pins.
You want to reuse a vanilla kernel image across variants.

The device tree is Linux’s answer on many embedded platforms: a data‑driven hardware description that says “what exists” and “where it lives,” separated from the kernel code.

High‑level idea:

One kernel image, many DTBs.
Bootloader passes the appropriate DTB for the actual board.
Kernel parses it and instantiates devices + drivers dynamically.

2. Mental model: it’s just a tree of nodes and properties
A device tree is literally a tree:

Each node represents a device or bus (CPUs, memory, SoC, UART, I2C, GPIO controller, etc.).
Each node has properties—simple key/value pairs that encode addresses, interrupts, strings, or small arrays.

At the source level, you work with DTS/DTI files:

/dts-v1/;

 / {
     model = "My Tiny ARM Board";
     compatible = "myvendor,myboard", "myvendor,my-soc";
 };

 cpus {
     #address-cells = <1>;
     #size-cells = <0>;

     cpu0: cpu@0 {
         compatible = "arm,cortex-a7";
         reg = <0>;
     };
 };

 memory@80000000 {
     device_type = "memory";
     reg = <0x80000000 0x10000000>; /* 256 MB */
 };

 soc {
     #address-cells = <1>;
     #size-cells = <1>;
     compatible = "simple-bus";
     ranges;

     uart0: serial@4000 {
         compatible = "vendor,soc-uart";
         reg = <0x00004000 0x1000>;
         interrupts = <5>;
         status = "okay";
     };

     i2c1: i2c@5000 {
         compatible = "vendor,soc-i2c";
         reg = <0x00005000 0x1000>;
         interrupts = <6>;
         status = "disabled";
     };
 };

A few must‑understand properties:

compatible: the string the kernel uses to match this node to a driver. Drivers declare a table of strings they support.
reg: base address and size of the device’s register region, in parent bus address space.
interrupts: which interrupt the device uses; encoding depends on the interrupt controller binding.

status: "okay" means “use this device”; "disabled" means “ignore it.”

Once you see a DTS as “a typed, structured config file for hardware,” it stops feeling mystical and becomes a tool you control.

3. File structure: .dtsi vs .dts
Real BSPs rarely have a single giant .dts. Instead, they layer the description:

SoC .dtsi—shared between boards using the same SoC. It describes the common peripherals (timers, UARTs, SPI/I2C controllers, pinctrl, etc.), often with status = "disabled".
Board .dts — includes the SoC .dtsi and turns on only what your board actually wires out, plus external devices (sensors, PMICs, connectors).

Conceptually:

/* my-soc.dtsi – used by many boards */
soc {
    i2c1: i2c@5000 {
        compatible = "vendor,soc-i2c";
        reg = <0x00005000 0x1000>;
        interrupts = <6>;
        #address-cells = <1>;
        #size-cells = <0>;
        status = "disabled";
    };
};

/* my-board.dts */
#include "my-soc.dtsi"

 / {
     model = "My Tiny ARM Board RevA";
     compatible = "myvendor,myboard-reva", "myvendor,my-soc";
 };

 &i2c1 {
     status = "okay";
     /* external devices will be added here */
 };

The board file doesn’t duplicate the SoC details—it only overrides and extends them. That’s exactly why you can have multiple board DTs pointing at the same SoC .dtsi.

4. From DTS to DTB: compiling the description
DTS is not what the kernel reads directly; it reads a compact binary form called a DTB (Device Tree Blob).

The conversion is handled by the Device Tree Compiler (dtc):

Install the tool on your dev machine:

sudo apt-get install device-tree-compiler

Compile a single DTS manually:

dtc -I dts -O dtb -o my-board.dtb my-board.dts

Inside the kernel tree, you usually run:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs

This makes Kbuild walk directories like arch/arm/boot/dts/, resolve all #include chains, expand labels, and emit .dtb files.

5. Boot flow: how the DTB reaches the kernel
On a typical ARM board with U‑Boot, the journey looks like this:

Boot ROM loads and runs the first stage bootloader.
Bootloader initializes DRAM and basic clocks.
Bootloader loads Image/zImage (the kernel) and my-board.dtb into RAM.
Bootloader sets a CPU register or passes a pointer via the boot protocol to tell the kernel where the DTB lives, then jumps to the kernel entry.

From that point onward, it’s all kernel:

Early boot code parses the DTB into an internal “OF” tree (struct device_node hierarchy).
The kernel walks this tree, creating platform devices and bus devices based on node compatible strings and bus types.
Subsystems like I2C, SPI, GPIO, and pinctrl register their drivers and match nodes whose compatible entries appear in their of_match_table.

The important consequence: if your DTB is wrong, the kernel will politely ignore hardware or attach the wrong driver—even if your code is perfect.

6. Concrete example: I2C temperature sensor
Let’s map this to something real you might have on a board: a temperature sensor connected to an SoC’s I2C1 bus.

6.1. SoC .dtsi
As seen earlier, the SoC describes the controller but does not commit to any external devices:

i2c1: i2c@5000 {
    compatible = "vendor,soc-i2c";
    reg = <0x00005000 0x1000>;
    interrupts = <6>;
    #address-cells = <1>;
    #size-cells = <0>;
    status = "disabled";
};

This tells the kernel:

There is an I2C controller at base address 0x5000.
It uses interrupt 6.
It can host children (devices with reg = I2C addresses).

6.2. Board .dts: enabling bus + sensor
Now your board .dts wires in the external sensor:

& i2c1 {
    status = "okay";

    temp@48 {
        compatible = "vendor,temp-sensor123";
        reg = <0x48>;          /* I2C address */
        interrupt-parent = <&gpio1>;
        interrupts = <12 0>;   /* GPIO1_12, active-low for example */
    };
};

Boot‑time story:

Kernel sees /soc/i2c@5000 with compatible = "vendor,soc-i2c", so it instantiates an I2C controller and binds it to the corresponding driver.
The I2C subsystem scans child nodes under that controller and finds temp@48.
It then looks for a driver whose of_device_id table contains "vendor,temp-sensor123". That I2C sensor driver’s probe() is called with a handle to this DT node.
Inside probe(), the driver typically reads reg (address), interrupts, and any extra properties (e.g. vdd-supply, reset-gpios) to configure the device.

No hard‑coded addresses inside the driver. All board‑specific wiring lives in DTS.

7. Bindings: formal contract between DTS and drivers
If DTS is the configuration, bindings are the schema. They define what properties are valid and required for a given device type.

You’ll find them in the kernel tree under Documentation/devicetree/bindings/. Modern bindings are written in YAML and can be validated using dt-schema.

Before you create or modify a node:

Locate the binding file for your device, e.g.i2c/vendor,temp-sensor123.yaml.
Check: required properties, allowed values, phandle relationships (interrupt-parent, clocks, resets, gpios, etc.).

Treat bindings like a datasheet for your DTS. If your properties don’t satisfy the binding, the driver either won’t probe, or it will behave unpredictably.

8. Inspecting and debugging the live device tree
One of the nicest aspects of DT is that you can inspect what the kernel actually sees—no guesswork.

8.1. Browse the live tree
On DT‑based systems, the kernel exposes the live device tree under /sys/firmware/devicetree/base:

ls /sys/firmware/devicetree/base

You can:

find nodes (find . -name 'i2c*').
cat properties (cat soc/i2c@5000/temp@48/compatible). 8.2. Decompile the running DTB Sometimes the DTB in use is not the one you think you built. To verify:

# Many platforms expose the flattened DT as a single blob:
sudo dtc -I dtb -O dts -o running.dts /sys/firmware/fdt

Or if your distribution uses DTBs under /boot/dtb/:

sudo dtc -I dtb -O dts -o board-from-boot.dts /boot/dtb/my-board.dtb

This lets you:

Compare “expected DTS” vs “actual running DTS.”
See overlays applied by the bootloader or OS (common on Jetson, Raspberry Pi, Android, etc.).

A very practical debug loop:

Inspect /sys/firmware/devicetree/base to see whether your node exists and is "okay".
Confirm compatible and reg are what the driver expects (from bindings/docs).
Check dmesgfor probe failures or “no compatible device found” messages.

9. Conclusion:
The device tree is not magic—it’s the simple, structured layer that tells Linux what your hardware really looks like. Once you’re comfortable moving from DTS to DTB and tracing a node all the way to a driver’s probe() board, bring‑up stops being guesswork and becomes a repeatable skill you can apply to every new design.

Zephyr RTOS: The Modern Embedded Engineer’s Guide

Darshan Rathod — Wed, 06 Aug 2025 06:21:44 +0000

Why Care About RTOS in Embedded Development?
If you’re like me—working on everything from sensor nodes and wearables to future-ready IoT products—you already know how crucial real-time operating systems are. They turn bare-metal hardware into manageable, upgradeable products. But with so many RTOS choices, where do you start? Today, I’ll share why Zephyr RTOS is one of the most exciting projects in the embedded world and how it shapes up against the classic FreeRTOS.

What Sets Zephyr RTOS Apart?
Zephyr RTOS is more than just another open-source RTOS. With robust backing from the Linux Foundation, it’s evolved to meet the reality of today’s connected devices: modular, scalable, and security-focused, without bogging you down in legacy hurdles.

Where Is Zephyr Used?

Wearable tech (think smart watches, fitness bands)
IoT nodes and home automation
Industrial gateways
Basically, any device that needs to grow, update, or be trusted with sensitive data

Deep-Dive: Zephyr’s Core Features Every Developer Should Know
1. Modularity and Scalability
You only include what you need. Zephyr uses Kconfig (yes, like the Linux kernel) and device trees so you can easily add or strip out features at build time. That means a small memory footprint for simple projects or expansion room for complex ones.

2. Multi-architecture Support
Support isn’t an afterthought! Zephyr runs on ARM, x86, RISC-V, and even more exotic architectures, so your codebase can follow your hardware ambitions without huge rewrites.

3. Real-Time Scheduling
Under the hood, Zephyr delivers deterministic scheduling and priority-based preemptive threads. Translation: mission-critical tasks won’t get skipped or delayed.

4. Rich Protocol Stacks & Driver Ecosystem
Bluetooth LE out of the box? Check. TCP/IP, LoRa, 802.15.4, and more? All there—plus a unified device driver model, so you spend less time integrating and more time building.

5. Security First
Zephyr takes secure coding seriously: routine code audits, best-in-class cryptography options, memory protection, and that coveted OpenSSF Gold Badge.

6. Unified, Modern Build System
Gone are the days of assembler-specific Makefiles. Zephyr uses CMake under the hood with the ‘west’ meta-tool, making it easy to reproduce builds and manage dependencies for professional-grade projects.

7. Advanced Power Management
Need battery savings on a wearable or IoT node? Zephyr handles deep sleep, peripheral power gating, and dynamic clocking to help maximize uptime between charges.

Zephyr vs. FreeRTOS: How Do They Stack Up?
Let’s be honest—FreeRTOS remains wildly popular for a reason. Here’s a side-by-side look to help you choose the right tool for your job:

When Should You Use FreeRTOS?

Your project is simple, single-purpose, or MVP grade.
You want minimal complexity, with just enough RTOS features to get the job done.
Fast prototyping on ultra-cheap hardware matters most.
AWS IoT integration is a must-have, and reduced setup time trumps future expansion.

When Should You Use Zephyr RTOS?

You need scalability for evolving requirements or multiple product lines.
Security, system stability, or compliance is non-negotiable (think medical, industrial, or automotive devices).
Your project will benefit from built-in protocols/stacks and modern power management.
Multiple architectures/hardware must be supported—without massive code refactors.
You can invest upfront for longer-term maintainability and ecosystem advantages.

Final Thoughts
If your project demands advanced features, future-proofing, full-stack integration, and trusted community support, Zephyr RTOS is the highway to professional embedded development. But don’t ditch FreeRTOS for small projects—its minimal approach is still a winner when resources or time-to-market are tight.

Want to know more?
Here is the link for your reference:
https://docs.zephyrproject.org/latest/develop/getting_started/index.html

Board Bring-Up: A Developer's Guide to Flashing Android 15 on the NXP i.MX 8M Plus EVKB

Darshan Rathod — Mon, 07 Jul 2025 12:11:47 +0000

The NXP i.MX 8M Plus system-on-chip (SoC) stands as a powerhouse for the embedded world, integrating a dual or quad-core Arm® Cortex®-A53 processor with a Neural Processing Unit (NPU) operating at up to 2.3 TOPS. This makes its evaluation kit (EVKB) an ideal platform for developing cutting-edge applications in machine learning, industrial automation, and advanced multimedia.

This guide provides a comprehensive, step-by-step walkthrough for bringing up the i.MX 8M Plus EVKB by flashing the latest Android 15 image using the SD card method on a Linux host system.

Prerequisites: What You'll Need

Before diving in, ensure your workspace is equipped with the necessary hardware and software.

Software:

The official NXP Android 15 Board Support Package (BSP). For this guide, we are using

imx-android-15.0.0_1.2.0.tar.gz

Step 1: Preparing the Host Environment and SD Card

Proper preparation is key to a smooth flashing process. This involves extracting the necessary tools from the BSP and correctly identifying your storage medium.

Extract the BSP Archive: On your Linux host PC, decompress the downloaded NXP Android image archive. This will create a directory containing the bootloader, system images, and essential flashing scripts.

tar -xvf imx-android-15.0.0_1.2.0.tar.gz

Identify the SD Card: Insert the microSD card into your host machine. To prevent catastrophic data loss, you must correctly identify its device name. Use the lsblk command to list block devices before and after insertion. Your SD card will appear as a new device, such as /dev/sdX.

Critical Warning: Double-check the device name. Writing to the wrong device, like /dev/sda, could erase your host operating system.

Unmount the SD Card: Linux systems often auto-mount removable media. Before you can write to the raw device, you must unmount any of its partitions.

# Replace /dev/sdX1 with your card's partition(s) sudo umount /dev/sdX1

Step 2: Flashing Android Using the NXP Provisioning Script

While manual flashing with tools like dd is possible, Android's multi-partition layout (boot, system, vendor, userdata, etc.) makes it complex. The most reliable method is to use the dedicated script provided within the NXP BSP, which handles partitioning and image placement automatically.

Navigate to the Script Location: The provisioning script, imx-sdcard-partition.sh, is typically located within the extracted BSP directory.

Execute the Script: Run the script with sudo privileges, specifying the SoC family (imx8mp) and the SD card device name. For a 32 GB card, using the -c 28 flag ensures the partition table is correctly sized.

sudo ./imx_android_setup.sh -f imx8mp /dev/sdX -c 28

The script will now perform the following actions:

Create a GUID Partition Table (GPT) on the SD card.
Format the necessary partitions with appropriate filesystems.
Copy all the required image files from your working directory to their corresponding partitions on the card.
This process will take several minutes to complete.

Step 3: Configuring the EVKB and Booting Up

With a freshly flashed SD card, the final step is to configure the EVKB hardware to boot from it.

Set the Boot Mode Switches: Locate the boot mode DIP switch on your EVKB (often labeled SW7 or SW4). You must configure these switches to select the "SD boot" or "EXT" boot source. The exact configuration can be found in the official user manual or Quick Start Guide for your specific board revision.
For i.MX 8 PLUS EVKB set switches to (0011)

Insert the SD Card and Power On: Safely eject the microSD card from your host PC and insert it into the SD card slot on the EVKB. Connect the power supply.

Verify the Boot Process: The board will power on and begin the boot sequence. You can monitor the process in two ways:

HDMI Display: Connect a monitor to see the Android boot animation followed by the lock screen.

Serial Console: Connect the USB-C debug port to your host PC and use a terminal emulator (like minicom or screen) to view the detailed boot logs from the kernel.

Future Scope:

From here, you can begin your application development, explore the capabilities of the NPU, or delve deeper into customizing the Android BSP to fit your project's specific needs. This foundational skill unlocks the full potential of this powerful embedded platform.

Linux Kernel Source Tree Explained : Everything You Need to Know

Darshan Rathod — Mon, 14 Apr 2025 09:02:59 +0000

Introduction

The Linux kernel is the core component of the Linux operating system, responsible for managing system resources, hardware interaction, and core system services. Understanding the layout of the Linux kernel source tree is essential for developers who want to explore kernel internals, develop modules, or contribute to kernel development.

In this blog post, we will explore the structure of the Linux kernel source code, providing an overview of the key directories and their functions. This will serve as a foundational guide for anyone beginning their journey into Linux kernel development.

Overview of the Source Tree

When you download and extract the Linux kernel source code (typically from kernel.org), you will find a set of directories and files in the root directory. Each component of the kernel is organized logically to facilitate ease of development and maintenance.

arch/

This directory contains architecture-specific code. Each supported architecture has its own subdirectory (e.g., x86/, arm/, riscv/). These directories include boot code, memory layout definitions, and syscall implementations tailored for each hardware architecture.

block/

This directory includes the block layer code, which manages block devices such as hard drives and solid-state drives. It contains I/O schedulers and general block device infrastructure.

drivers/

This is one of the largest directories in the kernel source tree. It contains drivers for various hardware devices, such as USB, audio, graphics, and network interfaces. The subdirectories within drivers/ are organized by hardware type (e.g., usb/, net/, gpu/, char/).

fs/

The fs/ directory contains implementations of file systems, including EXT4, XFS, Btrfs, and others. It also includes the Virtual File System (VFS) layer, which provides an abstraction layer for file system operations.

include/

This directory holds header files used throughout the kernel. It includes subdirectories such as:

linux/: General kernel headers.

asm-generic/: Generic architecture headers.

uapi/: User-space API headers.

init/

Contains the kernel initialization code. This includes the routines that are executed during the boot process, including the start_kernel() function.

ipc/

This directory manages inter-process communication mechanisms such as semaphores, message queues, and shared memory.

kernel/

This directory includes core kernel components such as the scheduler, timekeeping, system calls, and process management.

lib/

Contains utility functions and common libraries used across the kernel, including string handling, compression, and checksums.

mm/

The memory management subsystem resides here. It includes code for handling paging, virtual memory, slab/slub allocators, and memory mapping.

net/

Houses the networking stack, including support for protocols like TCP, UDP, and sockets. It also includes infrastructure for firewall and routing functionality.

scripts/

Contains build scripts and utilities used during kernel compilation. These scripts help automate the configuration and generation of source files.

security/

Includes the Linux security modules framework, along with implementations like SELinux, AppArmor, and other access control mechanisms.

sound/

This directory contains sound subsystem drivers and core audio frameworks, including ALSA (Advanced Linux Sound Architecture).

tools/

Provides user-space tools for interacting with and analyzing kernel behavior, including perf, bpf, and selftests.

usr/

This directory is used to generate the initial RAM filesystem (initramfs) that is embedded into the kernel image.

Documentation/

Contains textual documentation, design guidelines, subsystem overviews, and best practices. It is an excellent resource for both new and experienced kernel developers.

MAINTAINERS

A text file listing the maintainers for each subsystem and component in the kernel. This is useful for contributing code and seeking guidance.

Makefile and Kconfig

These files form the kernel's build and configuration system. Makefile defines build rules, while Kconfigfiles define configuration options that can be selected using tools like make menuconfig

Navigating the Source Code

To explore the kernel source code effectively, developers can use tools such as:

cscope or ctags: For code navigation.

git grep: For fast source code searching.

elixir.bootlin.com: A web-based Linux source browser.

These tools help in understanding code dependencies, function calls, and system behavior.

Conclusion

Understanding the structure of the Linux kernel source tree is a vital first step for anyone interested in kernel development. By familiarizing yourself with the purpose and content of each directory, you can navigate the kernel codebase more efficiently and confidently begin experimenting with or contributing to one of the most important open-source projects in the world.

In future posts, we will explore topics such as compiling the Linux kernel, writing kernel modules, and debugging techniques.

Linux Kernel Explained: Everything You Need to Know

Darshan Rathod — Wed, 19 Mar 2025 16:37:10 +0000

Introduction

The Linux kernel is the foundational component of the Linux operating system, serving as an intermediary between user applications and the underlying hardware. As a monolithic and open-source kernel, it plays a critical role in system resource management, inter-process communication, and overall system stability. This article provides an in-depth exploration of the Linux kernel, detailing its architecture, operational mechanisms, and the reasons behind its widespread adoption across diverse technological landscapes.

What is the Linux kernel?

The Linux kernel is a sophisticated, modular, and extensible core that governs hardware-software interactions. Initially developed by Linus Torvalds in 1991, the kernel has undergone extensive refinement through collaborative contributions from a vast global community. It serves as the backbone of Linux-based operating systems, executing essential functions such as process scheduling, memory allocation, device management, and enforcing security policies.

Architectural Overview

The Linux kernel is designed with a monolithic architecture, incorporating dynamically loadable modules to enhance flexibility. The following core components constitute its architecture:

Process Scheduler: Manages the execution of multiple processes, ensuring efficient CPU time allocation through scheduling algorithms such as Completely Fair Scheduler (CFS) and real-time scheduling policies.

Memory Management Unit (MMU): Oversees physical and virtual memory allocation, employing mechanisms such as paging, demand paging, and swapping to optimize memory utilization.

Virtual File System (VFS): Provides an abstraction layer that enables the kernel to support multiple file systems (e.g., ext4, XFS, Btrfs) while maintaining a uniform interface for file operations.

Device drivers: Act as an interface between hardware components and the operating system, allowing seamless communication between software applications and peripherals such as storage devices, input devices, and network adapters.

Networking Stack: Implements a suite of network protocols, including TCP/IP, UDP, and SCTP, facilitating reliable data transmission and interconnectivity across devices.

Security Module: Enforces access control policies, permissions, and security frameworks such as SELinux (Security-Enhanced Linux) to prevent unauthorized access and mitigate vulnerabilities.

Operational Mechanisms

The Linux kernel operates through well-defined mechanisms that enable efficient resource management and system performance. Key functionalities include:

Process Management: Employs techniques such as process forking, inter-process communication (IPC), and context switching to manage concurrent execution of tasks.

Memory Management: Utilizes sophisticated memory allocation strategies, including slab allocation, kernel paging, and memory-mapped files, to optimize system performance.

Interrupt Handling and Scheduling: Implements interrupt request (IRQ) handling to manage asynchronous events and real-time responsiveness.

Kernel Space vs. User Space: Ensures process isolation by executing core functionalities in kernel space while user applications operate in user space, minimizing security risks.

Concurrency and Synchronization: Implements synchronization primitives such as mutexes, spinlocks, and semaphores to ensure data consistency in multi-threaded environments.

Why is the Linux kernel ubiquitous?

The Linux kernel’s pervasiveness across diverse domains can be attributed to the following factors:

Open-Source and Customizability Its open-source nature allows developers to modify, optimize, and tailor the kernel for specific use cases, from embedded systems to enterprise solutions.

Stability and Reliability: The kernel is known for its robustness, making it an ideal choice for critical applications such as cloud computing, high-performance computing (HPC), and industrial automation.

Security and Access Control: Regular updates and security patches, coupled with advanced security modules, ensure a highly secure computing environment.

Performance Optimization: The kernel's resource management algorithms enhance system performance even in constrained hardware environments.

Scalability and Portability: It supports multiple architectures, including x86, ARM, RISC-V, and PowerPC, enabling deployment on devices ranging from microcontrollers to supercomputers.

Extensive Ecosystem and Community Support: A thriving developer ecosystem continuously enhances the kernel's capabilities, ensuring long-term sustainability and innovation.

Conclusion

The Linux kernel stands as a cornerstone of modern computing, offering unparalleled stability, security, and performance. Its modular architecture, extensive hardware support, and adaptability make it an essential component in a wide range of applications, from mobile devices and IoT systems to enterprise servers and cloud infrastructure.
As technology continues to evolve, the Linux kernel remains at the forefront of innovation, powering mission-critical systems worldwide.

Linux File System Explained: Everything You Need to Know

Darshan Rathod — Mon, 10 Mar 2025 10:55:54 +0000

Linux is a robust and versatile operating system that manages data through a well-organized file system. Gaining a solid understanding of the Linux file system is essential for users at all levels, as it enhances navigation, streamlines system administration, and aids in troubleshooting. This guide delves into the Linux file system, covering its structure, core directories, and fundamental file management practices.

What is the Linux File System?

The Linux file system follows a hierarchical directory structure where everything—directories, devices, and even hardware components—is treated as a file. Unlike Windows, which organizes storage using drive letters like C: and D:, Linux operates under a unified structure with a single root directory (/) that encompasses all files and directories.

Linux File System Hierarchy

The Linux file system follows the Filesystem Hierarchy Standard (FHS), which defines a consistent structure for directories and files. Below is an overview of essential directories with examples:

1. / (Root Directory)

The top-level directory from which all other directories branch out.

Only the root user has full access to modify critical system files.

Example:

ls /

Lists all top-level directories.

2. /bin (Binary Executables)

Contains essential system binaries (commands) like ls, cp, mv, rm, and cat.

Example:

ls /bin

Lists all essential system binaries.

3. /boot (Boot Loader Files)

Stores files needed for booting the system, including the Linux kernel (vmlinuz), bootloader configuration, and initial RAM disk (initrd).

Example:

ls /boot

Displays all boot-related files.

4. /dev (Device Files)

Contains files representing hardware devices (e.g., /dev/sda for the first hard disk, /dev/tty for terminals).

Example:

ls /dev | grep sda

Lists available storage devices.

5. /etc (Configuration Files)

Stores system-wide configuration files and scripts.

Example:

cat /etc/passwd

Displays system user account details.

6. /home (User Home Directories)

Contains personal directories for users (e.g., /home/user1, /home/user2).

Example:

ls /home

Lists all user directories.

7. /lib & /lib64 (Shared Libraries)

Stores essential shared libraries required by system programs.

Example:

ls /lib | grep libc

Lists shared C library files.

8. /media & /mnt (Mount Points)

/media: Used for mounting external devices like USB drives and CDs.

/mnt: Temporary mount point for manual mounting of filesystems.

Example:

mount /dev/sdb1 /mnt
ls /mnt

This mounts an external drive and lists its contents.

9. /opt (Optional Software)

Contains software installed by third-party vendors.

Example:

ls /opt

Lists installed optional software.

10. /proc (Process Information)

Virtual filesystem that provides information about running processes and system resources.

Example:

cat /proc/cpuinfo

Displays CPU details.

11. /root (Root User’s Home Directory)

Home directory for the root user.

Example:

ls /root

Lists files in the root user's home directory.

12. /run (Runtime Data)

Stores volatile runtime information like process IDs.

Example:

ls /run

Lists runtime data files.

13. /sbin (System Binaries)

Contains essential system administration commands.

Example:

ls /sbin

Lists administrative commands.

14. /srv (Service Data)

Stores data related to services like web servers (/srv/www).

Example:

ls /srv

Lists stored service data.

15. /sys (System Information)

Virtual filesystem providing real-time access to kernel and hardware information.

Example:

ls /sys

Displays system-related files.

16. /tmp (Temporary Files)

Used for storing temporary files.

Example:

ls /tmp

Lists temporary files.

17. /usr (User Binaries and Libraries)

Contains user applications, libraries, documentation, and source code.

Example:

ls /usr/bin

Lists user command binaries.

18. /var (Variable Data)

Stores variable files like logs and caches.

Example:

ls /var/log

Lists system logs.

File Management in Linux

Understanding file management is essential for effective use of the Linux file system.

File Types in Linux

Regular Files (-************************): Text, binary, and executable files.
Directories (d************************): Containers that hold files.
Symbolic Links (l************************): Pointers to other files.
Special Files:

Character devices (c): /dev/tty

Block devices (b): /dev/sda

Named pipes (p), sockets (s)

Important File Operations with Examples

Viewing Files:

cat filename
less filename

Copying Files:

cp source.txt destination.txt

Moving/Renaming Files:

mv oldname.txt newname.txt

Deleting Files:

rm filename

Changing File Permissions:

chmod 755 script.sh

Changing File Ownership:

chown user:group filename

Creating a Symbolic Link:

ln -s /path/to/file linkname

Finding Files:

find / -name "file.txt"

Checking Disk Usage:

df -h

Conclusion

The Linux file system is well-organized and follows a standardized hierarchy that makes file management efficient. By understanding the structure, directories, and file handling commands, users can navigate and manage their Linux systems effectively. Whether you are a beginner or an intermediate user, mastering the Linux file system is a crucial step in your Linux journey.

[Boost]

Darshan Rathod — Thu, 06 Mar 2025 08:48:00 +0000

Object Detection with ESP32-AI Thinker and Edge Impulse

Darshan Rathod ・ Mar 6

#esp32 #edgeimpulse

Object Detection with ESP32-AI Thinker and Edge Impulse

Darshan Rathod — Thu, 06 Mar 2025 06:53:09 +0000

In this blog, we will explore how to leverage the ESP32-AI Thinker module with Edge Impulse to create an intelligent object detection system. We will walk through the entire process—from capturing images using an ESP32 web server, training a model using Edge Impulse, deploying the model as an Arduino library, and running real-time object detection on the ESP32 module.

This guide is perfect for developers, IoT enthusiasts, and makers who want to bring AI-powered vision capabilities to embedded systems.

Prerequisites

Hardware Requirements:

ESP32-AI Thinker module (ESP32-CAM)
USB-TTL module (for flashing firmware)
Jumper wires (for connections)
Computer (for programming and training)

Software Requirements:

Arduino IDE (with ESP32 board support installed)
Edge Impulse Studio (free account required)
Eloquent Web Server Example for ESP32 (to capture images)

Step 1: Setting Up an ESP32 Web Server for Data Collection

To train a machine learning model effectively, we need a high-quality dataset with multiple images of the target object under various lighting conditions and angles.

Why Use a Web Server?

Instead of manually transferring images, we will create a local web server on the ESP32 module. This will allow us to capture images directly from a browser and store them on a local machine for dataset creation.

Implementation:

Set up an ESP32 Web Server using an eloquent example from the ESP32-CAM library.
Connect to the ESP32’s WiFi hotspot and access the camera feed via a browser.
Capture multiple images by clicking a button on the web interface.
Download the images and store them on your PC for further processing.

Ensure you capture images with different backgrounds, lighting conditions, and orientations to improve model accuracy.

Step 2: Upload the Dataset to Edge Impulse for Model Training

Once we have collected a diverse dataset, we will upload it to Edge Impulse for processing.

Steps:

Sign up/Login to Edge Impulse Studio.
Create a new project and select ESP32-AI Thinker as the target device.
Upload the dataset (captured images) to Edge Impulse.
Label the images appropriately (e.g., "Object Detected", "No Object").
Train the model and benchmark its performance.

Edge Impulse will optimize the dataset, extract features, and train a model for real-time object detection.

Step 3: Deploy the Trained Model to ESP32 (Arduino Library)

Once the model is trained and validated, we need to deploy it to the ESP32 module. Edge Impulse provides a precompiled Arduino library that can be directly used in your ESP32 sketch.

Deployment Process:

Go to the Deployment section in Edge Impulse.
Select Arduino Library as the export format.
Download the .zip file containing the trained model.
Extract and add the library to Arduino IDE.
Include the Edge Impulse library in your ESP32 sketch.

Step 4: Flash the Model onto ESP32 and Test Object Detection

Time to See AI in Action!

Open Arduino IDE and select the ESP32-CAM board.
Modify the ESP32 sketch to initialize the camera and run inference using the Edge Impulse model.
Compile and upload the firmware to the ESP32 module.
Open the Serial Monitor and check the real-time object detection output.

The ESP32 will now process live images, detect objects, and display accuracy levels in the serial monitor.

Conclusion & Future Enhancements

By following this workflow, we have successfully implemented AI-powered object detection on the ESP32-AI Thinker module using Edge Impulse. This method enables embedded systems to leverage computer vision for applications such as:

Smart home automation
✅ Security & surveillance
✅ Robotics & AI-powered assistants
✅ Industrial quality control