(Linux) BSP Board level support package development understanding

1. Overview

Embedded system consists of hardware environment, embedded operating system and application, hardware environment is the hardware platform of operating system and application, it has different requirements depending on the application. The diversity of hardware platform is the main feature of embedded system, how to make the embedded operating system run effectively on different hardware platform is the key problem in the development of embedded system. The solution is to provide a hardware-related layer between the hardware platform and the operating system to shield the differences of these hardware, to provide a unified operating environment, the hardware-related layer is embedded system in the board-level support packages BSP (Board-supported package, referred to as BSP).

2. BSP and its role

BSP is the middle-tier software between hardware platform and operating system in embedded system, the main purpose is to shield the diversity of the underlying hardware, complete the direct operation to the hardware according to the requirements of the operating system, provide the operating system with the underlying hardware information and finally start the operating system. BSP has the characteristics of hardware correlation and operating system affinity, and its main functions include:

1. Initializing the underlying hardware to provide the underlying hardware information for the operating system;
2. Initialization of related hardware devices, mainly storage devices, communications equipment;
3. Detection system hardware is normal;
4. Load the operating system and start the system running.

3. Implementation of embedded Linux system BSP

BSP is relative to the operating system, different operating systems have different definitions of the BSP, it is required to implement the functions of the BSP is different. In the embedded Linux system, the primary is to initialize the underlying hardware and boot the operating system, and the BSP is hardware-related, but also to consider the initialization of the hardware operation.
At different stages of development, the work done by BSP differs, because the core and file systems are in different locations:
In the development and debugging phase, BSP should be able to communicate with the host and download the core from the host;
In the target product, the BSP should be able to load the core from the nonvolatile storage device.

3.1 Implementation of BSP during development and commissioning

Initial development due to the need of debugging system, BSP needs to download the core and file system from the host directly to the memory of the target board to run.
BSP to complete the following work:
1. Initialization and configuration of hardware
2. Initialization of communication devices
The BSP needs to communicate with the host, download the core and file system from the host, and therefore complete the initialization of the corresponding communication device. Communication with the host device is usually a network card and serial port.
Communication between the serial port to follow a certain protocol, including data format, synchronization mode, transmission rate, error correction methods. The initialization of the serial port is to set these protocols, so that the communication between the two sides in the same transmission mode. Initialization of the serial port on the target board is achieved by setting its register: set the serial port of the line control register to determine the format of the serial port to receive data, set the serial port baud rate generation register to determine the serial port to receive data rate. The communication protocol for setting up the serial port is: Eight data bits, one stop bit, no parity bit, 9600 baud rate. After the serial port is initialized, the data can be read from its data receiving register.
The initialization of the NIC is also implemented by setting its register, and the control register is set so that the network card is in receive mode. When using the network card to communicate with the host, the communication program on the host side must know the MAC address of the network card on the target board to send the data. Therefore, we need to set the MAC address of the network card to the specified value.
When reading data from the data receiving register of the network card, discard the non-data information (packet state, length, original address, destination address and type) in the packet.
The BSP receives the file from the host, so it must provide a program for the host to communicate with the BSP. Host side of the communication program can be used by the operating system to provide the system calls directly set the properties of the serial port, the host port communication protocol and the target Board serial Port communication protocol is consistent. The host-side program writes data to the data register of the target board serial port via a serial line connected to the target board. When using the network card, the original socket interface is used to write the network card, and the packet is sent to the data receiving cache register of the network card on the target board.
3. Receive core and file system from host, start core operation
When the system is power-up, the BSP executes from nonvolatile memory flash in 0 address, communicates with the program running on the host, reads data from the data register of the serial or network card, downloads the core and file system to the specified location in memory, and finally resets the program counter PC in the CPU to the starting address of the core in memory. To achieve core startup. However, the program does not write to the variable when it executes in Flash, and in order for the program to execute correctly, the BSP must relocate itself (that is, move itself) into memory, and set the stack pointer before entering the C-language function execution.
The pseudo code of its main implementation process is as follows:

    硬件(cup、内存等)初始化；    通信设备(网卡、串口)初始化；    将自己重定位到内存中；    设置系统的堆栈指针；    跳转到从串口读取核心和文件系统的函数；    从串口读取核心和文件系统的函数(void)    {        while(核心没读取完){            while(串口的接收数据寄存器为空)(等待)；            从串口的数据寄存器读取数据到内存中；            核心大小减去已读取的大小，确定核心是否读取完；            if(核心读取完){                -asm{mov pc，一核心在内存中的起始地址；}        }    }

3.2. Implementation of BSP in target product 3.2.1 BSP Independent implementation

The core and file systems are downloaded directly from the host into memory and are only available for the development debugging phase. The core and file systems in the target product are burned on non-volatile storage devices, so the BSP will load and start the core from these devices. At this point, the BSP does not need to communicate with the host and can be implemented separately in the product. When the BSP is implemented separately, it is possible to flexibly add a variety of functions to it as needed: detecting whether the memory can be read and written correctly before starting the core, and determining whether the hardware device is normal by judging the property register of the hardware such as network card, sound card and so on.
At this point, the BSP will complete the following work:

1. Initialize hardware and storage devices.
2. Test that the hardware device is normal.
3. Load the core into memory from the appropriate storage device and start the core.

The initialization and configuration of the hardware is the same as before, which mainly completes the initialization of CPU and memory. At this point, the BSP loads and starts the core from the storage device, so the storage device (typically flash or CF card) is initialized so that it can be properly addressed. BSP read the core code is independent of the specific operating system and file format, not from the file system layer to the core as a file read in, only from the hardware interface to achieve specific operations, the core from the storage device read into memory, and then the core of the beginning as a beginning of a program, so that the CPU into the core execution.
Nonvolatile memory Flash and memory-unified addressing, the same access and access to memory, you can use the register to the core directly from the FALSH read into memory. CF card is a peripheral to the memory, read operation is by controlling its register (data register, State and control register) to achieve, to its control register to publish the ATA command OA where to read, read the size of the data, etc.), to determine whether its status register is ready, In order to read data from its data registers into memory. After the core is read into memory from nonvolatile storage device, the program counter PC in CPU is set as the starting address of core in memory, which realizes the system start-up.
The corresponding pseudo code is as follows:

