Understanding Raspberry Pi System Files

This blog analyzes and summarizes the Raspberry Pi system files and their functions. The system used is Raspberry Pi OS with desktop.

•System: 64-bit

•Kernel version: 6.1

•Debian version: 12 (bookworm)

First, let’s take a look at the top-level directory /root which contains the following

files and folders

Understanding Raspberry Pi System Files

Among them,

1.LICENCE.broadcom: This is the license file from Broadcom, containing the licensing information related to Broadcom.

2.bcm2710-rpi-*.dtb and bcm2711-rpi-*.dtb: These are device tree binary files that describe the hardware component information on the Raspberry Pi board, such as processors, peripherals, etc. Different files correspond to different models of Raspberry Pi.

3.cmdline.txt: This file contains the command line parameters for kernel startup, such as the location of the root filesystem, startup options, etc.

4.config.txt: This is the configuration file for Raspberry Pi, used to configure parameters at system startup, such as resolution, memory allocation, etc.

5.fixup*.dat: These are firmware files that contain some firmware information used to fix and initialize hardware.

6.initramfs*: These files are images of the initial RAM filesystem (Initial RAM Filesystem), used to provide a temporary filesystem during the boot process.

7.overlays/: This directory contains a series of device tree overlay files that can configure hardware without modifying the main device tree.

8.start*.elf: This is one of the main components of the Raspberry Pi bootloader, responsible for loading the kernel and starting the tree.

9.System Volume Information/: This is a hidden system directory specific to Windows, which usually appears in FAT filesystems.

10.bootcode.bin: This is a key component of the Raspberry Pi bootloader, responsible for initializing hardware and loading the start*.elf file.

11.issue.txt: This is a text file that contains some information about the system.

Overall, these files make up the boot and configuration environment of the Raspberry Pi system, working together to ensure the system can boot and run correctly.

Now let’s take a closer look at the contents of cmdline.txt. cmdline.txt is a very important configuration file in the Raspberry Pi operating system that contains parameters passed to the kernel when booting. Specifically, the cmdline.txt file contains a command line parameter string that is passed to the Linux kernel during Raspberry Pi startup. These parameters can control the behavior of the kernel, such as setting the location of the root filesystem and specifying the startup mode.

In the Debian bookworm version system I used, the content of cmdline.txt is as follows:

console=serial0,115200 console=tty1 root=PARTUUID=f6a7c4bd-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot splash plymouth.ignore-serial-consoles

Let’s explain the contents:

1.console=serial0,115200: Set serial port 0 (i.e., UART interface) as the console, with a baud rate of 115200. This means communication and debugging can be done via the serial port.

2.console=tty1: Display system information on console 1 (i.e., graphical user interface).

3.root=PARTUUID=f6a7c4bd-02: Specify the location of the root filesystem, specified here by PARTUUID (partition unique identifier). This ensures that the root filesystem is mounted correctly.

4.rootfstype=ext4: Specify the type of the root filesystem, which is ext4 here.

5.fsck.repair=yes: Automatically attempt to repair if filesystem errors are detected at startup.

6.rootwait: Wait for the root filesystem to be ready before continuing booting.

7.quiet: Suppress a lot of boot information to make the boot process quieter.

8.init=/usr/lib/raspberrypi-sys-mods/firstboot: Specify the first initialization program to run. This is usually used to perform some system initialization tasks.

9.splash: Allow the display of a startup screen (if the system is configured for this feature).

10.plymouth.ignore-serial-consoles: Ignore serial consoles to avoid interference with the display of the startup screen.

Next, let’s look at the config.txt file. config.txt is an important configuration file in the Raspberry Pi system used to control hardware parameters and settings. It is located in the boot partition and is read and applied by the bootloader at startup.

Here are some common uses of the config.txt file:

1.Resolution and display settings: You can set the display resolution, refresh rate, and other display parameters by modifying config.txt.

2.Overclocking: You can configure the overclocking parameters for the Raspberry Pi’s CPU, GPU, and memory in config.txt to enhance performance.

3.Memory allocation: You can adjust the way memory is allocated in the system, such as resizing the GPU memory to meet specific needs.

4.Power management: You can control power management behavior through config.txt, such as disabling power supply via USB ports.

5.Device tree configuration: You can load specific device tree files in config.txt to configure hardware or enable external devices.

6.Boot options: You can set some options at boot time, such as disabling the splash screen, specifying the root filesystem, etc.

