uboot代码剖析

Uboot 代码剖析

黄雪莉

代码重定位

编译器在编译一段程序链接过程中，要对所有目标文件进行重定位，建立符号引用规则，同时为变量，函数等分配地址。程序执行时，把代码加载到链接时指定的地址空间，以保证程序在执行过程中对变量，函数等符号的正确引用，是程序正常运行。

但是在操作系统中，一个进程通常从硬盘等二级存储设备拷贝到内存中去执行，这两者的地址是不同的，因此操作系统要对这个进程进行重定位，才能正确运行该进程。

位置不相关代码：

在设计系统引导程序如bootloader时，一般为了提高速度，需要将bootloader 从ROM拷贝到RAM中去执行，这两者的地址也不同。如果这些代码即使不在链接时指定的地址空间也能正确运行，这就是位置无关代码(position independent code)。PIC的特点是，它被加载到任意地址空间都可以正确的执行。其原理是PIC对常量和函数入口地址的操作都是基于PC+偏移量的寻址方式。即使程序被移动，但是PC也变化了，而偏移量是不变的，所以程序仍然可以找到正确的入口地址或者常量。

位置代码无关在U-boot中的实现：

U-Boot中用GOT表(Global Offset Table 全局偏移量表)实现PIC代码位置无关，总的来讲，U-Boot依靠维护GOT表来实现，在GOT表中存放一些全局label 的表项，这些表项记录重要的地址；运行在Flash时，GOT表中存放的是编译时全局label的值(地址)；当U-Boot运行时检测RAM大小进行代码搬运之后，利用代码搬运前后产生的地址偏移对(相对偏移)GOT表中的各个表项值进行更新，使其记录RAM中的相应的地址。这样代码运行时不会出现代码/变量地址出错的问题。

主要代码剖析

1.关于GOT的主要宏定义（include/ppc_asm.tmpl）

2. .got2段的声明

3.上电复位，从flash的起始地址读取硬件复位配置字HRCW(Hard Reset Configuration Word)，每次都8位，每四次组成一个32位配置字，分别组成低

32位配置字和高32位配置字,分别存放在CFG_HRCW_LOW 和CFG_HRCW_HIGH寄存

HRCW控制时钟及其他硬件的功能，如PCI host和Agent模式，启动位置和大小端。详细配置信息见MPC8313ERM.pdf第四章第三节

4.入口启动，u-boou.lds指定程序入口,ENTRY(_start)

5.init_e300_core（start.S）:

初始化机器状态寄存器; 使能机器检查中断machine check interrupt 跟据MSR更新 SRR1（save/restore register）参考7.7.1.3.3

初始化Watchdog—修改SWCRR（system watchdog control register），并重置。参考5.4.4.1

初始化硬件执行依赖寄存器（HID），设置HID0，详见表 7-2

所有的BAT置零

关闭所有的TLB（Translation lookaside buffer） entry

6.cpu_init_f(cpu/mpc83xx/cpu_ini.c)

对IMMR的一些寄存器进行设置，实现TSEC，复位寄存器，窗口映射和时钟模块等的设置。r3存放的是IMMR的值，作为cpu_int_f的传

递参数（PowerPC中，r3-r10作为函数传递参数），结构类型为

immap_t(定义在文件include/asm_ppc/immap_83xx.h).

设置对全局数据指针gd，并对其进行初始化.gd主要用来保存开发板信息、终端存在标志位、环境变量结构体起始地址、环境变量校验标

志位、frame buffer 基地址等。它是指向gd_t 结构体的指针（gd_t

定义在include/asm_ppc/global_data.h）。这里都初始化为0。

7.Board_init_f(lib_ppc/board.c)

初始化init_sequence中的各个函数

?board_early_init_f：基本的板级相关配置，主要包括设置处理器类型和启动参数地址

?get_clocks：获得并设置CPU 和BUS 时钟

?init_timebase：初始化计数器；

?env_init：设置环境变量,初始化环境；

?init_baudrate：指定串口的波特率；

?serial_init：串口初始化设置；选择通讯端口，设置串口波特率和工作方式.

? console_init_f：设置gd->have_console=1,表示可以使用串口通讯控制台

