This article is suitable for: engineers who want to build a complete cognitive framework for embedded systems, developers preparing to delve from the application layer to the underlying layers, and those who wish to systematically understand the entire path from “bare-metal → kernel”.

In one sentence: After reading this article, you will advance from “fragmented knowledge” to “systematic understanding”.

📌 Why Understand the “Embedded Systems Panorama”?

Most embedded engineers have two confusions:

• Having learned many drivers, networking, and kernels, yet still feeling that the knowledge is fragmented.

• Being able to solve problems during projects but unable to abstract them into a system.

The truly skilled embedded talents share a common trait —they have a “panoramic view” in their minds, allowing them to analyze problems from a system-level perspective.

Today, I will guide you through the entire framework from the lowest level of bare-metal → Bootloader → Linux Kernel → Rootfs → System Services → Applications to form a thoroughly clear big picture.

The article is lengthy, but it is definitely worth saving and reading repeatedly.

🧭 01. Bare-metal: The Starting Point of Embedded Systems

What is Bare-metal?

No operating system, no scheduling, no virtual memory. Programs run directly on the MCU or SoC.

while(1) {
    LED_Toggle();
    delay();
}

This is a typical bare-metal example.

Core Capabilities of Bare-metal

• Start clock, PLL

• Configure GPIO / UART / SPI / I2C

• Configure interrupt controller (NVIC/GIC)

• Write registers, directly manipulate hardware

• Complete task scheduling through loops and interrupts

• Manage all resources yourself: CPU, memory, time slices

The essence of bare-metal is:you are the sole operator, and you do not need an OS to do anything for you.

Advantages of Bare-metal

• Low latency, strong real-time performance

• Minimal resource usage

• Safe and controllable

Disadvantages of Bare-metal

• Once system complexity increases, it becomes difficult to manage

• Not suitable for networking, file systems, multi-process, multi-tasking

• Difficult to extend functionality

Therefore, complex products almost all move towards Linux.

🧭 02. Bootloader: The First Step to Make Hardware “Run”

Embedded Linux cannot run directly like bare-metal. It must be set up by a Bootloader to “stage the environment”.

The classic two stages of Bootloader:

① First Stage: Initialize Hardware (Minimal System)

• Disable watchdog

• Enable DRAM

• Initialize clock

• Configure serial port (for log output)

• Load the second stage Bootloader

For example, in ARM SoCs:

• i.MX

• Allwinner

• Amlogic

• Rockchip all require DRAM initialization (this part is often vendor-specific code).

② Second Stage: Load and Start the Kernel

The most common tasks of U-Boot:

• Detect storage (EMMC/NAND/SPI Flash)

• Parse boot parameters

• Load Kernel + DTB

• Load initrd

• Jump to the Linux kernel entry point

In one sentence:Bootloader prepares the hardware, loads the kernel, and then hands over control to the kernel.

🧭 03. Linux Kernel: The Soul of Embedded Systems

This is the most complex part of the entire system.

Key Capabilities of the Linux Kernel

• Scheduling (Scheduler): Who runs first? Who occupies the CPU?

• Memory Management (MMU / Virtual Memory)

• Interrupt Management (IRQ / SoftIRQ)

• Device Driver Model

• Networking Subsystem (TCP/IP Protocol Stack)

• File System (VFS)

• Process and Thread Management

The power of Linux lies in —it abstracts hardware, manages scheduling, and handles complexity for us.

Impact of Linux on Embedded Development

• You no longer need to manage every interrupt yourself

• You also don’t need to write your own task scheduler

• A complete socket API can achieve full network communication

• A file system abstraction can access various storage media

90% of the complexity in embedded systems is managed by the kernel.

🧭 04. Device Tree: The Cornerstone of Embedded Linux

Embedded Linux is different from x86; there is no unified hardware platform. Therefore, Linux uses Device Tree to describe hardware.

Example:

uart3: serial@ff180000 {
    compatible = "rockchip,rk3399-uart";
    reg = <0x0 0xff180000 0x0 0x100>;
    interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
};

Device Tree solves:

• Portability of drivers between different SoCs

• Modular hardware description

• Running the same kernel on different hardware platforms

In one sentence:Device Tree is the “translator” between Linux and hardware.

🧭 05. RootFS: Making the System Truly a “System”

Having the Linux kernel is not enough.

You also need:

• Init system (systemd, busybox init)

• Shell

• Common commands (ls / ps / ifconfig / ip)

• Dynamic libraries

• Network services

• Applications

• Configuration files

These make up the Root Filesystem (RootFS).

A typical embedded system includes:

/bin
/sbin
/lib
/usr
/etc
/proc
/sys
/root

As long as RootFS + kernel exist, Linux can run completely.

🧭 06. System Services: The “Logical Layer” that Constitutes Product Behavior

Embedded products typically have:

• OTA upgrade services

• Network management services

• Daemon processes

• Log services

• IoT Agent

• Monitoring systems

Embedded engineers often interface with:

• Init scripts

• Systemd unit files

• File permissions

• Network configurations

• Daemon management

This is a key step from the bottom layer to “productization”.

🧭 07. Application Layer: The Value Users Can Truly Perceive

The ultimate goal of embedded systems is to run applications.

For example:

• Traffic control programs on routers

• Message processing programs on gateways (based on DPDK or kernel network stack)

• AI inference programs for smart hardware

• Video encoding applications for security cameras

• Control logic for industrial control devices

No matter how complex the system is, without applications, the product has no meaning.

🧭 08. Summary of the Panoramic View: A Complete Journey of Embedded Systems

Here is a complete panoramic framework for you: (can be used as the cover image for your article)

Hardware → Bare-metal → Bootloader → Linux Kernel
      ↓        ↓             ↓
  Peripheral Registers   DRAM Initialization    Scheduling/Memory/Drivers
      ↓        ↓             ↓
  Interrupt System    Image Loading       Networking/File System/Processes
--------------------------------------------
        RootFS → System Services → Applications

In one sentence:Embedded systems are a link from “silicon” to “software ecosystem”. Understanding it means you understand the entire lifeline of a system.

🧭 09. Growth Path for Embedded Engineers (Recommended to Save)

If you are an embedded engineer, this path is crucial:

1. Bare-metal → Read and write registers, familiarize with the essence of peripherals

2. Bootloader → Understand system boot logic

3. Kernel → Scheduling/Memory/Drivers/Networking Basics

4. RootFS → Understand how the system operates as a whole

5. System Services → Product architecture capabilities

6. Application Layer → Solve real business problems

Ultimately, become an engineer who can identify problems from a system-level perspective.

📌 Finally: Why Write This Article?

Because embedded engineers are too easily bound by “fragmented knowledge”.

You learn a bit about drivers, a bit about kernels, you have dealt with some performance issues… But without a systematic map, it is difficult to form true capability.

And today, you already have this map.

If You Want to Continue Reading This Series

The next article will be:

👉 “Understanding Bootloader in One Article: How U-Boot Boots Linux?”