7.Overlays: You can load some hardware-specific features or functional modules through config.txt, such as GPIO expansion boards.

8.Audio settings: You can configure audio parameters, such as selecting audio output devices or configuring I2S audio.

Overall, config.txt provides a way to configure and customize the Raspberry Pi at a hardware level to meet specific applications or needs. However, care should be taken when editing this file, as incorrect configurations may lead to system boot issues or hardware damage.

In the Debian bookworm version system I used, the content of the config.txt file is as follows:

# For more options and information see# http://rptl.io/configtxt# Some settings may impact device functionality. See link above for details
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Additional overlays and parameters are documented
# /boot/firmware/overlays/README

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

# Run as fast as firmware / board allows
arm_boost=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]

Let’s explain the contents:

1.dtparam=audio=on: Enable audio functionality and load the snd_bcm2835 driver.

2.camera_auto_detect=1: Automatically load the relevant overlay when a camera is detected.

3.display_auto_detect=1: Automatically load the relevant overlay when a DSI (Display Serial Interface) display is detected.

4.auto_initramfs=1: Automatically load if initramfs files are found.

5.dtoverlay=vc4-kms-v3d: Enable the DRM VC4 V3D driver for graphics rendering.

6.max_framebuffers=2: Set the maximum number of framebuffers to 2.

7.disable_fw_kms_setup=1: Disable the firmware from creating an initial video= setting in cmdline.txt, using the kernel’s default instead.

8.arm_64bit=1: Enable 64-bit mode.

9.disable_overscan=1: Disable compensation for displays with overscan.

10.arm_boost=1: Run at maximum speed as allowed by firmware/board.

11.[cm4]: Marks that the following settings are specifically designed for Compute Module 4.

12.otg_mode=1: Enable host mode on the built-in XHCI USB controller of the 2711. The 2711 refers to the chip model of the Raspberry Pi. Specifically, it refers to the Broadcom BCM2711 SoC (System on Chip) used in the Raspberry Pi 4.

XHCI is a standard for USB controller interfaces, which stands for eXtensible Host Controller Interface, supporting superspeed transfers and low power consumption.

This interface is typically used for host devices, such as the motherboard’s USB controller connecting external USB devices (like mice, keyboards, hard drives, etc.). By adding otg_mode=1 to config.txt, the built-in USB 3.0 controller on the Raspberry Pi 4 is enabled and configured to support host mode, allowing you to connect other USB devices to the Raspberry Pi.

Now let’s look at the overlays folder. This directory contains a series of device tree overlay files that can configure hardware without modifying the main device tree.

The device tree (Device Tree) is a data structure that describes hardware platform information, abstracting the relationships and attributes between various hardware components in the system in a structured way. Device tree files usually have .dts or .dtb extensions.

In embedded systems, especially in some complex systems-on-chip (SoC), there are a lot of hardware components, such as processors, peripherals, buses, etc.

The connections and attribute relationships between these components can be very complex. The purpose of the device tree is to abstract this hardware information so that the kernel can correctly identify and configure the hardware at boot time.

The functions of the device tree include:

1.Hardware description: Device tree files describe the components of the hardware platform and their connection relationships. This includes processors, memory, peripherals, etc.

2.Abstraction layer: The device tree provides an abstraction layer for hardware descriptions, allowing the same kernel image to run on different hardware platforms.

3.Hot-plugging and dynamic configuration: The device tree allows the system to detect and configure hardware components at runtime, supporting hot-plugging and dynamic configuration.

4.System portability and development simplification: The device tree allows the kernel to be ported to different hardware platforms without modifying the kernel source code, simplifying development and porting work.

The device tree works as follows:

1.Write device tree source files (.dts): This is a script-like file that describes the structure, properties, and connection relationships of the hardware.

2.Compile device tree source files (.dts): Use the device tree compiler (dtc) to compile the device tree source file into a binary device tree file (.dtb).

3.Load the device tree at kernel boot: The kernel loads the device tree file at boot time to get hardware configuration information.

4.Kernel configures hardware based on the device tree: The kernel uses the information described in the device tree file to configure hardware components.

Overall, the device tree is a powerful tool for describing hardware configurations in embedded systems, allowing the kernel to run on different hardware platforms, thus improving the system’s portability and flexibility.

Now let’s look at a specific example of a device tree file.

