Abstract: This paper introduces the process of building a digital video playback system software platform on PowerPC405 using embedded Linux, and discusses the construction process of several main parts of the embedded Linux system, such as cross compiler, bootloader, Linux kernel, and root file system. Keywords: PowerPC405, embedded Linux, digital video player U-BOOT Introduction: Digital video playback devices have developed rapidly in recent years and come in a wide variety of types. The software system of traditional video playback devices (such as DVD players) is generally a simple control loop system without an operating system, and the function expansion and upgrade are limited. The portable digital video playback device studied in this paper is built on an embedded 32-bit PowerPC405 CPU, runs the Linux operating system, uses a large-capacity hard disk as the storage medium, and has network functions. PowerPC405 is a RISC processor launched by IBM specifically for embedded applications and is widely used. Embedded Linux[1] is an open-source operating system software with the characteristics of being free, supporting many CPUs, being customizable, supporting networks, and having rich software resources. Using embedded Linux to build a software platform for a digital video playback system makes the player low-cost, easy to upgrade and manage, and supports multiple interfaces such as USB, facilitating video program exchange. This represents a future direction for the development of such devices. This article mainly discusses the bootloader construction for an embedded Linux system used in a digital video player, the main process of Linux kernel porting, and potential problems, and provides corresponding solutions. 1. Digital Video Playback System Block Diagram Figure 1-1 Hardware Block Diagram of the Stream Playback System. Figure 1-1 shows the system block diagram of this player. Its core control system is an embedded Linux system based on PowerPC405. The application program on this system processes the programs in the data storage system and moves them to the FPGA in the stream control system. The FPGA decrypts the programs and sends them to the decoding system. After decompression, the decoding system outputs RGB signals to the display device for display. Our focus here is on the construction of the embedded Linux system in the core control system. The hierarchical structure of the embedded Linux system in the player is shown in Figure 1-2. After the hardware powers on, the CPU's program pointer first points to a specific memory address, which typically contains the bootloader. After initializing the CPU and memory, the bootloader moves and decompresses the Linux kernel from the general ROM device into memory. Then, the program pointer jumps to the beginning of the kernel in memory, and the Linux kernel continues to complete the remaining system boot work. After re-initializing the system, the kernel loads the root file system and runs user applications. The entire process of building an embedded Linux system platform can be referenced from the system startup process. The main tasks include building the bootloader, Linux kernel, and root file system. 2. Preparation for Building an Embedded Linux System Platform To build an embedded Linux system platform, a cross-platform development toolchain must first be prepared. It runs on the local host, and the compiled and linked binary executable program can run on the development board's CPU and operating system. There are many ways to build such a toolchain, mainly including the compiler gcc, linker ld, and C library glibc. You can download the source code from relevant websites and compile it manually. The most convenient method is to use a complete pre-compiled development package, such as the ELDK development package from the German company Denx. 3. Bootloader and Kernel Selection After preparing the development toolchain, you can begin developing the embedded Linux system. The first step is selecting the bootloader. 3.1 Bootloader Selection Generally, after booting, a PC first enters the BIOS. The BIOS performs certain system initializations before booting the operating system, such as Windows or Linux. Embedded systems generally do not have a BIOS, but they still need a module that performs similar functions. This is the bootloader, whose main functions are to initialize hardware devices such as the CPU and memory, and to import the operating system. There are many types of bootloaders, such as blob, lilo, grub, and U-BOOT. Currently, the most widely used software in the embedded field is Denx's free and open-source software U-BOOT. It supports multiple CPUs such as PowerPC, ARM, MIPS, and x86, and more than 100 development boards. The source code structure is clear, easy to port, and rich in development documentation. Problems that users may encounter during use can generally be solved quickly. Therefore, we chose U-BOOT as the bootloader for the development board. Depending on the different development boards, the size and model of the flash, the size of the memory, and the boot method, some corresponding modifications are required when using U-BOOT to adapt to the user's own development board. For specific porting methods and common problems, please refer to [3]. 3.2 Linux Kernel Porting After the bootloader initializes the system hardware, it imports the Linux kernel from the external storage medium into the memory. Then, it hands over control to the Linux kernel, which continues to complete the system booting work. If the kernel does not support the development board used by the user, the user needs to manually modify the Linux kernel and do some related porting work. The focus should be on the processing of the hardware peripherals of the development board, including the kernel's processing of the board's basic hardware information, the initialization of hardware devices on the board, and the allocation of interrupts. The most convenient way to port a Linux kernel to a development board is to use a development board that is already present in the kernel and is closest to the user's hardware platform as a template, and then make modifications accordingly. The development board we used is similar to the IBM Walnut development board. Its main peripherals, including hard drives and USB devices, are all connected via the PCI bus interface (PCI to IDE, PCI to USB). Therefore, the kernel porting work mainly consists of two parts: first, the transfer of board hardware information between the bootloader and the kernel; and second, the initialization of the PCI peripherals. 3.2.1 U-BOOT and Linux Kernel Cooperation After initializing the hardware devices, U-BOOT loads the kernel into memory. Then, as the program pointer jumps to the kernel's location, it passes some parameters to the kernel for use. These include the `board_info` data structure, which contains information such as the board's CPU frequency, SDRAM and flash size, IP address, and MAC address. Linux uses these parameters to initialize the system. However, the Linux kernel and U-BOOT are developed by different organizations. To modify relevant parts of the Linux kernel to match the data passed from U-BOOT, for the PowerPC we are using, U-BOOT uses five general-purpose registers (r3, r4, r5, r6, r7) to pass parameters. We need to modify the `board_info` data structure passed through register r3 (defined in `arch/ppc/platforms/cs2000.h` in the Linux kernel) to match the content of the `bd_info` data structure defined in `u-boot-1.1.1/include/asm-ppc/u-boot.h` in the U-BOOT source code. This ensures the kernel doesn't misinterpret the `board_info` data structure passed from U-BOOT. 3.2.2 Modification of the PCI Peripheral Initialization Section The main process of initializing the PCI part of the Linux kernel is as follows: scan the entire PCI bus, find all devices connected to the bus, and allocate I/O space, memory space, and IRQ interrupt numbers to each PCI device based on the information in the configuration space registers of each PCI device. For the x86 platform, this work is already done in the BIOS; the Linux kernel only needs to call the configuration generated by the BIOS. However, for our embedded Linux system, which lacks a BIOS, the Linux kernel must handle this task manually. For different development boards, two parts need to be added to the standard PCI initialization code: one is the access method for the PCI device configuration space registers, and the other is the PCI interrupt configuration. According to the PCI protocol specification, accessing the configuration space of a PCI device requires first enabling the device's IDSEL pin before reading and writing to the device's configuration register group. However, the PCI specification does not define the connection method for the IDSEL pin, so the method for accessing the PCI device configuration space varies depending on the hardware connection method of the IDSEL pin for each development board's PCI slave device. Figure 3-1 shows two connection methods for the IDSEL pin of a PCI device. In the general connection (a), the IDSEL pin of the PCI slave device is connected in series with a resistor to one of the address lines AD[11-31] ​​of the PCI bus. This allows you to set each address line AD[11-31] ​​high during PCI bus address access. If the read configuration register data is valid, it indicates that the address line is connected to the IDSEL of a device; otherwise, it indicates that it is not connected. Our development board uses connection method (b) in Figure 3-1, connecting the IDSEL pin of the PCI slave device to a GPIO port of the CPU. This allows for flexible control of enabling or disabling a device on the PCI bus via the GPIO. With this hardware connection, when accessing the PCI slave device's configuration space, you need to first set the GPIO connected to the device's IDSEL pin high before reading or writing the configuration register group. Therefore, for our development board, before reading and writing configuration registers in the general source code for reading configuration register space (arch/ppc/kernel/indirect_pci.c), the following code needs to be inserted: `switch (dev_function) { case PCI_DEV1: set_gpio1_high(); // Set the corresponding GPIO high case PCI_DEV2: set_gpio2_high(); default: break; }` Another PCI initialization code that needs modification is related to PCI device interrupt number allocation. For embedded Linux without BIOS, PCI device interrupt number allocation is determined by the kernel based on the board's hardware connections. Generally, embedded devices do not require interrupt path interconnectors; the /INT pin of the slot is directly connected to the CPU's IRQ line. There are many connection methods, such as connecting all four interrupt pins of a slot to one IRQ, with the operating system controlling the interrupt multiplexing relationship, or connecting one PCI interrupt pin to only one IRQ line. Therefore, the Linux code for PCI IRQ allocation needs to be modified according to the actual interrupt connection method of each development board. In our development board, each PCI's /INT pin is connected to a separate IRQ line. Based on this connection, we can construct the following table from the software: /* arch/ppc/platforms/our_board_name.c: ppc405_map_irq() */ static char pci_irq_table[][4] = /* PCI /INT PIN->INTLINE * ABCD */ { {28, 29, 30, 30}, /* IDSEL 1 - PCI slot 1 */ {31, 31, 31, 31}, /* IDSEL 2 - PCI slot 2 */ }; The table above describes the interrupt number 28 for PCI slot 1's /INT A. This interrupt number 28 comes from the fact that the slot's /INT A is connected to the CPU's interrupt number 28 IRQ line. By filling in the connection relationship between the interrupt lines of all PCI slots and the CPU IRQ lines in the table, the interrupt numbers of each PCI device can be correctly assigned through the standard PCI initialization code in the kernel. Of course, in the IRQ initialization part of the board (arch/ppc/platforms/our_board_name.c: board_setup_irq()), the trigger mode, polarity, etc. of these assigned interrupt lines must also be correctly set. The porting of the Linux kernel involves a lot of hardware knowledge. Having a clear understanding of the hardware schematic of the development board can make the porting work more efficient. 4 Conclusion With the bootloader, kernel, and Busybox[4][5] to build a simple root file system, the embedded Linux system platform has been built. The embedded Linux system platform built by the above process is small in size, powerful in function, and stable in operation. It is very suitable for devices that need to work for a long time, such as digital video players. Moreover, it is highly upgradable. For some future application needs, it can be expanded through the PCI, USB, Ethernet and other interfaces on the development board. It can be said that it has laid a solid foundation for the further functional enhancement of the device in the future. The innovation of this paper lies in upgrading the simple control system of traditional video playback devices to an embedded Linux system, and in the detailed discussion of the construction and porting of the embedded Linux system. In particular, a new initialization algorithm is proposed based on the new connection method of PCI devices, which has strong application value.