Linux启动bootargs参数分析
这几天刚好在看linux c语言启动，现在就顺便把内核在启动时解析bootargs这一块单独拎出来讲解下，内核对于bootargs的解析分为几块：
1.setup_arch(&command_line);
综述：在这个函数中，系统会获得bootargs参数，并对其做简单的初步分析。
并将bootargs的参数保存在command_line这个地址中。
详解：
A．先获得bootargs的地址，uboot传进来的参数是放在30000100的地方的
//一般默认为0x30000100位置//boot_params 如果为0则表示bootloader 没有传参数
if (mdesc->boot_params)
tags = phys_to_virt(mdesc->boot_params);
B．是通过标签ATAG来辨别的，uboot中有相应的标签字，将相应的uboot 参数放置到相应的全局变量中。
if (tags->hdr.tag == ATAG_CORE) {
//已经被fixup函数修改，则将atag中的mem段置为none
if (meminfo.nr_banks != 0)
squash_mem_tags(tags);
//继续把atag的参数传递结束，通过参数的类型（比如ATAG_CMDLINE，ATAG_MEM诸如此类的参数）将bootargs参数全部分析完毕。
parse_tags(tags);
{
extern struct tagtable __tagtable_begin, __tagtable_end;
struct tagtable *t;
//我们的参数是放在__tagtable_begin到__tagtable_end区间内，各个类型的通过__tagtable的宏定义在编译的时候就将其定位在这个区间，我们的每一个参数只需要和每个宏比较，并调用其对用的parse函数。
//对于我们一般的bootargs，只传递了ATAG_CMDLINE，而在其对应的parse函数就是把传递进来的cmdline存放到default_command_line中。
for (t = &__tagtable_begin; t < &__tagtable_end; t++)
if (tag->hdr.tag == t->tag) {
t->parse(tag);
break;
}
return t < &__tagtable_end;
}
}
C．将cmdline存放至saved_command_line中
//在setup_arch函数刚开始就定义了char *from= default_command_line,因此通过下面这个函数实现把cmdline存放至saved_command_line中。
memcpy(saved_command_line, from, COMMAND_LINE_SIZE);
D．对cmdline做简单的分析，主要是mem和initrd的
这里的处理和B步比较类似，通过对cmdline中的一个个参数和
__early_begin到__early_end间的参数进行比较。从而得到匹配的参数，
然后调用其相应的parse函数进行处理，同时将剩余部分存放到
setup_arch(&command_line)传进来的字符串指针command_line中。。这
部分先对cmdline进行分析是因为接下来就需要对页表进行建立，所以必须知道内存mem和initrd文件系统的信息，所以这部分属于early，parse 的参数很少。其余的参数解析都留至后面的参数分析中。
2.parse_early_param();
综述：第二次分析cmdline，不过在这里分析的是系统能够辨别的一些早期参数（这个函数甚至可以去掉），而且在分析的时候并不是以setup_arch
（&command_line）传出来的command_line为基础，而是以最原生态的
saved_command_line为基础的。
详解：
parse_args("early options", tmp_cmdline, NULL, 0, do_early_param);
{
args = next_arg(args, ¶m, &val);//一个个参数分离
ret = parse_one(param, val, params, num, unknown（就是
do_early_param）);//解析参数
由于传进去的num为0，因此对于每一个参数param和值value，直接调用do_early_param解析。
}
// do_early_param这部分的实现就和1中的B/D的处理类似，通过对
__setup_start和__setup_end区间的参数进行比较，找到对应的参数，调用该参数的解析函数。这部分的定义是以__setup(str, fn)的类型出现的，在linux中这类型的启动参数有非常多（比如root，console，ro,rw,rootfstype,md,resume……），几乎这步可以涵盖所有有用的，而且我们自己也可以增加这种操作来支持新的启动参数。
static int __init do_early_param(char *param, char *val)
{
struct obs_kernel_param *p;
for (p = __setup_start; p < __setup_end; p++) {
if (p->early && strcmp(param, p->str) == 0) {
if (p->setup_func(val) != 0)
printk(KERN_WARNING
"Malformed early option '%s'\n", param);
}
}
}
3.parse_args("Booting kernel", command_line, __start___param,
__stop___param - __start___param, &unknown_bootoption);
综述：对于比较新的版本真正起作用的函数，与2的parse_early_param();相比，此处对解析列表的处理范围加大了，解析列表中除了包括系统以setup定义的启动参数，还包括模块中定义的param参数以及系统不能辨别的参数。
详解：
command_line是setup_arch函数传递出来的值；
__start___param是param参数的起始地址，在System.map文件中能看到
__stop___param - __start___param是参数个数
unknown_bootoption是对应与启动参数不是param的相应处理函数
同样跟进去最核心的函数也是parse_args（同2中分析）：
parse_args("early options", tmp_cmdline, NULL, 0, do_early_param);
{
args = next_arg(args, ¶m, &val);//一个个参数分离
ret = parse_one(param, val, params, num, unknown（就是
do_early_param）);//解析参数
由于传进去的num为就是parm的个数，所以先要将启动参数和param一个个比较。
static int parse_one(char *param,char *val,struct kernel_param *params,
unsigned num_params,int (*handle_unknown)(char *param, char *val)) {
unsigned int i;
//先寻找启动参数是否和param匹配，param变量一般是在驱动模块中
module_param定义的，存放在*（param）空间。如果匹配则将param参数的值用相应的value代替。
//也就是说通过这种方式可以在启动参数中为驱动的参数赋值，而且可以看出linux中认为param参数是以后主要使用的启动参数传递方式，将慢慢摒弃__setup的形式。
for (i = 0; i < num_params; i++) {
if (parameq(param, params[i].name)) {
DEBUGP("They are equal! Calling %p\n",
params[i].set);
return params[i].set(val, ¶ms[i]);
}
}
//当然对于嵌入式的cmdline，一般而言都没有param参数的值，所以都是调用此处的handle_unknown
如一个很简单的例子：
Kernel command line: root=/dev/mtdblock3 console=ttyS0,115200
rootfstype=yaffs mem=32m
Unknown argument: calling c00082e4
parram is root, val is /dev/mtdblock3
parram is console, val is ttyS0,115200
parram is rootfstype, val is yaffs
if (handle_unknown) {
DEBUGP("Unknown argument: calling %p\n", handle_unknown);
return handle_unknown(param, val);
}
{
/* Handle obsolete-style parameters */其实我们的参数在handle_unknown 中还是过时的参数解析方式的，就是obsolette_checksetup函数，这个函数内部的处理和parse_early_param()类似，所以这里就不详细解释了。
if (obsolete_checksetup(param))
return 0;
对于既不是param，在handle_unknown中又不是setup形式的参数字符串，但设置了参数值。就将其放置在系统启动后的环境变量全局数组envp_init[]中的同名参数或空环境变量中。
对于没有设置参数值的参数字符串就将其传给argv_init[]中同名参数或空参数。
……
}
DEBUGP("Unknown argument `%s'\n", param);
return -ENOENT;
}
}
展讯系列各芯片组的参数
SC6600IGSM/GPRS入门级多媒体基带芯片 SC6600IGSM/GPRS基带芯片是壹款面向入门级多媒体手机市场的具有音乐播放、视频播放和拍照摄像功能的多媒体基带壹体化手机核心芯片。该芯片于提升集成度的同时增强了芯片的可靠性设计，降低了生产成本，且可帮助客户缩短新产品的上市时间。 SC6600I基带芯片图示 SC6600I主要功能 芯片内核?ARM7TDMI?核（主频速度达78MHz） 多媒体支持?内置30万像素数码相机控制器,可直接连接至数字CMOS图像传感器 ?支持MPEG4QVGA@15fps视频播放 ?内置MP3播放器 ?64和弦铃声(MIDI格式) LCD显示功能?内置LCD控制器 ?支持双彩屏 ?支持262KTFT/OLED显示模块 ?支持240x320分辨率LCD显示模式 存储接口?外接存储器接口(SDRAM,NAND,NOR) ?内置NANDflash控制器 ?支持NANDbooting ?支持NAND+SDRAMMCP,SDRAM运行速率可达72MHz 外围设备接口?USB1.1接口 ?MMC和SD卡接口 ?4UART接口（传输速率达1.152Mbps） ?PCM音频接口 ?IrDA（传输速率达115kbps,1.152Mbps） ?SPI接口 ?I2C接口 ?I2S接口 ?GPIO接口 ?支持蓝牙/WLAN/A-GPS接口 ?1.8/3.0SIM卡接口 ?8-channelDMAs ?JTAG接口（用于测试和内部电路校准） ?实时时钟
模拟参数?各种支持IF/NZIF/ZIF架构的RF接口 ?带LDO调节器的芯片集成电源管理 软／硬件支持?GSM/GPRS标准(版本 V8.2.012/1999),GSM850/GSM900/DCS1800/PCS1900 ?GPRS多时隙Class10 ?PTT(PushtoTalk)功能 ?FR,EFR,AMR ?录音和语音识别 ?A5/1和A5/2加密算法 其他功能?工作环境温度:-25至+65摄氏度 ?低耗电设计,输入输出：3.0V,芯片核：1.8V ?12×12mm2265-ballLFBGA封装 SC6600DGSM/GPRS入门级多媒体基带芯片 SC6600DGSM/GPRS基带芯片为客户设计入门级GSM/GPRS多媒体手机提供了高效的解决方案。它将多媒体处理器和电源管理电路集成于4频段GSM/GPRS基带芯片上。该芯片于提升集成度的同时增强了芯片的可靠性设计，降低了生产成本，且可帮助客户缩短新产品的上市时间。 SC6600D基带芯片图示 SC6600D主要功能 芯片内核?ARM9EJ-S?核（主频速率达192MHz） 多媒体支持?内置MPEG-4,2D图像处理器,JAVA加速器 ?内置5M像素数码相机控制器,可直接连接数字CMOS图像传感器 ?内置ISP,支持处理BayerRGB图像数据,支持视频功能 ?支持MIDI/MP3/AAC/AAC+/WMA音频格式 ?支持MPEG4/H.263视频,速率达3Mbpsbit ?电视视频输出(PAL/NSTCTV输出) ?3D立体声环绕效果 LCD显示参数?内置LCD控制器,支持RGB和MCU接口 ?支持双彩屏 ?可支持262KTFTLCD显示模块 ?可支持240x320分辨率LCD显示模块
详解bootloader的执行流程与ARM Linux启动过程分析 ARM Linux启动过程分析是本文要介绍的内容，嵌入式Linux 的可移植性使得我们可以在各种电子产品上看到它的身影。对于不同体系结构的处理器来说Linux的启动过程也有所不同。 本文以S3C2410 ARM处理器为例，详细分析了系统上电后bootloader的执行流程及ARM Linux的启动过程。 1、引言 Linux 最初是由瑞典赫尔辛基大学的学生Linus Torvalds在1991 年开发出来的，之后在GNU的支持下，Linux 获得了巨大的发展。虽然Linux 在桌面PC 机上的普及程度远不及微软的Windows 操作系统，但它的发展速度之快、用户数量的日益增多，也是微软所不能轻视的。而近些年来Linux 在嵌入式领域的迅猛发展，更是给Linux 注入了新的活力。 一个嵌入式Linux 系统从软件角度看可以分为四个部分：引导加载程序（bootloader），Linux 内核，文件系统，应用程序。 其中bootloader是系统启动或复位以后执行的第一段代码，它主要用来初始化处理器及外设，然后调用Linux 内核。 Linux 内核在完成系统的初始化之后需要挂载某个文件系统做为根文件系统（Root Filesystem）。 根文件系统是Linux 系统的核心组成部分，它可以做为Linux 系统中文件和数据的存储区域，通常它还包括系统配置文件和运行应用软件所需要的库。 应用程序可以说是嵌入式系统的“灵魂”，它所实现的功能通常就是设计该嵌入式系统所要达到的目标。如果没有应用程序的支持，任何硬件上设计精良的嵌入式系统都没有实用意义。 从以上分析我们可以看出bootloader 和Linux 内核在嵌入式系统中的关系和作用。Bootloader在运行过程中虽然具有初始化系统和执行用户输入的命令等作用，但它最根本
Linux系统启动过程分析 by 王斌斌 binbinwang118@https://www.doczj.com/doc/a96352086.html, Linux系统启动过程分析 操作系统的启动过程，实际上是控制权移交的过程。Linux 系统启动包含四个主要的阶段：BIOS initialization, boot loader, kernel initialization, and init startup.见下图： 阶段一、BIOS initialization，主要功能如下： 1.Peripherals detected 2.Boot device selected 3.First sector of boot device read and executed 系统上电开机后，主板BIOS（Basic Input / Output System）运行POST（Power on self test）代码，检测系统外围关键设备（如：CPU、内存、显卡、I/O、键盘鼠标等）。硬件配置信息及一些用户配置参数存储在主板的CMOS( Complementary Metal Oxide Semiconductor)上（一般64字节），实际上就是主板上一块可读写的RAM芯片，由主板上的电池供电，系统掉电后，信息不会丢失。 执行POST代码对系统外围关键设备检测通过后，系统启动自举程序，根据我们在BIOS中设置的启动顺序搜索启动驱动器（比如的硬盘、光驱、网络服务器等）。选择合适的启动器，比如通常情况下的硬盘设备，BIOS会读取硬盘设备的第一个扇区（MBR，512字节），并执行其中的代码。实际上这里BIOS并不关心启动设备第一个扇区中是什么内容，它只是负责读取该扇区内容、并执行，BIOS的任务就完成了。此后将系统启动的控制权移交到MBR部分的代码。 注：在我们的现行系统中，大多关键设备都是连在主板上的。因此主板BIOS提供了一个操作系统（软件）和系统外围关键设备（硬件）最底级别的接口，在这个阶段，检测系统外围关键设备是否准备好，以供操作系 “” 统使用。 阶段二、Boot Loader 关于Boot Loader，简单的说就是启动操作系统的程序，如grub，lilo，也可以将boot loader本身看成一个小系统。 The BIOS invokes the boot loader in one of two ways: 1.It pass control to an initial program loader (IPL) installed within a driver's Master Boot Record (MBR) 2.It passes control to another boot loader, which passes control to an IPL installed within a partition's boot sector. In either case, the IPL must exist within a very small space, no larger than 446 bytes. Therefore, the IPL for GRUB is merely a first stage, whose sole task is to locate and load a second stage boot loader, which does most of the work to boot the system. There are two possible ways to configure boot loaders: Primary boot loader: Install the first stage of your Linux boot loader into the MBR. The boot loader must be configure to pass control to any other desired operating systems. Secondary boot loader: Install the first stage of your Linux boot loader into the boot sector of some partition. Another boot loader must be installed into the MBR, and configured to pass control to your Linux boot loader. 假设Boot Loader 为grub (grub-0.97)，其引导系统的过程如下： grub 分为stage1 (stage1_5) stage2两个阶段。stage1 可以看成是initial program loaderI（IPL），而stage2则实现了grub 的主要功能，包括对特定文件系统的支持（如ext2,ext3，reiserfs等），grub自己的shell，以及内部程序（如：kernrl，initrd，root ）等。
linux内核启动+Android系统启动过程详解 第一部分：汇编部分 Linux启动之 linux-rk3288-tchip/kernel/arch/arm/boot/compressed/ head.S分析这段代码是linux boot后执行的第一个程序，完成的主要工作是解压内核，然后跳转到相关执行地址。这部分代码在做驱动开发时不需要改动，但分析其执行流程对是理解android的第一步 开头有一段宏定义这是gnu arm汇编的宏定义。关于GUN 的汇编和其他编译器，在指令语法上有很大差别，具体可查询相关GUN汇编语法了解 另外此段代码必须不能包括重定位部分。因为这时一开始必须要立即运行的。所谓重定位，比如当编译时某个文件用到外部符号是用动态链接库的方式，那么该文件生成的目标文件将包含重定位信息，在加载时需要重定位该符号，否则执行时将因找不到地址而出错 #ifdef DEBUG//开始是调试用，主要是一些打印输出函数，不用关心 #if defined(CONFIG_DEBUG_ICEDCC)
……具体代码略 #endif 宏定义结束之后定义了一个段， .section ".start", #alloc, #execinstr 这个段的段名是 .start，#alloc表示Section contains allocated data, #execinstr表示Section contains executable instructions. 生成最终映像时，这段代码会放在最开头 .align start: .type start,#function /*.type指定start这个符号是函数类型*/ .rept 8 mov r0, r0 //将此命令重复8次，相当于nop，这里是为中断向量保存空间 .endr b 1f .word 0x016f2818 @ Magic numbers to help the loader
linux grub 引导启动过程详解 2008-01-08 17:18 这几天看了很多文档,算是对linux的启动过程有了比较细致的了解. 网上有很多文章谈到这方面的内容,但总觉得没有一篇完全的解析linux启动的 细节,下面是我小弟在学习的过程中总结出来的一些东东.这个是完整的linux启动过程, 不涉及内核,但是我觉得比较详细哦. (由于本人比较懒,这一段是从网上抄的) 机器加电启动后,BIOS开始检测系统参数,如内存的大小,日期和时间,磁盘 设备以及这些磁盘设备用来引导的顺序,通常情况下，BIOS都是被配置成首先检查 软驱或者光驱（或两者都检查），然后再尝试从硬盘引导。如果在这些可移动的设 备中，没有找到可引导的介质，那么BIOS通常是转向第一块硬盘最初的几个扇区， 寻找用于装载操作系统的指令。装载操作系统的这个程序就是boot loader. linux里面的boot loader通常是lilo或者grub,从Red Hat Linux 7.2起，GRUB( GRand Unified Bootloader)取代LILO成为了默认的启动装载程序。那么启动的时候grub是如何被载入的呢 grub有几个重要的文件,stage1,stage2,有的时候需要stage1.5.这些文件一般都 在/boot/grub文件夹下面.grub被载入通常包括以下几个步骤: 1. 装载基本的引导装载程序(stage1),stage1很小,网上说是512字节,但是在我的系统上用du -b /boot/grub/stage1 显示的是1024个字节,不知道是不是grub版本不同的缘故还是我理解有误.stage1通常位于主引导扇区里面,对于硬盘就是MBR了,stage1的主要功能就是装载第二引导程序(stage2).这主要是归结于在主引导扇区中没有足够的空间用于其他东西了,我用的是grub 0.93,stage2文件的大小是107520 bit. 2. 装载第二引导装载程序(stage2),这第二引导装载程序实际上是引出更高级的功能, 以允许用户装载入一个特定的操作系统。在GRUB中，这步是让用户显示一个菜单或是输入命令。由于stage2很大,所以它一般位于文件系统之中(通常是boot所在的根 分区). 上面还提到了stage1.5这个文件,它的作用是什么呢你到/boot/grub目录下看看, fat_stage_1.5 e2fs_stage_1.5 xfs_stage_1.5等等,很容易猜想stage1.5和文件系统 有关系.有时候基本引导装载程序(stage1)不能识别stage2所在的文件系统分区,那么这 时候就需要stage1.5来连接stage1和stage2了.因此对于不同的文件系统就会有不同的stage1.5.但是对于grub 0.93好像stage1.5并不是很重要,因为我试过了,在没有stage1.5 的情况下, 我把stage1安装在软盘的引导扇区内,然后把stage2放在格式化成ext2或者fat格式的软盘内,启动的时候照常引导,并不需要e2fs_stage_1.5或者fat_stage_1.5. 下面是我的试验: #mkfs.ext2 /dev/fd0 #mount -t ext2 /dev/fd0 /mnt/floppy #cd /mnt/floppy #mkdir boot #cd boot #mkdir grub (以上三步可用mkdir -p boot/grub命令完成) #cd grub #cp /boot/grub/{stage1,stage2,grub.conf} ./ #cd; umount /mnt/floppy
深入浅出：Linux的启动流程刨析 Linux的启动过程，是一个Linuxer必须要熟练掌握的。通过系统的启动过程，可以更深入的理解Linux，假如Linux系统出问题的话，可以通过启动过程来分析原因，解决问题。而且，在掌握了Linux的启动流程后，还可以借助宿主机来打造自己的Linux。 下面是我画的一张简单的Linux启动流程图 在了解启动流程之前，我们应该先知道系统的几个重要脚本和配置文件，他们对应的路径为： 1、/sbin/init 2、/etc/inittab 3、/etc/rc.d/rc.sysinit 4、/etc/rc.d/rcN.d //这是几个文件夹N代表数字1，2，3，4.. 5、/etc/fstab 1、关于/sbin/init与/etc/inittab 关于/sbin/init ，它是一个二进制可执行文件，为系统的初始化程序，而/etc/inittab是它的配置文件，我们可以通过/etc/inittab来一睹它的功能，里面的内容是一种固定的文本格式，id：runlevels：action：process 我们来通过它的内容来学习它之前，先了解写运行级别的分类（0-6）： 0：关机half
1：单用户模式singel user 2：多用户模式multi user ，不提供nfs服务without nfs 3：完全多用户字符模式full multiuser text mod 4：系统预留officially undefined 5：图形登录界面graphical login 6：重启reboot id:3:initdefault: //这里定义linux的启动时的运行级别，可以看到我的主机的启动级别是3 # System initialization. si::sysinit:/etc/rc.d/rc.sysinit //紧接着，运行系统第一个脚本/etc/rc.d/rc/sysinit //它的action:sysyinit指的是定义系统初始化过程 l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 //然后就是加载服务了，他们被定义在/etc/rc.d/rcN.d l3:3:wait:/etc/rc.d/rc 3 //action：waite 这个进程在在对应级别启动一次，知道它结束为止，我的系统启动级别为3，所有执行rc 3对应的服务 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 ca::ctrlaltdel:/sbin/shutdown -t3 -r now //这里定义了一个组合快捷键，熟悉吧，没错就是重启，你可以把它注释掉不用 pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"//这里定义了ups电源，powerfail 指的是如果突然断电，它对应的process命令是，提示用户系统电源失效，将要关机，提醒用户把数据都存储好 pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"//这里的action,powerokwaite，指的是系统恢复供电，关机取消...
1:2345:respawn:/sbin/mingetty tty1 //开启终端，在系统准备工作做好后，就会启动出6个终端，tty1～6 mingetyy就是终端的执行命令 2:2345:respawn:/sbin/mingetty tty2 //可以看到他们对应的级别是2345，你也可以注释Linux启动全过程-由bootloader到fs
Linux启动过程 许多人对Linux的启动过程感到很神秘，因为所有的启动信息都在屏幕上一闪而过。其实Linux的启动过程并不象启动信息所显示的那样复杂，它主要分成两个阶段： 1.启动内核。在这个阶段，内核装入内存并在初始化每个设备驱动器时打印信息。 2.执行程序init。装入内核并初始化设备后，运行init程序。init程序处理所有程序的启动， 包括重要系统精灵程序和其它指定在启动时装入的软件。 下面以Red Hat为例简单介绍一下Linux的启动过程。 一、启动内核 首先介绍启动内核部分。电脑启动时，BIOS装载MBR，然后从当前活动分区启动，LILO获得引导过程的控制权后，会显示LILO提示符。此时如果用户不进行任何操作，LILO将在等待制定时间后自动引导默认的操作系统，而如果在此期间按下TAB键，则可以看到一个可引导的操作系统列表，选择相应的操作系统名称就能进入相应的操作系统。当用户选择启动LINUX操作系统时，LILO就会根据事先设置好的信息从ROOT文件系统所在的分区读取LINUX映象，然后装入内核映象并将控制权交给LINUX内核。LINUX内核获得控制权后，以如下步骤继续引导系统： 1. LINUX内核一般是压缩保存的，因此，它首先要进行自身的解压缩。内核映象前面的一些代码完成解压缩。 2. 如果系统中安装有可支持特殊文本模式的、且LINUX可识别的SVGA卡，LINUX会提示用户选择适当的文本显示模式。但如果在内核的编译过程中预先设置了文本模式，则不会提示选择显示模式。该显示模式可通过LILO或RDEV工具程序设置。 3. 内核接下来检测其他的硬件设备，例如硬盘、软盘和网卡等，并对相应的设备驱动程序进行配置。这时，显示器上出现内核运行输出的一些硬件信息。 4. 接下来，内核装载ROOT文件系统。ROOT文件系统的位置可在编译内核时指定，也可通过LILO 或RDEV指定。文件系统的类型可自动检测。如果由于某些原因装载失败，则内核启动失败，最终会终止系统。 二、执行init程序 其次介绍init程序，利用init程序可以方便地定制启动其间装入哪些程序。init的任务是启动新进程和退出时重新启动其它进程。例如，在大多数Linux系统中，启动时最初装入六个虚拟的控制台进程，退出控制台窗口时，进程死亡，然后init启动新的虚拟登录控制台，因而总是提供六个虚拟登陆控控制台进程。控制init程序操作的规则存放在文件/etc/inittab中。Red Hat Linux缺省的inittab文件如下：# #inittab This file describes how the INIT process should set up the system in a certain #run-level. # # #Default runlevel.The runlevels used by RHS are: #0-halt(Do NOT set initdefault to this) #1-Single user mode #2-Multiuser,without NFS(the same as 3,if you do not have networking) #3-Full multiuser mode #4-unused #5-X11 #6-reboot(Do NOT set initdefault to this)
使用modelsin对quartus II仿真时遇到问题的解决方法
1、FFT core可以设置成两种不同的引擎结构，四输出（Quad——output）和单输出（signal output），对于要求转换时间尽量小的应用，四输出的是最佳的结构，对于要求资源尽量小的应用，单输出的引擎结构比较合适，为了增加吞吐量，可以采用并行引擎结构。 FFT core支持的数据流： FFT core支持三种I/O数据流结构，连续（streaming）、缓冲突发（buffered burst）、突发（burst）。连续I/o数据流允许处理连续输入数据，输出连续复数数据流，而不中断输入和输出数据；缓冲突发结构于连续相比，需要更少的存储资源，但是这是以减少平均吞吐量为代价的；突发数据流的操作于缓冲突发的方法基本上一致，但是突发方式需要更少的存储资源，这也是以降低吞吐量为代价的、。2、用modelsim对fft模块进行仿真的时候出现此类问题的解决方法： ** Error: (vsim-3033) E:/Quartus II projects/fft_1024_t/fft_1024_ip.v(92): Instantiation of 'asj_fft_sglstream_fft_130' failed. The design unit was not found. 出现这种情况， 第一可能是quartus破解不完整，导致有些库已经器件不能够使用，重新破解，在破解的时候有时候可能有好几个网卡，则选择前两个网卡号对license.dat进行破解。 在完整破解的时候，在仿真的时候需要加进去.vo文件以及测试文件，顶层文件，同时将生成fft核的时候产生.hex,.txt文件,在进行仿真的时候需要将其放到所建的modelsim工程文件夹下面。 第二种情况就是在不同版本的quartus上建立了ip核，比如说在9.0上建立的文件，在8.0上进行综合编译，就会出现这样的问题。解决方法就是在现有的版本上重新建一个fft核之后进行仿真，应该就可以解决问题了。 3、在高版本的quartus中打开低版本的quartus工程的时候，存储原来quartus 工程的路径不要包含汉字，否则会造成打不开文件的情况。 4、在modelsim中对rom核进行仿真的时候可能会出现这样的问题： #warning：（vsim—3524）【FOFIR】—Failed to open file’simulation_ip.hex’for reading. #No such file for directory.(error=ENOENT) 出现这样的情况是因为在quartus 中建立的是.mif的文件，但是在modelsim中
Linux内核启动流程分析(一)
很久以前分析的，一直在电脑的一个角落，今天发现贴出来和大家分享下。由于是word直接粘过来的有点乱，敬请谅解！ S3C2410 Linux 2.6.35.7启动分析(第一阶段) arm linux 内核生成过程 1. 依据arch/arm/kernel/vmlinux.lds 生成linux内核源码根目录下的vmlinux，这个vmlinux属于未压缩， 带调试信息、符号表的最初的内核，大小约23MB； 命令：arm-linux-gnu-ld -o vmlinux -T arch/arm/kernel/vmlinux.lds arch/arm/kernel/head.o init/built-in.o --start-group arch/arm/mach-s3c2410/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o drivers/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o 2. 将上面的vmlinux去除调试信息、注释、符号表等内容，生成arch/arm/boot/Image，这是不带多余信息的linux内核，Image的大小约 3.2MB； 命令:arm-linux-gnu-objcopy -O binary -S vmlinux arch/arm/boot/Image 3.将 arch/arm/boot/Image 用gzip -9 压缩生成arch/arm/boot/compressed/piggy.gz大小约 1.5MB；命令:gzip -f -9 < arch/arm/boot/compressed/../Image > arch/arm/boot/compressed/piggy.gz 4. 编译arch/arm/boot/compressed/piggy.S 生成arch/arm/boot/compressed/piggy.o大小约1.5MB，这里实 际上是将piggy.gz通过piggy.S编译进piggy.o文件中。而piggy.S文件仅有6行，只是包含了文件piggy.gz; 命令:arm-linux-gnu-gcc -o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/piggy.S 5. 依据arch/arm/boot/compressed/vmlinux.lds 将arch/arm/boot/compressed/目录下的文件head.o 、piggy.o 、misc.o链接生成arch/arm/boot/compressed/vmlinux，这个vmlinux是经过压缩且含有自解压代码的内核, 大小约1.5MB; 命 令:arm-linux-gnu-ld zreladdr=0x30008000 params_phys=0x30000100 -T arch/arm/boot/compressed/vmlinux.lds a rch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o arch/arm/boot/compressed/misc.o -o arch/arm /boot/compressed/vmlinux
modelsim使用命令
1. 常用仿真命令 vlib work // 建立work仿真库 vmap work wrok // 映射库 vlog -cover bcest *.v // 加覆盖率分析的编译 vsim -coverage -voptargs="+acc" -t ns test // 仿真文件为test.v add wave * // 将所有模块waveform. dump出来 add wave sim:/test/t/M2/Reg_out // 将模块Reg_out中的waveform. dump出来 delete wave /test/i 2. SVA 断言仿真命令 vlog -sv a.v vsim -assertdebug test view assertions vsim -assertdebug ScaleBlock_tf -L xilinxcorelib_ver -L unisims_ver // 加载xilinxlib库 3. verror 3601 // 查错 4. 给仿真工具加载xilinx 库命令 (1)加载之前将modelsim.ini改为非“只读” (2)“运行” cmd，到xilinx目录下 (3) C:\Xilinx > compxlib -s mti_se -p c:\Modeltech_6.0\win32 -f all -l verilog -o C:\ Modeltech_6.0\Xilinx_lbis 或者Xilinx目录下.\bin\nt\下有compxlib.exe
简单得modelsim命令行仿真 用do文件进行仿真真得很方便，比写testbench方便多了，我是深有感触呀，开始时因为不知道，只知道写testbence，在小得模块也写testbench,真得很烦躁！而且信号定义什么得比较多，采用do文件得方法就没有那么多信号定义了，管理也比较方便，呵呵，真得很方便，而且采用命令行得形式，感觉特有成就感，呵呵！ 1.运行仿真，在主窗口输入命令：vsim work.实体名 2.为时钟信号添加驱动，输入命令：force clk 0 0,1 10 -r 20，将仿真时钟设为50MHz；(设时间单位为ns) 3.打开波形窗口，输入命令：view wave 4.为波形窗口添加信号，输入命令：add wave -hex *，这里的*表示添加设计中所有的信号，-hex 表示以十六进制来表示波形窗口中的信号值； 5.开始仿真，输入命令，run 3us，这时候在波形窗口中出现仿真波形 6.退出仿真，输入命令：quit –sim。 modelsim常用命令 分类：Verilog/FPGA 2010-05-26 10:49 354人阅读评论(1) 收藏举报 用do文件进行仿真真得很方便，比写testbench方便多了，采用do文件没有那么多信号定义，管理也比较方便. 1.运行仿真，在主窗口输入命令：vsim work.实体名 2.为时钟信号添加驱动，输入命令：force clk 0 0,1 10 -r 20，将仿真时钟设为50MHz；(设时间单位为ns) 3.打开波形窗口，输入命令：view wave 4.为波形窗口添加信号，输入命令：add wave -hex *，这里的*表示添加设计中所有的信号，-hex表示以十六进制来表示波
嵌入式linux系统地启动过程
一、分析嵌入式系统的启动过程 嵌入式系统的启动过程： 上电------->u-boot------->加载Linux内核------->挂载rootfs ---->执行应用程序 二、分析u-boot 1.什么是u-boot（是一个通用的bootloader） U-Boot，全称Universal Boot Loader，是遵循GPL条款的开放源码项目。 Universal ----------->通用的 Boot ----------------->启动，引导 Loader ----------------->加载 通用------->支持多种架构的CPU,除了支持ARM系列的处理器外，还能支持MIPS、x86、Power PC、NIOS等诸多常用系列的处理器 ------->支持多种厂家的开发板，如cortex-A8，cortex-A9，cortex-A53等不同厂 家的开发板 ------->支持多种嵌入式操作系统，U-Boot不仅仅支持嵌入式Linux系统的引导，它还支持Net BSD, Vx Works, QNX, RTEMS, ARTOS, Lynx OS, android 嵌入式操作系统。 Boot -------->完成硬件的初始化，启动硬件平台。 Loader ------->当初始化硬件结束后，加载操作系统。 2.u-boot的作用 大多数BootLoader都分为stage1和stage2两大部分，U-boot也不例外。依赖于cpu体系结构的代码（如设备初始化代码等）通常都放在stage1且可以用汇编语言来实现，而stage2则通常用C语言来实现，这样可以实现复杂的功能，而且有更好的可读性和移植性。 （1）Stage1：CPU（S5P6818-->Cortex-A53）的初始化,使用汇编语言编写。 如：初始化Cache、MMU、clock、中断、看门狗、DDR3、eMMC、... （2）Stage2：板级初始化，使用C语言编写。 如：uart、网卡、usb、LCD、.... （3）提供了一些工具，如进入uboot的命令行模式，使用u-boot命令 （4）加载操作系统 3.U-boot的工作模式 U-Boot的工作模式有启动加载模式和下载模式。
荐)ModelSim SE仿真Altera库的一些问题 常见仿真错误 问题 合集
荐)ModelSim SE仿真Altera库的一些问题常见仿真错误问题合集 1. modelsim怎么调用altera的库仿真啊？(megafunctions) 以前有个帖子说把quartus安装目录下的sim文件夹里面的文件编译进modelsim里面就可以了，可是sim文件夹里面我要的那个函数不是.v文件啊，还有他里面的一些.vhd文件怎么编译错误啊？ 是eda/sim_lib里，编译错误，我想是你编译的顺序不对 用EDA/SIM_LIB中文件直接放到PROJECT中，你需要看看它的告错信息。一般是缺库。你可以按提示缺的库，在FILE/NEW/LIBRARY菜单里创建一个映射到WORK的库。这样一般就好了。 如何在modelsim里如altera的库中做后仿真啊，急死了 我用synplify综合后，用modelsim做后仿真，我在modelsim里面加入了C:quartusedasim_libmodelsimvhdl里面的两个库，但是编译的时候还是提示我找不到library apex20k。还要加什么库啊？？？郁闷死了 vlib apex20k vmap apex20k apex20k vcom -work apex20k c:/quartus/eda/sim_lib/apex20k_atoms.vhd vcom -work apex20k c:/quartus/eda/sim_lib/apex20k_components.vhd 谢谢i8086，我现在知道怎么加入altera的库了，但是错误依然在，不知道是什么原因，modelsim里面的提示如下：vcom -reportprogress 300 -work work {D:/caiyang/rev_1/caiyang_1.vhd} # Model Technology ModelSim SE vcom 5.7e Compiler 2003.07 Jul 8 2003 # -- Loading package standard # ** Error: (vcom-19) Failed to access library 'acex2k' at "acex2k". # No such file or directory. (errno = ENOENT) # ** Error: D:/caiyang/rev_1/caiyang_1.vhd(7): Library acex2k not found. # -- Loading package std_logic_1164 # -- Loading package numeric_std # -- Loading package components # ** Error: D:/caiyang/rev_1/caiyang_1.vhd(12): Unknown identifier: acex2k # ** Error: D:/caiyang/rev_1/caiyang_1.vhd(14): VHDL Compiler exiting library ieee, acex2k; use ieee.std_logic_1164.all; use ieee.numeric_std.all; library synplify; use https://www.doczj.com/doc/a96352086.html,ponents.all; use acex2k.acex2k_components.all; ~~~~~~~~~~~~~~~就是提示找不到这个东西，这是用synplify综合后的文件的前面几行代码。 除了把altera的apex20k库加上外，还要把acex2k对应的库加上，跟加apex20k库差不多。不过我不知道acex2k对应的vhd文件。
linux系统引导过程
linux系统引导过程简介 首先,主板的BIOS会读取硬盘的主引导记录(MBR),MBR中存放的是一段很小的程序,他的功能是从硬盘读取操作系统核心文件并运行,因为这个小程序太小了,因此通常这个小程序不具备直接引导系统内核的能力,他先去引导另一个稍微大一点的小程序,再由这个大一点的小程序去引导系统内核.在linux系统中这样的小程序有LILO和GRUB.在这个项目中,我决定用LILO来做系统引导程序.在软盘上启动linux系统的过程和在硬盘上启动的过程相似. Linux系统内核被引导程序装入内核并运行后,linux内核会检测系统中的各种硬件.并做好各种硬件的初始化工作,使他们在系统正式运行后能正常工作.之后内核做的最后一个工作是运行 /sbin下的init程序,init是英文单词initialization(初始化)的简称,init程序的工作是读取/etc/inittab 文件中描述的指令,对系统的各种软硬件环境做最初化设定.最后运行mingetty等待用户输入用户名登录系统.所有的工作就这么简单,虽然linux启动的时候有很多内容,看上去十分高深,但是都不过是对这个过程的扩充.明白了这个道理,你可以写一些脚本程序让他在系统启动的特定时间运行完成任务.事实上系统内核并不关心/sbin下的init是不是真的init,只要是放在/sbin下名叫init 的可执行程序他都可以执行. Red Hat Enterprise Linux在电脑的启动阶段，一共经历以下两个阶段: 1.启动内核。在这个阶段，内核装入内存并在初始化每个设备驱动器时打印信息。 2.执行程序init．(系统初始化)．装入内核并初始化设备后，运行init程序。init程序处理所有程序的启动，包括重要系统精灵程序和其它指定在启动时装入的软件。 开机---BIOS自检---载入启动程序---加载内核---启动init服务---加载/etc/inittab---Run level---rc.sysinit---rc--- mingetty---rc.local 一.BIOS自检 当电脑开机的时候,电脑会进入BIOS,在PC机中引导LINUX是从BIOS中的地址0xFFFF0处开始的.BIOS的第一个步骤是加电自检,即所谓的POST(Power On Self Test),BIOS的第二个步骤是进行本地设备的枚举和初始化,侦测电脑周边配套设备是否工作正常,如cpu的类型,速度,缓存等;主板类型,内存的速度,容量,硬盘的大小,类型和工作模式,风扇速度等,主要是为了检查这些设备在开机的时候是否能通过检测,说明电脑可以正常的工作.BIOS由两部分组成:POST代码和运行时的服务.当POST完成之后,它被从内存中清理了出来,但是,BOIS 运行时服务依然保留在内存中,目标操作系统可以使用这些服务 二.载入启动程序
ARMLinux启动过程分析_百度文库.
ARM Linux启动过程分析 一个嵌入式Linux 系统从软件角度看可以分为四个部分[1]：引导加载程序（bootloader），Linux 内核，文件系统，应用程序。 其中 bootloader是系统启动或复位以后执行的第一段代码，它主要用来初始化处理器及外设，然后调用 Linux 内核。Linux 内核在完成系统的初始化之后需要挂载某个文件系统做为根文件系统（Root Filesystem）。根文件系统是 Linux 系统的核心组成部分，它可以做为Linux 系统中文件和数据的存储区域，通常它还包括系统配置文件和运行应用软件所需要的库。应用程序可以说是嵌入式系统的“灵魂”，它所实现的功能通常就是设计该嵌入式系统所要达到的目标。如果没有应用程序的支持，任何硬件上设计精良的嵌入式系统都没有实用意义。 从以上分析我们可以看出bootloader 和Linux 内核在嵌入式系统中的关系和作用。Bootloader在运行过程中虽然具有初始化系统和执行用户输入的命令等作用，但它最根本的功能就是为了启动 Linux 内核。在嵌入式系统开发的过程中，很大一部分精力都是花在bootloader 和 Linux 内核的开发或移植上。如果能清楚的了解 bootloader 执行流程和 Linux的启动过程，将有助于明确开发过程中所需的工作，从而加速嵌入式系统的开发过程。而这正是本文的所要研究的内容。 2. Bootloader 2.1 Bootloader的概念和作用Bootloader是嵌入式系统的引导加载程序，它是系统上电后运行的第一段程序，其作用类似于 PC 机上的BIOS。在完成对系统的初始化任务之后，它会将非易失性存储器（通常是 Flash或 DOC 等）中的Linux 内核拷贝到 RAM 中去，然后跳转到内核的第一条指令处继续执行，从而启动 Linux 内核。由此可见，bootloader 和 Linux 内核有着密不可分的联系，要想清楚的了解 Linux内核的启动过程，我们必须先得认识bootloader的执行过程，这样才能对嵌入式系统的整个启过程有清晰的掌握。 2.2 Bootloader的执行过程不同的处理器上电或复位后执行的第一条指令地址并不相同，对于 ARM 处理器来说，该地址为 0x00000000。对于一般的嵌入式系统，通常把 Flash 等非易失性存储器映射到这个地址处，而 bootloader就位于该存储器的最前端，所以系统上电或复位后执行的第一段程序便是 bootloader。而因为存储 bootloader的存储器不同，bootloader的执行过程也并不相同，下面将具体分析。嵌入式系统中广泛采用的非易失性存储器通常是 Flash，而 Flash 又分为 Nor Flash 和Nand Flash 两种。它们之间的不同在于： Nor Flash 支持芯片内执行（XIP， eXecute In Place），这样代码可以在Flash上直接执行而不必拷贝到RAM中去执行。而Nand Flash并不支持XIP，所以要想执行 Nand Flash 上的代码，必须先将其拷贝到 RAM中去，然后跳到 RAM 中去执行。实际应用中的 bootloader根据所需功能的不同可以设计得很复杂，除完成基本的初始化系统和调用 Linux 内核等基本任务外，还可以执行很多用户输入的命令，比如设置 Linux 启动参数，给 Flash 分区等；也可以设计得很简单，只完成最基本的功能。但为了能达到启动Linux 内核的目的，所有的 bootloader都必须具备以下功能：BR> 1 初始化RAM 因为 Linux 内核一般都会在 RAM 中运行，所以在调用 Linux 内核之前 bootloader 必须设置和初始化 RAM，为调用
相关主题文本预览