UBOOT详细解读

UBOOT详细解读
UBOOT详细解读

@文件包含处理

#include <>

@由顶层的mkconfig生成,其中只包含了一个文件:configs/<顶层makefile中6个参数的第1个参数>.h

#include <>

#include <>

/*

*************************************************************************

*

* Jump vector table as in table in [1]

*

*************************************************************************

*/

注:ARM微处理器支持字节(8位)、半字(16位)、字(32位)3种数据类型

@向量跳转表,每条占四个字节(一个字),地址范围为0x0000 0000~@0x0000 0020

@ARM体系结构规定在上电复位后的起始位置,必须有8条连续的跳

@转指令,通过硬件实现。他们就是异常向量表。ARM在上电复位后,@是从0x00000000开始启动的,其实如果bootloader存在,在执行

@下面第一条指令后,就无条件跳转到start_code,下面一部分并没@执行。设置异常向量表的作用是识别bootloader。以后系统每当有@异常出现,则CPU会根据异常号,从内存的0x00000000处开始查表@做相应的处理

/******************************************************

;当一个异常出现以后,ARM会自动执行以下几个步骤:

;1.把下一条指令的地址放到连接寄存器LR(通常是R14).---保存位置

;2.将相应的CPSR(当前程序状态寄存器)复制到SPSR(备份的程序状态寄存器)中---保存CPSR

;3.根据异常类型,强制设置CPSR的运行模式位

;4.强制PC(程序计数器)从相关异常向量地址取出下一条指令执行,从而跳转到相应的异常处理程序中

*********************************************************/

.globl _start /*系统复位位置,整个程序入口*/

@_start是GNU汇编器的默认入口标签,.globl将_start声明为外部程序可访问的标签,.globl是GNU汇编的保留关键字,前面加点是GNU汇编的语法

_start: b start_code @0x00

@ARM上电后执行的第一条指令,也即复位向量,跳转到start_code

@reset用b,就是因为reset在MMU建立前后都有可能发生

@其他的异常只有在MMU建立之后才会发生

ldr pc, _undefined_instruction /*未定义指令异常,0x04*/

ldr pc, _software_interrupt /*软中断异常,0x08*/

ldr pc, _prefetch_abort /*内存操作异常,0x0c*/

ldr pc, _data_abort /*数据异常,0x10*/

ldr pc, _not_used /*未适用,0x14*/

ldr pc, _irq /*慢速中断异常,0x18*/

ldr pc, _fiq /*快速中断异常,0x1c*/

@对于ARM数据从内存到CPU之间的移动只能通过L/S指令,如:ldr r0,0x为把0x内存中的数据写到r0中,还有一个就是ldr伪指令,如:ldr r0,=0x为把0x地址写到r0中,mov 只能完成寄存器间数据的移动,而且立即数长度限制在8位

_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

@.word为GNU ARM汇编特有的伪操作,为分配一段字内存单元(分配的单元为字对齐的),可以使用.word把标志符作为常量使用。如_fiq:.word fiq即把fiq存入内存变量_fiq中,也即是把fiq放到地址_fiq中。

.balignl 16,0xdeadbeef

@.balignl是.balign的变体

@ .align伪操作用于表示对齐方式:通过添加填充字节使当前位置

@满足一定的对齐方式。.balign的作用同.align。

@ .align {alignment} {,fill} {,max}

@ 其中:alignment用于指定对齐方式,可能的取值为2的次

@幂,缺省为4。fill是填充内容,缺省用0填充。max是填充字节@数最大值,如果填充字节数超过max, 就不进行对齐,例如:

@ .align 4 /* 指定对齐方式为字对齐 */

【参考好野人的窝,于关u-boot中的.balignl 16,0xdeadbeef的理解】

/*

*************************************************************************

*

* Startup Code (called from the ARM reset exception vector)

*

* do important init only if we don't start from memory!

* relocate armboot to ram

* setup stack

* jump to second stage

*

*************************************************************************

@保存变量的数据区,保存一些全局变量,用于BOOT程序从FLASH拷贝@到RAM,或者其它的使用。

@还有一些变量的长度是通过连接脚本里得到,实际上由编译器算出

@来的

_TEXT_BASE:

@因为linux开始地址是0x,我这里是64M SDRAM,所以@TEXT_BASE = 0x33F80000 ?

.word TEXT_BASE /*uboot映像在SDRAM中的重定位地址*/

