Shulou(Shulou.com)06/01 Report--

This article shares with you the content of a sample analysis of the raspberry pie 3b + power-on startup process. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Recently, I have been playing with raspberry pie. I think the start-up process of this raspberry pie is a little interesting. So after collecting a lot of information, the individual also carried out some experiments and summaries. Let's take a look at a piece of raw material:

This is an in-detail account of the Raspberry Pi boot process collected from various sources, mainly from the official forums. First, you need to know the RPi does not boot up like a conventional desktop computer. The VideoCore a.k.a the Graphics processor actually boots before the ARM CPU! Anyway, before we get into the details here's a diagram of the RPi highlighting the Broadcom BCM2835 SoC.

The SoC (or System-on-Chip) contains the ARM CPU, the VideoCore Graphics Processor, ROM (Read-Only-Memory) chips, the SDRAM and so many other things. Basically, think of a SoC as your Motherboard and CPU compressed together into a single chip.

When you power on your Raspberry Pi, the first bits of code to run is stored in a ROM chip in the SoC and is built into the Pi during manufacture! This is the called the first-stage bootloader. The SoC is hardwired to run this code on startup on a small RISC Core (Reduced Instruction Set Computer). It is used to mount the FAT32 boot partition in your SDCard so that the second-stage bootloader can be accessed. So what is this' second-stage bootloader' stored in the SD Card? It's' bootcode.bin'. You might have seen this file if you had mounted the SD Card in Windows. Now here's something tricky. The first-stage bootloader has not yet initialized your ARM CPU (meaning CPU is in reset) or your RAM. So, the second-stage bootloader also has to run on the GPU. The bootloader.bin file is loaded into the 128K 4 way set associative L2 cache of the GPU and then executed. This enables the RAM and loads start.elf which is also in your SD Card. This is the third-stage bootloader and is also the most important. It is the firmware for the GPU, meaning it contains the settings or in our case, has instructions to load the settings from config.txt which is also in the SD Card. You can think of the config.txt as the 'BIOS settings' (as is mentioned in the forum). Some of the settings you can control are (thanks to dom):

Arm_freq: frequency of ARM in MHz. Default 700.

Gpu_freq: Sets core_freq, h364_freq, isp_freq, v3d_freq together.

Core_freq: frequency of GPU processor core in MHz. Default 250.

H364_freq: frequency of hardware video block in MHz. Default 250.

Isp_freq: frequency of image sensor pipeline block in MHz. Default 250.

V3d_freq: frequency of 3D block in MHz. Default 250.

Sdram_freq: frequency of SDRAM in MHz. Default 400.

The start.elf also splits the RAM between your GPU and the ARM CPU. The ARM only has access the to the address space left over by the GPU address space. For example, if the GPU was allocated addresses from 0x000F000-0x0000FFFF, the ARM has access to addresses from 0 × 00000000-0x0000EFFF. (These are not real address ranges. It's just for demonstration purposes). Now what's even funnier is that the ARM core perceives 0 × 00005001 as it's beginning address 0 × 00000000. In other words, if the ARM core requests the address 0 × 0000000, the actual address in RAM is 0 × 00005001. Edit: The physical addresses perceived by the ARM core is actually mapped to another address in the VideoCore (0xC0000000 and beyond) by the MMU (Memory Management Unit) of the VideoCore. The config.txt is loaded after the split is done so you cannot specify the splitting amounts in the config.txt. However, different .elf files having different splits exist in the SD Card. So, depending on your requirement, you can rename those files to start.elf and boot the Pi. (The forums mention of having this functionality in a dynamic fashion, but I don't know whether they have implemented it yet) In the Pi, the GPU is King!

Other than loading config.txt and splitting RAM, the start.elf also loads cmdline.txt if it exists. It contains the command line parameters for whatever kernel that is to be loaded. This brings us to the final stage of the boot process. The start.elf finally loads kernel.img which is the binary file containing the OS kernel (DUHQ?) And releases the reset on the CPU. The ARM CPU then executes whatever instructions in the kernel.img thereby loading the operating system.

After starting the operating system, the GPU code is not unloaded. In fact, start.elf is not just firmware for the GPU, It is a proprietary operating system called VideoCore OS. When the normal OS (Linux) requires an element not directly accessible to it, Linux communicates with VCOS using the mailbox messaging system.

Note: Special thanks to user dom in the official RPi forums and the community behind the official wiki.