?display_banner：在控制台输出 U-boot 信息

?checkcpu：检查CPU 版本信息

?checkboard：检查board 信息

?init_func_i2c：初始化i2c 接口

?init_func_ram：初始化SDRAM

对gd进行设置，即对开发板信息（结构体bd_t定义在文件

include/asm_ppc /u-boot.h 中）、终端存在标志位、环境变量结构

体起始地址、环境变量校验标志位、frame buffer 基地址等进行赋值。

relocate_code (addr_sp, id, addr)，将代码加载到的目的地址，addr_sp是相应的栈顶指针，id为全局数据变量gd.

8.relocate_code函数定义在start.S中

9.in_ram(位于start.S中)

10 ．Board_init_r(lib_ppc/board.c):

调用一系列的初始化函数，初始化高速缓存器和本阶段所用到的外围硬件设备,主要调用了函数：

watchdog_reset()：复位看门狗；

icache_enable()：初始化I-Cache；

unlock_ram_in_cache()：解锁D-Cache；

flash_init()：初始化Nor Flash，使之支持写入、擦除功能； cpu_init_r ();对cpu的hiher level部分进行初始化

nand_init()：初始化Nand Flash；

console_init_r()：再次初始化控制台串口；

eth_initialize()：初始化以太网口；

main_loop()：检查delay时间，若在期间没有按键，则启动操作系统内核

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

Android源代码结构分析

目录一、源代码结构 (2) 第一层次目录 (2) bionic目录 (3) bootloader目录 (5) build目录 (7) dalvik目录 (9) development目录 (9) external目录 (13) frameworks目录 (19) Hardware (20) Out (22) Kernel (22) packages目录 (22) prebuilt目录 (27) SDK (28) system目录 (28) Vendor (32)

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

词法分析器实验报告及源代码

数学与软件科学学院实验报告学期：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命令详解

常用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

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

yaffs2文件系统制作

交叉编译器ARM-Linux-gcc4.1.2 开发板TX2440A Busybox-1.15.1.tar.bz2（在Linux中被称为瑞士军刀） mkyaffs2image工具首先创建一个名字为root_2.6.31的文件夹，在其中创建如下文件夹 etc bin var dev home lib mnt proc root sbin sys tmp usr opt共14个文件夹解压Busybox tar xjvf busybox 进入源目录，修改Makefile 第164行，CROSS_COMPILE=arm-linux- 第190行，ARCH=arm 执行#make men onfig进行配置配置选项大部分都是保持默认的，只需要注意选择以下这几个选项，其他的选项都不用动：Busybox Setting---> Build Options---> [*]Build Busybox as a static binary(no shared libs) [*]Build with Large File Support(for accessing files>2GB) Installation Options--->

(./_install)Busybox installation prefix 进入这个选项，输入busybox的安装路径，如：../rootfs Busybox Library Tuning---> [*]vi-style line editing commands [*]Fancy shell prompts 要选择这个选项:“Fancy shell prompts”，否则挂载文件系统后，无法正常显示命令提示符：“[\u@\h\W]#” 配置完成以后执行#make #make install 然后就会在上一级目录下生成rootfs文件夹，里面包含几个文件夹/bin/sbin/usr linuxrc 把这些文件全部复制到刚建好的root_2.6.31目录下， #cp–rf*../root_2.6.31 在dev目录下，创建两个设备节点: #mknod console c51 #mknod null c13 然后进入自己建立的etc目录拷贝Busybox-1.15.2/examples/bootfloopy/etc/*到当前目录下。 #cp-r../../busybox-1.15.2/examples/bootfloopy/etc/*./ 包括文件:fstab init.d inittab profile

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

语法分析器源代码

