目录
u-boot-1.1.6之cpu/arm920t/start.s分析 (2)
u-boot中.lds连接脚本文件的分析 (12)
分享一篇我总结的uboot学习笔记（转） (15)
U-BOOT内存布局及启动过程浅析 (22)
u-boot中的命令实现 (25)
U-BOOT环境变量实现 (28)
1.相关文件 (28)
2.数据结构 (28)
3.ENV 的初始化 (30)
3.1env_init (30)
3.2 env_relocate (30)
3.3*env_relocate_spec (31)
4. ENV 的保存 (31)
U-Boot环境变量 (32)
u-boot代码链接的问题 (35)
ldr和adr在使用标号表达式作为操作数的区别 (40)
start_armboot浅析 (42)
1.全局数据结构的初始化 (42)
2.调用通用初始化函数 (43)
3.初始化具体设备 (44)
4.初始化环境变量 (44)
5.进入主循环 (44)
u-boot编译过程 (44)
mkconfig文件的分析 (47)
从NAND闪存中启动U-BOOT的设计 (50)
引言 (50)
NAND闪存工作原理 (51)
从NAND闪存启动U-BOOT的设计思路 (51)
具体设计 (51)
支持NAND闪存的启动程序设计 (51)
支持U-BOOT命令设计 (52)
结语 (53)
参考文献 (53)
U-boot给kernel传参数和kernel读取参数—struct tag (以及补充) (53)
1、u-boot给kernel传RAM参数 (54)
2、Kernel读取U-boot传递的相关参数 (56)
3、关于U-boot中的bd和gd (59)
U-BOOT源码分析及移植 (60)
一、u-boot工程的总体结构： (61)
1、源代码组织 (61)
2.makefile简要分析 (61)
3、u-boot的通用目录是怎么做到与平台无关的？ (63)
4、smkd2410其余重要的文件： (63)
二、u-boot的流程、主要的数据结构、内存分配 (64)
1、u-boot的启动流程： (64)
2、u-boot主要的数据结构 (66)
3、u-boot重定位后的内存分布： (68)
三、u-boot的重要细节。 (68)
关于U-boot中命令相关的编程： (73)
四、U-boot在ST2410的移植，基于NOR FLASH和NAND FLASH启动。 (76)
1、从smdk2410到ST2410: (76)
2、移植过程： (76)
3、移植要考虑的问题： (77)
4、SST39VF1601: (77)
5、我实现的flash.c主要部分： (78)
6、增加从Nand 启动的代码： (82)
7、添加网络命令。 (87)
u-boot-1.1.6之cpu/arm920t/start.s分析
/*
* armboot - Startup Code for ARM920 CPU-core
*
* Copyright (c) 2001 Marius Gr鰃er
* Copyright (c) 2002 Alex Z黳ke
* Copyright (c) 2002 Gary Jennejohn
*
* See file CREDITS for list of people who contributed to this
* project.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
#include
#include
/*
************************************************************* ************
*
* Jump vector table as in table 3.1 in [1]
*
************************************************************* ************
*/
//global声明一个符号可被其他文档引用，相当于声明了一个全局变量，.globl和.global相同。
//该部分为处理器的异常处理向量表。地址范围为0x0000 0000 ~ 0x0000 0020,刚好8条指令。.globl _start //u-boot启动入口
_start: b reset //复位向量并且跳转到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 //中断向量
// .word伪操作用于分配一段字内存单元（分配的单元都是字对齐的），并用伪操作中的expr初始化。.long和.int作用与之相同。
_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
// .align伪操作用于表示对齐方式：通过添加填充字节使当前位置满足一定的对齐方式。.balign的作用同.align。
// .align {alignment} {,fill} {,max}
// 其中：alignment用于指定对齐方式，可能的取值为2的次幂，缺省为4。fill是填充内容，缺省用0填充。max是填充字节数最大值，假如填充字节数超过max,
// 就不进行对齐,例如：
// .align 4 /* 指定对齐方式为字对齐*/
.balignl 16,0xdeadbeef
/*
************************************************************* ************
*
* Startup Code (reset vector)
*
* do important init only if we don't start from memory!
* relocate armboot to ram
* setup stack
* jump to second stage
*
************************************************************* ************
*/
// TEXT_BASE在研发板相关的目录中的config.mk文档中定义, 他定义了
// 代码在运行时所在的地址, 那么_TEXT_BASE中保存了这个地址
_TEXT_BASE:
.word TEXT_BASE
// 声明_armboot_start 并用_start 来进行初始化，在board/u-boot.lds中定义。
.globl _armboot_start
_armboot_start:
.word _start
/*
* These are defined in the board-specific linker script.
*/
// 声明_bss_start并用__bss_start来初始化，其中__bss_start定义在和板相关的u-boot.lds中。 // _bss_start保存的是__bss_start这个标号所在的地址, 这里涉及到当前代码所在
// 的地址不是编译时的地址的情况, 这里直接取得该标号对应的地址, 不受编译时
// 地址的影响. _bss_end也是同样的道理.
.globl _bss_start
_bss_start:
.word __bss_start
// 同上
.globl _bss_end
_bss_end:
.word _end
#ifdef CONFIG_USE_IRQ
/* IRQ stack memory (calculated at run-time) */
.globl IRQ_STACK_START
IRQ_STACK_START:
.word 0x0badc0de
/* IRQ stack memory (calculated at run-time) */
.globl FIQ_STACK_START
FIQ_STACK_START:
.word 0x0badc0de
#endif
/*
* the actual reset code
*/
// MRS {} Rd,CPSR|SPSR 将CPSR|SPSR传送到Rd
// 使用这两条指令将状态寄存器传送到一般寄存器，只修改必要的位，再将结果传送回状态寄存器，这样能够最好地完成对CRSP或SPSR的修改
// MSR {} CPSR_|SPSR_,Rm 或是MSR {} CPSR_f|SPSR_f,#
// MRS和MSR配合使用，作为更新PSR的“读取－－修改－－写回”序列的一部分
// bic r0,r1,r2 ;r0:=r1 and not r2
// orr ro,r1,r2 ;r0:=r1 or r2
// 这几条指令执行完毕后，进入SVC32模式，该模式主要用来处理软件中断(SWI)
reset:
/*
* set the cpu to SVC32 mode
*/
mrs r0,cpsr //将CPSR状态寄存器读取，保存到R0中
bic r0,r0,#0x1f
orr r0,r0,#0xd3
msr cpsr,r0 //将R0写入状态寄存器中
/* turn off the watchdog */
//关闭看门狗
#if defined(CONFIG_S3C2400)
# define pWTCON 0x15300000
# define INTMSK 0x14400008 /* Interupt-Controller base addresses */
# define CLKDIVN 0x14800014 /* clock divisor register */
#elif defined(CONFIG_S3C2410)
# define pWTCON 0x53000000
# define INTMSK 0x4A000008 /* Interupt-Controller base addresses */
# define INTSUBMSK 0x4A00001C
# define CLKDIVN 0x4C000014 /* clock divisor register */
#endif
#if defined(CONFIG_S3C2400) || defined(CONFIG_S3C2410)
ldr r0, =pWTCON
mov r1, #0x0
str r1, [r0]
/*
* mask all IRQs by setting all bits in the INTMR - default
*/
//关闭所有中断
mov r1, #0xffffffff
ldr r0, =INTMSK
str r1, [r0]
# if defined(CONFIG_S3C2410)
ldr r1, =0x3ff
ldr r0, =INTSUBMSK
str r1, [r0]
# endif
/* FCLK:HCLK:PCLK = 1:2:4 */
/* default FCLK is 120 MHz ! */
ldr r0, =CLKDIVN
mov r1, #3
str r1, [r0]
#endif /* CONFIG_S3C2400 || CONFIG_S3C2410 */
/*
* we do sys-critical inits only at reboot,
* not when booting from ram!
*/
// B 转移指令，跳转到指令中指定的目的地址
// BL 带链接的转移指令，像B相同跳转并把转移后面紧接的一条指令地址保存到链接寄存器LR（R14）中，以此来完成子程式的调用
// 该语句首先调用cpu_init_crit进行CPU的初始化，并把下一条指令的地址保存在LR中，以使得执行完后能够正常返回。
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
bl cpu_init_crit
#endif
#ifndef CONFIG_SKIP_RELOCATE_UBOOT
//调试阶段的代码是直接在RAM中运行的，而最后需要把这些代码固化到Flash中，因此U-Boot需要自己从Flash转移到
//RAM中运行，这也是重定向的目的所在。
//通过adr指令得到当前代码的地址信息：假如U-boot是从RAM开始运行，则从adr,r0,_start得到的地址信息为
//r0=_start=_TEXT_BASE=TEXT_BASE=0xa3000000;假如U-boot从Flash开始运行，即从处理器对应的地址运行，
//则r0=0x0000,这时将会执行copy_loop标识的那段代码了。
// _TEXT_BASE 定义在board/smdk2410/config.mk中
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
//重新定位代码
//声明_bss_start并用__bss_start来初始化，其中__bss_start定义在和板相关的u-boot.lds中 ldr r2, _armboot_start
ldr r3, _bss_start
sub r2, r3, r2 /* r2 <- size of armboot */
add r2, r0, r2 /* r2 <- source end address */
copy_loop:
ldmia r0!, {r3-r10} /* copy from source address [r0] */
stmia r1!, {r3-r10} /* copy to target address [r1] */
cmp r0, r2 /* until source end addreee [r2] */
ble copy_loop
#endif /* CONFIG_SKIP_RELOCATE_UBOOT */
/* Set up the stack */
//初始化堆栈
stack_setup:
ldr r0, _TEXT_BASE /* upper 128 KiB: relocated uboot */
sub r0, r0, #CFG_MALLOC_LEN /* malloc area */
sub r0, r0, #CFG_GBL_DATA_SIZE /* bdinfo */
#ifdef CONFIG_USE_IRQ
sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
#endif
sub sp, r0, #12 /* leave 3 words for abort-stack */
clear_bss:
ldr r0, _bss_start /* find start of bss segment */
ldr r1, _bss_end /* stop here */
mov r2, #0x00000000 /* clear */
clbss_l:str r2, [r0] /* clear loop... */
add r0, r0, #4
cmp r0, r1
ble clbss_l
#if 0
/* try doing this stuff after the relocation */
ldr r0, =pWTCON
mov r1, #0x0
str r1, [r0]
/*
* mask all IRQs by setting all bits in the INTMR - default
*/
mov r1, #0xffffffff
ldr r0, =INTMR
str r1, [r0]
/* FCLK:HCLK:PCLK = 1:2:4 */
/* default FCLK is 120 MHz ! */
ldr r0, =CLKDIVN
mov r1, #3
str r1, [r0]
/* END stuff after relocation */
#endif
//跳转到start_armboot函数入口，_start_armboot字保存函数入口指针
//start_armboot函数在lib_arm/board.c中实现
ldr pc, _start_armboot
_start_armboot: .word start_armboot
/*
************************************************************* ************
*
* CPU_init_critical registers
*
* setup important registers
* setup memory timing
*
************************************************************* ************
*/
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
cpu_init_crit:
/*
* flush v4 I/D caches
*/
//初始化CACHE
mov r0, #0
mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */
mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */
/*
* disable MMU stuff and caches
*/
//关闭MMU和CACHE
mrc p15, 0, r0, c1, c0, 0
bic r0, r0, #0x00002300 @ clear bits 13, 9:8 (--V- --RS)
bic r0, r0, #0x00000087 @ clear bits 7, 2:0 (B--- -CAM)
orr r0, r0, #0x00000002 @ set bit 2 (A) Align
orr r0, r0, #0x00001000 @ set bit 12 (I) I-Cache
mcr p15, 0, r0, c1, c0, 0
/*
* before relocating, we have to setup RAM timing
* because memory timing is board-dependend, you will
* find a lowlevel_init.S in your board directory.
*/
//初始化RAM时钟。因为内存时钟是依赖开发板硬件的，所以在board的相应目录下可以找到memsetup.s文件
mov ip, lr
bl lowlevel_init //lowlevel_init子程序在board/smdk2410/memsetup.s中实现 mov lr, ip
mov pc, lr
#endif /* CONFIG_SKIP_LOWLEVEL_INIT */
/*
************************************************************* ************
*
* Interrupt handling
*
************************************************************* ************
*/
@
@ IRQ stack frame.
@
#define S_FRAME_SIZE 72
#define S_OLD_R0 68
#define S_PSR 64
#define S_PC 60
#define S_LR 56
#define S_SP 52
#define S_IP 48
#define S_FP 44
#define S_R10 40
#define S_R9 36
#define S_R8 32
#define S_R7 28
#define S_R6 24
#define S_R5 20
#define S_R4 16
#define S_R3 12
#define S_R2 8
#define S_R1 4
#define S_R0 0
#define MODE_SVC 0x13
#define I_BIT 0x80
/*
* use bad_save_user_regs for abort/prefetch/undef/swi ...
* use irq_save_user_regs / irq_restore_user_regs for IRQ/FIQ handling
*/
.macro bad_save_user_regs
sub sp, sp, #S_FRAME_SIZE
stmia sp, {r0 - r12} @ Calling r0-r12
ldr r2, _armboot_start
sub r2, r2, #(CONFIG_STACKSIZE+CFG_MALLOC_LEN)
sub r2, r2, #(CFG_GBL_DATA_SIZE+8) @ set base 2 words into abort stack ldmia r2, {r2 - r3} @ get pc, cpsr
add r0, sp, #S_FRAME_SIZE @ restore sp_SVC
add r5, sp, #S_SP
mov r1, lr
stmia r5, {r0 - r3} @ save sp_SVC, lr_SVC, pc, cpsr
mov r0, sp
.endm
.macro irq_save_user_regs
sub sp, sp, #S_FRAME_SIZE
stmia sp, {r0 - r12} @ Calling r0-r12
add r8, sp, #S_PC
stmdb r8, {sp, lr}^ @ Calling SP, LR
str lr, [r8, #0] @ Save calling PC
mrs r6, spsr
str r6, [r8, #4] @ Save CPSR
str r0, [r8, #8] @ Save OLD_R0
mov r0, sp
.endm
.macro irq_restore_user_regs
ldmia sp, {r0 - lr}^ @ Calling r0 - lr
mov r0, r0
ldr lr, [sp, #S_PC] @ Get PC
add sp, sp, #S_FRAME_SIZE
subs pc, lr, #4 @ return & move spsr_svc into cpsr
.endm
.macro get_bad_stack
ldr r13, _armboot_start @ setup our mode stack
sub r13, r13, #(CONFIG_STACKSIZE+CFG_MALLOC_LEN)
sub r13, r13, #(CFG_GBL_DATA_SIZE+8) @ reserved a couple spots in abort stack
str lr, [r13] @ save caller lr / spsr
mrs lr, spsr
str lr, [r13, #4]
mov r13, #MODE_SVC @ prepare SVC-Mode
@ msr spsr_c, r13
msr spsr, r13
mov lr, pc
movs pc, lr
.endm
.macro get_irq_stack @ setup IRQ stack
ldr sp, IRQ_STACK_START
.endm
.macro get_fiq_stack @ setup FIQ stack
ldr sp, FIQ_STACK_START
.endm
/*
* exception handlers
*/
//以下都是中断处理函数,具体实现在lib_arm目录下interrupts.c .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
#ifdef CONFIG_USE_IRQ
.align 5
irq:
get_irq_stack
irq_save_user_regs
bl do_irq
irq_restore_user_regs
.align 5
fiq:
get_fiq_stack
/* someone ought to write a more effiction fiq_save_user_regs */
irq_save_user_regs
bl do_fiq
irq_restore_user_regs
#else
.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
#endif
u-boot中.lds连接脚本文件的分析
对于.lds文件，它定义了整个程序编译之后的连接过程，决定了一个可执行程序的各个段的存储位置。虽然现在我还没怎么用它，但感觉还是挺重要的，有必要了解一下。
先看一下GNU官方网站上对.lds文件形式的完整描述：
SECTIONS {
...
secname start BLOCK(align) (NOLOAD) : AT ( ldadr)
{ contents} >region:phdr=fill
...
}
s e c n a m e和c o n t e n t s是必须的，其他的都是可选的。下面挑几个常用的看看：
1、secname：段名
2、contents：决定哪些内容放在本段，可以是整个目标文件，也可以是目标文件中的
某段（代码段、数据段等）
3、start：本段连接（运行）的地址，如果没有使用AT（ldadr），本段存储的地址也
是start。GNU网站上说start可以用任意一种描述地址的符号来描述。
4、AT（ldadr）：定义本段存储（加载）的地址。
看一个简单的例子：（摘自《2410完全开发》）
/* nand.lds */
SECTIONS {
firtst 0x00000000 : { head.o init.o }
second 0x30000000 : AT(4096) { main.o }
}
以上，head.o放在0x00000000地址开始处，init.o放在head.o后面，他们的运行地址也是0x00000000，即连接和存储地址相同（没有AT指定）；main.o放在4096（0x1000，是AT指定的，存储地址）开始处，但是它的运行地址在0x30000000，运行之前需要从0 x1000（加载处）复制到0x30000000（运行处），此过程也就用到了读取Nand flash。
这就是存储地址和连接（运行）地址的不同，称为加载时域和运行时域，可以在.lds连接脚本文件中分别指定。
编写好的.lds文件，在用arm-linux-ld连接命令时带-Tfilename来调用执行，如
arm-linux-ld –Tnand.lds x.o y.o –o xy.o。也用-Ttext参数直接指定连接地址，如
arm-linux-ld –Ttext 0x30000000 x.o y.o –o xy.o。
既然程序有了两种地址，就涉及到一些跳转指令的区别，这里正好写下来，以后万一忘记了也可查看，以前不少东西没记下来现在忘得差不多了。。。
ARM汇编中，常有两种跳转方法：b跳转指令、ldr指令向PC赋值。
我自己经过归纳如下：
（1） b step1 ：b跳转指令是相对跳转，依赖当前PC的值，偏移量是通过该指令本身的bit[2 3:0]算出来的，这使得使用b指令的程序不依赖于要跳到的代码的位置，只看指令本身。（2）ldr pc, =step1 ：该指令是从内存中的某个位置（step1）读出数据并赋给PC，同样依赖当前PC的值，但是偏移量是那个位置（step1）的连接地址（运行时的地址），所以可以用它实现从Flash到RAM的程序跳转。
（3）此外，有必要回味一下adr伪指令，U-boot中那段relocate代码就是通过adr实现当前程序是在RAM中还是flash中。仍然用我当时的注释：
relocate: /* 把U-Boot重新定位到RAM */
adr r0, _start /* r0是代码的当前位置*/
/* adr伪指令，汇编器自动通过当前PC的值算出如果执行到_start时PC的值，
放到r0中：
当此段在flash中执行时r0 = _start = 0；当此段在RAM中执行时_start = _TEX
T_BASE(在board/smdk2410/config.mk中指定的值为0x33F80000，即u-boot在
把代码拷贝到RAM中去执行的代码段的开始) */
ldr r1, _TEXT_BASE /* 测试判断是从Flash启动，还是RAM */
/* 此句执行的结果r1始终是0x33FF80000，因为此值是又编译器指定的(ads中设
置，或-D设置编译器参数) */
cmp r0, r1 /* 比较r0和r1，调试的时候不要执行重定位*/
下面，结合u-boot.lds看看一个正式的连接脚本文件。这个文件的基本功能还能看明白，虽然上面分析了好多，但其中那些GNU风格的符号还是着实让我感到迷惑，好菜啊，怪不得连被3家公司鄙视，自己鄙视自己。。。
OUTPUT_FORMAT("elf32littlearm", "elf32littlearm", "elf32littlea rm")
;指定输出可执行文件是elf格式,32位ARM指令,小端
OUTPUT_ARCH(arm)
;指定输出可执行文件的平台为ARM
ENTRY(_start)
;指定输出可执行文件的起始代码段为_start.
SECTIONS
{
. = 0x00000000 ; 从0x0位置开始
. = ALIGN(4) ; 代码以4字节对齐
.text : ;指定代码段
{
cpu/arm920t/start.o (.text) ; 代码的第一个代码部分
*(.text) ;其它代码部分
}
. = ALIGN(4)
.rodata : { *(.rodata) } ;指定只读数据段
. = ALIGN(4);
.data : { *(.data) } ;指定读/写数据段
. = ALIGN(4);
.got : { *(.got) } ;指定got段, got段式是uboot自定义的一个段, 非标准段
__u_boot_cmd_start = . ;把__u_boot_cmd_start赋值为当前位置, 即起始位置
.u_boot_cmd : { *(.u_boot_cmd) } ;指定u_boot_cmd段, uboot把所有的u boot命令放在该段.
__u_boot_cmd_end = .;把__u_boot_cmd_end赋值为当前位置,即结束位置
. = ALIGN(4);
__bss_start = .; 把__bss_start赋值为当前位置,即bss段的开始位置
.bss : { *(.bss) }; 指定bss段
_end = .; 把_end赋值为当前位置,即bss段的结束位置
}
分享一篇我总结的uboot学习笔记（转）
1. 下面代码是系统启动后U-boot上电后运行的第一段代码，他是什么意思？
.globl _start
_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
_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
他们是系统定义的异常，一上电程序跳转到reset异常处执行相应的汇编指令，下面定义出的都是不同的异常，比如软件发生软中断时，CPU就会去执行软中断的指令，这些异常中断在CUP中地址是从0开始，每个异常占4个字节。
reset:
/*
* set the cpu to SVC32 mode
*/
mrs r0,cpsr
bic r0,r0,#0x1f
orr r0,r0,#0xd3
msr cpsr,r0
操作系统先注册一个总的中断，然后去查是由哪个中断源产生的中断，再去查用户注册的中断表，查出来后就去执行用户定义的用户中断处理函数。
ldr pc, _undefined_instruction表示把_undefined_instruction存放的数值存放到pc指针上，_undefined_instruction: .word undefined_instruction表示未定义的这个异常是由.word来定义的，它表示定义一个字，一个32位的数，.word后面的数表示把该标识的编译地址写入当前地址，标识是不占用任何指令的。把标识存放的数值copy到指针pc上面，那么标识上存放的值是什么？是由.word undefined_instruction来指定的，pc就代表你运行代码的地址，她就实现了CPU要做一次跳转时的工作。
什么是编译地址？什么是运行地址？
32位的处理器，它的每一条指令是4个字节，以4个字节存储顺序，进行顺序执行，CPU 是顺序执行的，只要没发生什么跳转，它会顺序进行执行，编译器会对每一条指令分配一个编译地址，这是编译器分配的，在编译过程中分配的地址，我们称之为编译地址。
运行地址是指，程序指令真正运行的地址，是由用户指定的，用户将运行地址烧录到哪里，哪里就是运行的地址。比如有一个指令的编译地址是0x5，实际运行的地址是0x200，如果
用户将指令烧到0x200上，那么这条指令的运行地址就是0x200，当编译地址和运行地址不同的时候会出现什么结果？结果是不能跳转，编译后会产生跳转地址，如果实际地址和编译后产生的地址不相等，那么就不能跳转。C语言编译地址都希望把编译地址和实际运行地址放在一起的，但是汇编代码因为不需要做C语言到汇编的转换，可以人为的去写地址，所以直接写的就是他的运行地址，这就是为什么任何bootloader刚开始会有一段汇编代码，因为起始代码编译地址和实际地址不相等，这段代码和汇编无关，跳转用的运行地址。编译地址和运行地址如何来算呢？假如有两个编译地址a=0x10，b=0x7，b的运行地址是0x300，那么a的运行地址就是b的运行地址加上两者编译地址的差值，a-b=0x10-0x7=0x3，a的运行地址就是0x300+0x3=0x303。
假设uboot上两条指令的编译地址为a=0x33000007和b=0x33000001，这两条指令都落在bank6上，现在要计算出他们对应的运行地址，要找出运行地址的始地址，这个是由用户烧录进去的，假设运行地址的首地址是0x0，则a的运行地址
为0x7，b为0x1，就是这样算出来的。
为什么要分配编译地址？这样做有什么好处，有什么作用？
比如在函数a中定义了函数b，当执行到函数b时要进行指令跳转，要跳转到b函数所对应的起始地址上去，编译时，编译器给每条指令都分配了编译地址，如果编译器已经给分配了地址就可以直接进行跳转，查找b函数跳转指令所对应的表，进行直接跳转，因为有个编译地址和指令对应的一个表，如果没有分配，编译器就查找不到这个跳转地址，要进行计算，非常麻烦。
什么是相对地址？
以NOR Flash为例，NOR Falsh是映射到bank0上面，SDRAM是映射到bank6上面，uboot
和内核最终是在SDRAM上面运行，最开始我们是从Nor Flash的零地址开始往后烧录，uboot 中至少有一段代码编译地址和运行地址是不一样的，编译uboot或内核时，都会将编译地址放入到SDRAM中，他们最终都会在SDRAM中执行，刚开始uboot在Nor Flash中运行，运行地址是一个低端地址，是bank0中的一个地址，但编译地址是bank6中的地址，这样就会导致绝对跳转指令执行的失败，所以就引出了相对地址的概念。那么什么是相对地址呢？至少在bank0中uboot这段代码要知道不能用b+编译地址这样的方法去跳转指令，因为这段代码的编译地址和运行地址不一样，那如何去做呢？要去计算这个指令运行的真实地址，计算出来后再做跳转，应该是b+运行地址，不能出现b+编译地址，而是b+运行地址，而运行地址是算出来的。
_TEXT_BASE:
.word TEXT_BASE //0x33F80000,在board/config.mk中
这段话表示，用户告诉编译器编译地址的起始地址
Uboot启动流程
1. 设置CPU的启动模式
reset:
//设置CPU进入管理模式即设置相应的CPSR程序状态字
/* * set the cpu to SVC32 mode*/
mrs r0,cpsr
bic r0,r0,#0x1f
orr r0,r0,#0xd3
msr cpsr,r0
2. 关闭看门狗，关闭中断，所谓的喂狗是每隔一段时间给某个寄存器置位而已，在实际中会专门启动一个线程或进程会专门喂狗，当上层软件出现故障时就会停止喂狗，停止喂狗之后，cpu会自动复位，一般都在外部专门有一个看门狗，做一个外部的电路，不在cpu内部使用看门狗，cpu内部的看门狗是复位的cpu，当开发板很复杂时，有好几个cpu时，就不能完全让板子复位，但我们通常都让整个板子复位。看门狗每隔短时间就会喂狗，问题是在两次喂狗之间的时间间隔内，运行的代码的时间是否够用，两次喂狗之间的代码是否在两次喂狗的时间延迟之内，如果在延迟之外的话，代码还没改完就又进行喂狗，代码永远也改不完。
//关闭看门狗的实际代码
#if defined(CONFIG_S3C2400) || defined(CONFIG_S3C2410)
ldr r0, =pWTCON //将pwtcon寄存器地址赋给R0
mov r1, #0x0 //r1的内容为0
str r1, [r0] //将R1的内容送到Ro寄存器中去
3. 屏蔽所有中断，为什么要关中断？中断处理中ldr pc是将代码的编译地址放在了指针上，而这段时间还没有搬移代码，所以编译地址上面没有这个代码，如果进行跳转就会跳转到空指针上面
/* * mask all IRQs by setting all bits in the INTMR - default*/
mov r1, #0xffffffff //寄存器中的值全为11111111111111111111111111111111
ldr r0, =INTMSK //将管理中断的寄存器地址赋给ro
str r1, [r0] //将全1的值赋给ro地址中的内容
#if defined(CONFIG_S3C2410)
ldr r1, =0x3ff
ldr r0, =INTSUBMSK
str r1, [r0]
#endif
3. 设置时钟分频，为什么要设置时钟？起始可以不设，系统能不能跑起来和频率没有任何关系，频率的设置是要让外围的设备能承受所设置的频率，如果频率过高则会导致cpu 操作外围设备失败
//设置CPU的频率
/* FCLK:HCLK:PCLK = 1:2:4 */
/* default FCLK is 120 MHz ! */
ldr r0, =CLKDIVN
mov r1, #3
str r1, [r0]
4. 做bank的设置
cpu_init_crit:
/* flush v4 I/D caches，关闭catch*/
mov r0, #0
mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */
mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB *///协处理器
//禁止MMU
/** disable MMU stuff and caches*/
mrc p15, 0, r0, c1, c0, 0
bic r0, r0, #0x00002300 @ clear bits 13, 9:8 (--V- --RS)
bic r0, r0, #0x00000087 @ clear bits 7, 2:0 (B--- -CAM)
orr r0, r0, #0x00000002 @ set bit 2 (A) Align
orr r0, r0, #0x00001000 @ set bit 12 (I) I-Cache
mcr p15, 0, r0, c1, c0, 0 //关闭
为什么要关闭catch和MMU呢？catch和MMU是做什么用的？
Catch是cpu内部的一个2级缓存，她的作用是将常用的数据和指令放在cpu内部，MMU 是用来做虚实地址转换用的，我们的目的是设置控制的寄存器，寄存器都是实地址，如果既要开启MMU又要做虚实地址转换的话，中间还多一步，
先要把实地址转换成虚地址，然后再做设置，但对uboot而言就是起到一个简单的初始化的作用和引导操作系统，如果开启MMU的话，很麻烦，也没必要，所以关闭MMU.
说道catch就必须提到一个关键字Volatile，以后在设置寄存器时会经常遇到，他的本质是告诉编译器不要对我的代码进行优化，优化的过程是将常用的代码取出来放到catch中，它没有从实际的物理地址去取，它直接从cpu的缓存中去取，但常用的代码就是为了感知一
些常用变量的变化，如果正在取数据的时候发生跳变，那么就感觉不到变量的变化了，所以在这种情况下要用Volatile关键字告诉编译器不要做优化，每次从实际的物理地址中去取指令，这就是为什么关闭catch关闭MMU。但在C语言中是不会关闭catch和MMU的，会打开，如果编写者要感知外界变化，或变化太快，从catch中取数据会有误差，就加一个关键字Volatile。
5. bl lowlevel_init下来初始化各个bank，把各个bank设置必须搞清楚，对以后移植复杂的uboot有很大帮助
6.设置完毕后拷贝uboot代码到4k空间，拷贝完毕后执行内存中的uboot代码
以上流程基本上适用于所有的bootloader，这就是step1阶段
7. 问题：如果换一块开发板有可能改哪些东西？
首先，cpu的运行模式，如果需要对cpu进行设置那就设置，管看门狗，关中断不用改，时钟有可能要改，如果能正常使用则不用改，关闭catch和MMU不用改，设置bank有可能要改。最后一步拷贝时看地址会不会变，如果变化也要改，执行内存中代码，地址有可能要改。
8. Nor Flash和Nand Flash本质区别就在于是否进行代码拷贝，也就是下面代码所表述：无论是Nor Flash还是Nand Flash，核心思想就是将uboot代码搬运到内存中去运行，但是没有拷贝bss后面这段代码，只拷贝bss前面的代码，bss代码是放置全局变量的。Bss段代码是为了清零，拷贝过去再清零重复操作
//uboot代码搬运到RAM中去
#ifndef CONFIG_SKIP_RELOCATE_UBOOT
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 //flash中armboot_start的起始地址
ldr r3, _bss_start //uboot_bss的起始地址
sub r2, r3, r2 /* r2 <- size of armboot//uboot实际程序代码的大小 */ add r2, r0, r2 /* r2 <- source end address */
copy_loop:
ldmia r0!, {r3-r10} /* copy from source address [r0] */
stmia r1!, {r3-r10} /* copy to target address [r1] */
cmp r0, r2 /* until source end addreee [r2] */
背景： Board →ar7240(ap93) Cpu →mips 1、首先弄清楚什么是u-boot Uboot是德国DENX小组的开发，它用于多种嵌入式CPU的bootloader程序, uboot不仅支持嵌入式linux系统的引导，当前，它还支持其他的很多嵌入式操作系统。 除了PowerPC系列，还支持MIPS，x86，ARM，NIOS，XScale。 2、下载完uboot后解压，在根目录下，有如下重要的信息（目录或者文件）： 以下为为每个目录的说明： Board：和一些已有开发板有关的文件。每一个开发板都以一个子目录出现在当前目录中，子目录存放和开发板相关的配置文件。它的每个子文件夹里都有如下文件(以ar7240/ap93为例)： Makefile Config.mk Ap93.c 和板子相关的代码 Flash.c Flash操作代码 u-boot.lds 对应的链接文件 common：实现uboot命令行下支持的命令，每一条命令都对应一个文件。例如bootm命令对应就是cmd_bootm.c cpu：与特定CPU架构相关目录，每一款Uboot下支持的CPU在该目录下对应一个子目录，比如有子目录mips等。它的每个子文件夹里都有入下文件： Makefile Config.mk Cpu.c 和处理器相关的代码s Interrupts.c 中断处理代码 Serial.c 串口初始化代码 Start.s 全局开始启动代码 Disk：对磁盘的支持
Doc：文档目录。Uboot有非常完善的文档。 Drivers：Uboot支持的设备驱动程序都放在该目录，比如网卡，支持CFI的Flash，串口和USB等。 Fs：支持的文件系统，Uboot现在支持cramfs、fat、fdos、jffs2和registerfs。 Include：Uboot使用的头文件，还有对各种硬件平台支持的汇编文件，系统的配置文件和对文件系统支持的文件。该目下configs目录有与开发板相关的配置文件，如 ar7240_soc.h。该目录下的asm目录有与CPU体系结构相关的头文件，比如说mips 对应的有asm-mips。 Lib_xxx：与体系结构相关的库文件。如与ARM相关的库放在lib_arm中。 Net：与网络协议栈相关的代码，BOOTP协议、TFTP协议、RARP协议和NFS文件系统的实现。 Tools：生成Uboot的工具，如：mkimage等等。 3、mips架构u-boot启动流程 u-boot的启动过程大致做如下工作： 1、cpu初始化 2、时钟、串口、内存(ddr ram)初始化 3、内存划分、分配栈、数据、配置参数、以及u-boot代码在内存中的位置。 4、对u-boot代码作relocate 5、初始化malloc、flash、pci以及外设(比如，网口) 6、进入命令行或者直接启动Linux kernel 刚一开始由于参考网上代码，我一个劲的对基于smdk2410的板子，arm926ejs的cpu看了N 久，启动过程和这个大致相同。 整个启动中要涉及到四个文件： Start.S →cpu/mips/start.S Cache.S →cpu/mips/cache.S Lowlevel_init.S →board/ar7240/common/lowlevel_init.S Board.c →lib_mips/board.c 整个启动过程分为两个阶段来看： Stage1：系统上电后通过汇编执行代码 Stage2：通过一些列设置搭建了C环境，通过汇编指令跳转到C语言执行. Stage1： 程序从Start.S的_start开始执行.(至于为什么，参考u-boot.lds分析.doc) 先查看start.S文件吧!~ 从_start标记开始会看到一长串莫名奇妙的代码：
u－boot 移植步骤详解 1 U-Boot简介 U-Boot，全称Universal Boot Loader，是遵循GPL条款的开放源码项目。从FADSROM、8xxROM、PPCBOOT逐步发展演化而来。其源码目录、编译形式与Linux内核很相似，事实上，不少U-Boot源码就是相应的Linux内核源程序的简化，尤其是一些设备的驱动程序，这从U-Boot源码的注释中能体现这一点。但是U-Boot不仅仅支持嵌入式Linux 系统的引导，当前，它还支持NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS嵌入式操作系统。其目前要支持的目标操作系统是OpenBSD, NetBSD, FreeBSD,4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, LynxOS, pSOS, QNX, RTEMS, ARTOS。这是U-Boot中Universal的一层含义，另外一层含义则是U-Boot除了支持PowerPC系列的处理器外，还能支持MIPS、x86、ARM、NIOS、XScale等诸多常用系列的处理器。这两个特点正是U-Boot项目的开发目标，即支持尽可能多的嵌入式处理器和嵌入式操作系统。就目前来看，U-Boot对PowerPC系列处理器支持最为丰富，对Linux的支持最完善。其它系列的处理器和操作系统基本是在2002年11 月PPCBOOT 改名为U-Boot后逐步扩充的。从PPCBOOT向U-Boot的顺利过渡，很大程度上归功于U-Boot的维护人德国DENX软件工程中心Wolfgang Denk[以下简称W.D]本人精湛专业水平和持着不懈的努力。当前，U-Boot项目正在他的领军之下，众多有志于开放源码BOOT LOADER移植工作的嵌入式开发人员正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入，以支持更多的嵌入式操作系统的装载与引导。 选择U-Boot的理由： ①开放源码； ②支持多种嵌入式操作系统内核，如Linux、NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS； ③支持多个处理器系列，如PowerPC、ARM、x86、MIPS、XScale； ④较高的可靠性和稳定性； ④较高的可靠性和稳定性； ⑤高度灵活的功能设置，适合U-Boot调试、操作系统不同引导要求、产品发布等； ⑥丰富的设备驱动源码，如串口、以太网、SDRAM、FLASH、LCD、NVRAM、EEPROM、RTC、键盘等； ⑦较为丰富的开发调试文档与强大的网络技术支持； 2 U-Boot主要目录结构 - board 目标板相关文件，主要包含SDRAM、FLASH驱动； - common 独立于处理器体系结构的通用代码，如内存大小探测与故障检测；
数学与软件科学学院实验报告 学期：13至14__ 第_2 学期 2014年3月17 日 课程名称:编译原理专业:2011级5_班 实验编号：01 实验项目：词法分析器指导教师_王开端 姓名：张世镪学号： 2011060566 实验成绩： 一、目的 学习编译原理，词法分析是编译的第一个阶段，其任务是从左至右挨个字符地对源程序进行扫描，产生一个个单词符号，把字符串形式的源程序改造成单词符号串形式的中间程序。执行词法分析的程序称为词法分析程序，也称为词法分析器或扫描器。词法分析器的功能是输入源程序，输出单词符号 做一个关于C的词法分析器，C++实现 二、任务及要求 1．词法分析器产生下述C的单词序列 这个C的所有的单词符号，以及它们的种别编码和内部值如下表： －* / & ＜＜＝＞＞＝＝＝!＝ && || , : ; { } [ ] ( ) ID和NUM的正规定义式为： ID→letter(letter | didit)* NUM→digit digit* letter→a | … | z | A | … | Z
digit→ 0 | … | 9 如果关键字、标识符和常数之间没有确定的算符或界符作间隔，则至少用一个空格作间隔。空格由空白、制表符和换行符组成。 三、大概设计 1. 设计原理 词法分析的任务：从左至右逐个字符地对源程序进行扫描，产生一个个单词符号。 理论基础：有限自动机、正规文法、正规式 词法分析器又称扫描器：执行词法分析的程序 2. 词法分析器的功能和输出形式 功能:输入源程序、输出单词符号 程序语言的单词符号一般分为以下五种：关键字、标识符、常数、运算符、界符。3. 输出的单词符号的表示形式: (单词种别，单词符号的属性值) 单词种别用整数编码，关键字一字一种，标识符统归为一种，常数一种，各种符号各一种。 4. 状态转换图实现
Uboot_for_Tiny6410_移植步骤详解 一、设计要求 1.目的 1)掌握U-boot剪裁编写 2)掌握交叉编译环境的配置 3)掌握U-boot的移植 2.实现的功能 1)U-boot编译成功 2)移植U-boot，使系统支持从NAND FLASH启动 二、设计方案 1.硬件资源 1)ARM处理器：ARM11芯片(Samsung S3C6410A)，基于ARM1176JZF-S核设 计，运行频率533Mhz,最高可达 667Mhz 2)存储器：128M DDR RAM，可升级至 256M；MLC NAND Flash(2GB) 3)其他资源：具有三LCD接口、4线电阻 触摸屏接口、100M标准网络接口、标准DB9 五线串口、Mini USB2.0接口、USB Host 1.1、3.5mm音频输入输出口、标准TV-OUT
接口、SD卡座、红外接收等常用接口；另外 还引出4路TTL串口，另1路TV-OUT、 SDIO2接口(可接SD WiFi)接口等；在板的 还有蜂鸣器、I2C-EEPROM、备份电池、A D 可调电阻、8个中断式按键等。 2.软件资源 1)arm-linux-gcc-4.5.1（交叉编译） 2)u-boot-2010.09.tar.gz arm-linux-gcc-4.5.1-v6-vfp-20101103.t gz 三、移植过程 1.环境搭建 1)建立交叉编译环境 2)去这2个网站随便下载都可以下载得到最 新或者你想要的u-boot。（ https://www.doczj.com/doc/013748428.html,/batch.viewl ink.php?itemid=1694 ftp://ftp.denx.de/pub/u-boot/ ）
AM335x uboot spl分析 芯片到uboot启动流程 ROM → SPL→ uboot.img 简介 在335x 中ROM code是第一级的bootlader。mpu上电后将会自动执行这里的代码，完成部分初始化和引导第二级的bootlader，第二级的bootlader引导第三级bootader，在 ti官方上对于第二级和第三级的bootlader由uboot提供。 SPL To unify all existing implementations for a secondary program loader (SPL) and to allow simply adding of new implementations this generic SPL framework has been created. With this framework almost all source files for a board can be reused. No code duplication or symlinking is necessary anymore. 1> Basic ARM initialization 2> UART console initialization 3> Clocks and DPLL locking (minimal) 4> SDRAM initialization 5> Mux (minimal) 6> BootDevice initialization(based on where we are booting from.MMC1/MMC2/Nand/Onenand) 7> Bootloading real u-boot from the BootDevice and passing control to it. uboot spl源代码分析 一、makefile分析 打开spl文件夹只有一个makefile 可见spl都是复用uboot原先的代码。 主要涉及的代码文件为u-boot-2011.09-psp04.06.00.03/arch/arm/cpu/armv7 u-boot-2011.09-psp04.06.00.03/arch/arm/lib u-boot-2011.09-psp04.06.00.03/drivers LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-spl.lds 这个为链接脚本 __image_copy_end _end 三、代码解析 __start 为程序开始（arch/arm/cpu/armv7/start.S） .globl _start 这是在定义u-boot的启动定义入口点，汇编程序的缺省入口是 start 标号，用户也可以在连接脚本文件中用ENTRY标志指明其它入口点。
?UBoot源码解析（一）
主要内容 ?分析UBoot是如何引导Linux内核 ?UBoot源码的一阶段解析
BootLoader概念?Boot Loader 就是在操作系统内核运行之前运行 的一段小程序。通过这段小程序，我们可以初始 化硬件设备、建立内存空间的映射图，从而将系 统的软硬件环境带到一个合适的状态，以便为最 终调用操作系统内核准备好正确的环境 ?通常，Boot Loader 是严重地依赖于硬件而实现 的，特别是在嵌入式世界。因此，在嵌入式世界 里建立一个通用的Boot Loader 几乎是不可能的。 尽管如此，我们仍然可以对Boot Loader 归纳出 一些通用的概念来，以指导用户特定的Boot Loader 设计与实现。
UBoot来源?U-Boot 是 Das U-Boot 的简称，其含义是 Universal Boot Loader，是遵循 GPL 条款的开放源码项目。最早德国 DENX 软件工程中心的 Wolfgang Denk 基于 8xxROM 和 FADSROM 的源码创建了 PPCBoot 工程项目，此后不断 添加处理器的支持。而后，Sysgo Gmbh 把 PPCBoot 移 植到 ARM 平台上，创建了 ARMBoot 工程项目。最终， 以 PPCBoot 工程和 ARMBoot 工程为基础，创建了 U- Boot 工程。 ?而今，U-Boot 作为一个主流、通用的 BootLoader，成功地被移植到包括 PowerPC、ARM、X86 、MIPS、NIOS、XScale 等主流体系结构上的百种开发板，成为功能最多、 灵活性最强，并且开发最积极的开源 BootLoader。目前。 U-Boot 仍然由 DENX 的 Wolfgang Denk 维护
常用U-boot命令详解(z) 2010-09-30 15:05:52| 分类：学习心得体会|字号订阅 U-boot发展到现在，他的命令行模式已经非常接近Linux下的shell了，在我编译的 U-boot-2009.11中的命令行模式模式下支持“Tab”键的命令补全和命令的历史记录功能。而且如果你输入的命令的前几个字符和别的命令不重复，那么你就只需要打这几个字符即可，比如我想看这个U-boot的版本号，命令就是“ version”，但是在所有的命令中没有其他任何一个的命令是由“v”开头的，所以只需要输入“v”即可。 [u-boot@MINI2440]# version U-Boot 2009.11 ( 4月04 2010 - 12:09:25) [u-boot@MINI2440]# v U-Boot 2009.11 ( 4月04 2010 - 12:09:25) [u-boot@MINI2440]# base Base Address: 0x00000000 [u-boot@MINI2440]# ba Base Address: 0x00000000 由于U-boot支持的命令实在太多，一个一个细讲不现实，也没有必要。所以下面我挑一些烧写和引导常用命令介绍一下，其他的命令大家就举一反三，或者“help”吧！ （1）获取帮助 命令：help 或? 功能：查看当前U-boot版本中支持的所有命令。 [u-boot@MINI2440]#help ?- alias for'help' askenv - get environment variables from stdin base - print or set address offset bdinfo - print Board Info structure bmp - manipulate BMP image data boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootelf - Boot from an ELF image in memory bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol
i.MX6UL -- Linux系统移植过程详解(最新的长期支持版本) ?开发平台：i.MX 6UL ?最新系统： u-boot2015.04 + Linux4.1.15_1.2.0 ?交叉编译工具：dchip-linaro-toolchain.tar.bz2 源码下载地址： U-Boot: (选择rel_imx_4.1.15_1.2.0_ga.tar.bz2) https://www.doczj.com/doc/013748428.html,/git/cgit.cgi/imx/uboot-imx.git/ Kernel: (选择rel_imx_4.1.15_1.2.0_ga.tar.bz2) https://www.doczj.com/doc/013748428.html,/git/cgit.cgi/imx/linux-2.6-imx.git/ 源码移植过程： 1、将linux内核及uBoot源码拷贝到Ubuntu12.04系统中的dchip_imx6ul目录下； 2、使用tar命令分别将uboot和kernel解压到dchip_imx6ul目录下； 3、解压后进入uboot目录下，新建文件make_dchip_imx6ul_uboot201504.sh，且文件内容如下： ################################################################### # Build U-Boot.2015.04 For D518--i.MX6UL By FRESXC # ################################################################### #!/bin/bash export ARCH=arm export CROSS_COMPILE=
uboot版本文件结构的更新改变 分类：ARM2011-09-22 12:57 339人阅读评论(0) 收藏举报本来是开始分析uboot代码的，但是无论是教材还是网上资料都对于我最新下的uboot原码结构不同，对于还是小白的我不容易找到相应的文件，下面是uboot版本中文件组织结构的改变，，，，， u-boot版本情况 网站：http://ftp.denx.de/pub/u-boot/ 1、版本号变化： 2008年8月及以前 按版本号命名：u-boot-1.3.4.tar.bz2(2008年8月更新) 2008年8月以后均按日期命名。 目前最新版本：u-boot-2011.06.tar.bz2（2011年6月更新） 2、目录结构变化： u-boot目录结构主要经历过2次变化，u-boot版本第一次从u-boot-1.3.2开始发生变化，主要增加了api的内容；变化最大的是第二次，从2010.6版本开始。 u-boot-2010.03及以前版本 ├── api存放uboot提供的接口函数 ├── board根据不同开发板定制的代码，代码也不少 ├── common通用的代码，涵盖各个方面，已命令行处理为主 ├── cpu与体系结构相关的代码，uboot的重头戏 ├── disk磁盘分区相关代码 ├── doc文档，一堆README开头的文件 ├── drivers驱动，很丰富，每种类型的设备驱动占用一个子目录 ├── examples示例程序 ├── fs文件系统，支持嵌入式开发板常见的文件系统 ├── include头文件，已通用的头文件为主 ├── lib_【arch】与体系结构相关的通用库文件 ├── nand_spl NAND存储器相关代码 ├── net网络相关代码，小型的协议栈 ├── onenand_ipl
2 uboo t 源码分析 2.5.1.star t.S 2.5.1.star t.S 引入引入 2.5.1.1、u-boot.lds中找到start.S入口 (1)在C语言中整个项目的入口就是 main函数（这是 个.c文件的项目，第一个要分析的文件就是包含了C语言规定的），所以譬如说一 个有 main函数的那个文件。 10000 ( 2 方。ENTRY(_start)因此 _start 符号所在的文件就是整个程序的起始文 件， _sta rt 所在处的 代码就是整个程序的起始代码。 2.5.1.2、SourceInsight中如何找到 文件 (1)当前状况：我们知道在uboot中的1000多个文件中有一个符号 叫 _start，但是我们不知道 这个符号在哪个文件中。这种情况下要查找一个符号在所有项目中文件中的引用，要使用SourceInsight的搜索功能。 (2)start.s 在cpu/arm_cortexa9/start.s (3)然后进入start.S文件中，发现 个uboot的入口代码，就是第57 57行中就 是行。_sta rt 标号的定义处，于是乎我们就找到了整 2.5.1.3、SI中找文件技巧 (1)以上，找到了start.S文件，下面我们就从start.S文件开始分析uboot第一阶段。 (2)在SI中，如果我们知道我们要找的文件的名字，但是我们又不知道他在哪个目录下，我 们要怎样找到并打开这个文件？方法是在 SI中先打开右边的工程项目管理栏目，然后点击 最左边那个（这个是以文件为单位来浏览的），然后在上面输入栏中输入要找的文件的名 字。我们在输入的时候，SI在不断帮我们进行匹配，即使你不记得文件的全名只是大概记 得名字，也能帮助你找到你要找的文件。 2.5.2.start.S解析1 2.5.2.1、不简单的头文件包含
uboot 下载内核和文件系统的步骤 1)下载linux到系统的SDRAM运行(仅做测试之用，断电或退出后就会消失) 1>运行Uboot，设置环境变量 Uboot>setenv bootargs root=/dev/ram rw initrd=0x21100000,6000000 ramdisk_size=15360 console=ttyS0,115200,mem=32M 启动系统环境变量 Uboot>setenv ethaddr 12:34:56:78:99:aa mac 地址 Uboot>setenv ipaddr [目标板 ip 地址] 目标板 ip 地址 Uboot>setenv serverip [主机 ip 地址] 主机 ip 地址 2>下载linux内核，文件系统 打开tftpserver应用程序，设置根目录路径，将内核、文件系统等拷贝到所设置的根目录下。 Uboot>tftp 21100000 ramdisk.gz 下载文件系统 Uboot>tftp 21000000 uImage 下载 linux 内核 Uboot>bootm 21000000 启动 linux 然后linux操作系统就开始运行。 2)烧写 Linux 到系统的 Flash 运行 1>设置运行Linux的环境变量 Uboot> setenv bootargs root=/dev/ram rw initrd=0x21100000,6000000 ramdisk_size=15360 console=ttyS0,115200,mem=32M 启动系统环境变量Uboot>setenv image cp.b 10020000 21000000 b0000 拷贝内核到sdram Uboot>setenv ramdisk cp.b 100d0000 21100000 226000 拷贝文件系统到sdram Uboot>setenv boot bootm 设置变量boot Uboot>setenv bootcmd run ramdisk\;run image\;run boot 设置默认变量bootcmd Uboot>setenv ethaddr 12:34:56:78:99:aa mac 地址 Uboot>setenv ipaddr 目标板 ip 地址目标板 ip 地址，由你自己决定Uboot>setenv serverip 主机ip地址主机ip地址，就是你的PC的ip Uboot>saveenv 保存环境变量 2>烧写Linux内核到Flash Uboot>tftp 21100000 ramdisk.gz Uboot>cp.b 21100000 100d0000 226000
#include
Common目录下面与环境变量有关的文件有以下几个：env_common.c，env_dataflash.c，env_eeprom.c，env_flash.c，env_nand.c，env_nowhere.c，env_nvram.c，environment.c。 env_common.c中包含的是default_environment[]的定义； env_dataflash.c，env_eeprom.c，env_flash.c，env_nand.c， env_nvram.c 中包含的是相应存储器与环境变量有关的函数：env_init(void)，saveenv(void)，env_relocate_spec (void)，env_relocate_spec (void)，use_default()。至于env_nowhere.c，因为我们没有定义CFG_ENV_IS_NOWHERE，所以这个文件实际上没有用。 environment.c这个文件时是我真正理解环境变量的一个关键。在这个文件里定义了一个完整的环境变量的结构体，即包含了这两个ENV_CRC（用于CRC校验），Flags（标志有没有环境变量的备份，根据CFG_REDUNDAND_ENVIRONMENT这个宏定义判断）。定义这个环境变量结构体的时候还有一个非常重要的关键字： __PPCENV__，而__PPCENV__在该.c文件中好像说是gnu c编译器的属性,如下： # define __PPCENV__ __attribute__ ((section(".text"))) 意思是把这个环境变量表作为代码段，所以在编译完UBOOT后，UBOOT的代码段就会有环境变量表。当然，这要在我们定义了ENV_IS_EMBEDDED之后才行，具体而言，环境变量表会在以下几个地方出现（以nand flash为例）： 1、UBOOT中的代码段（定义了ENV_IS_EMBEDDED）， 2、UBOOT中的默认环 境变量， 3、紧接UBOOT（0x0 ~ 0x1ffff）后面：0x20000 ~ 0x3ffff 之间，包括备份的环境变量，我们读取，保存也是对这个区域（即参数区）进行的。3、SDRAM中的UBOOT中，包括代码段部分和默认部分，4、SDRAM中的melloc分配的内存空间中。 Environment.c代码如下： env_t environment __PPCENV__ = { ENV_CRC, /* CRC Sum */ #ifdef CFG_REDUNDAND_ENVIRONMENT 1, /* Flags: valid */ #endif { #if defined(CONFIG_BOOTARGS) "bootargs=" CONFIG_BOOTARGS "\0" #endif #if defined(CONFIG_BOOTCOMMAND) "bootcmd=" CONFIG_BOOTCOMMAND "\0" #endif #if defined(CONFIG_RAMBOOTCOMMAND) "ramboot=" CONFIG_RAMBOOTCOMMAND "\0"
嵌入式Linux之我行——u-boot-2009.08在2440上的移植详解（一） 嵌入式Linux之我行，主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验，二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处，谢请指正。 ?共享资源，欢迎转载：https://www.doczj.com/doc/013748428.html, 一、移植环境 ?主机：VMWare--Fedora 9 ?开发板：Mini2440--64MB Nand,Kernel:2.6.30.4 ?编译器：arm-linux-gcc-4.3.2.tgz ?u-boot：u-boot-2009.08.tar.bz2 二、移植步骤 本次移植的功能特点包括： ?支持Nand Flash读写 ?支持从Nor/Nand Flash启动 ?支持CS8900或者DM9000网卡 ?支持Yaffs文件系统 ?支持USB下载(还未实现) 1.了解u-boot主要的目录结构和启动流程，如下图。
u-boot的stage1代码通常放在cpu/xxxx/start.S文件中，他用汇编语言写成；u-boot的stage2代码通常放在lib_xxxx/board.c文件中，他用C语言写成。各个部分的流程图如下：
2. 建立自己的开发板项目并测试编译。 目前u-boot对很多CPU直接支持，可以查看board目录的一些子目录，如：board/samsung/目录下就是对三星一些ARM 处理器的支持，有smdk2400、smdk2410和smdk6400，但没有2440，所以我们就在这里建立自己的开发板项目。 1）因2440和2410的资源差不多，主频和外设有点差别，所以我们就在board/samsung/下建立自己开发板的项目，取名叫my2440 2）因2440和2410的资源差不多，所以就以2410项目的代码作为模板，以后再修改
编译原理-词法分析器的设计 一．设计说明及设计要求 一般来说，编译程序的整个过程可以划分为五个阶段：词法分析、语法分析、中间代码生成、优化和目标代码生成。本课程设计即为词法分析阶段。词法分析阶段是编译过程的第一个阶段。这个阶段的任务是从左到右一个字符一个字符地读入源程序，对构成源程序的字符流进行扫描和分解，从而识别出一个个单词（也称单词符号或符号）。如保留字（关键字或基本字）、标志符、常数、算符和界符等等。 二．设计中相关关键字说明 1．基本字：也称关键字，如C语言中的 if , else , while , do ,for,case,break, return 等。 2．标志符：用来表示各种名字，如常量名、变量名和过程名等。 3．常数：各种类型的常数，如12，6.88，和“ABC” 等。 4．运算符：如 + ，- , * , / ,%, < , > ,<= , >= 等。5．界符，如逗点，冒号，分号，括号，# ，〈〈，〉〉等。 三、程序分析 词法分析是编译的第一个阶段，它的主要任务是从左到右逐个字符地对源 程序进行 扫描，产生一个个单词序列，用以语法分析。词法分析工作可以是独立的一遍，把字符流的源程序变为单词序列，输出在一个中间文件上，这个文件做为语法分析程序的输入而继续编译过程。然而，更一般的情况，常将
词法分析程序设计成一个子程序，每当语法分析程序需要一个单词时，则 调用该子程序。词法分析程序每得到一次调用，便从源程序文件中读入一 些字符，直到识别出一个单词，或说直到下一个单词的第一个字符为止。 四、模块设计 下面是程序的流程图 五、程序介绍 在程序当前目录里建立一个文本文档，取名为infile.txt,所有需要分析的程序都写在此文本文档里，程序的结尾必须以“@”标志符结束。程序结果输出在同一个目录下，文件名为outfile.txt，此文件为自动生成。本程序所输出的单词符号采用以下二元式表示：（单词种别，单词自身的值）如程序输出结果(57,"#")(33,"include")(52,"<")(33,"iostream") 等。 程序的功能：（1）能识别C语言中所有关键字（共32个）（单词种别分别为1 — 32 ，详情见程序代码相关部分，下同） （2）能识别C语言中自定义的标示符（单词种别为 33） （3）能识别C语言中的常数（单词种别为0） （4）能识别C语言中几乎所有运算符（单词种别分别为41 — 54） （5）能识别C语言中绝大多数界符（单词种别分别为 55 — 66）六、运行结果 输入文件infile.txt 运行结果（输出文件 outfile.txt）
Uboot启动分析笔记-----Stage1(start.S与lowlevel_init.S详解) Uboot启动分析笔记-----Stage1(start.S与lowlevel_init.S详解) 1 u-boot.lds 首先了解uboot的链接脚本board/my2410/u-boot.lds,它定义了目标程序各部分的链接顺序。OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") /*指定输出可执行文件为ELF格式，32为，ARM小端*/ OUTPUT_ARCH(arm) /*指定输出可执行文件为ARM平台*/ ENTRY(_start) /*起始代码段为_start*/ SECTIONS { /* 指定可执行image文件的全局入口点，通常这个地址都放在ROM(flash)0x0位置*、. = 0x00000000;从0x0位置开始 . = ALIGN(4); 4字节对齐 .text : {
cpu/arm920t/start.o (.text) board/my2440/lowlevel_init.o (.text) *(.text) } . = ALIGN(4); .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } . = ALIGN(4); .data : { *(.data) } /* 只读数据段，所有的只读数据段都放在这个位置*/ . = ALIGN(4); .got : { *(.got) } /*指定got段, got段式是uboot自定义的一个段, 非标准段*/ . = .; __u_boot_cmd_start = .; /*把__u_boot_cmd_start赋值为当前位置, 即起始位置*/ .u_boot_cmd : { *(.u_boot_cmd) } /* u_boot_cmd段，所有的u-boot命令相关的定义都放在这个位置，因为每个命令定义等长，所以只要以__u_boot_cmd_start为起始地址进行查找就可以很快查找到某一个命令的定义，并依据定义的命令指针调用相应的函数进行处理用户的任务*/ __u_boot_cmd_end = .; /* u_boot_cmd段结束位置，由此可以看出，这段空间的长度并没有严格限制，用户可以添加一些u-boot的命令，最终都会在连接是存放在这个位置。*/
关于uboot移植 CAMDIVN与时钟 2010-03-09 19:57 在该文件的122行附近有这样一个结构体 typedef struct { S3C24X0_REG32 LOCKTIME; S3C24X0_REG32 MPLLCON; S3C24X0_REG32 UPLLCON; S3C24X0_REG32 CLKCON; S3C24X0_REG32 CLKSLOW; S3C24X0_REG32 CLKDIVN; } /*__attribute__((__packed__))*/ S3C24X0_CLOCK_POWER; 是用来封装时钟寄存器的，我们要在其中增加一项S3C24X0_REG32 CAMDIVN，为什么加这么一个呢？因为这个寄存器是2410所没有的，而2440在配置时钟的时候又必须用到，看名字我们就知道是用来配置CAMERA时钟的，也就是配置摄像头的时钟的。 貌似和配置uboot启动的时钟没有关系？其实不然，我们在修改下一个文件的时候就可以看到其用途了， 此结构体修改后的结果为 typedef struct { S3C24X0_REG32 LOCKTIME; S3C24X0_REG32 MPLLCON; S3C24X0_REG32 UPLLCON; S3C24X0_REG32 CLKCON; S3C24X0_REG32 CLKSLOW; S3C24X0_REG32 CLKDIVN; S3C24X0_REG32 CAMDIVN; } /*__attribute__((__packed__))*/ S3C24X0_CLOCK_POWER; 第二个文件..\cpu\arm920t\s3c24x0\speed.c 在这个文件中需要修改两个函数 第一个函数在54行附近：static ulong get_PLLCLK(int pllreg) 由于S3C2410和S3C2440的MPLL、UPLL计算公式不一样，所以get_PLLCLK 函数也需要修改：
bootm命令中地址参数，内核加载地址以及内核入口地址 分类：u-boot2010-11-04 10:472962人阅读评论(0)收藏举报downloadlinuxbytecmdheaderimage bootm命令只能用来引导经过mkimage构建了镜像头的内核镜像文件以及根文件镜像，对于没有用mkimage对内核进行处理的话，那直接把内核下载到连接脚本中指定的加载地址0x30008000再运行就行，内核会自解压运行（不过内核运行需要一个tag来传递参数，而这个tag是由bootloader提供的，在u-boot下默认是由bootm命令建立的）。 通过mkimage可以给内核镜像或根文件系统镜像加入一个用来记录镜像的各种信息的头。同样通过mkimage也可以将内核镜像进行一次压缩(指定-C none/gzip/bzip2),所以这里也就引申出了两个阶段的解压缩过程：第一个阶段是u-boot里面的解压缩，也就是将由mkimage压缩的镜像解压缩得到原始的没加镜像头的内核镜像。第二个阶段是内核镜像的自解压，u-boot 里面的解压实际上是bootm 实现的，把mkimage -C bzip2或者gzip 生成的uImage进行解压；而kernel的自解压是对zImage进行解压，发生在bootm解压之后。 下面通过cmd_bootm.c文件中对bootm命令进行解析以及执行的过程来分析，这三种不同地址的区别： ulong load_addr = CFG_LOAD_ADDR; /* Default Load Address */ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) { ...... if (argc < 2) { addr = load_addr;//当bootm命令后面不带地址参数时，将默认的加载地址赋值给addr } else { addr = simple_strtoul(argv[1], NULL, 16); //如果bootm命令后面带了加载地址，则将该地址赋值给addr,所以最终有用的地址还是bootm命令后附带的地址 } ...... //