Uboot Startup Process

The first thing to say is that the platform is based on the Samsung s5pv210, because the different ways of the platform are different.
Let's talk about the specific processes first, and then analyze the implementation of these processes.
Inand is connected to mmc0 and mmc1; SD card is connected to mmc2; WiFi is connected to mmc3. We started our analysis from the production sector for the first time. At this time, inand was empty and there were no agents. We wanted to launch a mobile TV station, then we have to perform the operation on behalf of Alibaba Cloud. We can't just split inand and copy a copy of the code, so we can only copy the token from the computer to the SD card, how can I insert an SD card to a machine and move it from SD card to the memory?

In the past, Samsung fixed a generation of memory in the CPU for s5pv210. In any case, the CPU startup must be performed first, this generation is used to determine which external device drive (such as USB, Nand, inand, SD card, and onenand) where the device is triggered ), how can I determine a token? From om pin? First look at the CPU manual memory 534 Bytes:

VPC connected to 4th connections:

The circuit R102 and r103 are connected to a high level. The other four resistors are not welded. They are empty, that is, the low level, that is, the 001100 resistance. The schematic is used to start SD/MMC, therefore, we decided to initiate an operation from MMC first. MMC has mmc0, mmc1, mmc2, and mmc3, so we will first access mmc0, so we should first look for inand, but the inand detected by the CPU dynamic representative does not have any dynamic representative, and then look for mmc2, I found that there is an active token in the SD card. How did he find it? The original copy starts directly from the place where the SD card offset address is 512 bytes. How much is the copy? This is related to CPU, pv210
Copy 32 KB (like? Where can I copy it? Copy to the ram of the CPU (because the external memery has not been initialized at this time, it must be copied to the CPU ), this CPU internal memery has been mapped to a place where the address is 0, therefore, starting from 0x0000000, The uboot generation is copied (it should be noted that at this time, the curing generation of the CPU in this segment has already switched from which MMC the notebook is coming, later we will use it to copy the remaining uboot slave), and then we will start to analyze the uboot slave, uboot from start. s starts the starting line. Why is it starting from start. what about the second row? View the Board/Venus/pdc2/u-boot.lds file:

Let's put start. O at the beginning. What is the starting line from start. S? Entry (_ start) indicates that it must start from the place where lable is _ start (do not ask me why the entry decides to start execution from _ start, the compiler is designed like this ):

Directly jump to the reset, but we need to describe the definition of the next seven embedding vectors, according to the arm's CPU specification, the 7 32-bit addresses starting from the 0 address are the ingress addresses of the center node. Therefore, these 32-bit IP addresses are the hop address of each center node, we can see one of the following:
Ldr pc, _ undefined_instruction
_ Undefined_instruction
. Word undefined_instruction

Undefined_instruction:
Get_bad_stack
Bad_save_user_regs
BL do_undefined_instruction
The first reason is that ldr pc is not used directly. What about undefined_instruction? But is it necessary to jump over with a medium volume? If you use this command directly, the hop address must be placed in the command line (0-11 characters in the command line ), in this case, only 4 K is supported! However, when we use a medium variation, we have opened a 32-bit address space to record this address, in this way, we can see the jump within the 4G bandwidth (of course, the 32-bit address space cannot be different from the previous skip command. 4 K, we usually keep up with them like above)
After the analysis is complete, the vectors are followed:

Here we want to talk about bl lowlevel_init. In lowlevel_init.s, we can see that the memery initialization function BL mem_ctrl_asm_init is in cpu_init.s:

That is, why does our memery address start with 0x30000000 and start with another address such as 0x20000000? The answer is yes. You can configure dmc0_memconfig_0 and dmc0_memconfig_1 here. As for how to use this register, I can take the test by referring to manual operations.

When the memory of the OM pin was used, the CPU internal firmware was analyzed before, and the effect was similar to that of the previous one, save it to a specific register (a person thinks that if there is a stored token for the previous CPU operation, there may be no need to renew it again ), we must have determined that the operation was initiated from MMC, and then proceed to the next step:

After initializing some external settings (including memery), start to copy the remaining uboot to memery. Therefore, the OM pin value saved by the slave is proposed, this must also jump to the movi_bl2_copy function to upload the rows, in movi. c:

See if sentence CH = * (volatile u32 *) (0xd0037488); what is this address? Doesn't the hacker have it? Originally, it was the mark that was previously mentioned when the CPU generation was determined from the mmc0 drive or the mmc2 drive, where the output was CH = elfin_hsmmc_2_base, so in the IF else sentence:

The config_mmc_partition parameter is set here. movi_uboot1_start = 512; movi_uboot1_blkcnt = 256 K; pai_phy_uboot_base = 0x33e00000
That is, copy 512 KB content from the SD card to the 0x33e00000 address of memery, our uboot has a good size of KB (we mentioned earlier that the remaining part of copy uboot is not necessarily correct, so it should be copy all ), why should I put it in memery 0x33e00000? Other locations are not supported? First look at makefile:

Text_base in start. S:

It can be understood as follows: the value of text_base in the address "_ text_base" is 33e00000, and the address of _ text_phy_base is the value of pai_phy_uboot_base. What is it?

It turns out to be the same address. It's probably just a different mark to increase the accessibility! Look at the uboot under the u-boot.dis file (study uboot must see this file to see understand ^_^ ),

As you can see, our uboot generation line is starting from 0x33e00000! Now, it is only the original starting address that is migrated to the same internal storage, in this way, the root of the uboot agent itself could not find out when it was about to jump from the CPU to the memery. (Of course, I know it must be this LDR PC, _ start_armboot), question again? We started with 0x0000000 In the ram of the CPU. It's not 0x33e00000 at all. in S, the previous generation is irrelevant to the address (ldr pc, _ start_armboot and earlier !), This means that you can upload this token to any position in the content storage. We can take a paragraph for analysis to see if this is the case?
U-boot.dis in:

First of all, you must understand the progress of the CPU. It is like a single-chip machine. After the CPU is connected or the bandwidth is reached, the CPU jumps to the specified entry address when the connection is established, the _ start in the u-boot.lds is the entry, so when sending the ea000013 command, the hacker switches out that this is a pair of skip commands B, the offset of the hop type is 24 characters lower, which is 0x13 (decimal system 19). Therefore, it is increased by 19*4 = 76 = 0x4c to the address before the jump, we add 0x4c,

How is _ bss_start, not the reset we want? Why? Originally, the opposite hop type is the hop type for the current PC, and the previous PC is always eight characters ahead of the address of the previous command line, this is arm's journal (address-fetch-Fetch), that is, when you are busy, he has already ran to the front to fetch the address, you will never be able to keep up with it, so here 0x4c + 0x08 = 0x54, which is the reset address we want.
It's awesome. Return to the previous movi. c, it moves uboot from SD card to memory 0x33e00000, and then back to start. s, you need to understand whether the runtime is running in the ram of the CPU. Pull down:

Enable MMU:

Set the IP address pointed to by the register sp. The parameter _uboot_size is 2 m, which is the required bytes for the uboot segment. Clear the BBS segment, the starting position and end of the block are determined by the u-boot.lds, And the BBS segment is the Global Variation of our uboot definition, its space is allocated in the u-boot.bin file, and it can be said that if you define a lot of global changes, then the u-boot.bin that you pull out will grow.

We can see that it is placed at the end of uboot.

Next, after the ldr pc, _ start_armboot statement is completed, the uboot generation finally completed the CPU internal RAM bundle, from the internal RAM to the external memery, do not return from this one.

Put the data value 0x33e02b44 in the PC register, and then the PC runs to the address 0x33e02b44 to fetch the command. This is easy to confuse: ldr pc, [PC, #-4] This is the opposite hop, and there is no response, but the jump point (0x33e001b8) is a numeric value, which is equivalent to the ldr pc, = 0x33e02b44. This address is the address in the memory, which is address-related. The previous generations did not use this hop type. If you use it, congratulations, uboot failed. Start_armboot is defined on the board. in C, the next part of the analysis is the generation of the C part. If so, we can see that uboot is half done.
When the previous SD card activation occurs here, uboot knows that when the SD card was triggered, it will set the standard BIT, with the specific position in borad. c, let's take a look at it first:

Upgrade the SDK into inand, and you will not need sdcard if you try again later!

Jump through some initialization parts in board. C and directly enter the main_loop function, in C2/common/Main. C:

Abortboot () is waiting to be imported using the specified parameter later. After bootdelay seconds, it is triggered by the number of default regions. Here, we encounter two types of function run_command and parse_string_outer, let's first look at the serial number S of the string they are going:

It is in the CMD environment change storage area to retrieve the data, CMD environment change storage location is in the u-boot.lds connected to the variable in the definition, during runtime, S = "Run boot1__android" is allocated here, So run_command searches for a specific comparison character in this region "run "; parse_string_outer uses an effective algorithm for search, which saves time. In fact, the two have the same routing. Here we analyze the first one. Let's take a look at the Run Command, which is available in common/nv_nvedit.c:

Do_run is defined in common/Main. C:

We can see that the for cycle starts from the second dataset. In this example, the second dataset is boot1__android, which is defined in include/configs/pdc2.h:

The greatest condition is included in common/env_common.c:

Therefore, run_command will be used to initialize the bootargs_android, load_kernel, load_ramdisk, $ {kernel_start}, and $ {ramdisk_addr} lines in sequence. However, these parameters are described as follows:

All of them are defined in pdc2.h. We can see that the commands above are actually just a few operators, which makes them easier for us to operate. The final result is to compile the u_boot_cmd command as a specific tool, for example, run load_kernel-> load kernel $ {kernel_addr}-> load kernel 30008000. Let's look at the load command, in common/load. c:

Run the u_boot_cmd command movi. The final result is to move the kernel to the 30008000 address. The last line is bootm $ {kernel_start }$ {ramdisk_addr }, this is where uboot jumps to the kernel. The bootm command is defined in common/cmd_bootm.c:

As you can see, argc = 3, argv [0] = "bootm", argv [1] = "30008040", argv [2] = "31000000 ", specific analysis data:

Here, argc = 3, The else part of the entire row, simple_strtoul first converts the string "30008040" into a hexadecimal number of 0x30008040, memmove contains the uimage header file information, how big is it:

After 64-character encoding, It is the uimage we generated using the mkimage tool, and the zimage and zimage have the 64-character additional information, without such information, uboot cannot correctly initialize the kernel, here is mkimage usage mkimage-A arm-O Linux-T kernel-C none-A 0x30008000-E 0x30008000-N 'linux-2.6.32.9 '-D zimage uimage, address definition in arch/ARM/mach-s5pv210/makefile. in boot (modify the address of the partition to be the same as that of the internal storage), in arch/ARM/boot/makefile
Zreladdr and params_phys; the log information done of the kernel, booting the kernel. in ARCH/ARM/boot/compressed/Misc. in C, the machine-type value must be consistent with that in uboot in arch/ARM/tools/Mach-types; the phys_offset value in the inner must be in arch/ARM/kernel/head. S is used in the arch/ARM/mach-s5pv210/include/Mach/memory. h, so port from kernel2.6 to kernel3.0, where to modify:
2. Arch/ARM/mach-s5pv210/makefile. boot
2. Arch/ARM/mach-s5pv210/include/Mach/memory. h
3. Arch/ARM/mach-s5pv210/include/Mach/map. h
4. Arch/ARM/tools/Mach-types (consistent with uboot)

The mkimage of the kernel operation is in BW-kN/ARCH/ARM/boot/makefile. Next, let's look at the Token Generation. linux_zimage_magic is added in Linux kernel. It is defined in arch/ARM/boot/compressed/head. s to determine whether the kernel image is a Linux kernel. Memmove, memory bytes 64byte content to images. legacy_hdr_ OS _copy. Finally, Jump directly to after_header_check:

Switch sentence, see do_bootm_linux data:

Bi_arch_number is initialized in start_armboot, and the worker uses board_init of smdkc110.c:

In the kernel, we need to determine that the machine ID and the kenel are consistent in order to perform the operation normally. getenv ("bootargs"); As mentioned earlier, let's take a look at the unremembered headers:

Thekernel = (void (*) (INT, Int, uint) EP; convert the address 30008040 into a function. Next, let's look:

The structure struct tag stores the kernel data address assigned to the kernel. The uboot and kernel have a fixed location for storing these data, where are their agreed addresses?

The structure of a series of struct tags stored in this address starts with the setup_start_tag function. The setup_end_tag function is the end, Params-> HDR. tag = atag_core is the initial tag; (struct tag *) BD-> bi_boot_params exists before it. I don't know if it has been noticed. In smdkc110.c:

Originally, the agreed address is 0x30000100, which is exactly the starting point of the Offset memory 0 x bytes. Params-> HDR. the size stores the size of the component. tag_next points to the starting position of the next component, and analyzes it by yourself. The last sentence is Thekernel (0, machid, BD-> bi_boot_params); Thekernel function carries the machid information and the number of transaction environment changes that uboot has worked hard to set, betrayed uboot, and switched to kernel, from this kernel, it controls everything about the system!

Let's take a look at the parameters passed by one ramdisk:

Let's see where the start and end addresses are:

Let's talk about the definition of functions such as image_get_data_size in advance. These functions are all macro-defined, in image. h:

The ramdisk length and other information here are calculated by mkiamge and written into the header file.