#include #include #include #define HIGHER 1 #define LOWER -1 #define EQUAL 0 #define TRUE 1 #define FALSE 0 #define OPER_NUM 50 //默认算符数目 #define VN_NUM 50 //默认非终结符数目#define MAX_BUFFER 128 //每行输入行最大长度 #define MAX_GRA_NUM 20 //最大文法数目#define EMPTY -2 //算符优先表初始值，表示这对算符没有优先关系 #define STACK_SIZE 64 typedef struct { char c; //非终极符符号 int firstvt[OPER_NUM]; //firstvt集，保存算符在oper_list中的下标 int fir_n,last_n; int lastvt[OPER_NUM]; }vn_t; int prior_table[OPER_NUM][OPER_NUM]; char oper_list[OPER_NUM]; int oper_num = 0; vn_t vn_list[VN_NUM]; int vn_num = 0; char *grammar[MAX_GRA_NUM][2]; int gra_num = 0; char start_vn; char stack[STACK_SIZE]; int top = 0; void get_input(char *buf); int buf_deal(char* buf); void get_FIRVT_LASTVT(int vn_n);

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-2.6.18移植

Linux-2.6.18移植有了我们的交叉编译环境和我们先前学的内核基础知识，下面我们就开始我们的内核移植了，我们所用的是博创的 S3C2410 。关于 linux-2.6.18.tar.bz2 的下载网站先前我们说过，我们要先到该官方网站上去下载一个全新的内核。 [root@Binnary ~ ]# tar –jxvf linux-2.6.18.tar.bz2 [root@Binnary ~ ]# make mrproper 如果你是新下载的内核，那这一步就不用了。但如果你用的是别人移植好的内核，那最好在编译内核之前先清除一下中间文件，因为你们用来编译内核的交叉编译工具可能不同。第一步：修改Makefile文件将改为第二步：修改分区设置信息我们要先在BootLoader中查看相应的分区信息 vivi>help 然后修改内核源码中的分区信息。分区信息文件在 a rch/arm/mach-s3c2410/common-smdk.c 将其中的

改为如下内容：

第三步：内核通过 BootLoader把数据写入NAND Flash，而vivi的ECC效验算法和内核的不同，内核的效验码是由NAND Flash控制器产生的，所以在此必须禁用NAND Flash ECC。所以我们就要修改 drivers/mtd/nand/s3c2410.c 这个文件。将中的 chip->ecc.mode = NAND_ECC_SOFT ，改为如下 chip->ecc.mode = NAND_ECC_NONE。

只此一处。第四步：下面是devfs的问题，因为2.6.12内核以后取消了devfs的配置选项，缺少了它内核会找不到mtdblock设备。所以我们需要修改 fs/Kconfig 文件，或者是从2.6.12的fs/Kconfig中拷贝下面几项到2.6.18的fs/Kconfig中去，我们采用修改的方法来完成。修改 fs/Kconfig支持devfs 。在Pseudo filesystems 主菜单的最后添加我们所要的内容。第五步：文件系统的支持 Yaffs 文件系统 YAFFS文件系统简介 YAFFS，Yet Another Flash File System，是一种类似于JFFS/JFFS2的专门为Flash设计的嵌入式文件系统。与JFFS相比，它减少了一些功能，因此速度更快、占用内存更少。 YAFFS和JFFS都提供了写均衡，垃圾收集等底层操作。它们的不同之处在于：（1）、JFFS是一种日志文件系统，通过日志机制保证文件系统的稳定性。YAFFS仅仅借鉴了日志系统的思想，不提供日志机能，所以稳定性不如JAFFS，但是资源占用少。（2）、JFFS中使用多级链表管理需要回收的脏块，并且使用系统生成伪随机变量决定要回收的块，通过这种方法能提供较好的写均衡，在YAFFS中是从头到尾对块搜索，所以在垃圾收集上JFFS的速度慢，但是能延长NAND的寿命。（3）、JFFS支持文件压缩，适合存储容量较小的系统；YAFFS不支持压缩，更适合存储容量大的系统。 YAFFS还带有NAND芯片驱动，并为嵌入式系统提供了直接访问文件系统的API，用户可以不使用Linux中的MTD和VFS，直接对文件进行操作。NAND Flash大多采用 MTD+YAFFS的模式。MTD（ Memory Technology Devices，内存技术设备）是对Flash 操作的接口，提供了一系列的标准函数，将硬件驱动设计和系统程序设计分开。 Yaffs 文件系统内核没有集成，可以对其主页下载： https://www.360docs.net/doc/c23458315.html,/cgi-bin/viewcvs.cgi/#dirlist

