Implementation of S3C2410 Quick Start

Embedded systems have strict requirements on functions, reliability, cost, volume, power consumption, etc. Various RISC microprocessors based on ARM architecture have flexible characteristics and powerful performance, and have been widely used in embedded systems. ---S3C2410 is a processor designed by Samsung based on ARM920T. In the process of developing a system based on S3C2410, how to make the system start quickly and stably is an important issue. The resources of embedded systems are limited, and programs are usually solidified in ROM to run. However, in actual applications, in order to improve the real-time performance of the system and speed up the execution of the code, the program is often moved to RAM after the system starts, because the access speed of RAM is much faster than ROM, which greatly improves the performance of the system. The tasks to be completed by the startup program include: hardware initialization, system storage system configuration, and copying the secondary interrupt vector table.

Startup Program Process

System hardware initialization

After the system is powered on or reset, the program starts to execute from the Reset Exception Vector at address 0x0, so the first instruction of the Bootloader needs to be placed here: b ResetHandler, jump to the ResetHandler label to perform the first stage of hardware initialization, the main contents are: turn off the watchdog timer, turn off interrupts, initialize PLL and clock, and initialize the memory system. After executing the above programs, the system initializes the stack and memory. The system stack initialization depends on which interrupts the user uses and which types of errors the system needs to handle. In general, the manager stack must be set, and if the IRQ interrupt is used, the IRQ stack must also be set. If the system uses peripherals, the relevant registers need to be set to determine their refresh frequency, bus width and other information.

The code segment is copied to RAM and executed

Because the code of embedded systems is usually solidified in ROM or Flash and starts running after power-on. Since the reading speed of ROM and Flash is relatively slow, this will undoubtedly reduce the execution speed of the code and the operating efficiency of the system. For this reason, the system code needs to be copied to RAM for execution. Use the positioning information generated by the SDT linker ARMLink to move the valid code and data segments of RO to RAM. ARMLink links the compiled program into an ELF file. There are three output segments in the image file: RO segment, RW segment, and ZI segment. These three output segments contain read-only code and a small amount of data contained in the code segment, readable and writable data, and data initialized to 0. ARMLink also generates the start and end positioning information of these three output segments: Image$$RO$$Base, Image$$RO$$Limit, Image$$RW$$Base, Image$$Limit, Image$$Linit, and Image$$ZI$$Limit. These positioning information can be used in the program. Move the code and data in ROM to RAM. The specific procedure is as follows:

BNE %B0 /*If the copy is not complete, jump to the assembly statement at the 0 identifier and continue copying. See the ARM instruction help manual

Create a secondary interrupt vector table

In the ARM system, the interrupt vector table is located at the address starting from 0X0, which means that no matter what upper-level software is running, once an interrupt occurs, the program will get the interrupt vector table in the Flash memory, reducing the system's operating efficiency. Therefore, build your own secondary interrupt vector table in RAM. When an interrupt occurs, the program directly takes the interrupt vector from RAM and enters the interrupt subroutine. Especially in systems where interrupts occur frequently, this method can greatly improve the system's operating efficiency. The specific implementation code is as follows

HANDLER is a macro used to find the entry address of the interrupt handler. These addresses are stored in the table pointed to by HandleXXX, which is located at the high end of RAM and has a base address of _ISR_STARTADDRESS.

Applications of MMU

MMU is the abbreviation of memory management unit, which is a device used to manage the virtual memory system. MMU is usually part of the CPU and has a small amount of storage space to store the matching table from virtual address to physical address. This table is called TLB (Translation Lookaside Buffer). All data requests are sent to the MMU, which determines whether the data is in RAM or in a large-capacity external memory device. If the data is not in the storage space, the MMU will generate a page fault interrupt. The structure of the MMU memory system allows fine control of the memory system, and most of the control details are provided by the translation table stored in the memory. The entries of these tables define the properties of various memory areas from 1KB to 1MB. The two main functions performed by the MMU are: converting virtual addresses into physical addresses and controlling memory access permissions. When the MMU is turned off, the virtual address is directly output to the physical address bus.

Through the above analysis, it can be found that the system startup program mainly completes the hardware initialization, overcomes the weakness of slow Flash or ROM reading speed, improves the reading speed of instructions and data, realizes high-speed operation of the system, and reduces the use of RAM and reduces system costs through the application of MMU.