@TEXT_BASE在开发板相关的目录中的文档中定义, 他定

@义了代码在运行时所在的地址, 那么_TEXT_BASE中保存了这个地

@址(这个TEXT_BASE怎么来的还不清楚)

.globl _armboot_start

_armboot_start:

.word _start

@用_start来初始化_armboot_start。(为什么要这么定义一下还不明白)

/*

* These are defined in the board-specific linker script.

*/

@下面这些是定义在开发板目录链接脚本中的

.globl _bss_start

_bss_start:

.word __bss_start

@__bss_start定义在和开发板相关的中,_bss_start保存的是__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 start code

*/

@复位后执行程序

@真正的初始化从这里开始了。其实在CPU一上电以后就是跳到这里执行的reset:

/*

* set the cpu to SVC32 mode

*/

@更改处理器模式为管理模式

@对状态寄存器的修改要按照:读出-修改-写回的顺序来执行

@

31 30 29 28 --- 7 6 - 4 3 2 1 0

N Z C V I F M4 M3 M2 M1 M0

0 0 0 0 0 User26 模式

0 0 0 0 1 FIQ26 模式

0 0 0 1 0 IRQ26 模式

0 0 0 1 1 SVC26 模式

1 0 0 0 0 User 模式

1 0 0 0 1 FIQ 模式

1 0 0 1 0 IRQ 模式

1 0 0 1 1 SVC 模式

1 0 1 1 1 ABT 模式

1 1 0 1 1 UND 模式

1 1 1 1 1 SYS 模式

mrs r0,cpsr

@将cpsr的值读到r0中

bic r0,r0,#0x1f

@清除M0~M4

orr r0,r0,#0xd3

@禁止IRQ,FIQ中断,并将处理器置于管理模式

msr cpsr,r0

@以下是点灯了,这里应该会牵涉到硬件设置,移植的时候应该可以不要

bl coloured_LED_init

bl red_LED_on

@针对AT91RM9200进行特殊处理

#if defined(CONFIG_AT91RM9200DK) || defined(CONFIG_AT91RM9200EK)

/*

* relocate exception table

*/

ldr r0, =_start

ldr r1, =0x0

mov r2, #16

copyex:

subs r2, r2, #1

@sub带上了s用来更改进位标志,对于sub来说,若发生借位则C标志置0,没有则为1,这跟adds指令相反!要注意。

ldr r3, [r0], #4

str r3, [r1], #4

bne copyex

#endif

@针对S3C2400和S3C2410进行特殊处理

@CONFIG_S3C2400、CONFIG_S3C2410等定义在include/configs/下不同开发板的头文件中#if defined(CONFIG_S3C2400) || defined(CONFIG_S3C2410)

/* turn off the watchdog */

@关闭看门狗定时器的自动复位功能并屏蔽所有中断,上电后看门狗为开,中断为关

# if defined(CONFIG_S3C2400)

# define pWTCON 0x

# define INTMSK 0x /* Interupt-Controller base addresses */

# define CLKDIVN 0x /* clock divisor register */

#else @s3c2410的配置

# define pWTCON 0x

@pWTCON定义为看门狗控制寄存器的地址(s3c2410和s3c2440相同)

# define INTMSK 0x4A000008 /* Interupt-Controller base addresses */

@INTMSK定义为主中断屏蔽寄存器的地址(s3c2410和s3c2440相同)

# define INTSUBMSK 0x4A00001C

@INTSUBMSK定义为副中断屏蔽寄存器的地址(s3c2410和s3c2440相同)

# define CLKDIVN 0x4C000014 /* clock divisor register */

@CLKDIVN定义为时钟分频控制寄存器的地址(s3c2410和s3c2440相同)

# endif

@至此寄存器地址设置完毕

