碼上歡樂
相關內容    簡體    繁體

[uboot] （番外篇）uboot relocation介紹

本文轉載自   查看原文   2017-01-18 11:17   3407    bootload

http://blog.csdn.net/ooonebook/article/details/53047992

 

以下例子都以project X項目tiny210（s5pv210平台,armv7架構）為例

[uboot] uboot流程系列： 
[project X] tiny210(s5pv210)上電啟動流程（BL0-BL2） 
[uboot] （第一章）uboot流程——概述 
[uboot] （第二章）uboot流程——uboot-spl編譯流程

========================================================================================================

一、relocate介紹

1、uboot的relocate

uboot的relocate動作就是指uboot的重定向動作，也就是將uboot自身鏡像拷貝到ddr上的另外一個位置的動作。

2、uboot為什么要進行relocate

考慮以下問題 
* 在某些情況下，uboot是在某些只讀存儲器上運行，比如ROM、nor flash等等。需要將這部分代碼拷貝到DDR上才能完整運行uboot。 
（當然，如果我們在spl階段就把uboot拷貝到ddr上，就不會有這種情況。但是uboot本身就是要考慮各種可能性） 
* 一般會把kernel放在ddr的低端地址上。

考慮到以上情況，uboot的relocation動作會把自己本身relocate到ddr上（前提是在SPL的過程中或者在dram_init中已經對ddr進行初始化了），並且會relocate到ddr的頂端地址使之不會和kernel的沖突。

3、uboot的一些注意事項

  • 既然uboot會把自身relocate到ddr的其他位置上，那么相當於執行地址也會發生變化。也就是要求uboot既要能在relocate正常執行，也要能在relocate之后正常執行。這就涉及到uboot需要使用“位置無關代碼”技術，也就是Position independent code技術。

二、“位置無關代碼”介紹及其原理

1、什么是“位置無關代碼”

“位置無關代碼”是指無論代碼加載到內存上的什么地址上，都可以被正常運行。也就是當加載地址和連接地址不一樣時，CPU也可以通過相對尋址獲得到正確的指令地址。

2、如何生成“位置無關代碼”

（1）生成位置無關代碼分成兩部分 
* 首先是編譯源文件的時候，需要將其編譯成位置無關代碼，主要通過gcc的-fpic選項（也有可能是fPIC,fPIE, mword-relocations選項） 
* 其次是連接時要將其連接成一個完整的位置無關的可執行文件，主要通過ld的-fpie選項

（2）ARM在如何生成“位置無關代碼” 
* 編譯PIC代碼 
在《[uboot] （第四章）uboot流程——uboot編譯流程》中，我們知道gcc的編譯選項如下：

c_flags=-Wp,-MD,arch/arm/mach-s5pc1xx/.clock.o.d -nostdinc -isystem /home/disk3/xys/temp/project-x/build/arm-none-linux-gnueabi-4.8/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.3/include -Iinclude -I/home/disk3/xys/temp/project-x/u-boot/include -I/home/disk3/xys/temp/project-x/u-boot/arch/arm/include -include /home/disk3/xys/temp/project-x/u-boot/include/linux/kconfig.h -I/home/disk3/xys/temp/project-x/u-boot/arch/arm/mach-s5pc1xx -Iarch/arm/mach-s5pc1xx -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -fno-pic -mno-unaligned-access -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -pipe -march=armv7-a -I/home/disk3/xys/temp/project-x/u-boot/arch/arm/mach-s5pc1xx/include -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(clock) -DKBUILD_MODNAME=KBUILD_STR(clock)

重點關注“-mword-relocations -fno-pic”。 
由於使用pic時movt / movw指令會硬編碼16bit的地址域，而uboot的relocation並不支持這個， 
所以arm平台使用mword-relocations來生成位置無關代碼。-fno-pic則表示不使用pic。 
如下./arch/arm/config.mk

# The movt / movw can hardcode 16 bit parts of the addresses in the # instruction. Relocation is not supported for that case, so disable # such usage by requiring word relocations. PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations) PLATFORM_CPPFLAGS += $(call cc-option, -fno-pic)
  • 生成PIE可執行文件 
    在《[uboot] （第四章）uboot流程——uboot編譯流程》中，我們知道ld的連接選項如下：
LDFLAGS_u-boot=-pie --gc-sections -Bstatic -Ttext 0x23E00000

-pie選項用於生成PIE位置無關可執行文件。

