Embedded system application development differs from PC development. Its development process involves both hardware and software, requiring comprehensive consideration of hardware platform design, operating system, and upper-layer application development. PC application development, on the other hand, is built on pre-defined hardware and operating system platforms; developers only need to call the system's provided interfaces and services to complete the corresponding functions. Due to application and cost constraints, embedded system hardware platforms must be customized to the application. There are typically multiple choices for the MPU, memory, and peripheral devices used, and the specialized software debugging techniques make the platform's boot design extremely complex. Therefore, for embedded system developers, it is necessary to deeply analyze the system boot process and effectively integrate hardware and software development. This means correctly performing low-level power-on initialization for different hardware platforms and software operating modes, thereby guiding the operating system to execute. The core of this problem lies in the study of the system's boot mode. The startup code of an embedded system generally consists of two parts: boot code and operating system execution environment initialization code. The boot code generally consists of two parts: the first part is board-level and chip-level initialization code, whose main function is to initialize the hardware's operating mode by setting registers, such as setting the clock and interrupt control registers, completing memory mapping, and initializing the MMU; the second part is the loader, whose function is to load or copy the images of the operating system and application programs from read-only memory to the system's RAM, and then jump to the corresponding code to continue execution. The initialization code of the operating system execution environment mainly consists of three parts: Hardware Abstraction Layer (HAL) code, device driver initialization code, and operating system executable initialization code. This paper takes the Motorola MPC860 processor and the proprietary operating system CRTOSII as examples to study the design and implementation technology of embedded system boot programs. Embedded software development involves two operating states: debug mode and firmware mode. Debug mode mainly solves the problem of how to debug programs whose correctness has not been verified on the target board; while firmware mode mainly solves the problem of how to boot programs that have been successfully debugged. Accordingly, the design of the boot code should be carried out separately for the two modes. 1. System Booting in Debug Mode 1.1 The Role of Boot Code in Debug Mode A complete embedded software solution generally includes four aspects: ① Hardware platform configuration initialization and system boot code; ② Operating system software execution environment initialization code; ③ Operating system; ④ Application program. Among these four aspects, the boot code is the problem this research aims to solve. In fact, board-level initialization, the operating system hardware abstraction layer, and device drivers, when integrated together, constitute the main body of the BSP (Board Support Package) in an embedded system. The BSP code is related to the specific target board hardware design, as well as the design requirements of the application program. For different requirements proposed by the application program, such as different device drivers, different numbers of interrupt sources, different interrupt priority arrangements, and whether to enable the MMU mechanism, the BSP should make corresponding arrangements. The application program in the fourth part is built upon the correct operation of the first three parts and requires repeated debugging. As can be seen from the above analysis, the correctness of the BSP and application code cannot be guaranteed by writing it once; it requires an iterative process of "debugging—modifying—debugging." Therefore, a reliable debugging environment needs to be established. The foundation for establishing this environment is the boot code in debug mode. 1.2 Debugging Method of Boot Code This study employs an OCD (On Chip Debugging) debugging technique called BDM (Background Debug Mode). BDM is a hardware debugging method provided by Motorola, similar to JTAG debugging. It utilizes the debug port provided by the processor. The MPC860 uses a special BDM—EPBDM, which operates by having the processor's embedded debug module take over interrupt and exception handling. Users specify which interrupts or exceptions trigger the processor to directly enter debug mode instead of the operating system's handlers by setting the debug enable register. After entering debug mode, the embedded debug module sends a signal to the external debug communication interface, notifying the host debugger that has been listening on the communication interface. The debugger can then use the debug module to make the processor execute system instructions (equivalent to privileged mode). Due to the support of a dedicated chip-level debug interface device (BDI2000), no corresponding debug agent (Monitor) software is required on the target side. 1.3 Implementation of Debug Mode Boot Code The core of the debug mode boot code lies in using the BDM protocol to parse microinstructions and sending signals to the MPC860 through the debug interface to initialize the debugging environment. Since the MPC860 adopts a RISC architecture, the initialization part mainly involves setting up the processor's internal registers. This process includes three aspects: (1) Initializing processor-related registers: mainly registers related to processor status (MSR, SRR1, SIUMCR, etc.), interrupt and clock-related modules (SYPCR, SCCR, PLPRCR, TBSCR, etc.). (2) Initializing the BDM debug port: including the debug enable register DER, the register ICTRL that supports instruction breakpoints, etc. (3) Initializing chip-level and board-level memory mapping: including the internal memory mapping register IMMR, memory control-related registers OR0~OR7, BR0~BR7, etc. Their main functions are address mapping, chip select signal selection, and memory controller selection (UMPA, UMPB, GPCM). If UPM is selected, since UPM control uses micro-instruction, and these micro-instructions vary depending on the memory (SRAM, SDRAM, DRAM, etc.), the designer needs to write the code to the corresponding location in the MPC860's internal memory area. For memory banks that need to be refreshed in real time (such as SDRAM), refresh control micro-instructions also need to be set. The execution of the aforementioned initialization code relies on both the debugging interface support provided by the target machine MPC860 and the support of the host machine's GDB. For the host system, Linux can be chosen, with GBD configured on it; alternatively, Windows 2000 can be used with the visual debugging tool LambdaTools GDB (a Coretek product, which does not support hardware breakpoints), or BDI2000 (an emulator that supports hardware breakpoints). Regardless of the debugging tool used, the initialization instructions can be stored in a script file that the debugger can recognize. These scripts are functionally equivalent, and the instructions are generally described in the following format: Opcode register values. For example, the code snippet for SDRAM initialization under embedded Linux is: `mpcbdm spr MDR=0x1FF77C35` `mpcbdm spr MDR=0xEFEABC34` `mpcbdm spr MDR=0x1FB57C35` ... While under Windows 2000 using BDI2000, the code is: `WUPM 0x00000005 0x1FF77C35` `WUPM 0x00000006 0xEFEABC34` `WUPM 0x00000007 0x1FB57C35` ... After the instructions described in the script are executed, the MPC860 enters a normally functioning state as intended. The program can be downloaded to the SDRAM for debugging and execution using a loader. This program mainly consists of two parts: an interrupt table, an operating system, and an application image. Its format can be bin, elf, coff, etc. Figure 1 shows the memory image after downloading. [align=center][img=395,232]http://www.e-works.net.cn/images/127982020320781250.GIF[/img] Figure 1 Memory Image in Debug Mode[/align] After the program download is complete, the PC pointer points to the first instruction of the Image code segment (text segment), and debugging can begin using the commands provided by the debugger. 2. System Booting in Solidified Mode 2.1 Overview After debugging, the correctness of the Image composed of the OS and the upper-level application is guaranteed, but this Image cannot run autonomously. This is because in debug mode, the processor is initialized through the BDM interface, and the program is downloaded to RAM for execution through the BDM interface. In practical application environments, the Image must be stored in non-volatile memory, such as Flash, EPROM, etc. This paper chooses Flash. When the system starts, the processor executes a boot program to replace the functions of the debug script and loader in debug mode. The boot code mainly considers the following issues:

