OK6410A 开发板 (三) 13 u-boot-2021.01 boot 解析 U-boot 镜像运行部分 boot 详细解析2 relocate_vectors

从链接角度分析 u-boot.bin 的构成
从运行的角度分析 u-boot.bin 前 64byte  的 relocate

• relocate_vectors 的实现

#ifdef CONFIG_HAS_VBAR
	// 虽然走的是这一套,但是找到的协处理器cp15的C12的实现(DDI0301H_arm1176jzfs_r0p7_trm.pdf)和下面的内容对不上
	// 那就分析 #else 那条路
	// 这条路 其实就是 架构实现(ARM1176) 对(#else那条路) 做出的优化

	// 后面在 DDI0301H_arm1176jzfs_r0p7_trm.pdf P254 找到了,继续分析这条路
	
	/*
	 * If the ARM processor has the security extensions,
	 * use VBAR to relocate the exception vectors.
	 */
	ldr	r0, [r9, #GD_RELOCADDR]	/* r0 = gd->relocaddr */
	mcr     p15, 0, r0, c12, c0, 0  /* Set VBAR */
#else
	/*
	 * Copy the relocated exception vectors to the
	 * correct address
	 * CP15 c1 V bit gives us the location of the vectors:
	 * 0x00000000 or 0xFFFF0000.
	 */
	
	// r0 = gd->relocaddr
	// gd->relocaddr 起始的 8个32bit是 relocated exception vectors
	ldr	r0, [r9, #GD_RELOCADDR]	/* r0 = gd->relocaddr */

	// 读 cp15 Register 1：控制寄存器 ,并选择 选择架构上指定的控制寄存器
	// 读到 r2中
	mrc	p15, 0, r2, c1, c0, 0	/* V bit (bit[13]) in CP15 c1 */

	// bit[13] 
	//该位用于选择异常向量的位置：
	//	0=选择的正常异常向量（地址范围0x00000000-0x0000001C）
	//	1=选择的高异常向量（地址范围0xFFFF0000-0xFFFF001C）。
	//一个实现可以提供一个输入信号来确定复位后该位的状态。

	// 选择目标地址
	ands	r2, r2, #(1 << 13)
	ldreq	r1, =0x00000000		/* If V=0 */
	ldrne	r1, =0xFFFF0000		/* If V=1 */

	// 从 gd->relocaddr 拷贝到 0x00000000,拷贝了8个32bit
	ldmia	r0!, {
    
    r2-r8,r10}
	stmia	r1!, {
    
    r2-r8,r10}
	// 又拷贝了8个32bit
	ldmia	r0!, {
    
    r2-r8,r10}
	stmia	r1!, {
    
    r2-r8,r10}
#endif

gd->relocaddr 的 16个32bit 是什么

 b reset // 占用 1个 32bit
 ldr pc, _undefined_instruction // 占用 1个32bit
 ldr pc, _software_interrupt
 ldr pc, _prefetch_abort
 ldr pc, _data_abort
 ldr pc, _not_used
 ldr pc, _irq
 ldr pc, _fiq
 
_undefined_instruction: .word undefined_instruction // 占用1个32bit
_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
 .balignl 16,0xdeadbeef // 占用1个32bit

0x00000000 在 芯片 memory map 的什么位置 // 0xFFFF0000 不存在于 memory map

0x0000_0000 | 0x07FF_FFFF | 128MB  | Booting Device Region by XOM Setting 		| Mirrored Region
按照 ok6410a 的 电路图 OM[4:0] 为 0011 , Boot device 为  RESERVED

也就是说,但是 没有连接设备,那么 0x0000 0000 在哪里? // TODO

• arch/arm/lib/vectors.S

.globl _start
 .section ".vectors", "ax"

_start:
 b reset

 ldr pc, _undefined_instruction
 ldr pc, _software_interrupt
 ldr pc, _prefetch_abort
 ldr pc, _data_abort
 ldr pc, _not_used
 ldr pc, _irq
 ldr pc, _fiq

 .globl _reset
 .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

 .balignl 16,0xdeadbeef
 
.globl IRQ_STACK_START_IN
IRQ_STACK_START_IN:
 .word 0x0badc0de



宏汇编
	bad_save_user_regs
	irq_save_user_regs
	irq_restore_user_regs
	get_bad_stack
	get_irq_stack
	get_fiq_stack


 .align 5
undefined_instruction:
 get_bad_stack
 bad_save_user_regs
 bl do_undefined_instruction

 .align 5
software_interrupt:
 get_bad_stack
 bad_save_user_regs
 bl do_software_interrupt

 .align 5
prefetch_abort:
 get_bad_stack
 bad_save_user_regs
 bl do_prefetch_abort

 .align 5
data_abort:
 get_bad_stack
 bad_save_user_regs
 bl do_data_abort

 .align 5
not_used:
 get_bad_stack
 bad_save_user_regs
 bl do_not_used


 .align 5
irq:
 get_bad_stack
 bad_save_user_regs
 bl do_irq

 .align 5
fiq:
 get_bad_stack
 bad_save_user_regs
 bl do_fiq

• u-boot.lds

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
    
    
 . = 0x00000000;
 . = ALIGN(4);
 .text :
 {
    
    
  *(.__image_copy_start)
  *(.vectors)
  arch/arm/cpu/arm1176/start.o (.text*)
  board/samsung/ok6410a/lowlevel_init.o (.text*)
  board/samsung/ok6410a/bl2_mmc_copy.o (.text*)
 }

• arch/arm/lib/sections.c

char __image_copy_start[0] __attribute__((section(".__image_copy_start")));

问题

问题:
	relocate 的目标地址 0x0000 0000 在哪里?
		A 还没解决的问题


	relocate 之后,如果异常发生, 0x0000 0000 中的 每一个 入口指令是不是 会 地址相关?
		arm-linux-gnueabi-objdump  -D  u-boot > u-boot.dis 之后
		
		1.还没解决的问题
		发现 b reset 反汇编 为 b   5fb00300
			一旦reset异常发生,
				PC = 0x00000000
				此时 0x00000000 中 是 b reset 吗???
		linux 和 u-boot 也一样, 0x00000000 也写入了指令
		
		为什么 在linux管理时 reset 的时候,还是要执行 u-boot 呢?

		
		2. 已经解决的问题
		发现 ldr pc, _undefined_instruction 反汇编 为 ldr pc, [pc, #20]
		
		看起来 b reset 在 reset异常发生时没问题
		按道理来讲_undefined_instruction异常发生时,就会有问题,因为跳转的地址与pc相关
		之所以没发生问题,是因为做了fixloop
			对以下7个32bit做了fixloop,更改了以下7个32bit的值
			_undefined_instruction: .word undefined_instruction // 占用1个32bit
			_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

			// 第一个32bit ,更改为重定位过后 undefined_instruction 的地址
			// ldr pc, [pc, #20]的时候,pc中的值为重定位过后的函数的值,就不会出现问题了

		以上分析的详细过程原型 请参考 https://blog.csdn.net/u011011827/article/details/115241203