The Text_base in Uboot

Reprint: http://blog.csdn.net/xxblinux/article/details/6281295

We all know that U-boot is divided into two stages, the first stage is (~/cpu/arm920t/start). s) run on Flash (in general), complete the initialization of the hardware, including the watchdog, interrupt cache, etc., and is responsible for moving the code into the SDRAM (when moving to check if their code is in SDRAM), and then complete the C program to run the environment required to build, including the initialization of the stack, etc. Finally execute a jump command:

Ldr pc, _start_armboot

_start_armboot:. Word start_armboot,

The function void Start_armboot (void) entered into/LIB_ARM/BOARD.C, from which it entered the second phase. This is a lot of information on the story, so don't need to say more.

Now for the first phase there are a few problems, I have been not understand, since the code in Flash is to copy themselves into the SDRAM, then in the memory address space s3c2410, there are two of the boot code, the first is in Flash, the second is in the SDRAM. According to the linked script file (~/board/smdk2410/u-boot.lds)

Output_format ("Elf32-littlearm", "Elf32-littlearm", "Elf32-littlearm")
/*output_format ("Elf32-arm", "Elf32-arm", "elf32-arm") */
Output_arch (ARM)
ENTRY (_start)
SECTIONS
{
.    = 0x00000000; /* PostScript: This link start address is actually updated by-ttest $ (test_base) */

. = ALIGN (4);
. Text:
{
CPU/ARM920T/START.O (. Text)
* (. Text)
}

. = ALIGN (4);
. Rodata: {* (. rodata)}

. = ALIGN (4);
. Data: {* (. data)}

. = ALIGN (4);
. Got: {* (. Got)}

. = .;
__u_boot_cmd_start =.;
. U_boot_cmd: {* (. u_boot_cmd)}
__u_boot_cmd_end =.;

. = ALIGN (4);
__bss_start =.;
. BSS: {* (. BSS)}
_end =.;

}
The link command. = 0x00000000; Indicates that the address counter is counted from the 0 address, and that _start is the entry for the program code snippet, then all the address designators in the *.text (Cpu/arm920t/start. s) should be counted from the 0 address, then the label start_armboot (is the void start_armboot (void) function of the entry address) should be in flash, so according to the above analysis,

Ldr pc, _start_armboot

_start_armboot:. Word start_armboot

This statement does not jump to void start_armboot (void) in SDRAM, but instead jumps to void start_armboot (void) in Flash.

So there is a contradiction, in flash there is a piece of code to copy themselves into the SDRAM, resulting in two uboot executable instruction flow, but finally did not jump to the SDRAM to run to improve the speed of instruction execution.

The above realizations are based on the following understandings (which are certainly wrong):

All address labels in the 1.*.text (determined at link time) are generated from the 0 address.

In fact, when Arm-linux-ld executes, the originally defined 0x0 address is updated to the address defined by Text_base.

2.relocate:/* Relocate u-boot to RAM */
ADR R0, _start/* R0 <-Current position of code */
LDR R1, _text_base/* Test if we run from flash or RAM */
CMP r0, r1/* don ' t reloc during debug */
BEQ Stack_setup

LDR R2, _armboot_start
LDR R3, _bss_start
Sub R2, R3, R2/* R2 <-size of Armboot */
Add R2, R0, r2/* R2 <-Source End Address */

If it is not for the debugging phase, the R0 and R1 in this move code are certainly unequal, r0= #0, r1= #TEXT_BASE: 0x33f80000 (in./board/smdk2410/config.mk), so execute the code's own copy and move.

Note: in GNU: ADR R0, _start function is to obtain _start the actual operation of the address value, and LDR R1, _text_base to obtain the data stored in the address _text_base, where ADR r0, _start translated into add r0, (PC + #offset), offset is the ADR r0, _start instruction to _start offsets, determined at the time of the link, this offset is address-independent. LDR R1, the _text_base directive, means that loading data in a program relative offset is another form of index offset loading, equivalent to Ldr r1,[pc+ #offset],offset is LDR R1, _text_base to _text_base offset Amount Note that this usage is not pseudo-directive, the characteristic of pseudo-instruction is LDR R1, =expr/lable_expr. For LDR pseudo-directives, the situation of ads is somewhat different (subtle differences), in the case of ads can refer to Duchunrei <arm Architecture and Programming >144 page.

Compare:

Add R0, (pc+ #offset): (pc+ #offset) is a relative address, which indicates that the address of this instruction upstream or offset is loaded into the r0;

Ldr r1,[pc+ #offset]:[pc+ #offset] is also a relative address, indicating that the data on the address at offset offsets is loaded into R1;

Now continue:

The contradiction that has been analyzed just now, certainly is in the understanding of the deviation, after the u-boot made, from the generated two. Map file (~/u-boot.map and Systen.map), all the address labels are from the beginning of 0x33f80000, is to start with the high address of the SDRAM, equal to the value of text_base, that is, the linker is starting from 0x33f80000 to link the compiled generated target file, instead of starting from 0 address, after viewing, start_armboot=0x33f80d9c, This means that the entry address of the void start_armboot (void) function is in SDRAM (the linker determines), so the execution

Ldr pc, _start_armboot

_start_armboot:. Word start_armboot,

The PC pointer is definitely pointing to the SDRAM, in other words, into the SDRAM, for LDR pc, _start_armboot, it is still gnu in the use of the program relative offset way to load data, translation is Ldr pc, [pc+pc to _start_ Armboot offset value], the result of the _start_armboot address of the number start_armboot into the PC to complete the jump, and the value of start_armboot (function address) is determined at the time of the link, is relative to the text_base. Because all of the addressing in Phase 1 of the uboot is relative to the location (although the linker considers the code for phase 1 to be linked from the address 0x3ff80000), the code for phase 1 is run correctly in Flash where the 0 address starts, If arm's reset vector is in 0x00000001 (assuming), then the code is burned to start from the 0x00000004 place, the power-up can also be run correctly (assuming that arm's reset vector is established in 0x00000004), of course, arm's reset vector is not here, This is just a hypothesis to illustrate the above analysis of phase 1.

Now the last contradiction is that the link script (~/board/smdk2410/u-boot.lds) describes the link address is not the same as the actual link address, because according to the link script, all address labels should be counted from the 0 address, but not. After finding the makefile file, in the top-level makefile file, link the link command in line 166:

$ (LD) $ (ldflags) $ $UNDEF _sym $ (OBJS)/,

Where the ldflags is defined in the top level of the CONFIG.MK 145 lines: Ldflags + =-bstatic-t $ (ldscript)-ttext $ (text_base) $ (platform_ldflags),

The key is-ttext $ (text_base) command, his meaning is that the starting address in Text_base, and text_base in ~/board/smdk2410/config.mk text_base = 0x3ff80000;

To find out why the link started from 0x3ff80000, as for the link script, its main function is to indicate the order of each *.O file, such as the entry address designator (_start), etc., and the two address labels to get the current address

__u_boot_cmd_start =.; Start address of the *.u_boot_cmd segment

. U_boot_cmd: {* (. u_boot_cmd)}
__u_boot_cmd_end =.; End address of the *.u_boot_cmd segment

For use in C programs. __u_boot_cmd_start and __u_boot_cmd_end can be used as a constant for the global.

Summarize:

Because of the use of the-ttext $ (text_base) command, the linker connects Uboot from the address 0x3ff80000, and in the first phase all used destination address addressing is the method of using the current PC value plus minus the offset. So the uboot burned to 0 address in the beginning of Flash, does not affect the first stage of the correct execution.

The Text_base in Uboot