Extract the kernel from the Startup Process of ARM Linux

Author-------Dansen-----xzd2734@163.com

Looking at the zimage generation process from the back, we can find out whether the program entry is very important.
Link file, find it, and the directory where zimage is generated is kernel/ARCH/ARM/boot/compressed/
Make process is... LD-p-X-T vmlinux. LDS head. O Misc. O head-s3c2410.o piggy. o
Libgcc. O-o vmlinux
Then we use the binary tool objcopy to make vmlinux into an executable binary image file zimage.
In this way, go to the kernel/ARCH/ARM/boot/compressed/directory and find the vmlinux. LDS file.
This file will not exist if it is not compiled, because it is also generated during the compilation process, and is generated by
Generate vmlinux. LDS. in and open this file.
Entry (_ start)
Sections
{
. = Load_addr;
_ Load_addr = .;

. = Text_start;
_ Text = .;

. Text :{
_ Start = .;
* (. Start)
* (. Text)
........
The entry is _ start, and the entry is directly defined in this file.
The entry is followed by the. Start segment, so the program starts to run from the. Start segment.
If you look at the vmlinux. LDS generation process, you should be able to find the load_addr and text_start values.
In fact, these two values are the zreladdr and ztextaddr assigned by the other two variables.
In kernel/ARCH/ARM/boot/makefile, we can find the values of these two variables.
Ifeq ($ (config_arch_s3c2410), Y)
Ztextaddr = 0x30008000
Zreladdr = 0x30008000
Endif
So
Load_addr = 0x30008000
Text_start = 0x30008000
Let's take a look at vmlinux. LDS.
Entry (_ start)
Sections
{
. = 0x30008000;
_ Load_addr = .;

. = 0;
_ Text = .;
Obviously, load_addr is assigned 0x30008000.
Let's see how text_start is 0. I think this should be an offset, and the offset is 0.
So it is still 0x30008000
Next, let's start reading the code from head. S.
. Section ". Start", # alloc, # execinstr
/*
* Sort out different calling conventions
*/
. Align
Start:
. Type start, # Function
. Rept 8
MoV r0, R0
. Endr

B 1f
. Word 0x016f2818 @ magic numbers to help the loader
. Word start @ absolute load/run zimage address
. Word _ edata @ zimage end address
1: mov R7, R1 @ save architecture ID
This must be the entry to the program. Generally, let's look at the meaning of the assembler.
One thing to note is that either an assembly file or a segment does not mean that the execution is complete first.
Head. s to execute head-s3c2410.s, or pay attention to the link segment, apparently head. s
In a short time, another segment is started. Text.
. Text
ADR r0, lc0
Ldmia r0, {R1, R2, R3, R4, R5, R6, IP, SP}
Subs r0, R0, R1 @ calculate the Delta offset
And our head-s3c2410.s?
. Section ". Start", # alloc, # execinstr
_ S3c2410_start:
Bic R2, PC, # 0x1f
Add R3, R2, #0X4000 @ 16 KB is quite enough...
Still belongs to the. Start segment, so the head-s3c2410.s is executed first when the sequence is executed, and then the execution
. Text Segment. Head-s3c2410.s is mainly some of the initialization work of the CPU. Next, we will need
Compression. Let's talk about why. I still noticed that there is a piggy. O in the file that generated zimage above.
We can see that piggy. O is generated by the real kernel vmlinux. This vmlinux has been running since it was started.
The running kernel, originally very large, can be easily put into flash after compression, of course, in fact, do not compress Jump to it
The entry can also run. The decompressed kernel is 4 MB of space starting with load_addr = 0x30008000, which will overwrite
Our currently running code first decompress the kernel to the end of zimage + allocating stack 0x10000
CMP R4, R2 // R4 is load_addr = 0x30008000
BHS wont_overwrite // R2 is the bottom of the current Code.
Add r0, R4, #4096*1024 @ 4 MB largest kernel size
CMP r0, R5 // R5 is also 0x30008000
BLS wont_overwrite // skip

MoV R5, R2 // R2 is (user_stack + 4096) at the end of zimage + 0x10000
MoV r0, R5
MoV R3, R7 // machine type
BL decompress_kernel
With R5, R0, and R7 as parameters, you can call the decompress_kernel function in Misc. C to decompress the package.
When this function calls the gunzip function, the GCC library function is not found in the source code.
At the beginning of R5, the function returns the length obtained from R0 decompression. At this time, we need to adjust the code
Add R1, R5, R0 @ end of decompressed Kernel
ADR R2, reloc_start
LDR R3, LC1 // LC1:. Word reloc_end-reloc_start
Add R3, R2, R3
1: ldmia R2 !, {R8-R13} @ copy relocation code
Stmia R1 !, {R8-R13}
Ldmia R2 !, {R8-R13}
Stmia R1 !, {R8-R13}
CMP R2, R3 // the code we need from reloc_start to reloc_end is put here
BlO 1B // decompress the kernel, and we will overwrite zimage below
BL cache_clean_flush
Add PC, R5, R0 // adjust to the adjusted reloc_start, after decompressed Kernel
Reloc_start: Add R8, R5, R0 // Where R5 unzips the kernel, R0 unzips the kernel Length
Debug_reloc_start
MoV R1, R4 // r4 = 0x30008000
1:
. Rept 4
Ldmia R5 !, {R0, R2, R3, R9-R13} @ relocate Kernel
Stmia R1 !, {R0, R2, R3, R9-R13}
. Endr

CMP R5, R8
BlO 1B // in this way, the decompressed kernel is moved to 0x30008000.
Call_kernel: BL cache_clean_flush
BL cache_off
MoV r0, #0
MoV R1, R7 @ restore architecture number
MoV PC, R4 @ call Kernel
The above is to jump to 0x30008000 to execute the real kernel.