ldr r0, =pWTCON

mov r1, #0x0

str r1, [r0]

@对于S3C2440和S3C2410的WTCON寄存器的[0]控制允许或禁止看门狗定时器的复位输出功能,设置为“0”禁止复位功能。

/*

* 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 @2410好像应该为7ff才对(不理解uboot为何是这个数字)

ldr r0, =INTSUBMSK

str r1, [r0]

# endif

@对于S3C2410的INTMSK寄存器的32位和INTSUBMSK寄存器的低11位每一位对应一个中断,相应位置“1”为不响应相应的中断。对于S3C2440的INTSUBMSK有15位可用,所以应该为0x7fff了。

/* FCLK:HCLK:PCLK = 1:2:4 */

/* default FCLK is 120 MHz ! */

ldr r0, =CLKDIVN

mov r1, #3

str r1, [r0]

@时钟分频设置,FCLK为核心提供时钟,HCLK为AHB(ARM920T,内存@控制器,中断控制器,LCD控制器,DMA和主USB模块)提供时钟,@PCLK为APB(看门狗、IIS、I2C、PWM、MMC、ADC、UART、GPIO、@RTC、SPI)提供时钟。分频数一般选择1:4:8,所以HDIVN=2,PDIVN=1,@CLKDIVN=5,这里仅仅是配置了分频寄存器,

@归纳出CLKDIVN的值跟分频的关系:

@0x0 = 1:1:1 , 0x1 = 1:1:2 , 0x2 = 1:2:2 , 0x3 = 1:2:4, 0x4 = 1:4:4, 0x5 = 1:4:8, 0x6 = 1:3:3,

0x7 = 1:3:6

@S3C2440的输出时钟计算式为:Mpll=(2*m*Fin)/(p*2^s)

S3C2410的输出时钟计算式为:Mpll=(m*Fin)/(p*2^s)

m=M(the value for divider M)+8;p=P(the value for divider P)+2

M,P,S的选择根据datasheet中PLL VALUE SELECTION TABLE表格进行,

我的开发板晶振为,所以输出频率选为:的话M=0x6e,P=3,S=1

@s3c2440增加了摄像头,其FCLK、HCLK、PCLK的分频数还受到CAMDIVN[9](默认为0),CAMDIVN[8](默认为0)的影响

#endif /* CONFIG_S3C2400 || CONFIG_S3C2410 */

/*

* we do sys-critical inits only at reboot,

* not when booting from ram!

*/

@选择是否初始化CPU

#ifndef CONFIG_SKIP_LOWLEVEL_INIT

bl cpu_init_crit

@执行CPU初始化,BL完成跳转的同时会把后面紧跟的一条指令地址保存到连接寄存器LR (R14)中。以使子程序执行完后正常返回。

#endif

@调试阶段的代码是直接在RAM中运行的,而最后需要把这些代码 @固化到Flash中,因此U-Boot需要自己从Flash转移到

@RAM中运行,这也是重定向的目的所在。

@通过adr指令得到当前代码的地址信息:如果U-boot是从RAM @开始运行,则从adr,r0,_start得到的地址信息为

@r0=_start=_TEXT_BASE=TEXT_BASE=0x33F80000; @如果U-boot从Flash开始运行,即从处理器对应的地址运行,

@则r0=0x0000,这时将会执行copy_loop标识的那段代码了。

@ _TEXT_BASE 定义在board/smdk2410/中

#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

@_armboot_start为_start地址

ldr r3, _bss_start

@_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] */

@从源地址[r0]读取8个字节到寄存器,每读一个就更新一次r0地址

@ldmia:r0安字节增长

stmia r1!, {r3-r10} /* copy to target address [r1] */

@LDM(STM)用于在寄存器所指的一片连续存储器和寄存器列表的寄存@器间进行数据移动,或是进行压栈和出栈操作。

@格式为:LDM(STM){条件}{类型}基址寄存器{!},寄存器列表{^}

@对于类型有以下几种情况: IA 每次传送后地址加1,用于移动数

@据块

IB 每次传送前地址加1,用于移动数据块