[＊] How the program executes when the system powers on and resets, and which registers need to be initialized, with a focus on memory mapping-related parts; [＊] How many parts are in the startup code, and should each part be executed entirely or partially in Flash or RAM; [＊] The trade-off between time efficiency and space efficiency.

2.2 Power-on initialization In both boot modes, power-on initialization is always a necessary step. It involves the handling of various core register initialization, address mapping and other issues. (1) Address mapping The MPC860 reset is handled by an exception interrupt (which can be understood as an interrupt generated by the CPU itself), with a vector number of 0x100. The base address of the exception vector table plus the reset vector number is the reset vector, which is where the CPU starts executing instructions. There are two possible locations of the exception vector table in memory space: 0x0000000 and 0xFFF00000. So the reset vector of PowerPC is 0x100 or 0xFFF00100. Assuming the reset vector is 0xFFF00100, the system has 128K bytes of Flash and is preparing to map it to the address starting at 0xFE000000 in the CPU memory space. The CS0 chip select signal inside the MPC860 is the default system boot chip select signal and has been connected to the chip select line of the Flash. When powered on, the memory controller ignores the high 17 bits of all address lines involved in the selection logic, and CS0 is always valid. In this way, Flash will always be selected, and the CPU fetches instructions from Flash offset 0x100. At this time, each 128KB block of the CPU's 4GB memory space is mapped to Flash. (2) The register initialization is roughly the same as in the hardening mode, but instead of using a script file, a piece of MPC860 assembly program is directly stored in a start.s file. Similar to the debug mode initialization program, the following processing is mainly performed:

[＊] Initialize CPU core registers; [＊] Set machine status registers; [＊] Disable ceche; [＊] Initialize IMMR; [＊] Initialize System Interface Unit (SIU); [＊] Initialize clock and interrupt control registers; [＊] Initialize communication processor (CPM); [＊] Initialize memory controller (UPM); [＊] Initialize C language stack.