Assuming we have a Raspberry Pi 3 Model B+, we will use a device tree file to describe its GPIO pins and an LED connected to one of the pins.

First, we write a device tree source file (.dts):

/dts-v1/;/plugin/;
/ {    compatible = "brcm,bcm2835";
    fragment@0 {        target = <&amp;gpio>;        __overlay__ {            led_pin: led_pin {                brcm,pins = <16>; // GPIO Pin Number                brcm,function = <1>; // 1 is OUTPUT mode            };        };    };};

This device tree source file describes the following information:

•It uses the brcm,bcm2835 compatibility identifier, indicating that this is a device tree file for the BCM2835 SoC.

•In the first fragment of the device tree (fragment@0), we will describe the properties of the GPIO controller (gpio).

•Inside the __overlay__ block, we define a node named led_pin, which represents the GPIO pin connected to an LED.

•brcm,pins = <16>; indicates that this LED is connected to GPIO pin 16.

•brcm,function = <1>; indicates that this pin will be configured as output mode.

Next, we use the device tree compiler (dtc) to compile this device tree source file into a binary device tree file (.dtbo):

dtc -@ -I dts -O dtb -o led-overlay.dtbo led-overlay.dts

This will generate a binary device tree file named led-overlay.dtbo.

Finally, load the generated device tree file into the /boot/overlays directory of the Raspberry Pi and add a line in the config.txt file to reference it:

dtoverlay=led-overlay

In this way, the device tree will be loaded by the kernel at the next boot and configure the corresponding GPIO pin to control the LED.

Now let’s look at the contents of the /root/overlays

folder

The overlays folder contains relatively more content. The /boot/overlays folder contains configuration files for loading device tree overlays (Device Tree Overlays). Device tree overlays allow for dynamic modification of the device tree at runtime to support different hardware configurations or features.

Here are some common device tree overlay files and their functions:

1.ads1015.dtbo: Supports ADS1015 class analog-to-digital converters.

2.ads1115.dtbo: Supports ADS1115 class analog-to-digital converters.

3.gpio-fan.dtbo: Supports fans connected to GPIO.

4.i2c-gpio.dtbo: Provides the functionality of simulating an I2C bus via GPIO.

5.spi0-0cs.dtbo, spi0-1cs.dtbo, spi0-2cs.dtbo: Different configurations for SPI0 bus, such as enabling/disabling chip select lines.

6.spi1-1cs.dtbo, spi1-2cs.dtbo, spi1-3cs.dtbo: Different configurations for SPI1 bus.

7.spi2-1cs.dtbo, spi2-2cs.dtbo, spi2-3cs.dtbo: Different configurations for SPI2 bus.

8.spi3-1cs.dtbo, spi3-2cs.dtbo, spi3-2cs-pi5.dtbo: Different configurations for SPI3 bus, including configurations for specific hardware (such as Pi 5).

9.spi4-1cs.dtbo, spi4-2cs.dtbo: Different configurations for SPI4 bus.

10.spi5-1cs.dtbo, spi5-1cs-pi5.dtbo, spi5-2cs.dtbo, spi5-2cs-pi5.dtbo: Different configurations for SPI5 bus, including configurations for specific hardware (such as Pi 5).

11.uart0.dtbo, uart0-pi5.dtbo, uart1.dtbo, uart1-pi5.dtbo, uart2.dtbo, uart2-pi5.dtbo, uart3.dtbo, uart3-pi5.dtbo, uart4.dtbo, uart4-pi5.dtbo, uart5.dtbo: Configurations for different UART (serial) interfaces.

12.w1-gpio.dtbo, w1-gpio-pullup.dtbo: Supports GPIO configurations for the 1-Wire bus.

13.imx*.dtbo are device tree overlay files for CMOS sensor models supported by the Raspberry Pi.

These files allow users to dynamically load or unload hardware modules based on actual needs, allowing the Raspberry Pi to adapt to various hardware configurations.

When loading device tree overlays, you can modify the /boot/config.txt file, adding a line similar to dtoverlay= to specify which overlay file to use.

Understanding Raspberry Pi System Files

Understanding Raspberry Pi System Files

↑Hot courses, limited time coupons!🎉Grab now↑

Understanding Raspberry Pi System Files

Understanding Raspberry Pi System Files

Understanding Raspberry Pi System FilesClick “Read Original” to view the course

Leave a Comment

Your email address will not be published. Required fields are marked *