DA 每次传送后地址减1,用于移动数据块

DB 每次传送前地址减1,用于移动数据块

FD 满递减堆栈,用于操作堆栈(即先移动指针再操作数据,相当于DB)

ED 空递减堆栈,用于操作堆栈(即先操作数据再移动指针,相当于DA)

FA 满递增堆栈,用于操作堆栈(即先移动指针再操作数据,相当于IB)

EA 空递增堆栈,用于操作堆栈(即先操作数据再移动指针,相当于IA)

(这里是不是应该要涉及到NAND或者NOR的读写没有看出来)

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, #CONFIG_SYS_MALLOC_LEN /* malloc area */

@CFG_MALLOC_LEN=128*1024+CFG_ENV_SIZE=128*1024+0x1@0000=192K

sub r0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* bdinfo */

@CFG_GBL_DATA_SIZE 128---size in bytes reserved for initial data 用来存储开发板信息

#ifdef CONFIG_USE_IRQ

@这里如果需要使用IRQ, 还有给IRQ保留堆栈空间, 一般不使用.

sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)

#endif

sub sp, r0, #12 /* leave 3 words for abort-stack */

@该部分将未初始化数据段_bss_start----_bss_end中的数据 @清零

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

@跳到阶段二C语言中去

ldr pc, _start_armboot

_start_armboot: .word start_armboot

@start_armboot在/lib_arm/中,到这里因该是第一阶段已经完成了吧,下面就要去C语言中执行第二阶段了吧

/*

*************************************************************************

*

* CPU_init_critical registers

*

* setup important registers

* setup memory timing

*

*************************************************************************

*/

@CPU初始化

@在“relocate: /* relocate U-Boot to RAM */ ”之前被调用

#ifndef CONFIG_SKIP_LOWLEVEL_INIT

cpu_init_crit:

/*

* flush v4 I/D caches

*/

@初始化CACHES

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和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

@对协处理器的操作还是看不懂,暂时先不管吧,有时间研究一下ARM技术手册的协处理器部分。

/*

* before relocating, we have to setup RAM timing

* because memory timing is board-dependend, you will

* find a in your board directory.

*/

@初始化RAM时钟,因为内存是跟开发板密切相关的,所以这部分在/开发板目录/中实现mov ip, lr

@保存LR,以便正常返回,注意前面是通过BL跳到cpu_init_crit来的。

@(ARM9有37个寄存器,ARM7有27个)

37个寄存器=7个未分组寄存器(R0~R7)+ 2×(5个分组寄存器R8~R12)+6×2(R13=SP,R14=lr 分组寄存器) + 1(R15=PC) +1(CPSR) + 5(SPSR)

用途和访问权限:

R0~R7:USR(用户模式)、fiq(快速中断模式)、irq(中断模式)、svc(超级用法模式)、abt、und

R8~R12:R8_usr~R12_usr(usr,irq,svc,abt,und)

R8_fiq~R12_fiq(fiq)

R11=fp

R12=IP(从反汇编上看,fp和ip一般用于存放SP的值)

R13~R14:R13_usr R14_usr(每种模式都有自己的寄存器)

SP ~lr :R13_fiq R14_fiq

R13_irq R14_irq

R13_svc R14_svc

R13_abt R14_abt

R13_und R14_und

R15(PC):都可以访问(即PC的值为当前指令的地址值加8个字节)

R16 :((Current Program Status Register,当前程序状态寄存器))

SPSR _fiq,SPSR_irq,SPSR_abt,SPSR_und(USR模式没有)

#if defined(CONFIG_AT91RM9200EK)

#else

bl lowlevel_init

@在重定向代码之前,必须初始化内存时序,因为重定向时需要将@flash中的代码复制到内存中lowlevel_init在@/board/smdk2410/中。

#endif

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)

sub r2, r2, #(CONFIG_SYS_MALLOC_LEN)

sub r2, r2, #(CONFIG_SYS_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 r7, sp, #S_PC

stmdb r7, {sp, lr}^ @ Calling SP, LR

