Main support software package (bootloader part)

Main support software package (bootloader part)
Translated from: Embedded Linux system design and development

"By P. Raghavan

Translated by Liu Jianwen (http://blog.csdn.net/keminlau

)

Key: BSP Hal embedded Linux

Board support package)

A BSP or "board support package" is the set of software used to initialize the hardware devices on the board and implement the Board-speci sans C routines that can be used by the kernel and Device drivers alike.

BSP is thus a hardware construct action layer gluing hardware to the OS by hiding the details of the processor and the Board. the BSP hides the board-and CPU-speci limit C details from the rest of the OS, so portability of drivers limit SS multiple boards and CPUs becomes extremely easy. another term that is often used instead of BSP is the hardware specified action layer or the Hal.

Board support software package
Package refers to a program that initializes devices on the hardware Load board and encapsulates hardware-related details to provide high-level interfaces for the operating system. With BSP, the operating system (including hardware drivers) has a certain degree of independence.
Stand-alone, making porting between different hardware platforms easier. BSP has similar functions and roles with common Hal, but not exactly the same.

 

Kemin: BSP should be strictly divided into two parts: one part only involves hardware initialization, and the other part is encapsulation of underlying hardware functions. The reason for this is that the former is only related to the migration task and has nothing to do with the development of the Operating System (driver development). The latter is not related to the migration task, more is to build a [system-level application development framework

], This framework is actually a set of abstract interfaces. operating system developers can understand the abstract semantics of the group abstract interfaces, but these interfaces
With a deeper understanding of its implementation principles, it is more efficient for development. (Original: http://blog.csdn.net/keminlau/archive/2009/12/20/5045121.aspx)

BSP

1. the microprocessor support: Linux has wide support for all the leading processors in the embedded market such as MIPS, arm, and soon the PowerPC.

2. The Board-speci implements C routines: a typical Hal for the board hardware will include:

• A. bootloader support
• B. Memory Map support
• C. System timers
• D. Interrupt Controller support
• E. Real-time clock (RTC)
• F. Serial support (debug and console)
• G. Bus support (PCI/ISA)
• H. DMA support
• I. Power Management

Hal and BSP

For making the terminology clean, we refer to the Hal as the layer that combines the board-and the processor-speci implements C software and the BSP as the layer that has only the board-speci implements C code. so when we talk about the MIPs Hal it means the support for the MIPs processors and the boards built with MIPS processors. when we talk about a BSP we refer to the software that does not have the processor support software but just the additional software for supporting the board. the HAL can be understood as a superset of all supported BSPs and it additionally between des the processor-speci limit C software.

There are some differences between Hal and BSP definitions. The former covers the abstraction of the board and processors, and the latter refers to the main supporting software part of the board.

BSP (abstract interface) has no standard

As mentioned in chapter 2, neither the Linux Hal nor the BSP has any standard. Hence it is very DIF into cult to explain the Hal for multiple ubuntures.

Onboard components (taking Eureka as an example)

This chapter delves into the Linux BSP and porting issues for a mips-based architecture; for making things easier, we use a fi tious board Eureka that is MIPS-based having the following set of hardware components.

• A 32-bit MIPS Processor
• 8 MB of SDRAM
• 4 MB of cash Ash
• A 8259-based Programmable Interrupt Controller
• A pci bus with some devices such as Ethernet and a sound card connected to it
• A timer chip for generating the system heartbeat
• A serial port that can be used for console and remote debugging

Add the BSP part to the kernel Build Process

3.1 inserting BSP in kernel build procedure

The position and functions of BSP in the source code tree

The Linux Hal Source Code resides under ARCH/and include/<ASM-xxx> (xxx = processor name such as PowerPC, MIPS) directories. thus ARCH/PPC will contain the source files for the PPC-based board and include/ASM-PPC will contain the header files.

Under each processor directory, all boards based on that CPU are categorized again into subdirectories. The important directories under each subdirectory are:

• * Kernel: This directory contains the CPU-speci kernel C routines for initializing, IRQ set-up, interrupts, and traps routines.
• * Mm: contains the hardware-speci except c tlb set-up and exception-handling code.

For example, MIPS Hal has the two subdirectories ARCH/MIPS/kernel and arch/MIPS/mm that hold the above Code. along with these two directories there is a host of other subdirectories; these are the BSP directories that hold the board-speci using C code only. the user needs to create a subdirectory tree under the appropriate processor directory that contains the secrets les necessary for the BSP.

BSP is integrated into the [kernel build system] to facilitate component selection (kernel component selection), that is, Kernel configuration.

3.2 The Boot Loader Interface

Most of the reset Initialization is board-speci sans C and normally manufacturers of boards give an onboard prom that does the above. it is better to make use of the prom to load either a kernel image or an intermittent boot loader and thus save the developers from the job of programming the board. even if a prom is not available, it is better to separate the boot process to a boot loader than let the kernel Bootstrap itself. the following are the advantages with this approach.

System Boot is a complex process, and boot loader is a program highly related to hardware. Boot Loader has various forms of performance. It is optional Based on hardware configuration (removed or embedded Boot Code by the kernel ). Hardware vendors generally build a prom program with the onboard Board to implement system introduction (or partial implementation). This way, developers can avoid the need to develop boot programs and directly use the functional interfaces provided by the prom.

Why do we need boot loader?

A computer's central processor can only execute program code found in read-only memory (ROM) and random access memory (RAM ). modern operating systems and application program code and data are stored on Nonvolatile Data storage devices, such as hard disk drives, when a computer is first powered on, it does not have an operating system in ROM or RAM. the computer must initially execute a small program stored in ROM along with the bare minimum of data needed to access the nonvolatile devices from which the operating system programs and data are loaded into RAM.

 

Regardless of the form of the boot program, the system boot process independent of the operating system has the following advantages:

Other than Rom downloads, multiple methods of downloading the kernel such as serial (Kermit) or network (TFTP) can be implemented.

It provides protection against unsafe overwrites of the kernel image in case the kernel image is stored in wrong ash. assume that there was a power outage when a kernel image is upgraded; then the Board is in limbo. the safer way is to burn a boot loader into some protected sectors of each ash (normally called boot sectors) and leave them untouched so that there is a reute route always available.

First, Multiple kernel download (loaded to ram) policies; the kernel can be downloaded through the serial port or network;

Second, if the kernel is connected to the boot program, Kernel updates may easily discard hardware boards. However, kernel development, such as driver development, often occurs. Furthermore, the separation between the boot program and the program that is not of the nature of the kernel is reasonable and natural.

As a thumb rule Linux always assumes that it is executing from memory (some allow Linux to execute from Rom directly ;). boot loaders are independent pieces of software that need to be built independently of the Linux kernel. unless your board supports a prom, the boot loader does the initialization of the processor and the Board. hence the boot loader is highly board-and processor-speci using C.

Linux is a modern operating system. It assumes that it runs in the primary Memory RAM and uses virtual addresses (generally it cannot run directly in the ROM ). However, the boot loaders is usually very small and highly related to hardware, so it can be run directly in Rom. The functions of boot loaders can be divided into two parts: mandatory and optional. The optional parts can be customized to meet customer needs. The required functions include:

First, hardware initialization, including the processor, some important controllers (such as the primary memory controller) and some necessary peripherals (such as the flash memory for storing the kernel );

Second, load the kernel;

The boot loader functionalities can be divided into two: the mandatory ones and the optional ones. The optional Boot Loader functionalities are varied and depend on the customer usage. The mandatory Boot Loader functionalities are:

1. initializing the hardware: This includes des the processor, the essential controllers such as the memory controller, and the hardware devices necessary for loading the kernel such as your ash.

2. loading the kernel: the necessary software to download the kernel and copy it to the appropriate memory location.

The general steps of the boot process (generic steps) are as follows:

These are generic steps and there can be exceptions depending on the usage.

Note that the x86 processors normally are shipped with an onboard bios that helps with the basic power-on and loading a secondary Boot Loader for loading the operating system; hence the following set of steps is meant for the non-X86 processors such as MIPS and arm.

1. booting: Most boot loaders start from the specified ash. they do the initial processor initialization such as con resume guring the cache, setting up some basic registers, and verifying the onboard Ram. also they run the post routines to do validation of the hardware required for the boot procedure such as Validating Memory, mongoash, buses, and so on.

2. relocation: The Boot loaders relocate themselves to the ram. this is because Ram is faster than washash. also the relocation step may include decompression as the boot loaders can be kept in a compressed format to save costly storage space.

3. device initialization: Next the boot loader initializes the basic devices necessary for user interaction. this usually means setting up a console so that a UI is thrown for the user. it also initializes the devices necessary for picking up the kernel (and maybe the root privilege le system ). this may include the balance ash, network card, USB, and so on.

4. ui: Next the UI is thrown for the user to select the kernel image she wishes to download onto the target. there can be a deadline set for the user to enter her choice; in case of a timeout a default image can be downloaded.

5. image download: the kernel image is downloaded. in case the user has been given the choice to download a root role le system using the initrd mechanic, The initrd image too gets downloaded to memory.

Select boot loaders and criteria for the Embedded System)

There are currently freely available boot loaders for Linux; the system effect ECT can evaluate the existing ones before deciding to write a new Boot Loader from scratch. what are the criteria in choosing a boot loader for a given embedded platform?

• * Support for the embedded hardware
• * Licensing issues: these are discussed in detail in appendix B.
• * Storage footprint
• * Support for network booting
• * Support for mongoash booting
• * Console UI availability
• * Upgrade solutions availability

Boot Loader to kernel interface

One other important area of discussion surrounding the boot loaders is the boot loader-to-kernel interface, which comprises the following components.

Argument passing from the boot loader to Linux kernel:

The list of Linux kernel boot time arguments can be Veri encoded ed after the system is fully up by reading the proc into Le/proc/release line.

• *-Passing boot command arguments:
• *-Parsing of boot command arguments:

Some important boot parameters are:

• *-Root:
• *-Nfsroot:
• *-MEM:
• *-Debug:

Memory Map:

On Elastic platforms, especially the intel and PowerPC, boot loaders set up a memory map that can be picked up by the OS. This makes it easy to port the OS into SS multiple platforms.