硬件(cup、内存等)初始化；存储设备(FLASH、CF卡)初始化；测试硬件设备是否正常；根据CF卡的属性寄存器判断CF卡是否存在；如果存在，跳转到从CF卡加载核心到内存的函数；如果不存在，直接将核心从FLASH加载到内存中；mov pc，一核心在内存中的起始地址；从CF卡加载核心到内存的函数(void){    while(核心没加载完){        向CF卡发布ATA命令，确定从CF卡的哪一块开始读，        读多少块        while(CF卡的状态没准备好){等待；}        从CF卡的数据寄存器读数据到内存中；        核心大小减去所读的块数乘以块大小；        if(核心加载完){            -asm{mow pc，=核心在内存中的起始地址；}    }}

3.2.2 Implementation of BSP in the core

BSP is easy to modify, and when the hardware changes, only the initialization code of the relevant hardware needs to be modified and recompiled. However, for embedded system storage media Flash, some file systems have byte alignment requirements for its partition, that is, the partition must be a specific size or a multiple of a specific size in order to have write access, if the BSP is written separately in a partition will create a waste of storage space. In essence, the BSP is part of the operating system and is tied to the operating system and can be implemented in the Linux core with the Development Board hardware fixed. When implementing BSP in the core, the BSP should be able to provide the necessary underlying hardware information to the core to enable the kernel to load and start from nonvolatile memory flash to memory.
There is no so-called boot sector in the storage media flash of the embedded system, and the corresponding embedded Linux kernel image zimage does not have the boot sector code BOOTSECT and the Auxiliary Code Setup on the PC, but is HEAD.O, MISC.O, HEAD-XSCALE.O and piggy.o several files in sequential connection. Among them, HEAD.O is made up of/arch/arm/boot/compressed/head. s compiled, is the core of the first execution of code, the main function is to extract the core with MISC.O and the CPU to go to the core after the decompression memory address execution. HEAD-XSCALE.O is architecture-related code. PIGGY.O is all the useful programs that remain in memory after the system starts [3], which is the code that HEAD.O to decompress. From the above analysis, the embedded Linux kernel can not be self-booting, to start the core must meet the following two conditions:

1. The system hardware has been properly initialized;
2. The core is in memory, and the program counters in the CPU are set to the starting address of the core in memory.

When implementing BSP in the core, the BSP must be at the front of the core code and will be in fact the head. s file, complete functions such as BIOS, bootsect, and setup on the PC. At the same time, ensure that the core is loaded into memory and must be able to jump to the same place in the core when there is no BSP. Once the core is recompiled, the BSP is implemented in the start code in the core image zimage. Burn the core to Flash 0 address, the system starts by executing the above code, the core is loaded into memory execution, to achieve the core self-booting.

(Linux) BSP Board level support package development understanding