This is the information shared by the great god Herman Hermitage.

Let me analyze this process according to my understanding:

When powering up the raspberry pie, the code saved in the ROM is first executed, which is set by the chip factory and is often referred to as first-stage bootloader. This code solidifies the hardware inside and can be considered part of the SoC hardware. This part of the code is usually solidified and cannot be modified or read.

The main job of first-stage bootloader is to load the bootloader (called second-stage bootloader) located in the first partition on the SD card, that is, to find a binary file called bootcode.bin in the root directory of the first FAT32 partition of the SD card. Well, at this time, the CPU is not actually started, and it is actually the GPU in the SOC encapsulation that performs this action. This is the very strange place! Generally speaking, we understand that CPU is responsible for generating data and then giving it to GPU to do the calculation, so why does GPU give priority to customers? But that's how raspberry pie is set! And GPU performance can outperform CPU. Then GPU reads the bootcode.bin into the 128KB-sized secondary cache (L2 Cache) and starts executing the bootcode.bin. This is phase two.

Of course, this is not over yet, followed by the implementation of the third phase. The main job of bootcode.bin is to initialize the ram and load the start.elf (also in the first partition of the SD card) into memory. Start.elf is third-stage bootloader. Then the third phase is over.

The function of the third phase of loading the running start.elf is to load the config.txt located in the SD card. This file can be understood as BISO, which records the configuration information in detail.

Arm_freq: frequency of ARM in MHz. Default 700.

Gpu_freq: Sets core_freq, h364_freq, isp_freq, v3d_freq together.

Core_freq: frequency of GPU processor core in MHz. Default 250.

H364_freq: frequency of hardware video block in MHz. Default 250.

Isp_freq: frequency of image sensor pipeline block in MHz. Default 250.

V3d_freq: frequency of 3D block in MHz. Default 250.

Sdram_freq: frequency of SDRAM in MHz. Default 400.

Start.elf divides the ram space into two parts: CPU access space and GPU access space. The SoC chip only accesses the memory area that belongs to the GPU address space. For example, the physical memory address space of the GPU is 0x000F000-0x0000FFFFJ CPU, the physical memory address space of the GPU is 0x00000000-0x0000EFFF, if the GPU accesses the 0x0000008, then the physical address it accesses is 0x000F008. In fact, the mmu part of the ARM processor maps the memory space of the GPU to the 0xC0000000 start. Config.txt is not loaded until the memory address space allocation is complete, so you cannot change the configuration of memory addresses in config.txt. However, you can configure multiple elf files to make start.elf and config.txt support multiple configuration spaces. Start.elf also loads cmdline.txt (if cmdline.txt exists) from the first partition of the SD card. This file holds the parameters for starting kernel (not necessarily the kernel of Linux). At this point, SoC has entered the final stage of boot. Start.efl loads kernel.img,ramdisk,dtb to the predetermined address of memory, and then sends a restart signal to cpu, so cpu can execute kernel code from the predetermined address of memory and enter the software-defined system startup process.

It is also interesting to analyze the start-up process of raspberry pie. Anyone who has played with embedded Linux knows that the general startup process is carried out in CPU:

The first phase: bootloader (solidified code, boot Uboot)

Phase 2: Uboot (initialize the necessary peripherals and boot up kernel)

Phase 3: kernel (initialize the peripheral and enter the file system rootfs)

However, the whole process of BCM2835 SoC is handled by GPU, and the startup process is:

The first phase: bootloader (solidifying code, loading bootcode.bin file in sd card)

The second phase: bootcode.bin (initialize ram and load the start.elf file in the SD card)

The third stage: start.elf (configure the address space of CPU and GPU, host frequency, and load the Linux kernel)

Special note: GPU

GPU (Graphics Processing Unit) is a graphics processing unit, which is generally used to accelerate image processing algorithms. It can perform complex operations and needs to be used with CPU. CPU is responsible for providing the data, passing it to the GPU calculation, and then collecting the results of the GPU calculation. GPU generally cannot execute code independently. But Broadcom has reached its fifth generation, called VideoCore IV. Is capable of code processing. As a result, I feel that sooner or later, GPU will replace CPU or the integration of the two, fully reflecting the value of the processor!

Thank you for reading! This is the end of the article on "sample analysis of raspberry pie 3b + power-up startup process". I hope the above content can be of some help to you, so that you can learn more knowledge. If you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.