str lr, [r7, #0] @ Save calling PC

mrs r6, spsr

str r6, [r7, #4] @ Save CPSR

str r0, [r7, #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)

sub r13, r13, #(CONFIG_SYS_MALLOC_LEN)

sub r13, r13, #(CONFIG_SYS_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

********************************************************/

@异常向量处理

@每一个异常向量处其实只放了一条跳转指令(因为每个异常向量只 @有4个字节不能放太多的程序),跳到相应的异常处理程序中。

.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 /*CONFIG_USE_IRQ*/

@可知的流程为:异常向量——上电复位后进入复位异常向量——跳到启动代码处——设置处理器进入管理模式——关闭看门狗——关闭中断——设置时钟分频——关闭MMU和CACHE ——进入——检查当前代码所处的位置,如果在FLASH中就将代码搬移到RAM中

u-boot启动分析

背景: 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标记开始会看到一长串莫名奇妙的代码:

UBoot移植详解

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 独立于处理器体系结构的通用代码,如内存大小探测与故障检测;

uboot2013.07lds分析

uboot 2013.07 lds 分析 转载自: uboot 2013.07 lds 分 析 .OUTPUT_FORMAT("elf32-littlearm", "elf32- littlearm", //指定输出可执行文件是 elf 格式 ,32 位 ARM 指令 ,小端 OUTPUT_ARCH(arm) //指定输出可执行 文件的平台为 ARMENTRY(_start) // 指定函数入口点为 _start 。 cpu/arm920t/start.S 0x00000000; // 指定可执行 image 文件的全局入口点,通常 这个地址都放在 ROM(flash)0x0 位置。必须使编译器知道这 以4 字节对齐 .text : //代码段 00000000 T __image_copy_start 见 __image_copy_start 等同于 _start CPUDIR/start.o (.text*) // 代码段的第一个代码部分 ALIGN(4); .rodata : "elf32-littlearm") 中定义 SECTIONS{ 个地址,通常都是修改此处来完成 . = ALIGN(4); // 代码 *(.__image_copy_start) // 在 System.map 匚=f 00000000 T _start, *(.text*) //其它代码部分

{ *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } 对应原来的 U_BOOT_CMD 对于那个的段 . KEEP(*(SORT(.u_boot_list*))); * 在 System.map 中 0006f52c D _u_boot_list_2_env_clbk_2_flags 0006f534 D _u_boot_list_2_env_clbk_2_loadaddr 0006f53c B __bss_base 0006f53c B __bss_start 0006f53c B monitor_flash_len 0006f53c D __image_copy_end 0006f53c D __rel_dyn_start //指定只读数据段 . = ALIGN(4); .data : { // 指定读 / 写数据段 *(.data*) ALIGN(4); . = ALIGN(4); .u_boot_list : { // } . = ALIGN(4);/*

AM335x uboot spl分析

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源码分析1

?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 维护

uboot版本文件结构

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

iTop4412的uboot第一阶段

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、不简单的头文件包含

xilinx uboot网卡驱动分析和一些概念扫盲

xilinx uboot网卡驱动分析和一些概念扫盲 1、MAC控制器、网卡、PHY、MDIO、mii、gmii、rgmii概念扫盲 网卡在功能上包含OSI模型的两个层,数据链路层和物理层。物理层定义了数据传送与接收所需要的电与光信号、线路状态、时钟基准、数据编码和电路等,并向数据链路层设备提供标准接口。数据链路层则提供寻址机构、数据帧的构建、数据差错检查、传送控制、向网络层提供标准的数据接口等功能。网卡中负责数据链路的芯片叫做MAC控制器,负责物理层的芯片叫做PHY。所以,一个网卡由MAC控制器和PHY组成。 MAC控制器与PHY连接使用MII(Medium independent interface)媒体独立接口,这个接口是IEEE-802.3定义的以太网行业标准定义的接口,包括一个数据接口和一个MAC和PHY之间的管理接口即MDIO。MII标准接口用于连接MAC和PHY,媒体独立表示不对MAC硬件重新设计或替换的情况下,任何类型的PHY设备接到当前MAC控制器上都可以正常工作。 MII支持10M和100M的网络速率,由于网卡的速率不同,所以在其他速率下工作的与MII等效的接口有:AUI(10M以太网)、GMII(Gigabit以太网)和XAUI(10-Gigabit 以太网)。此外还有RMII、RGMII、SMII、SGMII等。所有这些接口都是由MII而来。MII支持10兆和100兆的操作,一个接口由14根线组成。RMII是简化的MII接口,在数据的收发上它比MII接口少了一倍的信号线。SMII是由思科提出的一种媒体接口,它有比RMII更少的信号线数目,S表示串行的意思。因为它只用一根信号线传送发送数据,一根信号线传输接受数据,所以在时钟上为了满足100的需求,它的时钟频率很高,达到了125兆,为什么用125兆,是因为数据线里面会传送一些控制信息。GMII采用8位接口数据,工作时钟125MHz,因此传输速率可达1000Mbps。同时兼容MII所规定的10/100 Mbps工作方式。RGMII又是GMII接口的精简版。SGMII又是GMII的串行版。 MAC控制器和PHY除了数据传输的交流外,MAC和PHY控制信息的交流通过MDIO(管理数据输入输出)接口来完成。具体MAC控制器进行PHY检测、MAC控制器回去PHY 当前状态、MAC控制器控制PHY速率等操作就通过MDIO来完成。

uboot环境变量总结

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之我行 史上最牛最详细的uboot移植,不看别后悔

嵌入式Linux之我行——u-boot-2009.08在2440上的移植详解(一) 嵌入式Linux之我行,主要讲述和总结了本人在学习嵌入式linux中的每个步骤。一为总结经验,二希望能给想入门嵌入式Linux 的朋友提供方便。如有错误之处,谢请指正。 ?共享资源,欢迎转载:https://www.360docs.net/doc/f012741101.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项目的代码作为模板,以后再修改

U_Boot第一启动阶段Uboot启动分析笔记-----Stage1(start.S与lowlevel_init.S详解)

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移植实验

一、移植环境 ?主机:UBUNTU ?开发板:飞凌2440 ?编译器:arm-linux-gcc-4.3.2.tgz ?u-boot:u-boot-2009.03.tar.bz2

3)修改u-boot根目录下的Makefile文件。查找到smdk2410_config的地方,在他下面按照smdk2410_config的格式建立mini2440_config的编译选项,另外还要指定交叉编译器 4)测试编译新建的mini2440开发板项目

到此为止,u-boot对自己的mini2440开发板还没有任何用处,以上的移植只是搭建了一个mini2440开发板u-boot的框架,要使其功能实现,还要根据mini2440开发板的具体资源情况来对u-boot源码进行修改。 3. 根据u-boot启动流程图的步骤来分析或者修改添加u-boot源码,使之适合mini2440开发板(注:修改或添加的地方都用红色表示)。 1)mini2440开发板u-boot的stage1入口点分析。 一般在嵌入式系统软件开发中,在所有源码文件编译完成之后,链接器要读取一个链接分配文件,在该文件中定义了程序的入口点,代码段、数据段等分配情况等。那么我们的my2440开发板u-boot的这个链接文件就是cpu/arm920t/u-boot.lds,打开该文件部分代码如下:

知道了程序的入口点是_start,那么我们就打开mini2440开发板u-boot第一个要运行的程序cpu/arm920t/start.S(即u-boot的stage1部分),查找到_start的位置如下: 从这个汇编代码可以看到程序又跳转到start_code处开始执行,那么再查找到start_code 处的代码如下:

关于uboot移植 CAMDIVN与时钟

关于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 函数也需要修改:

经典=Uboot-2-命令详解(bootm)

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命令后附带的地址 } ...... //

