嵌入式底层开发概念汇总

参考自 channel

What is a BSP?

A “Board” is a particular configuration of hardware. This may be one physical circuit board, or could be many circuit boards connected together to form one “logical” board.

A “Board Support Package” (BSP) is a set of software that enables a particular operating system to run on a logical board. The operating system features able to be used with the board is directly proportional to the enabling code provided in the BSP. Here we discuss BSPs which enable Windows CE.

The most fundamental elements of a hardware platform are the Central Processing Unit (CPU), the Random Access Memory (RAM), and the primary persistent storage (usually FLASH Read-Only Memory). A BSP typically has to support these three components at a minimum in order for the operating system to function.

Core bringup – before the BSP exists

During development of a BSP from scratch, a developer will typically work first with the CPU core and its bootstrap storage to get instructions to begin to execute. This is usually extremely low level work where a developer will use JTAG connectors and/or custom flash programmers to get code into a CPU’s bootstrap storage. A Silicon Vendor will almost always produce examples of this code to verify its product, but tweaking and extension may be necessary to get a CPU to function with a particular combination of RAM and FLASH.
Once there is a mechanism to iteratively update and expand the code in the bootstrap storage, software can be written to bring up the platform to a state where RAM chips and other board hardware can be powered and enabled. This software is typically called a “bootloader”.

Bootloader

The board bootloader is a required part of the BSP. Its responsibility is to bring the system to a known state and either put in place the operating system code, or start code that may already be in place. The operating system code is typically stored in on-board FLASH ROM (NAND or NOR type), and the mechanism used to put it there is very board-specific. Well-known options for doing this are via Trivial File Transfer Protocol (TFTP) over bare-bones Ethernet, simple USB serial, or by download from a memory card (MMC, SD, or CompactFLASH). Regardless of the mechanism used, data comprising the operating system is transported to the board’s persistent store so that it can be started.
A bootloader can have many functions other than installing the operating system code. A bootloader used during development can usually select between different hardware functions or select a download mechanism for the operating system code. Some bootloader provide capabilities to do unit tests of on-board hardware. However, functionality is limited and is usually separated in implementation both physically and logically from operating system code. Some bootloaders are so separate that they are operating-system agnostic and can download, install, and start any other code. The bootloader software is sometimes completely removed from a board after development is finished, and the code to load and/or start the OS can be placed in the IPL (see below).

OAL

The board OAL is a required part of the BSP. “OAL” stands for “OEM Adaptation Layer”. “OEM” stands for “Original Equipment Manufacturer”. This layer is a set of code which becomes part of the Operating System Core. The layer adapts the generic Windows CE kernel code for a CPU type (such as ARM or x86) to the specific CPU or System-On-Chip (SoC) used on a specific board. There are many examples of the code required to make up an OAL. Most often a Silicon Vendor will supply the basics for an OAL to allow the Operating System to function on their CPU/SoC. The differences come in with how the CPU/SoC is connected to the board – the BSP comprises these differences and the way any hardware is attached to the CPU.

Pieces of the OAL for a board include code to support timers, specify memory, clean/flush caches, and set and get the time. OALs are typically extended by an OEM to perform board-specific functions. Some OEMs have a class of boards that all use the same extensions. Those extensions become part of their BSP.

ULDR and IPL

For BSPs that are for Windows Mobile products, the ULDR and IPL are required parts of the BSP.
“ULDR” stands for “Update Loader”, and is part of the Image Update system. This system allows deployed devices to be updated with new software after they ship. The Update Loader reads a configuration stored in persistent memory and downloads and installs new versions of operating system or OEM files.
“IPL” stands for “Initial Program Loader”. This piece of code is launched by the bootloader or executed directly at startup if a bootloader has been removed from a board. The sole job of this program is to choose whether to execute the ULDR software, or load and execute the operating system that is currently on the device. If a user has downloaded new versions of operating system or OEM files, the IPL will be configured to launch the ULDR. Otherwise, it will load and launch the OS.

KITL

KITL is typically a required part of the BSP during development. “KITL” stands for “Kernel Independent Transport Layer”, and is a mechanism by which the OS kernel of Windows CE can communicate with desktop-side tools and debuggers. A KITL “transport” is a mechanism by which data is sent and received through the OAL to the kernel. KITL transports are not device drivers and do not use the same mechanisms as device drivers do. Some examples of KITL transports are Ethernet, Serial, and USB. Once a KITL connection to the desktop is established, a developer can debug certain parts of the OAL and device drivers using the Kernel Debugger.

Device Drivers

Some board drivers are required parts of the BSP. A device driver presents functionality on a board to higher-level user processes in a generic way. For example, a serial port on a board is exposed in a generic way so that a user program written to send and receive data on a serial port does not have to know any details of the underlying hardware in order to function. All it needs to know is the name of the serial port. The Device Driver takes care of the abstraction of a generic interface.
There are many classes of device drivers. Some device drivers support others, or rely on other device drivers to function, in a layered fashion. Some drivers can be loaded on demand while the operating system is running, and some must be loaded very early on when the OS is started and persist for the whole time the system is running.
The device drivers that are required for a particular board depend on the functionality available on the board and its intended use. Most normally to be useful a system needs a driver to access persistent storage. Windows Mobile BSPs require a radio (RIL) driver, a display driver, an input driver, and an audio driver.

Custom Applications

Custom applications are optional parts of a BSP. A custom application can range from a control panel applet to configure a board-specific function (like a colored backlight), to an application to enable extra performance on a peripheral (such as a graphics accelerator). These elements are sometimes necessary in order for a board to be fully functional, and when standard Windows CE elements cannot account for the hardware differences or extensions that are used.