(3) Address Space Remapping: Upon power-up, only one chip select signal is active, which selects the Flash memory, while the addresses of RAM and other storage devices are invalid. Address space remapping is required for access. The MPC860's address space remapping is accomplished by setting sixteen registers: 0R0~OR7 and BR0~BR7. Since the 4GB address space is occupied by the Flash memory upon power-up, the address 0xFFF00100 remains at offset 0x100 in the Flash memory. During register initialization, the SDRAM, MPC860 internal register space, and peripherals also need to be mapped in. Before performing these operations, the Flash memory location needs to be fixed, for example, mapped to 0xFE000000. This is achieved by setting the OR0 and BR0 registers. However, when writing OR0, the CPU is still fetching instructions from the 0xFFF00000 block, while the Flash is about to be mapped to the 0xFE000000 block. Therefore, the program will inevitably "run away," and the program counter (PC) must be adjusted. However, the PC pointer is invisible to the programmer and must be modified using jump instructions. After the Flash address mapping is completed, the mapping of all memory spaces can be completed by setting OR1~OR7 and BR1~BR7. Various storage devices can be mapped to any location in the CPU address space, but they cannot conflict with each other. 2.3 Structure and Execution of Boot Code The code involved in system startup consists of three parts: the register initialization assembly file start.s, a Load program, and the Image of the operating system and application programs. The boot code only contains start.s and the Load program. The Load program's function is to copy the Image of the operating system and application programs from Flash to SDRAM and jump to the first instruction of the Image. After debugging, the Image has two operating modes: Flash-resident image: The Load program only copies the data segment (data+bss) of the Image to RAM, while the code segment (text) is executed directly in Flash. Flash-based image: The Load program moves the entire Image to RAM for execution, including both the code segment (text) and the data segment (data+bss). Figures 2 and 3 illustrate the storage mapping of the two types of Images, and the loading process from Flash to SDRAM, respectively. [align=center][img=500,221]http://www.e-works.net.cn/images/127982020780468750.GIF[/img] Figure 2 Flash-resident image memory mapping[/align][align=center][img=500,223]http://www.e-works.net.cn/images/127982022328437500.GIF[/img] Figure 3 Flash-based image memory mapping[/align] 2.4 Trade-offs between time efficiency and space efficiency In the application of embedded systems, different application environments have different requirements for time efficiency and space efficiency. The startup code based on MPC860 has a relatively sufficient solution for this. (1) Time constraints Time constraints mainly include two situations: the system requires fast startup and the program requires high-speed execution after the system starts. For systems requiring fast startup, the initialization program executed in Flash should be kept as short as possible, and syntax such as loop statements should be minimized. The program should be loaded into RAM for execution as soon as possible. This is because there is an order of magnitude difference between the access time of Flash and the access time of RAM. However, a trade-off must be made based on the amount of code and the characteristics of the memory. Although the copying speed in RAM is fast, the operation of copying the code in Flash to RAM will bring certain overhead. As can be seen, the startup time consists of three parts: the running time of the boot code in Flash, the time of copying the code from Flash to RAM, and the running time of the subsequent startup code in RAM. The minimum startup time is the minimum of the sum of these three. For systems that require high-speed program execution after startup, the main factors are the characteristics of the processor, memory, and I/O speed. In terms of software, the above-mentioned Flash-based image method should be adopted so that the code segment runs in RAM, thereby improving the running speed. (2) Space constraints Space constraints mainly include two situations: systems with limited space for non-volatile storage such as Flash and systems with limited space for volatile storage such as RAM. For systems using high-performance non-volatile memory, due to cost considerations, flash memory and other storage devices cannot be too large, yet they are where the system stores boot code and the operating system image. When storing the image, compression tools such as gzip can be used for compression, and a reverse decompression algorithm is used to decompress it when loading the image into RAM. However, for real-time considerations, the compression algorithm cannot be too complex; otherwise, the excessive time consumed in the compression and decompression process will severely conflict with boot time constraints. Using a compression strategy does not necessarily increase system boot time, because although the compression and decompression process saves some time, the time spent copying the image from Flash to RAM is correspondingly reduced due to the smaller image size, potentially resulting in a reduction in boot time. For systems using high-performance RAM, RAM space is also limited due to cost considerations. In this case, the Flash-resident image method described earlier is generally used: the Load program copies the data segment from the image to RAM, while the code segment runs in Flash. A trade-off also exists, because the code segment runs in the slower Flash, saving space but sacrificing time. This paper introduces operating system boot methods based on embedded processors, focusing on the boot modes of embedded systems and different types of boot methods. Taking the booting of the CRTOS II operating system on an MPC860C processor as an example, this paper elucidates the structure, function, and execution method of the boot code in debug and solidified modes, and analyzes the trade-offs in time and space efficiency under different boot modes. Finally, the written boot code was debugged using a BDI2000 emulator, successfully achieving operating system booting in both debug and solidified modes. Future work includes: further research on operating system booting methods on different hardware platforms, such as the most popular ARM and x86 series; and on the same platform, research on booting methods for different operating systems, such as embedded Linux, Vxworks, and WinCE. Simultaneously, digital models can be introduced to quantitatively analyze time and space performance, enabling the adoption of more suitable boot schemes under different environments.