uboot调试指南

Uboot调试参考指南 一、调试目的 Uboot的调试旨在通过观察uboot运行时状态来测试硬件问题。 二、调试步骤 1.修改代码 在uboot代码路径下,编辑uboot代码,需要做以下修改; a.修改config.mk文件,添加以下两行内容: AFLAGS += -Wa,-gdwarf2 CFLAGS += -g2 -gdwarf-2 b.修改. /arch/powerpc/lib/board.c文件 debug("Now running in RAM - U-Boot at: %08lx\n", dest_addr); printf("Now running in RAM - U-Boot at: %08lx\n", dest_addr); 将debug改为printf,如上所示。 2.编译uboot 执行make BSC9131RDB_SYSCLK100_NAND,编译uboot 3.将编译好的u-boot-nand.bin(uboot image格式)及u-boot(elf格式文件)文件拷 贝出来 4.烧录uboot 将步骤3中保存的u-boot-nand.bin烧录到目标板中,烧录过程略。 5.建立工程 a.在cw界面,点击file->import, 选择code warrior -> Power architecture ELF executable,如图1所示: 图1 建立elf工程 b.选择步骤3中保存的u-boot(elf格式文件),toolchain选择bareboard application, target OS选择none,工程名字请根据需要设置,比如我的机器上设置为example, 点击next,如图2所示:

Ubuntu下配置并使用LXR查看Uboot代码(原创)

Ubuntu下配置并使用LXR查看Uboot代码(原创) 之前买了个mini6410觉得查看uboot的源代码太麻烦,上网查到,利用lxr查看源代码比较方便,使用到的有:apache2,glimpse-4.18.6,lxr,u-boot-mini6410(查看的目标文件夹),我使用的Ubuntu9.10,在ylmf3下面也验证成功。 下面就正式开始搭建我们自己的lxr. 建议下面的所有的操作都使用root权限操作: sudo su 输入当前用户的使用密码即可就变成“root@XXXXXXX:” 一、安装apach2: sudo apt-get install apache2 二、安装glimpse: 先去网站下载最新的源代码glimpse-4.18.6.tar.gz,然后解压到当前目录下 tar -xvgf glimpse-4.18.6.tar.gz 再接着进入解压后的目录下,比如我的是: cd glimpse-4.18.6/ 在编译之前,首先看看你的机器上是否已经安装了flex,因为编译glimpse的时候需要这个软件。如果没有的话,那么进行安装: sudo apt-get install flex 接着进行编译: ./configure make sudo make install 执行完上面的步骤后,将生成的glimpse glimpseindex 拷贝到/bin目录下: cd /bin sudo cp glimpse glimpseindex /bin 三、安装lxr sudo apt-get install lxr 新建/usr/share/lxr/http/.htaccess文件 在里面增加如下内容: SetHandler cgi-script 四、复制U-boot源代码

uboot启动代码详解

·1 引言 在专用的嵌入式板子运行GNU/Linux 系统已经变得越来越流行。一个嵌入式Linux 系统从软件的角度看通常可以分为四个层次: 1. 引导加载程序。固化在固件(firmware)中的boot 代码,也就是Boot Loader,它的启动通常分为两个阶段。 2. Linux 内核。特定于嵌入式板子的定制内核以及内核的启动参数。 3. 文件系统。包括根文件系统和建立于Flash 内存设备之上文件系统,root fs。 4. 用户应用程序。特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式GUI 有:MicroWindows 和MiniGUI 等。 引导加载程序是系统加电后运行的第一段软件代码。回忆一下PC 的体系结构我们可以知道,PC 机中的引导加载程序由BIOS(其本质就是一段固件程序)和位于硬盘MBR 中的OS Boot Loader(比如,LILO 和GRUB 等)一起组成。BIOS 在完成硬件检测和资源分配后,将硬盘MBR 中的Boot Loader 读到系统的RAM 中,然后将控制权交给OS Boot Loader。Boot Loader 的主要运行任务就是将内核映象从硬盘上读到RAM 中,然后跳转到内核的入口点去运行,也即开始启动操作系统。 而在嵌入式系统中,通常并没有像BIOS 那样的固件程序(注,有的嵌入式CPU 也会内嵌一段短小的启动程序),因此整个系统的加载启动任务就完全由Boot Loader 来完成。比如在一个基于ARM7TDMI core 的嵌入式系统中,系统在上电或复位时通常都从地址 0x00000000 处开始执行,而在这个地址处安排的通常就是系统的Boot Loader 程序。·2 bootloader简介 简单地说,Boot Loader (引导加载程序)就是在操作系统内核运行之前运行的一段小程序,它的作用就是加载操作系统, 实现硬件的初始化,建立内存空间的映射图,为操作系统内核准备好硬件环境并引导内核的启动。如上图所示的那样在设备的启动过程中bootloader位于最底层,首先被运行来引导操作系统运行,很容易可以看出bootloader是底层程序所以它的实现严重地依赖于硬件,特别是在嵌入式世界。因此,在嵌入式世界里建立一个通用的BootLoader几乎是不可能的。尽管如此,一些功能强大、支持硬件环境较多的BootLoader也被广大的使用者和爱好者所支持,从而形成了一些被广泛认可的、较为通用的的bootloader实现。 2.1 Boot Loader 所支持的CPU 和嵌入式板 每种不同的CPU 体系结构都有不同的Boot Loader。有些Boot Loader 也支持多种体系结构的CPU,比如U-Boot 就同时支持ARM 体系结构和MIPS 体系结构。除了依赖于CPU 的体系结构外,Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说,对于两块不同的嵌入式板而言,即使它们是基于同一种CPU 而构建的,要想让运行在一块板子上的Boot Loader 程序也能运行在另一块板子上,通常也都需要修改Boot Loader 的源程序。 2.2 Boot Loader 的安装媒介(Installation Medium)