嵌入式Linux之我行史上最牛最详细的uboot移植,不看别后悔

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

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的命令，最终都会在连接是存放在这个位置。*/

Yaffs2文件系统中对NAND Flash磨损均衡的改进

Yaffs2文件系统中对NAND Flash磨损均衡的改进摘要：针对以NAND Flash为存储介质时Yaffs2文件系统存在磨损均衡的缺陷，通过改进回收块选择机制，并在数据更新中引入冷热数据分离策略，从而改善NAND Flash的磨损均衡性能。实验借助Qemu软件建立Linux嵌入式仿真平台，从总擦除次数、最大最小擦除次数差值和块擦除次数标准差等方面进行对比。实验结果表明，在改进后的Yaffs2文件系统下NAND Flash的磨损均衡效果有明显提升，这有益于延长NAND Flash的使用寿命。关键词： Yaffs2文件系统；NAND Flash；垃圾回收；冷热数据 0 引言 NAND Flash存储设备与传统机械磁盘相比，具有体积小、存储密度高、随机存储和读写能力强、抗震抗摔、功耗低等特点[1]。它被广泛用于智能手机、车载智能中心、平板电脑等智能终端中。近年来，以NAND Flash为存储介质的固态硬盘也得到越来越多的应用。目前Yaffs2文件系统(Yet Another Flash File System Two，Yaffs2)[1]是使用最多、可移植性最好的专用文件系统，在安卓、阿里云OS、Linux等嵌入式系统中都有使用。在Yaffs2文件系统下以NAND Flash为存储介质时存在磨损均衡的缺陷，可通过对回收块选择机制作改进和引入冷热数据分离策略来提高磨损均衡的效果。 1 Yaffs2和Nand Flash关系这里以使用最多的Linux操作系统为实践，将Yaffs2文件系统移植到Linux操作系统中。Linux系统通常可以分为3层：应用层、内核层和设备层，其中支持NAND Flash设备的Yaffs2文件系统属于内核层，。最上层用户应用程序通过VFS(Virtual File System)提供的统一接口，将数据更新等文件操作传递给Yaffs2。VFS代表虚拟文件系统，它为上层应用提供统一的接口。有了这些接口，应用程序只用遵循抽象后的访问规则，而不必理会底层文件系统和物理构成上的差异。然后Yaffs2通过MTD（Memory Technology Device）提供的统一访问接口对NAND Flash进行读、写和擦除操作，从而完成数据的更新或者存储操作。MTD代表内存技术设备，它为存储设备提供统一访问的接口。最终，在NAND Flash上以怎样的格式组织和存储数据由Yaffs2文件系统决定。 NAND Flash由若干块(block)组成，每个块又是由若干页(page)组成，页中含有数据区和附加区。NAND Flash的页根据状态不同，可以分为有效页、脏页、空闲页。有效页中存放有效数据，脏页中存放无效数据，空闲页是经过擦除后可以直接用于写入数据的页。NAND Flash在写入数据前需要执行擦除操作，因此数据不能直接在相同的位置更新。当一个页中数据需要更新时，必须将该页中有效数据拷贝到其他空闲页上再更新，并将原来页上的数据置为无效。随着时间的推移，许多无效页累积在存储器中使得空闲页逐渐减少。当存储器中的空闲空间不足时，启动垃圾回收操作，利用回收块选择机制从待回收块中选取满足要求的块来擦除，从而得到足够的空闲空间。NAND Flash中块的擦除次数有限，通常为10 000次～100 000次[2]。当某个块的擦除次数超过使用寿命时，该块将无法正常用于数据存储。因此，垃圾回收应利用合理的回收块选择机制，从待回收块中找到回收后能产生良好磨损均衡效果且付出较少额外代价的块来回收，从而获得足够的空闲空间用于数据更新操作。 2 Yaffs2在磨损均衡方面的缺陷 Yaffs2中回收块的选择机制[3]是从待回收块中找到有效数据最少的块来回收。回收过程中，Yaffs2能够减少有效数据的额外读和写操作。当数据更新处于均匀分布的情况下，Yaffs2表现出较好的磨损均衡效果。但是，通常情况下数据的更新频率不同，有些数据经常更新，而有些数据很少更新。经