Bootloader under WinCe system [reproduced] introduction
Windows CE.NET is an operating system that Microsoft introduced to the embedded field. It maximizes the rich features of the desktop version of Windows operating system, while also departing many new features to accommodate the actual situation and requirements in the embedded field. Whether it is commercial application demand, or people's multimedia consumer demand, it can be easily satisfied with the equipment of the CE operating system. The latest .NET version has greatly improved in real-time and stability, starting to be widely used by tablets, digital cameras, color screen mobile phones, PDA, etc. in real time and stability.
However, CE is not a universal installation system, in the world of embedded hardware equipment, a CE system usually only generates a hardware platform. Therefore, as the original equipment manufacturer, the most important job must be customized according to their hardware platform and application, the most important work is to prepare a board-level support package (BSP). In BSP, an important component is included - Bootloader. Creating an unmerifiable BootLoader is the first step in the development of WinCe systems and is also a key step. This article will combine development examples to show how to develop bootloaders suitable for their hardware.
1 Customize the basic knowledge of the CE operating system
Custom CE operating system is a Microsoft tool software: Platform Builder (PB). The tool can choose to build a CE system with different kernel functions according to the needs of the user. At the same time, it is also an integrated compilation environment that can compile C / C programs for all CPU target code supported by CE. The BSP and BootLoader programs mentioned earlier are compiled in this environment and integrate into the CE system. Once a CE system is successfully compiled, an image file called Nk.bin is obtained. Just download the file to the target platform (DEVICE), you can run CE.
2 bootloader
Bootloader is a separate program code that stores in a non-volatile memory medium of the target platform, such as ROM or FLASH. During the development of CE, it is mainly used to start hardware and download NK.bin on the target board and have a certain monitoring.
Figure 1 depicts the BSP basic structure of WinCE and the location where BootLoader is located.
In general, the functional requirements for bootloader are not strictly defined, and different occasions are very different. For example, on the hardware platform of the PC, because the hardware start is not through BootLoader (but through the BIOS), bootloader does not need to do anything on the initialization of CPU power; and on the author's development platform (MIPS32) Bootloader is the first program that is first executed, so it must include the power-on initializer. Typically, bootloader must contain the function of downloading the CE image file. In addition, managing monitoring hardware devices is usually necessary, because this can greatly facilitate engineering development. Since BootLoader involves basic hardware operations, such as CPU structure, instructions, etc., while also involving Ethernet download protocols (TFTP, of course, it is also possible to pass serial ports) and strategic image file formats. Therefore, if you implement it from zero, it will require a considerable process. Fortunately, Microsoft provides a BootLoader routine for a standard development board for each type of CPU, so normal approach is to find the closest to the hardware platform from these routines, and then from your own hardware Take a corresponding change in the platform. Some new evaluation boards may provide bootloader by third-party vendors. If the hardware platform is designed from such a substrate, then it is best to seek these vendors to get bootloader to reduce workload. The hardware platform used by the author is based on the MIPS32 architecture. The download port adopts the Ethernet port, and also has a serial port. The host is connected, and the platform is controlled by the hyper terminal. The platform is designed for a standard estimate of AMD, and Bootloader is transplanted with the BootLoader of this board.
3 Write the bootloader source program
As mentioned earlier, because the hardware is different, the BootLoader's function may have fewer features, and this author describes the process of developing Bootloader.
Figure 2 is the engineering process of the author Bootloader.
3.1 Starting section
First, you must implement the function of the primary and hardware. In the bootloader directory of the reference board, some .s file may be INIT.S or RESET.S, etc., such files are the first code that the CPU is powered. Since this is written in assembly language, it is close to the CPU relationship. The CPU of the general reference panel and the CPU of the development platform will be the same or the same architecture. The author uses the situation that belongs to the same CPU, so it can not change the definition and initialization process of the register. Then, for the analysis of platform configuration, including the allocation of platform storage, the working setting of the peripheral device, and the like. The difference here is very large. So you must set the value of the CPU register. This part of the work may require the help of the CPU provider.
It should be said that this part of the work is a major focus of bootloader, but it is impossible to make further detailed description because of the actual hardware very much.
3.2 Main control part
From this part, both C language is written.
In order to increase the control of the BootLoader to the platform, the general bootloader is designed to support command input, and receive the user's command through the serial port. In this mechanism, if the reference panel has loader support, you can add a command to have the utility value to complete some of the needs.
As can be seen from Figure 2, it is generally automatically loaded without using manual intervention, one of the necessary functions, and is basically supported by Loader in the debug phase without using one of the pre-intervention. Command is operated. Provide a sufficiently rich command to greatly simplify and fully test the development platform. As listed in Table 1, it is the command provided by the author Loader. Table 1
Command description
Help_______ lists all the commands supported and explained Eboot _____ CE download images from the development stage and load Write______ write data to a memory address Read______ display data memory address Jump______ a jump to the specified execution The program XMODEM___ receives the file TOY______ test platform CPU of the computer with XMODEM protocol to run flash____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Set the CPU's MAC address seti_______ set the platform's IP address
These commands involve various aspects of platform debugging, like memory detection, flash operation, file download, etc. With these commands, not only the partial test of the hardware platform, but also completed the most important feature of the BootLoader program as CE - Download the CE image.
3.3 Download Part
After compiling the image file generated by Platform Builder, then you need to download the file to the target board. If the hardware debug function can be replaced by other programs without placing the bootloader, the download image file is the necessary features of the bootloader.
The CE image file is usually called nk.bin, which is a Windows CE binary data format file, which not only contains valid program code, but also control information added in accordance with certain rules. Of course, you can also choose the code file generated. SRE format, but in the previous format, its code is much longer, and the download time required is longer. Here, we will download the .bin format file to explain the implementation of the download.
First look at the flowchart of the BootLoader Download section shown in Figure 3.
Typically, in the code comes with the Platform Builder, a basic function of completing the TFTP connection is included.
* Initialize TFTP connection: Finish with function ebootinittftp () and ebootinittftpd ().
* Registration parsing. The callback function of BIN format data: complete with eboottftpdserverregister ().
* Send a connection request: complete with ebootsendbootme ().
* Receive the packet issued by the host: complete with eboottftpreceiver ().
Here, there is a need to focus on two points.
1 For the function eboottftpreceiver () that receives the packet, it can only handle Ethernet packs that have been stored in memory, that is, the function of receiving data from the Ethernet controller must be done. Since this feature is closely related to hardware, it is not possible to use the PB's own function.
2 Function eBootTFTPDServerRegister () will register a callback function, and the general user can define this function yourself, which is used to complete the resolution and saving of BIN format data, and valid data to destination RAM. PB has a routine function that comes with it. In general, if the destination is RAM, the reference routine function can be directly referenced. But if the destination is Flash, don't store Flash (word-oriented units), first save the memory to import flash after downloading. Of course, this method must have enough memory. If there is not enough memory, it is also possible to cache some data, and after segmentation is written to Flash. 3.4 Support DOC
For WinCE operating systems, rich multimedia features are a major feature that makes it a nice choice in the current consumer electronics operating system. However, the problem with the system is that the system has greatly exceeded the quantity level of the traditional embedded system on hundreds of KB. In general, if the graphical interface and Chinese support are selected, the capacity will generally exceed 16MB. DOC (Disk O-N CHIP) provides a relatively inexpensive large storage capacity solution.
DOC is essentially a software-controlled NAND format Flash, providing support for WinCe through the software layer of TFFS.
Since the DOC cannot be directly accessed like memory, the process of loading WinCE is somewhat special, and a special code must be added to the bootloader to use DOC to store the WinCE image file.
To illustrate how to provide support for DOC in the loader file, first look at how to start CE using the DOC system, as shown in Figure 4.
As can be seen from Figure 4, when the DOC is used as a storage body, it is actually executed in the memory when started. In order to achieve this startup process, it must be involved in the reading and writing operations of the DOC. First get DOC Boot software development packages from M-System's website. In this development package, a series of DOC operation functions are provided. This development package is embedded in the BootLoader of the CE and then follows the steps of Figure 4 to call the corresponding read and write function to complete this process. For the description of the related functions in the development kit, the author is not specifically introduced, and the documentation can be referred to the development package.
4 BootLoader compile, links and downloads
The bootloader program can compile links through the integrated environment of PB, the control file is .bib file, below is a simple bootloader .bib file.
Memory
CLI 9FC00000 00050000 RamImage
Ram 80080000 00070000 RAM
Config
Compression = ON
SRE = ON
Romstart = 9fc00000
Romsize = 00020000
Romwidth = 32
Romoffet = 000000
Modules
Nk.exe $ (_ flatreleaseDir) .exe CLI
The Memory section defines the destination address of the generated image file, and the memory space that can be used by the program.
Config Some Compression compresses the target code; whether the SRE generates a target code for SRE; Romstart and Romsize, RomWidth, Romoffset define the starting address, size, width, and offset of the BootLoader physical media on the development platform.
The Modules section defines the files contained in Bootloader, usually only one file: CLI.exe.
During the compilation process, first use the command build-c to generate file CLI.exe, then generate the last image file CLI.SRE with the romimage cli.bib command.
For the download of the bootloader file; there are many ways: can be downloaded by the emulator; or you can download it directly to Flash directly. One thing to explain is that these methods may require different image formats. In the PB environment, it can be generated with .SRE format, pure binary format (for direct burning flash) and the same .bin format as the CE image. Conclusion
As can be seen from the CE's BootLoader Development Process, BootLoader has some debugging of the hardware in addition to the primary features of the downloading CE image and load image Of course, these features are not required, and different users may have their own definitions. But regardless of whether the function of Loader is simple or how complicated, it is a ring that is not skipped in the development CE system. In fact, due to the area of the Loader's interactive data, there is also a control effect on the CE startup process, and a window that is started by the PB control target board CE. It can be said that a fully functional loader, whether it is a debugging hardware or control and controlling the CE system, even becoming a product after the maintenance work, is a great help.
Writing bootloader is a first step in developing a WinCe system and a key step. Only Wince's BSP can be further developed until the success of the final system is further developed until the success of the last system.
This article is reproduced from: http://www.palmheart.net/modules.php? Op = modload & name = news & file = article & sim