uboot移植心得

最近跑完裸机之后,便开始跑系统,但想着裸机与系统之间隔着个Bootloader,反正以前也没怎么深入研究,便说花一到两周时间来搞搞U-BOOT。 参考了fzb和赵春江两位大牛的,也研究了2010.06版本的和2011.06版本两个经典版本,也对比了TQ(我买的板是天嵌的)自己写的U-BOOT,学到了不少,也发现了很多东西,以下便记录以下自己的心得吧,以便以后可以自己参考下。 U-BOOT的两个阶段启动过程:(2010.06经典版来说) 第一阶段:start.S的路径位于arch\arm\cpu\arm920t\这段汇编代码一般被称作第一阶段初始化代码。主要作用是初始化运行环境;初始化内存;重新放置UBOOT代码到内存中;跳入到内存中执行第二段初始化代码 1、关闭开门狗,屏蔽所有中断 2、设置分频比 3、bl cpu_init_crit() 关MMU,初始化内存 bl lowlevel_init() 配置内存,修改内存刷新率参数等 4、relocate判断当前代码是在NORFLASH还是RAM copy_loop循环将FLASH代码复制至RAM中 5、stack_setup栈设置 clear_bss_bss_start到_bss_end之间的数据清0 6、ldr pc , start_armboot 跳转到第二阶段 //===================================================================== 第二阶段:board.c的路径位于arch/arm/lib/board.c,这段代码为U-BOOT的第二阶段初始化代码。主要作用是初始化两个重要数据结构,对SDRAM的内存分配设置,对各种需要用到的外设进行初始化,最后循环跳入main_loop()函数 二阶段start_armboot分为board_init_f 和 board_init_r两部分 先执行的board_init_f部分: 1、为gd数据结构分配地址,并清零 2、执行init_fnc_ptr函数指针数组中的各个初始化函数,如下 board_early_init_f ,timer_init ,env_init init_baudrate serial_init console_init_f display_banner dram_init 3、A、分配SDRAM高64KB为TLB,用于U-BOOT B、分配SDRAM下一单元为U-BOOT代码段,数据段,BSS段 (这里插一句,原来BSS段是用来存放未初始化的全局变量与静态变量) C、接着开辟malloc空间,存bd , gd , 3个字大小的异常堆空间 4、将relorate的地址值赋给gd结构体相应变量(2011.06版本的,用于返回start.S) 后执行的board_init_r部分: 1、对gd , bd 数据结构赋值初始化 2、各种外设初始化: 初始化NORFLASH, NANDFLASH,初始化ONENAND FLASH

相关文档
最新文档