⑴ linux实时时间 xtime怎么获取并使用
RTC时间操作：
1.rtc时间是由rtc硬件控制的，所以在linux中想要修改和获取rtc时间就只能通过驱动的接口来获取和修改。
intrtc_test(void)
{
structrtc_timertc;
intfd=-1;
intret=-1;
fd=open("/dev/rtc0",O_RDWR);
if(fd<0){
return-1;
}
ret=ioctl(fd,RTC_RD_TIME,&rtc);
if(ret<0){
return-1;
}
printf(" CurrentRTCdata/timeis%d-%d-%d,%02d:%02d:%02d. ",rtc.tm_mday,rtc.tm_mon+1,
rtc.tm_year+1900,rtc.tm_hour,rtc.tm_min,rtc.tm_sec);
ret=ioctl(fd,RTC_SET_TIME,&rtc);
if(ret<0){
return-1;
}
return0;
}
2.除了上面这种方式操作rtc时间以外，linux中也有一个命令可以简化rtc时间操作，hwclock，比如，可以通过system("hwclock-w");系统调用来把xtime设置到rtc硬件。
墙上时间（realtime、xtime）：
linux系统中主要使用的就是xtime，它是系统运行的基础，很多程序都是依赖于xtime来运行的，接下来将介绍将如何操作xtime。
1.获取、设置微秒级别的时间：
#include
#include
structtimeval
{
inttv_sec;
inttv_usec;
};
intgettimeofday(structtimeval*tv,structtimezone*tz);
intsettimeofday(conststructtimeval*tv,conststructtimezone*gz);
功能描述：
gettimeofday()获取当前时间，有tv指向的结构体返回。
settimeofday()把当前时间设成由tv指向的结构体数据。当前地区信息则设成tz指向的结构体数据。
2.获取秒级别的时间
typedeflongtime_t;
time_ttime(time_t*t);
如果t是non-null，它将会把时间值填入t中
3.内核2.6版本后新增的clockapi接口
获取纳秒级别的时间
structtimespec{
time_ttv_sec;/*秒s*/
longtv_nsec;/*纳秒ns*/
};
intclock_getres(clockid_tclk_id,structtimespec*res);
intclock_gettime(clockid_tclk_id,structtimespec*tp);
intclock_settime(clockid_tclk_id、conststructtimespec*tp);
编译连接时采用-lrt才能编译通过。
clk_id可选参数：
CLOCK_REALTIME
系统全局的实时时钟.设置此时钟需要合适的权限.
CLOCK_MONOTONIC
只能被读取，无法被设置,表示monotonic时间起点.
CLOCK_PROCESS_CPUTIME_ID
从cpu每进程的高分辨率计时器.
CLOCK_THREAD_CPUTIME_ID
线程的特定cpu时间时钟.
系统启动时，会首先从rtc中读取rtc时间，并设置给xtime，而当ntp对系统时间进行更新时，首先设置xtime，然后调用hwclock设置到rtc硬件中。xtime根据需要的精度，可以通过上面几个接口来选择使用。
⑵ linux下怎么直接使用iic接口
利用Linux中IIC设备子系统移植IIC设备驱动
背景描述
IIC总线在嵌入式系统中应用十分广泛，常见的有eeprom，rtc。一般的处理器会包含IIC的控制器，用来完成IIC时序的控制；另外一方面，由于IIC的时序简单，使用GPIO口来模拟时序也是常见的做法。面对不同的IIC控制器，各种各样的芯片以及linux源码，如何更快做好IIC设备驱动。
问题描述
在我们的方案中，我们会用到eeprom，rtc以及tw2865。由于Hi3520的IIC控制器设计有问题，无法正常使用。而IIC控制器的SDA和SCL管脚正好是和两个GPIO管脚复用的。Hisi将控制gpio来实现IIC的时序，从而对IIC设备进行操作。这种设计方式简单明了，但使用IIC子系统，可以更方便的移植和维护其他的设备驱动。
问题分析
Hisi对于gpio口，rtc芯片以及tw2865的处理方式如下：将gpio口做成一个模块化的驱动，该驱动模拟IIC时序，并向外提供一些函数接口，比如：EXPORT_SYMBOL(gpio_i2c_read_tw2815);等。对于具体的rtc芯片，将其注册为一个misc设备，并利用gpio模块导出的函数进行rtc芯片的配置操作。
其实对于linux-2.6.24\drivers\i2c目录下代码，我们可以加以利用。
Linux的IIC字结构分为三个组成部分：
IIC核心
IIC核心提供了IIC总线驱动和设备驱动的注册、注销方法，IICalgorithm上层的、与具体适配器无关的代码以及探测设备、检测设备地址的上层代码。
IIC总线驱动
IIC总线驱动是对IIC硬件体系结构中适配器端的实现。
IIC设备驱动
IIC设备驱动是对IIC硬件体系总设备端的实现。
我们查看下该目录下的makefile和kconfig：
obj-$(CONFIG_I2C_BOARDINFO) +=i2c-boardinfo.o
obj-$(CONFIG_I2C) += i2c-core.o
obj-$(CONFIG_I2C_CHARDEV) +=i2c-dev.o
obj-y +=busses/ chips/ algos/
i2c-core.c就是IIC核心，buses中的文件是主流处理器中IIC总线的总线驱动，而chips中的文件就是常用芯片的驱动，algos中的文件实现了一些总线适配器的algorithm，其中就包括我们要用到的i2c-algo-bit.c文件。
我们首先利用i2c-gpio.c和i2c-algo-bit.c做好总线驱动。
在i2c-gpio.c中，mole_initi2c_gpio_initplatform_driver_probe(&i2c_gpio_driver,i2c_gpio_probe);
将其注册为platform虚拟总线的驱动。
在staticint __init i2c_gpio_probe(struct platform_device *pdev)中，
定义了如下三个结构体：
structi2c_gpio_platform_data *pdata;//平台相关的gpio的设置
structi2c_algo_bit_data *bit_data;//包含algorithm的具体函数，setor
get SDA和SCL
structi2c_adapter *adap;//适配器
i2c_gpio_probe主要做了下面几件事：
填充bit_data结构的各个函数指针，关联到具体的操作SDA和SCl函数。
填充adap结构，adap->algo_data= bit_data;
pdata= pdev->dev.platform_data;
bit_data->data= pdata;
pdev->dev->driver_data= adap;
在i2c-core中注册适配器类型。
inti2c_bit_add_numbered_bus(struct i2c_adapter *adap)
在staticint i2c_bit_prepare_bus(struct i2c_adapter *adap)中
adap->algo= &i2c_bit_algo;
将i2c_bit_algo与adap关联上。
static const structi2c_algorithm i2c_bit_algo = {
.master_xfer = bit_xfer,
.functionality = bit_func,
};
其中，master_xfer函数指针就是IIC传输函数指针。
I2c-algo-bit.c还实现了IIC开始条件，结束条件的模拟，发送字节，接收字节以及应答位的处理。
i2c-gpio.c中的i2c_gpio_setsda_val等函数是与具体平台gpio相关的。
修改对应arch-hi3520v100目录下的gpio.h中的各个函数，这些函数是通过操作寄存器来控制gpio的方向和值。
在对应mach-hi3520v100中的platform-devices.c中添加如下：
static structi2c_gpio_platform_data pdata = {
.sda_pin = 1<<0,
.sda_is_open_drain = 1,
.scl_pin = 1<<1,
.scl_is_open_drain = 1,
.udelay = 4, /* ~100 kHz */
};
static struct platform_devicehisilicon_i2c_gpio_device = {
.name = "i2c-gpio",
.id = -1,
.dev.platform_data = &pdata,
};
static struct platform_device*hisilicon_plat_devs[] __initdata = {
&hisilicon_i2c_gpio_device,
};
int __inithisilicon_register_platform_devices(void)
{
platform_add_devices(hisilicon_plat_devs,ARRAY_SIZE (hisilicon_plat_devs));
return 0;
}
通过platform添加devices和driver，使得pdev->dev.platform_data=pdata
综合上面的过程，我们完成了adapter的注册，并将用gpio口模拟的algorithm与adapter完成了关联。
这样，在rtc-x1205.c中，x1205_attach函数利用i2c核心完成client和adap的关联。
在x1205_probe函数中填充i2c_client结构体，并调用i2c_attach_client通知iic核心。
接着注册rtc驱动。
最后我们要读取时间，就需要构造i2c_msg结构体，如下所示：
struct i2c_msg msgs[] = {
{ client->addr, 0, 2,dt_addr }, /* setup read ptr */
{ client->addr, I2C_M_RD,8, buf }, /* read date */
};
/* read date registers */
if((i2c_transfer(client->adapter, &msgs[0], 2)) != 2) {
dev_err(&client->dev,"%s: read error\n", __FUNCTION__);
return -EIO;
}
dt_addr是寄存器的地址，I2C_M_RD表示iicread。
⑶ 如何使用linux的Documentation来写驱动
Linux I2C驱动是嵌入式Linux驱动开发人员经常需要编写的一种驱动，因为凡是系统中使用到的I2C设备，几乎都需要编写相应的I2C驱动去配置和控制它，例如 RTC实时时钟芯片、音视频采集芯片、音视频输出芯片、EEROM芯片、AD/DA转换芯片等等。
Linux I2C驱动涉及的知识点还是挺多的，主要分为Linux I2C的总线驱动（I2C BUS Driver）和设备驱动（I2C Clients Driver），本文主要关注如何快速地完成一个具体的I2C设备驱动（I2C Clients Driver）。关于Linux I2C驱动的整体架构、核心原理等可以在网上搜索其他相关文章学习。
本文主要参考了Linux内核源码目录下的 ./Documentation/i2c/writing-clients 文档。以手头的一款视频采集芯片TVP5158为驱动目标，编写Linux I2C设备驱动。
1. i2c_driver结构体对象
每一个I2C设备驱动，必须首先创造一个i2c_driver结构体对象，该结构体包含了I2C设备探测和注销的一些基本方法和信息，示例如下：
static struct i2c_driver tvp5158_i2c_driver = { .driver = { .name = "tvp5158_i2c_driver", }, .attach_adapter = &tvp5158_attach_adapter, .detach_client = &tvp5158_detach_client, .command = NULL, };
其中，name字段标识本驱动的名称（不要超过31个字符），attach_adapter和detach_client字段为函数指针，这两个函数在I2C设备注册的时候会自动调用，需要自己实现这两个函数，后面将详细讲述。
2. i2c_client 结构体对象
上面定义的i2c_driver对象，抽象为一个i2c的驱动模型，提供对i2C设备的探测和注销方法，而i2c_client结构体则是代表着一个具体的i2c设备，该结构体有一个data指针，可以指向任何私有的设备数据，在复杂点的驱动中可能会用到。示例如下：
struct tvp5158_obj{ struct i2c_client client; int users; // how many users using the driver }; struct tvp5158_obj* g_tvp5158_obj;
其中，users为示例，用户可以自己在tvp5158_obj这个结构体里面添加感兴趣的字段，但是i2c_client字段不可少。具体用法后面再详细讲。
3. 设备注册及探测功能
这一步很关键，按照标准的要求来写，则Linux系统会自动调用相关的代码去探测你的I2C设备，并且添加到系统的I2C设备列表中以供后面访问。
我们知道，每一个I2C设备芯片，都通过硬件连接设定好了该设备的I2C设备地址。因此，I2C设备的探测一般是靠设备地址来完成的。那么，首先要在驱动代码中声明你要探测的I2C设备地址列表，以及一个宏。示例如下：
static unsigned short normal_i2c[] = { 0xbc >> 1, 0xbe >> 1, I2C_CLIENT_END }; I2C_CLIENT_INSMOD;
normal_i2c 数组包含了你需要探测的I2C设备地址列表，并且必须以I2C_CLIENT_END作为结尾，注意，上述代码中的0xbc和0xbe是我在硬件上为我的tvp5158分配的地址，硬件上我支持通过跳线将该地址设置为 0xbc 或者 0xbe，所以把这两个地址均写入到探测列表中，让系统进行探测。如果你的I2C设备的地址是固定的，那么，这里可以只写你自己的I2C设备地址，注意必须向右移位1。
宏 I2C_CLIENT_INSMOD 的作用网上有许多文章进行了详细的讲解，这里我就不详细描述了，记得加上就行，我们重点关注实现。
下一步就应该编写第1步中的两个回调函数，一个用于注册设备，一个用于注销设备。探测函数示例如下：
static int tvp5158_attach_adapter(struct i2c_adapter *adapter) { return i2c_probe(adapter, &addr_data, &tvp5158_detect_client); }
这个回调函数系统会自动调用，我们只需要按照上述代码形式写好就行，这里调用了系统的I2C设备探测函数，i2c_probe()，第三个参数为具体的设备探测回调函数，系统会在探测设备的时候调用这个函数，需要自己实现。示例如下：
static int tvp5158_detect_client(struct i2c_adapter *adapter,int address,int kind) { struct tvp5158_obj *pObj; int err = 0; printk(KERN_INFO "I2C: tvp5158_detect_client at address %x ...\n", address); if( g_tvp5158_obj != NULL ) { //already allocated,inc user count, and return the allocated handle g_tvp5158_obj->users++; return 0; } /* alloc obj */ pObj = kmalloc(sizeof(struct tvp5158_obj), GFP_KERNEL); if (pObj==0){ return -ENOMEM; } memset(pObj, 0, sizeof(struct tvp5158_obj)); pObj->client.addr = address; pObj->client.adapter = adapter; pObj->client.driver = &tvp5158_i2c_driver; pObj->client.flags = I2C_CLIENT_ALLOW_USE; pObj->users++; /* attach i2c client to sys i2c clients list */ if((err = i2c_attach_client(&pObj->client))){ printk( KERN_ERR "I2C: ERROR: i2c_attach_client fail! address=%x\n",address); return err; } // store the pObj g_tvp5158_obj = pObj; printk( KERN_ERR "I2C: i2c_attach_client ok! address=%x\n",address); return 0; }
到此为止，探测并且注册设备的代码已经完成，以后对该 I2C 设备的访问均可以通过 g_tvp5158_obj 这个全局的指针进行了。
⑷ Linux内核睡眠唤醒调试
本文基于 RockPI 4A 单板 Debian 系统 Linux4.4 内核介绍下睡眠唤醒（ suspend/resume ）的一些调试方法。
1、关闭串口睡眠
在Linux内核睡眠过程中，会先调用 suspend_console() 函数使串口进入睡眠状态，这样会导致后续设备驱动的睡眠过程不可见。可以在boot启动参数中增加 no_console_suspend 参数，显示设备驱动睡眠日志。
2、修改串口日志等级
修改串口日志打印等级，显示更多调试信息。
3、打开设备睡眠唤醒时间
设置 pm_print_times 参数，可以显示设备驱动睡眠唤醒时间，方便调试时查看哪个函数处理占用时间过长。
在调试Linux内核睡眠唤醒功能时，可以使用 RTC 做唤醒源，在系统睡眠5秒后，自动唤醒系统。
在 arch/arm64/configs/rockchip_linux_defconfig 文件中配置宏 CONFIG_PM_TEST_SUSPEND 。
唤醒日志如下：
⑸ 如何调整Linux内核启动中的驱动初始化顺序late
Linux内核为不同驱动的加载顺序对应不同的优先级，定义了一些宏：
include\linux\init.h
#define pure_initcall(fn) __define_initcall("0",fn,1)
#define core_initcall(fn) __define_initcall("1",fn,1)
#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
#define postcore_initcall(fn) __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
#define arch_initcall(fn) __define_initcall("3",fn,3)
#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
#define subsys_initcall(fn) __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn) __define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn) __define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
#define __initcall(fn) device_initcall(fn)
把自己的驱动的函数名用这些宏去定义之后，
就会对应不同的加载时候的优先级。
其中，我们写驱动中所用到的mole_init对应的是
#define mole_init(x) __initcall(x);
而
#define __initcall(fn) device_initcall(fn)
所以，驱动对应的加载的优先级为6
在上面的不同的优先级中，
数字越小，优先级越高。
同一等级的优先级的驱动，加载顺序是链接过程决定的，结果是不确定的，我们无法去手动设置谁先谁后。
不同等级的驱动加载的顺序是先优先级高，后优先级低，这是可以确定的。
所以，像我们之前在驱动中用：
mole_init(i2c_dev_init);
mole_init(as352x_afe_init);
mole_init(as352x_afe_i2c_init);
mole_init(enc28j60_init);
所以，大家都是同一个优先级去初始化，
最后这些驱动加载的顺序，可以查看在根目录下，
生成的system.map：
。。。
c00197d8 t __initcall_alignment_init5
。。。。。
c00197f4 t __initcall_default_rootfsrootfs
c00197f8 t __initcall_timer_init_sysfs6
c00197fc t __initcall_clock_dev_init6
。。。
c00198d8 t __initcall_loop_init6
c00198dc t __initcall_net_olddevs_init6
c00198e0 t __initcall_loopback_init6
c00198e4 t __initcall_enc28j60_init6
。。。
c0019900 t __initcall_as352x_spi_init6
c0019904 t __initcall_spidev_init6
。。。
c0019920 t __initcall_i2c_dev_init6
c0019924 t __initcall_as352x_afe_i2c_init6
c0019928 t __initcall_as352x_afe_init6
。。。
c0019970 t __initcall_random32_reseed7
c0019974 t __initcall_seqgen_init7
c0019978 t __initcall_rtc_hctosys7
c001997c T __con_initcall_start
c001997c t __initcall_con_init
c001997c T __initcall_end
。。。
此处就是由于
c0019920 t __initcall_i2c_dev_init6
c0019924 t __initcall_as352x_afe_i2c_init6
c0019928 t __initcall_as352x_afe_init6
在
c00198e4 t __initcall_enc28j60_init6
之前，所以我这里才要去改。。。
知道原理，能想到的，就是
要么把
as352x_afe_init
改到
enc28j60_init
之前一级，即优先级为5。
即在驱动中，调用：
fs_initcall(as352x_afe_init)；
要么把
enc28j60_init
改到
as352x_afe_init
之后，即优先级为7
即在驱动中，调用：
late_initcall(enc28j60_init)；
但是，此处麻烦就麻烦在，
如果把
as352x_afe_init
改到
enc28j60_init
之前一级，
发现后面网卡初始化enc28j60_init中，虽然读取芯片ID对了，
但是后面的IP-auto configure 有问题。
所以放弃。
如果把
enc28j60_init
改到
as352x_afe_init
之后，
但是，从system.map中看到的是，优先级为7的驱动中，明显有几个驱动，
也是和网卡初始化相关的，所以，这样改，尝试后，还是失败了。
所以，没法简单的通过调整现有的驱动的顺序，去实现顺序的调整。
最后，被逼无奈，想到了一个可以实现我们需求的办法，
那就是，单独定义一个优先级，把afe相关的初始化都放到那里面去，
这样，就可以保证，其他没什么相关的冲突了。
最后证实，这样是可以实现目的的。
具体添加一个新的优先级的步骤如下：
1.定义新的优先级
include\linux\init.h中：
#define pure_initcall(fn) __define_initcall("0",fn,1)
#define core_initcall(fn) __define_initcall("1",fn,1)
#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
#define postcore_initcall(fn) __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
#define arch_initcall(fn) __define_initcall("3",fn,3)
#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
#define subsys_initcall(fn) __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn) __define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#if 1
#define prev_device_initcall(fn) __define_initcall("6",fn,6)
#define prev_device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define device_initcall(fn) __define_initcall("7",fn,7)
#define device_initcall_sync(fn) __define_initcall("7s",fn,7s)
#define late_initcall(fn) __define_initcall("8",fn,8)
#define late_initcall_sync(fn) __define_initcall("8s",fn,8s)
#else
#define device_initcall(fn) __define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
#endif
2.用对应新的宏，定义我们的驱动：
prev_device_initcall(i2c_dev_init);
prev_device_initcall(as352x_afe_i2c_init);
prev_device_initcall(as352x_afe_init);
做到这里，本以为可以了，但是编译后，在system.map中，发现之前优先级为7的那几个函数，
被放到system.map最后了，而不是预想的，
在优先级7之后，在
c001997c T __con_initcall_start
c001997c t __initcall_con_init
c001997c T __initcall_end
之前。
最后，发现时没有把对应的链接文件中的宏加进去：
3.
include\asm-generic\vmlinux.lds.h
#if 1
#define INITCALLS \
*(.initcall0.init) \
*(.initcall0s.init) \
*(.initcall1.init) \
*(.initcall1s.init) \
*(.initcall2.init) \
*(.initcall2s.init) \
*(.initcall3.init) \
*(.initcall3s.init) \
*(.initcall4.init) \
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
*(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
*(.initcall7s.init) \
*(.initcall8.init) \
*(.initcall8s.init)
#else
#define INITCALLS \
*(.initcall0.init) \
*(.initcall0s.init) \
*(.initcall1.init) \
*(.initcall1s.init) \
*(.initcall2.init) \
*(.initcall2s.init) \
*(.initcall3.init) \
*(.initcall3s.init) \
*(.initcall4.init) \
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
*(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
*(.initcall7s.init)
#endif
最后，再重新编译，就可以实现我们要的，
和afe相关的驱动初始化，都在网卡enc28j60_init之前了。
也就可以在网卡里面读芯片ID了。
当然，对应编译生成的system.map文件中，
对应的通过mole_init定义的驱动，优先级也都变成7了。
而late_initcall对应优先级8了。
注：当前开发板arm的板子，所以，对应的load 脚本在：
linux-2.6.28.4\arch\arm\kernel\vmlinux.lds
看起来，应该是这个文件：
linux-2.6.28.4\arch\arm\kernel\vmlinux.lds.S
生成上面那个脚本的。
vmlinux.lds中的这一行：
__initcall_start = .;
*(.initcallearly.init) __early_initcall_end = .; *(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init)
就是将之前那些对应的init类型的函数，展开，放到这对应的位置。
⑹ 「干货」嵌入式Linux系统移植的四大步骤（上）
在学习系统移植的相关知识，在学习和调试过程中，发现了很多问题，也解决了很多问题，但总是对于我们的开发结果有一种莫名其妙的感觉，纠其原因，主要对于我们的开发环境没有一个深刻的认识，有时候几个简单的命令就可以完成非常复杂的功能，可是我们有没有想过，为什么会有这样的效果？
如果没有去追问，只是机械地完成，并且看到实验效果，这样做其实并没有真正的掌握系统移植的本质。
在做每一个步骤的时候， 首先问问自己，为什么要这样做，然后再问问自己正在做什么？ 搞明白这几个问题，我觉得就差不多了，以后不管更换什么平台，什么芯片，什么开发环境，你都不会迷糊，很快就会上手。对于嵌入式的学习方法，我个人方法就是：从宏观上把握(解决为什么的问题)，微观上研究(解决正在做什么的问题)，下面以自己学习的arm-cortex_a8开发板为目标，介绍下自己的学习方法和经验。
嵌入式Linux系统移植主要由四大部分组成：
一、搭建交叉开发环境
二、bootloader的选择和移植
三、kernel的配置、编译、和移植
四、根文件系统的制作
第一部分：搭建交叉开发环境
先介绍第一分部的内容：搭建交叉开发环境，首先必须得思考两个问题，什么是交叉环境? 为什么需要搭建交叉环境？
先回答第一个问题，在嵌入式开发中，交叉开发是很重要的一个概念，开发的第一个环节就是搭建环境，第一步不能完成，后面的步骤从无谈起，这里所说的交叉开发环境主要指的是：在开发主机上(通常是我的pc机)开发出能够在目标机(通常是我们的开发板)上运行的程序。嵌入式比较特殊的是不能在目标机上开发程序(狭义上来说)，因为对于一个原始的开发板，在没有任何程序的情况下它根本都跑不起来，为了让它能够跑起来，我们还必须要借助pc机进行烧录程序等相关工作，开发板才能跑起来，这里的pc机就是我们说的开发主机，想想如果没有开发主机，我们的目标机基本上就是无法开发，这也就是电子行业的一句名言：搞电子，说白了，就是玩电脑！
然后回答第二个问题，为什么需要交叉开发环境？主要原因有以下几点：
原因 1： 嵌入式系统的硬件资源有很多限制，比如cpu主频相对较低，内存容量较小等，想想让几百MHZ主频的MCU去编译一个Linux kernel会让我们等的不耐烦，相对来说，pc机的速度更快，硬件资源更加丰富，因此利用pc机进行开发会提高开发效率。
原因2： 嵌入式系统MCU体系结构和指令集不同，因此需要安装交叉编译工具进行编译，这样编译的目标程序才能够在相应的平台上比如：ARM、MIPS、 POWEPC上正常运行。
交叉开发环境的硬件组成主要由以下几大部分 ：
1.开发主机
2.目标机（开发板）
3.二者的链接介质，常用的主要有3种方式：(1)串口线 (2)USB线 (3)网线
对应的硬件介质，还必须要有相应的软件“介质”支持：
1.对于串口，通常用的有串口调试助手，putty工具等，工具很多，功能都差不多，会用一两款就可以；
2.对于USB线，当然必须要有USB的驱动才可以，一般芯片公司会提供，比如对于三星的芯片，USB下载主要由DNW软件来完成；
3.对于网线，则必须要有网络协议支持才可以， 常用的服务主要两个
第一：tftp服务：
主要用于实现文件的下载，比如开发调试的过程中，主要用tftp把要测试的bootloader、kernel和文件系统直接下载到内存中运行，而不需要预先烧录到Flash芯片中，一方面，在测试的过程中，往往需要频繁的下载，如果每次把这些要测试的文件都烧录到Flash中然后再运行也可以，但是缺点是：过程比较麻烦，而且Flash的擦写次数是有限的；另外一方面：测试的目的就是把这些目标文件加载到内存中直接运行就可以了，而tftp就刚好能够实现这样的功能，因此，更没有必要把这些文件都烧录到Flash中去。
第二： nfs服务：
主要用于实现网络文件的挂载，实际上是实现网络文件的共享，在开发的过程中，通常在系统移植的最后一步会制作文件系统，那么这是可以把制作好的文件系统放置在我们开发主机PC的相应位置，开发板通过nfs服务进行挂载，从而测试我们制作的文件系统是否正确，在整个过程中并不需要把文件系统烧录到Flash中去，而且挂载是自动进行挂载的，bootload启动后，kernel运行起来后会根据我们设置的启动参数进行自动挂载，因此，对于开发测试来讲，这种方式非常的方便，能够提高开发效率。
另外，还有一个名字叫 samba 的服务也比较重要，主要用于文件的共享，这里说的共享和nfs的文件共享不是同一个概念，nfs的共享是实现网络文件的共享，而samba实现的是开发主机上 Windows主机和Linux虚拟机之间的文件共享，是一种跨平台的文件共享 ，方便的实现文件的传输。
以上这几种开发的工具在嵌入式开发中是必备的工具，对于嵌入式开发的效率提高做出了伟大的贡献，因此，要对这几个工具熟练使用，这样你的开发效率会提高很多。等测试完成以后，就会把相应的目标文件烧录到Flash中去，也就是等发布产品的时候才做的事情，因此对于开发人员来说，所有的工作永远是测试。
通过前面的工作，我们已经准备好了交叉开发环境的硬件部分和一部分软件，最后还缺少交叉编译器，读者可能会有疑问，为什么要用交叉编译器？前面已经讲过，交叉开发环境必然会用到交叉编译工具，通俗地讲就是在一种平台上编译出能运行在体系结构不同的另一种平台上的程序，开发主机PC平台（X86 CPU）上编译出能运行在以ARM为内核的CPU平台上的程序，编译得到的程序在X86 CPU平台上是不能运行的，必须放到ARM CPU平台上才能运行，虽然两个平台用的都是Linux系统。相对于交叉编译，平常做的编译叫本地编译，也就是在当前平台编译，编译得到的程序也是在本地执行。用来编译这种跨平台程序的编译器就叫交叉编译器，相对来说，用来做本地编译的工具就叫本地编译器。所以要生成在目标机上运行的程序，必须要用交叉编译工具链来完成。
这里又有一个问题，不就是一个交叉编译工具吗？为什么又叫交叉工具链呢？原因很简单，程序不能光编译一下就可以运行，还得进行汇编和链接等过程，同时还需要进行调试，对于一个很大工程，还需要进行工程管理等等，所以，这里 说的交叉编译工具是一个由 编译器、连接器和解释器 组成的综合开发环境，交叉编译工具链主要由binutils(主要包括汇编程序as和链接程序ld)、gcc(为GNU系统提供C编译器)和glibc(一些基本的C函数和其他函数的定义) 3个部分组成。有时为了减小libc库的大小，也可以用别的 c 库来代替 glibc，例如 uClibc、dietlibc 和 newlib。
那么，如何得到一个交叉工具链呢？是从网上下载一个“程序”然后安装就可以使用了吗？回答这个问题之前先思考这样一个问题，我们的交叉工具链顾名思义就是在PC机上编译出能够在我们目标开发平台比如ARM上运行的程序，这里就又有一个问题了，我们的ARM处理器型号非常多，难道有专门针对我们某一款的交叉工具链吗？若果有的话，可以想一想，这么多处理器平台，每个平台专门定制一个交叉工具链放在网络上，然后供大家去下载，想想可能需要找很久才能找到适合你的编译器，显然这种做法不太合理，且浪费资源！因此，要得到一个交叉工具链，就像我们移植一个Linux内核一样，我们只关心我们需要的东西，编译我们需要的东西在我们的平台上运行，不需要的东西我们不选择不编译，所以，交叉工具链的制作方法和系统移植有着很多相似的地方，也就是说，交叉开发工具是一个支持很多平台的工具集的集合(类似于Linux源码)，然后我们只需从这些工具集中找出跟我们平台相关的工具就行了，那么如何才能找到跟我们的平台相关的工具，这就是涉及到一个如何制作交叉工具链的问题了。
通常构建交叉工具链有如下三种方法：
方法一 ： 分步编译和安装交叉编译工具链所需要的库和源代码，最终生成交叉编译工具链。该方法相对比较困难，适合想深入学习构建交叉工具链的读者。如果只是想使用交叉工具链，建议使用下列的方法二构建交叉工具链。
方法二： 通过Crosstool-ng脚本工具来实现一次编译，生成交叉编译工具链，该方法相对于方法一要简单许多，并且出错的机会也非常少，建议大多数情况下使用该方法构建交叉编译工具链。
方法三 ： 直接通过网上下载已经制作好的交叉编译工具链。该方法的优点不用多说，当然是简单省事，但与此同时该方法有一定的弊端就是局限性太大，因为毕竟是别人构建好的，也就是固定的，没有灵活性，所以构建所用的库以及编译器的版本也许并不适合你要编译的程序，同时也许会在使用时出现许多莫名其妙的错误，建议读者慎用此方法。
crosstool-ng是一个脚本工具，可以制作出适合不同平台的交叉编译工具链，在进行制作之前要安装一下软件：
$ sudo apt-get install g++ libncurses5-dev bison flex texinfo automake libtool patch gcj cvs cvsd gawk
crosstool脚本工具可以在http://ymorin.is-a-geek.org/projects/crosstool下载到本地，然后解压，接下来就是进行安装配置了，这个配置优点类似内核的配置。主要的过程有以下几点：
1. 设定源码包路径和交叉编译器的安装路径
2. 修改交叉编译器针对的构架
3. 增加编译时的并行进程数，以增加运行效率，加快编译，因为这个编译会比较慢。
4. 关闭JAVA编译器 ，减少编译时间
5. 编译
6. 添加环境变量
7. 刷新环境变量。
8. 测试交叉工具链
到此，嵌入式Linux系统移植四大部分的第一部分工作全部完成，接下来可以进行后续的开发了。
第二部分：bootloader的选择和移植
01 Boot Loader 概念
就是在操作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境，他就是所谓的引导加载程序（Boot Loader）。
02 为什么系统移植之前要先移植BootLoader？
BootLoader的任务是引导操作系统，所谓引导操作系统，就是启动内核，让内核运行就是把内核加载到内存RAM中去运行，那先问两个问题：第一个问题，是谁把内核搬到内存中去运行？第二个问题：我们说的内存是SDRAM，大家都知道，这种内存和SRAM不同，最大的不同就是SRAM只要系统上电就可以运行，而SDRAM需要软件进行初始化才能运行，那么在把内核搬运到内存运行之前必须要先初始化内存吧，那么内存是由谁来初始化的呢？其实这两件事情都是由bootloader来干的，目的是为内核的运行准备好软硬件环境，没有bootloadr我们的系统当然不能跑起来。
03 bootloader的分类
首先更正一个错误的说法，很多人说bootloader就是U-boot，这种说法是错误的，确切来说是u-boot是bootloader的一种。也就是说bootloader具有很多种类，
由上图可以看出，不同的bootloader具有不同的使用范围，其中最令人瞩目的就是有一个叫U-Boot的bootloader，是一个通用的引导程序，而且同时支持X86、ARM和PowerPC等多种处理器架构。U-Boot，全称 Universal Boot Loader，是遵循GPL条款的开放源码项目，是由德国DENX小组开发的用于多种嵌入式CPU的bootloader程序，对于Linux的开发，德国的u-boot做出了巨大的贡献，而且是开源的。
u-boot具有以下特点：
① 开放源码；
② 支持多种嵌入式操作系统内核，如Linux、NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS；
③ 支持多个处理器系列，如PowerPC、ARM、x86、MIPS、XScale；
④ 较高的可靠性和稳定性；
⑤ 高度灵活的功能设置，适合U-Boot调试、操作系统不同引导要求、产品发布等；
⑥ 丰富的设备驱动源码，如串口、以太网、SDRAM、FLASH、LCD、NVRAM、EEPROM、RTC、键盘等；
⑦ 较为丰富的开发调试文档与强大的网络技术支持；
其实，把u-boot可以理解为是一个小型的操作系统。
04 u-boot的目录结构
* board 目标板相关文件，主要包含SDRAM、FLASH驱动；
* common 独立于处理器体系结构的通用代码，如内存大小探测与故障检测；
* cpu 与处理器相关的文件。如mpc8xx子目录下含串口、网口、LCD驱动及中断初始化等文件；
* driver 通用设备驱动，如CFI FLASH驱动(目前对INTEL FLASH支持较好)
* doc U-Boot的说明文档；
* examples可在U-Boot下运行的示例程序；如hello_world.c,timer.c；
* include U-Boot头文件；尤其configs子目录下与目标板相关的配置头文件是移植过程中经常要修改的文件；
* lib_xxx 处理器体系相关的文件，如lib_ppc, lib_arm目录分别包含与PowerPC、ARM体系结构相关的文件；
* net 与网络功能相关的文件目录，如bootp,nfs,tftp；
* post 上电自检文件目录。尚有待于进一步完善；
* rtc RTC驱动程序；
* tools 用于创建U-Boot S-RECORD和BIN镜像文件的工具；
05 u-boot的工作模式
U-Boot的工作模式有 启动加载模式和下载模式 。启动加载模式是Bootloader的正常工作模式，嵌入式产品发布时，Bootloader必须工作在这种模式下，Bootloader将嵌入式操作系统从FLASH中加载到SDRAM中运行，整个过程是自动的。 下载模式 就是Bootloader通过某些通信手段将内核映像或根文件系统映像等从PC机中下载到目标板的SDRAM中运行，用户可以利用Bootloader提供的一些令接口来完成自己想要的操作，这种模式主要用于测试和开发。
06 u-boot的启动过程
大多数BootLoader都分为stage1和stage2两大部分，U-boot也不例外。依赖于cpu体系结构的代码（如设备初始化代码等）通常都放在stage1且可以用汇编语言来实现，而stage2则通常用C语言来实现，这样可以实现复杂的功能，而且有更好的可读性和移植性。
1、 stage1(start.s代码结构)
U-boot的stage1代码通常放在start.s文件中，它用汇编语言写成，其主要代码部分如下：
（1） 定义入口。由于一个可执行的image必须有一个入口点，并且只能有一个全局入口，通常这个入口放在rom(Flash)的0x0地址，因此，必须通知编译器以使其知道这个入口，该工作可通过修改连接器脚本来完成。
（2）设置异常向量(exception vector)。
（3）设置CPU的速度、时钟频率及中断控制寄存器。
（4）初始化内存控制器 。
（5）将rom中的程序复制到ram中。
（6）初始化堆栈 。
（7）转到ram中执行，该工作可使用指令ldrpc来完成。
2、 stage2（C语言代码部分）
lib_arm/board.c中的start armboot是C语言开始的函数，也是整个启动代码中C语言的主函数，同时还是整个u-boot（armboot）的主函数，该函数主要完成如下操作：
（1）调用一系列的初始化函数。
（2）初始化flash设备。
（3）初始化系统内存分配函数。
（4）如果目标系统拥有nand设备，则初始化nand设备。
（5）如果目标系统有显示设备，则初始化该类设备。
（6）初始化相关网络设备，填写ip,c地址等。
（7）进入命令循环（即整个boot的工作循环），接受用户从串口输入的命令，然后进行相应的工作。
07 基于cortex-a8的s5pc100bootloader启动过程分析
s5pc100支持两种启动方式，分别为USB启动方式和NandFlash启动方式：
1. S5PC100 USB启动过程
[1] A8 reset, 执行iROM中的程序
[2] iROM中的程序根据S5PC100的配置管脚(SW1开关4，拨到4对面)，判断从哪里启动(USB)
[3] iROM中的程序会初始化USB，然后等待PC机下载程序
[4] 利用DNW程序，从PC机下载SDRAM的初始化程序到iRAM中运行，初始化SDRAM
[5] SDRAM初始化完毕，iROM中的程序继续接管A8, 然后等待PC下载程序(BootLoader)
[6] PC利用DNW下载BootLoader到SDRAM
[7] 在SDRAM中运行BootLoader
2. S5PC100 Nandflash启动过程
[1] A8 reset, 执行IROM中的程序
[2] iROM中的程序根据S5PC100的配置管脚(SW1开关4，拨到靠4那边)，判断从哪里启动(Nandflash)
[3] iROM中的程序驱动Nandflash
[4] iROM中的程序会拷贝Nandflash前16k到iRAM
[5] 前16k的程序(BootLoader前半部分)初始化SDRAM，然后拷贝完整的BootLoader到SDRAM并运行
[6] BootLoader拷贝内核到SDRAM，并运行它
[7] 内核运行起来后，挂载rootfs，并且运行系统初始化脚本
08 u-boot移植(基于cortex_a8的s5pc100为例)
1.建立自己的平台
(1).下载源码包2010.03版本，比较稳定
(2).解压后添加我们自己的平台信息，以smdkc100为参考版，移植自己s5pc100的开发板
(3).修改相应目录的文件名，和相应目录的Makefile，指定交叉工具链。
(4).编译
(5).针对我们的平台进行相应的移植，主要包括修改SDRAM的运行地址，从0x20000000
(6).“开关”相应的宏定义
(7).添加Nand和网卡的驱动代码
(8).优化go命令
(9).重新编译 make distclean(彻底删除中间文件和配置文件) make s5pc100_config(配置我们的开发板) make(编译出我们的u-boot.bin镜像文件)
(10).设置环境变量，即启动参数，把编译好的u-boot下载到内存中运行，过程如下：
1. 配置开发板网络
ip地址配置:
$setenv ipaddr 192.168.0.6 配置ip地址到内存的环境变量
$saveenv 保存环境变量的值到nandflash的参数区
网络测试:
在开发开发板上ping虚拟机：
$ ping 192.168.0.157(虚拟机的ip地址)
如果网络测试失败,从下面几个方面检查网络：
1. 网线连接好
2. 开发板和虚拟机的ip地址是否配置在同一个网段
3. 虚拟机网络一定要采用桥接(VM--Setting-->option)
4. 连接开发板时，虚拟机需要设置成 静态ip地址
2. 在开发板上，配置tftp服务器(虚拟机)的ip地址
$setenv serverip 192.168.0.157(虚拟机的ip地址)
$saveenv
3. 拷贝u-boot.bin到/tftpboot(虚拟机上的目录)
4. 通过tftp下载u-boot.bin到开发板内存
$ tftp 20008000(内存地址即可) u-boot.bin(要下载的文件名)
如果上面的命令无法正常下载:
1. serverip配置是否正确
2. tftp服务启动失败，重启tftp服务
#sudo service tftpd-hpa restart
5. 烧写u-boot.bin到nandflash的0地址
$nand erase 0(起始地址) 40000(大小) 擦出nandflash 0 - 256k的区域
$nand write 20008000((缓存u-boot.bin的内存地址) 0(nandflash上u-boot的位置) 40000(烧写大小)
6. 切换开发板的启动方式到nandflash
1. 关闭开发板
2. 把SW1的开关4拨到4的那边
3. 启动开发板，它就从nandflash启动