Source code analysis of Xunwei 4412 development board coprocessor

砂舞的玩笑

Source code analysis of Xunwei 4412 development board coprocessor [Copy link]

This article analyzes the uboot source code of 4412 and analyzes what work uboot has done by combining the uboot source code. The source code file analyzed is the "cpu/ ARM_cortexa9 /start.S" file.

1 Source code analysis

.globl _start: globl is similar to Extern in C language, similar to defining a global function _start, which can be accessed from outside. _start is the entry of the entire uboot, and the first line of code starts to execute from here.
_start: b reset: _start: indicates entering the main structure of the "global function" _start; b reset means jumping to reset. Similar to goto reset in C language, jumping to reset. In _start, only one statement "b reset" is run during normal startup, and it jumps to reset, and the rest will not be executed.
The rest of the _start "global function" will be forced to jump to the exception handling code in the event of an exception.
ldr pc, _undefined_instrument // The code that the system is going to execute when there is an "undefined instruction".
ldr pc, _software_interrupt //Software interrupt
ldr pc, _prefetch_abort //Prefetch error
ldr pc, _data_abort //Data error
ldr pc, _not_used //Undefined
ldr pc, _irq //(Normal) interrupt
ldr pc, _fiq //Fast interrupt

The following code is the exception vector address.

The following code indicates that the following code must be aligned to 16 bytes, and the missing parts are filled with 0xdeadbeef

Next, let's look at the main part of reset. Remove the irrelevant parts such as #IF 0. The valid code is as follows.
You can read the comments directly without looking at the meaning of each line of assembly.
Set the CPU to SVC32 mode.

Cache initialization and shutdown.

Disable TLBs, and icache.

Disable MMU and caches.

You may be unfamiliar with the above terms. In fact, not understanding this part does not affect our transplantation of the new uboot. We only need to compare this part with the new uboot part and modify the differences.

The 4412 development board uses the Exynos 4412 processor, which uses the arm v7 instruction set (architecture) and the cortex a9 architecture (CPU core structure). The concepts of cache, MMU and TLBs are not described in the 4412 datasheet. If you are interested, you can search for documents on the ARM official website.

ARM official website:
https://developer.arm.com/
The author downloaded the document "DDI0388I_cortex_a9_r4p1_trm.pdf" of A9 architecture, which has a detailed introduction to these registers. If you are very interested, you can read it.
When porting a new uboot, this part only needs to copy the code. In most cases, the new version of uboot comes with this part of the source code.

Here is a brief introduction to the above important terms and concepts.
3.2.2 ARM coprocessor
The author will introduce the registers mentioned above (SVC32, MMU and iCACHE registers). I have read the corresponding ARM official English documents many times and found that the translation of "coprocessor" is very confusing. "
Assisting processor" Someone on the Internet describes it as "a coprocessor is a chip used to relieve the system microprocessor of specific processing tasks."
Regarding the coprocessor of ARM processor, there is such a definition "coprocessor can be attached to ARM processor. A coprocessor extends the core processing function by extending the instruction set or providing configuration registers. One or more coprocessors can be connected to the ARM core through the coprocessor
interface ." If "coprocessor" is defined as a chip that generally assists the CPU, then the chip in the independent graphics card can also be called a coprocessor. If "coprocessor can be attached to ARM..." is used, then the hardware decoding and 3D graphics processing in 4412 can also be called coprocessors. The author thinks that it is still necessary to see how the ARM official website document describes this part, as shown in the figure below.

In the red box above, the first line is translated as "system control coprocessor". I think it is easier to understand and accept the term "system control coprocessor". It contains 15 special registers, mainly providing "all system control and configuration", "MMC control and management", "cache control and management" and "system performance monitoring " functions.

In the ARM assembly code, whenever you see the "mrc" and "mcr" instructions, it means that there is a short section of code to control the coprocessor (hereinafter referred to as the coprocessor). The specific meaning can be understood through the comments. If you are particularly interested, you can read the relevant documents, which have a detailed description of the function of each bit.
3.2.3 SVC32 mode In the coprocessor operation, the first thing is to set the system to SVC32 working mode. The ARM system has 7 working modes:

The other 6 processor modes besides user mode are called privileged modes. In privileged modes, programs can access all system resources and switch processor modes at will. In privileged modes, except system mode, the other 5 modes are also called exception modes. Most user programs run in user mode. At this time, applications cannot access some system resources protected by the operating system, and applications cannot directly switch processor modes. In user mode, when processor mode switching is required, applications can generate exception processing and switch processor modes in exception processing.
SVC mode is a privileged mode that can access restricted resources. It has the same register group as sys mode, but some resources in SVC mode cannot be accessed by sys mode.
Uboot needs to complete the work of initializing hardware, and the ultimate goal is to start the kernel. Before Uboot jumps to the kernel, the MPU needs to be set to SVC mode.
Combined with the functions of completing hardware initialization and booting the kernel in Uboot, Uboot should be set to SVC mode in the initialization stage of Uboot.

3.3.4 MMU Memory Management Unit The most important part of the coprocessor is the memory management unit. It is a computer hardware responsible for processing the memory access request of the CPU. Its functions include the conversion of virtual address to physical address (i.e. virtual memory management), memory protection, and control of the CPU cache.
If you have studied the driver tutorial, you will know that in the kernel source code, when operating GPIO, the operation is the virtual address, not the physical address. MMU is the control unit for the conversion of physical address and virtual address.
Cache is a high-speed cache. The processing speed of the CPU is getting faster and faster. If the CPU communicates directly with the memory , the speed of the memory still cannot meet the requirements. The CPU must communicate with the memory through the cache, and the speed of the cache is faster than the memory.
TLB is used to link cache and memory, and MMU is used to link memory and physical address.
What we need to understand here is that during the system startup process, the CPU and memory need to complete the communication. First, TLB is needed to realize the address mapping between cache and memory, and MMU is used to realize the mapping between virtual address and physical address.
If you do not turn off the mmu, TLB and cache, the CPU may directly go to the cache to get the value. At this time, the memory and cache may not communicate normally, which may cause errors in the CPU reading data. The
introduction of the coprocessor is complete. It is recommended to only understand the assembly instructions involved in this part through the appendix. We must grasp the overall picture as soon as possible and not get stuck in a certain concept. Moreover, this part does not affect the final goal--the transplantation of uboot.