3、“位置無關代碼”原理

這里只是個人根據實驗的一些看法。 
“位置無關代碼”主要是通過使用一些只會使用相對地址的指令實現，比如“b”、“bl”、“ldr”、“adr”等等。 
對於一些絕對地址符號（例如已經初始化的全局變量），會將其以label的形式放在每個函數的代碼實現的末端。 
同時，在鏈接的過程中，會把這些label的地址統一維護在.rel.dyn段中，當relocation的時候，方便對這些地址的fix。

綜上，個人覺得，既然使用絕對地址，那么就是說並不是完全的代碼無關，而是說可以通過調整絕對地址符號的label表來實現代碼的搬移。如果不做relocate或者在relocate之前還是需要加載到連接地址的位置上，這里只是個人看法！！！ 
個人也挺迷惑的，不知道對不對，這里希望有知道答案的大神給個意見。

4、.rel.dyn段介紹和使用

前面也說了： 
對於一些絕對地址符號（例如已經初始化的全局變量），會將其以label的形式放在每個函數的代碼實現的末端。 
同時，在鏈接的過程中，會把這些label的地址統一維護在.rel.dyn段中，當relocation的時候，方便對這些地址的fix。 
這邊簡單的給個例子： 
u-boot/common/board_f.c中

static init_fnc_t init_sequence_f[] = { // 這里定義了全局變量init_sequence_f ｝ void board_init_f(ulong boot_flags) { if (initcall_run_list(init_sequence_f)) // 這里使用了全局變量init_sequence_f hang(); ｝

通過如下命令對編譯生成的u-boot

arm-none-linux-gnueabi-objdump -D u-boot > uboot_objdump.txt

board_init_f和init_sequence_f相關的連接地址如下：

Disassembly of section .text:
23e08428 <board_init_f>: 23e08438: e59f000c ldr r0, [pc, #12] ; 23e0844c <board_init_f+0x24> // 通過ldr r0, [pc, #12]，相當於是ldr r0,[23e0844c] , // 也就是通過后面的label項，獲得了init_sequence_f的地址。 23e0844c: 23e35dcc mvncs r5, #204, 26 ; 0x3300 // 23e0844c: 23e35dcc 是一個label項，23e0844c表示這個label的地址，23e35dcc表示這個label里面的值，也就是全局變量23e35dcc的地址。 Disassembly of section .data: 23e35dcc <init_sequence_f>: // 全局變量init_sequence_f的地址在23e35dcc Disassembly of section .rel.dyn: 23e37b88: 23e0844c mvncs r8, #76, 8 ; 0x4c000000 23e37b8c: 00000017 andeq r0, r0, r7, lsl r0 // 把init_sequence_f的label的地址存在.rel.dyn段中，方便后續relocation的時候，對label中的絕對變量地址進行整理修改。

  • 各個符號的地址意義

    • 23e08428，是board_init_f的地址
    • 23e35dcc，是init_sequence_f的地址
    • 23e0844c，是board_init_f為init_sequence_f做的label的地址，所以其值是init_sequence_f的地址，也就是23e35dcc
    • 23e37b88，把init_sequence_f的label的地址存放在.rel.dyn段中的這個位置

  • 根據上述對全局變量的尋址進行簡單的說明 
    當board_init_f讀取init_sequence_f時，會通過相對偏移獲取init_sequence_f的label的地址（23e0844c），再從23e0844c中獲取到init_sequence_f的地址（23e35dcc）。

綜上，當uboot對自身進行relocate之后，此時全局變量的絕對地址已經發生變化，如果函數按照原來的label去獲取全局變量的地址的時候，這個地址其實是relocate之前的地址。因此，在relocate的過程中需要對全局變量的label中的地址值進行修改，所以uboot將這些label的地址全部維護在.rel.dyn段中，然后再統一對.rel.dyn段指向的label進行修改。后續代碼可以看出來。

三、uboot relocate代碼介紹

1、uboot relocate地址和布局。

前面已經說明，uboot的relocation動作會把自己本身relocate到ddr上（前提是在SPL的過程中或者在dram_init中已經對ddr進行初始化了），並且會relocate到ddr的頂端地址使之不會和kernel的沖突。 
但是relocate過程中，並不是直接把uboot直接放到ddr的頂端位置，而是會有一定的布局，預留一些空間給其他一些需要固定空間的功能使用。

  • uboot relocate從高地址到低地址布局如下（並不是所有的區域都是需要的，可以根據宏定義來確定），注意，對應區域的size在這個時候都是確定的，不會發生變化了。
relocate區域 size
prom頁表區域 8192byte
logbuffer LOGBUFF_RESERVE
pram區域 CONFIG_PRAM<<10
round_4k 用於4kb對齊
mmu頁表區域 PGTABLE_SIZE
video buffer 不關心。但是是確定的。不會隨着代碼變化
lcd buffer 不關心。但是是確定的。不會隨着代碼變化
trace buffer CONFIG_TRACE_BUFFER_SIZE
uboot代碼區域 gd->mon_len，並且對齊4KB對齊
malloc內存池 TOTAL_MALLOC_LEN
Board Info區域 sizeof(bd_t)
新global_data區域 sizeof(gd_t)
fdt區域 gd->fdt_size
對齊 16b對齊
堆棧區域 無限制

2、relocate代碼流程

主要是分成如下流程 
* 對relocate進行空間規划 
* 計算uboot代碼空間到relocation的位置的偏移 
* relocate舊的global_data到新的global_data的空間上 
* relocate舊的uboot代碼空間到新的空間上去 
* 修改relocate之后全局變量的label。（不懂的話參考第二節） 
* relocate中斷向量表

（1）首先看一下relocate的整體代碼 
去掉無關代碼的代碼如下： 
arch/arm/lib/crt0.S

ENTRY(_main)
    bl  board_init_f
@@ 在board_init_f里面實現了
@@                             （1）對relocate進行空間規划 @@ （2）計算uboot代碼空間到relocation的位置的偏移 @@ （3）relocate舊的global_data到新的global_data的空間上 ldr sp, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */ bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r9, [r9, #GD_BD] /* r9 = gd->bd */ sub r9, r9, #GD_SIZE /* new GD is below bd */ @@ 把新的global_data地址放在r9寄存器中 adr lr, here ldr r0, [r9, #GD_RELOC_OFF] /* r0 = gd->reloc_off */ add lr, lr, r0 @@ 計算返回地址在新的uboot空間中的地址。b調用函數返回之后，就跳到了新的uboot代碼空間中。 ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ @@ 把uboot的新的地址空間放到r0寄存器中，作為relocate_code的參數 b relocate_code @@ 跳轉到relocate_code中，在這里面實現了 @@ （1）relocate舊的uboot代碼空間到新的空間上去 @@ （2）修改relocate之后全局變量的label @@ 注意，由於上述已經把lr寄存器重定義到uboot新的代碼空間中了，所以返回之后，就已經跳到了新的代碼空間了！！！！！！ bl relocate_vectors @@ relocate中斷向量表

注意上面的注釋，從relocate_code返回之后就已經在新的uboot代碼空間中運行了。

這里簡單地說明一下board_init_f：

static init_fnc_t init_sequence_f[] = { #ifdef CONFIG_SANDBOX setup_ram_buf, #endif setup_mon_len, #ifdef CONFIG_OF_CONTROL fdtdec_setup, #endif #ifdef CONFIG_TRACE trace_early_init, ... } // 可以看出init_sequence_f是一個函數指針數組 void board_init_f(ulong boot_flags) { if (initcall_run_list(init_sequence_f)) // 在這里會init_sequence_f里面的函數 hang(); }

（2）對relocate進行空間規划 
布局已經在上面說過了。 
其規划只要體現在gd一些指針的設置，如下面所示

——————————————————— <—–(gd->ram_top) 
| 最高的區域 
——————————————————— 
| …… 
——————————————————— 
| uboot代碼區域 
——————————————————— <—–(gd->relocaddr) 
| …… 
——————————————————— 
| Board Info區域 
——————————————————— <—–(gd->bd) 
| 新global_data區域 
——————————————————— <—–(gd->new_gd) 
| fdt區域 
——————————————————— <—–(gd->new_fdt) 
| ….. 
——————————————————— <—–(gd->start_addr_sp) 
| 堆棧區域 
———————————————————

在board_init_f中，會依次執行init_sequence_f數組里面函數。其中，和relocate空間規划的函數如下：

static init_fnc_t init_sequence_f[] = { setup_dest_addr, #if defined(CONFIG_SPARC) reserve_prom, #endif #if defined(CONFIG_LOGBUFFER) && !defined(CONFIG_ALT_LB_ADDR) reserve_logbuffer, #endif #ifdef CONFIG_PRAM reserve_pram, #endif reserve_round_4k, #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) && \ defined(CONFIG_ARM) reserve_mmu, #endif #ifdef CONFIG_DM_VIDEO reserve_video, #else # ifdef CONFIG_LCD reserve_lcd, # endif /* TODO: Why the dependency on CONFIG_8xx? */ # if defined(CONFIG_VIDEO) && (!defined(CONFIG_PPC) || defined(CONFIG_8xx)) && \ !defined(CONFIG_ARM) && !defined(CONFIG_X86) && \ !defined(CONFIG_BLACKFIN) && !defined(CONFIG_M68K) reserve_legacy_video, # endif #endif /* CONFIG_DM_VIDEO */ reserve_trace, #if !defined(CONFIG_BLACKFIN) reserve_uboot, #endif #ifndef CONFIG_SPL_BUILD reserve_malloc, reserve_board, #endif setup_machine, reserve_global_data, reserve_fdt, reserve_arch, reserve_stacks,

代碼里面都是一些簡單的減法以及指針的設置。可以參考上述“區域布局”和指針設置自己看一下代碼，這里不詳細說明。 
這里說明一下setup_dest_addr，也就是一些指針的初始化。

static int setup_dest_addr(void) { debug("Monitor len: %08lX\n", gd->mon_len); // gd->mon_len表示了整個uboot代碼空間的大小，如下 // gd->mon_len = (ulong)&__bss_end - (ulong)_start; // 在uboot代碼空間relocate的時候，relocate的size就是由這里決定 debug("Ram size: %08lX\n", (ulong)gd->ram_size); // gd->ram_size表示了ram的size，也就是可使用的ddr的size，在board.c中定義如下 // int dram_init(void) // { // gd->ram_size = PHYS_SDRAM_1_SIZE;也就是0x2000_0000 // return 0; // } #ifdef CONFIG_SYS_SDRAM_BASE gd->ram_top = CONFIG_SYS_SDRAM_BASE; #endif gd->ram_top += get_effective_memsize(); gd->ram_top = board_get_usable_ram_top(gd->mon_len); // gd->ram_top計算ddr的頂端地址 // CONFIG_SYS_SDRAM_BASE(0x2000_0000+0x2000_0000=0x4000_0000) gd->relocaddr = gd->ram_top; // 從gd->ram_top的位置開始分配 debug("Ram top: %08lX\n", (ulong)gd->ram_top); return 0; }

（3）計算uboot代碼空間到relocation的位置的偏移 
同樣在board_init_f中，調用init_sequence_f數組里面的setup_reloc實現。

static int setup_reloc(void) { #ifdef CONFIG_SYS_TEXT_BASE gd->reloc_off = gd->relocaddr - CONFIG_SYS_TEXT_BASE; // gd->relocaddr表示新的uboot代碼空間的起始地址，CONFIG_SYS_TEXT_BASE表示舊的uboot代碼空間的起始地址，二者算起來就是偏移了。 #endif }

（4）relocate舊的global_data到新的global_data的空間上 
同樣在board_init_f中，調用init_sequence_f數組里面的setup_reloc實現。

static int setup_reloc(void) { memcpy(gd->new_gd, (char *)gd, sizeof(gd_t)); // 直接把gd的地址空間拷貝到gd->new_gd中 }

（5）relocate舊的uboot代碼空間到新的空間上去 
代碼在relocate_code中，上述（1）中可以知道此時的r0是uboot的新的地址空間。 
主要目的是把__image_copy_start到__image_copy_end的代碼空間拷貝到新的uboot地址空間中。 
關於__image_copy_start和__image_copy_end可以看《[uboot] （第四章）uboot流程——uboot編譯流程》

ENTRY(relocate_code)
    ldr r1, =__image_copy_start /* r1 <- SRC &__image_copy_start */ // 獲取uboot代碼空間的首地址 subs r4, r0, r1 /* r4 <- relocation offset */ // 計算新舊uboot代碼空間的偏移 beq relocate_done /* skip relocation */ ldr r2, =__image_copy_end /* r2 <- SRC &__image_copy_end */ // 獲取uboot代碼空間的尾地址 copy_loop: ldmia r1!, {r10-r11} /* copy from source address [r1] */ stmia r0!, {r10-r11} /* copy to target address [r0] */ cmp r1, r2 /* until source end address [r2] */ blo copy_loop // 把舊代碼空間復制到新代碼空間中。

（6）修改relocate之后全局變量的label 
需要先完全理解第二節““位置無關代碼”介紹及其原理” 
主要目的是修改label中的地址。 
這里復習一下： 
* 絕對地址符號的地址會放在label中提供位置無關代碼使用 
* label的地址會放在.rel.dyn段中 
綜上，當uboot對自身進行relocate之后，此時全局變量的絕對地址已經發生變化，如果函數按照原來的label去獲取全局變量的地址的時候，這個地址其實是relocate之前的地址。因此，在relocate的過程中需要對全局變量的label中的地址值進行修改，所以uboot將這些label的地址全部維護在.rel.dyn段中，然后再統一對.rel.dyn段指向的label進行修改。后續代碼可以看出來。 
.rel.dyn段部分示例如下：

23e37b88: 23e0844c mvncs r8, #76, 8 ; 0x4c000000 23e37b8c: 00000017 andeq r0, r0, r7, lsl r0 23e37b90: 23e084b4 mvncs r8, #180, 8 ; 0xb4000000 23e37b94: 00000017 andeq r0, r0, r7, lsl r0 23e37b98: 23e084d4 mvncs r8, #212, 8 ; 0xd4000000 23e37b9c: 00000017 andeq r0, r0, r7, lsl r0 23e37ba0: 23e0854c mvncs r8, #76, 10 ; 0x13000000 23e37ba4: 00000017 andeq r0, r0, r7, lsl r0

可以看出.rel.dyn段用了8個字節來描述一個label，其中，高4字節是label地址標識0x17，低4字節就是label的地址。 
所以需要先判斷label地址標識是否正確，然后再根據第四字節獲取label，對label中的符號地址進行修改。

代碼如下：

ENTRY(relocate_code)
    /* * fix .rel.dyn relocations */ ldr r2, =__rel_dyn_start /* r2 <- SRC &__rel_dyn_start */ ldr r3, =__rel_dyn_end /* r3 <- SRC &__rel_dyn_end */ // __rel_dyn段是由鏈接器生成的。 // 把__rel_dyn_start放到r2中，把__rel_dyn_end放到r3中 fixloop: ldmia r2!, {r0-r1} /* (r0,r1) <- (SRC location,fixup) */ // 從__rel_dyn_start開始，加載兩個字節到r0和r1中，高字節存在r1中表示標志，低字節存在r0中，表示label地址。 and r1, r1, #0xff cmp r1, #23 /* relative fixup? */ // 比較高4字節是否等於0x17 bne fixnext // 不等於的話，說明不是描述label地址，進行下一次循環 // label在relocate uboot的時候也已經復制到了新的uboot地址空間了！！！ // 這里要注意，是對新的uboot地址空間label進行修改！！！ /* relative fix: increase location by offset */ add r0, r0, r4 // 獲取新的uboot地址空間的label地址， // 因為r0存的是舊地址空間的label地址，而新地址空間的label地址就是在舊地址空間的label地址加上偏移得到 // r4就是relocate offset，也就是新舊地址空間的偏移 ldr r1, [r0] // 從label中獲取絕對地址符號的地址，存放在r1中 add r1, r1, r4 str r1, [r0] // 根據前面的描述，我們的目的就是要fix label中絕對地址符號的地址，也就是將其修改為新地址空間的地址 // 所以為r1加上偏移之后，重新存儲到label中。 // 后面CPU就可以根據LABEL在新uboot的地址空間中尋址到正確的符號。 fixnext: cmp r2, r3 blo fixloop

（7）relocate中斷向量表 
前面在《[uboot] （第四章）uboot流程——uboot編譯流程》中已經分析了，異常中斷向量表的定義如下 
arch/arm/lib/vectors.S

    .globl  _undefined_instruction
    .globl  _software_interrupt
    .globl  _prefetch_abort
    .globl  _data_abort
    .globl  _not_used
    .globl  _irq
    .globl  _fiq

_undefined_instruction: .word undefined_instruction
_software_interrupt:    .word software_interrupt
_prefetch_abort:    .word prefetch_abort
_data_abort:        .word data_abort
_not_used:      .word not_used
_irq:           .word irq
_fiq:           .word fiq

我們知道arm的異常中斷向量表需要復制到0x00000000處或者0xFFFF0000處（不知道的建議網上度娘一下）。 
當uboot進行relocate之后，其異常處理函數的地址也發生了變化，因此，我們需要把新的異常中斷向量表復制到0x00000000處或者0xFFFF0000處。 
這部分操作就是在relocate_vectors中進行。

異常中斷向量表在uboot代碼空間中的地址如下：

23e00000 <__image_copy_start>: 23e00000: ea0000be b 23e00300 <reset> 23e00004: e59ff014 ldr pc, [pc, #20] ; 23e00020 <_undefined_instruction> 23e00008: e59ff014 ldr pc, [pc, #20] ; 23e00024 <_software_interrupt> 23e0000c: e59ff014 ldr pc, [pc, #20] ; 23e00028 <_prefetch_abort> 23e00010: e59ff014 ldr pc, [pc, #20] ; 23e0002c <_data_abort> 23e00014: e59ff014 ldr pc, [pc, #20] ; 23e00030 <_not_used> 23e00018: e59ff014 ldr pc, [pc, #20] ; 23e00034 <_irq> 23e0001c: e59ff014 ldr pc, [pc, #20] ; 23e00038 <_fiq> // 可以看出以下是異常終端向量表 23e00020 <_undefined_instruction>: 23e00020: 23e00060 mvncs r0, #96 ; 0x60 // 其中，23e00020存放的是未定義指令處理函數的地址，也就是23e00060 // 以下以此類推 23e00024 <_software_interrupt>: 23e00024: 23e000c0 mvncs r0, #192 ; 0xc0 23e00028 <_prefetch_abort>: 23e00028: 23e00120 mvncs r0, #8 23e0002c <_data_abort>: 23e0002c: 23e00180 mvncs r0, #32 23e00030 <_not_used>: 23e00030: 23e001e0 mvncs r0, #56 ; 0x38 23e00034 <_irq>: 23e00034: 23e00240 mvncs r0, #4 23e00038 <_fiq>: 23e00038: 23e002a0 mvncs r0, #10 23e0003c: deadbeef cdple 14, 10, cr11, cr13, cr15, {7} 23e00040 <IRQ_STACK_START_IN>:

所以異常中斷向量表就是從偏移0x20開始的32個字節。

代碼如下（去除掉無關代碼部分）：

ENTRY(relocate_vectors)
    /* * Copy the relocated exception vectors to the * correct address * CP15 c1 V bit gives us the location of the vectors: * 0x00000000 or 0xFFFF0000. */ @@ 注意看注釋，通過cp15協處理器的c1寄存器的V標志來判斷cpu從什么位置獲取中斷向量表， @@ 換句話說，就是中斷向量表應該被復制到什么地方！！！ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ @@ 獲取uboot新地址空間的起始地址，存放到r0寄存器中 mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ ands r2, r2, #(1 << 13) ldreq r1, =0x00000000 /* If V=0 */ ldrne r1, =0xFFFF0000 /* If V=1 */ @@ 獲取cp15協處理器的c1寄存器的V標志，當V=0時，cpu從0x00000000獲取中斷向量表，當V=1時，cpu從0xFFFF0000獲取中斷向量表 @@ 將該地址存在r1中 ldmia r0!, {r2-r8,r10} stmia r1!, {r2-r8,r10} @@ 前面說了異常中斷向量表就是從偏移0x20開始的32個字節。 @@ 所以這里是過濾掉前面的0x20個字節（32個字節，8*4） @@ 但是不明白為什么還要stmia r1!, {r2-r8,r10}，理論上只需要讓r0的值產生0x20的偏移就可以了才對？？？不明白。 @@ 經過上述兩行代碼之后，此時r0的值已經偏移了0x20了 ldmia r0!, {r2-r8,r10} stmia r1!, {r2-r8,r10} @@ 繼續從0x20開始，獲取32個字節，存儲到r1指向的地址，也就是cpu獲取中斷向量表的地址 @@ r2-r8,r10表示從r2到r8寄存器和r10寄存器，一個8個寄存器，每個寄存器有4個字節，所以就從r0指向的地址處獲取到了32個字節 @@ 再把 {r2-r8,r10}的值存放到r1指向的地址，也就是cpu獲取中斷向量表的地址 bx lr @@ 返回 ENDPROC(relocate_vectors)

經過上述，uboot relocate就完成了。


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 [uboot] （番外篇）uboot之fdt介紹 uboot 番外篇--Moddule Zero介紹 Uboot 命令行 介紹 【uboot】uboot調試 [uboot]uboot如何引導系統 框架之番外篇 Uboot分析（一） Uboot分析（三） Uboot詳解
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM