http://www.chip123.com/forum.php?mod=viewthread&tid=11904
崁入式開發環境 - 減少footprint方式
在崁入式開發環境中 , 最常遭遇的環境之一就是編譯出來的footprint太大 , 而導致必須採用較大的Flash儲存而形成成本的增加。
為了要解決此類的問題 , 一般會有以下幾種作法: g& n4 `8 M4 R; ]; h! u
1. 僅使用boot loader在Flash device , 將 Kernel/Application image儲存於硬碟或是USB Flash /SD等類似的儲存媒體。2 y# W4 j) Z$ z1 A8 `
此類的解決方案大多是以NAS相關的產品居多 , 並且有比較完整的配套方式。譬如網路儲存大廠群暉科技(synology)提供顧客所附加的工具程式 , 就具備將硬碟格式化後並將Kernel/Application image置於硬碟的固定位置 , Boot loader執行結束後就跳到硬碟去執行此image.3 [: N9 Q4 V: `) p+ l: _6 n
( e# G: A: l' n/ s! R) q* ?& m% n
2. 選擇適當的 C Library , 可以使編譯出來的image也同步縮小. 但這會有一些問題產生 , 也可能將開發時間加長。
以下介紹三種不同的 C Library
GLibc:一般稱之為 GNU C Library , 是目前在Desktop Linux最受普羅大眾所喜愛與採用1 X& e) ] V- n y0 M
Pros: 函式庫支援最多而且沒有相容性問題; l8 S- F) O8 a$ J
Cons: 編譯出來的footprinte過大 不適用於產品量產化
uCLibc: 目前在崁入式Linux開發環境中 , 最常被拿來使用的C Libary. 一般而言 , 只要將source code在uCLibc重新編譯就可以在Kernel/Application執行 , 但open source並不一定會用uCLibc編譯 , 所以有時會花很多時間解決相容性的問題。( v# a, M8 ?* R, n& B! ~) @- z& @
Pros: 編譯出來的footprint很小 最適用於產品量產化
Cons: 函式庫支援較少而且會有相容性問題
! t$ ]& O) p( Y7 J
EGLibc: 全名為Embedded GLIBC , 是不同版本的GNU C Library 主要以崁入式開發環境為考量。目的是要將source與binary都能相容於GLibc.而且對縮小code size與結構劃設定都有比GLibc改善* @6 M( Y. I# I$ Y
Pros: 函式庫支援最多而且沒有相容性問題' D% ]1 u8 w5 Q8 v( q) b: f
Cons: 編譯出來的footprinte過大 不適用於產品量產化
! n& E9 K) U9 w/ I, G/ |, `
基本上 , 一樣的source code在此三種C Library中 , 編譯後所表現出的差異為:( F G9 d5 G, c! @- s0 w1 p% Y
Footprint size(由大到小): GLibc > EGLib > uCLibc, p L8 |0 F& h% L5 l- C
Compatibility (由最佳到次之): GLibc = EGLib > uCLibc5 G8 d% _/ h- ]
3. 另外, 還有一些技巧可以應用在縮減footprint的大小. 在此列舉一些常用方式提供參考。
- 靜態連結 (Static link) vs.動態連結(Dynamic Link): b. h) z' h _5 s
Footprint size(由大到小): 靜態連結 (Static link) > 動態連結(Dynamic Link); ~$ w' H n q4 O& r+ @! ^
Systemoverhead(由大到小): 動態連結(Dynamic Link) > 靜態連結 (Static link)" x; @8 D3 S- P% D, X: k. b
取決於所需與目的所在.
- 可以使用Linux Kernel 2.4 就不要用 2.6,雖然2.6提供較多的支援如IPv6與protocol ... etc.但相對的footprint就比較大.9 Z' ]0 _$ [2 [- w V
- 在Linux kernel Menu Configure將不必要的module都不要選, 減少footprint
- 透過壓縮率較佳的程式,將Kernel/Application image壓縮到極緻化.藉由解壓縮後,將file system解壓縮到memory,而此做法通常稱為RAMDisk.( W1 i# s, K. l' p: X/ q
Pros: 減少footprint size
Cons: 浪費部分記憶體空間做RAMDisk虛擬磁碟使用,增加解壓縮程式的binary file size與解壓縮image時間9 C/ h6 u% p8 X, f7 S( r4 P. g
3 @) e' h8 v- S; y/ T* q/ F
折衷的取代方案為CramFS,可以即時運算壓縮後的資料儲存位置然後解壓縮到記憶體中執行. 5 s2 F9 q! r5 g5 b, {
缺點為CramsFS是一個唯讀的檔案系統 ,系統須在Flash保留空間做儲存資料之用。
8 [, x* F- ^- x( {0 r, C# P
相關資料:
http://www.synology.com.tw/cht/index.php$ T0 D9 m/ c" r0 \+ s& q
http://www.eglibc.org/home
http://www.gnu.org/software/libc/
http://www.uclibc.org/
=========================================
=========================================
=========================================
http://home.eeworld.com.cn/my/space-uid-162102-blogid-64169.html
简要分析Uboot是如何启动内核
||
【转自】？
关于uboot启动的资料。
原文：
1.uboot启动内核的代码缩减如下：
s = getenv ("bootcmd");
debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "<UNDEFINED>");
if (bootdelay >= 0 && s && !abortboot (bootdelay))
{
run_command (s, 0);
}
2.假设bootcmd = nand read.jffs2 0x30007FC0 kernel; bootm 0x30007FC0
<1> nand read.jffs2 0x30007FC0 kernel
nand read.jffs2 0x30007FC0 kernel;
从nand读出内核：从哪里读？ 从kernel分区
放到哪里去？-0x30007FC0
下面讲解什么是分区：
就是将nand划分为几个区域，一般如下：
bootloader-》params-》kernel-》root
这些分区的划分是在/include/configs/mini2440.h中写死的：#define MTDPARTS_DEFAULT "mtdparts=nandflash0:250k@0(bootloader)," \
"128k(params)," \
"5m(kernel)," \
"-(root)"
注:@0表示从0地址开始，250k的bootloader分区可能对某些uboot不够用，这里只是举例而已。
将上面的信息换算成十六进制：
# name 大小 在nand上的起始地址
0 bootloader 0x00040000 0x00000000
1 params 0x00020000 0x00040000
2 kernel 0x00200000 0x00060000
3 root 0xfda00000 0x00260000
那么上面的nand read.jffs2 0x30007FC0 kernel就等价于：
nand read.jffs2 0x30007FC0 0x00060000 0x00200000
注：这里的read.jffs2并不是指定要什么特定的格式，而是用read.jffs2不需要块/页对齐,所以这个kernel的分区大小可以
随意定。
<2> bootm 0x30007FC0
关键函数do_bootm()
flash上存的内核：uImage
uImage = 头部+真正的内核
头部的定义如下：
typedef struct image_header {
uint32_t ih_magic; /* Image Header Magic Number */
uint32_t ih_hcrc; /* Image Header CRC Checksum */
uint32_t ih_time; /* Image Creation Timestamp */
uint32_t ih_size; /* Image Data Size */
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
uint32_t ih_dcrc; /* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch; /* CPU architecture */
uint8_t ih_type; /* Image Type */
uint8_t ih_comp; /* Compression Type */
uint8_t ih_name[IH_NMLEN]; /* Image Name */
} image_header_t;
我们需要关心的是： uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
ih_load是加载地址，即内核运行是应该位于的地方
ih_ep是入口地址，即内核的入口地址
这与uboot是类似的，uboot的加载地址是TEXT_BASE = 0x33F80000；入口地址是start.S中的_start。
其实我们把内核中nand读出来的时候是可以放在内核的任何地方的，如0x31000000，0x32000000等等，只要它不破坏uboot所占用的内存空间就可以了，如下图：
从0x33F4DF74-0x30000000都是可以用的。
那么为什么既然设定好了加载地址和入口地址内核还能随意放呢？
那是因为uImage有一个头部！头部里有加载地址和入口地址，当我们用bootm xxx的时候，
do_bootm这个函数会先去读uImage的头部以获取该uImage的加载地址和入口地址，当发现该uImage目前所处的内存地址不等于它的加载地址时，该函数会将该uImage移动到它的加载地址上，在代码中体现如下：
case IH_COMP_NONE:：
if (load != image_start)
{
memmove_wd ((void *)load, (void *)image_start, image_len, CHUNKSZ);
}
另外，当我们的内核正好处于头部指定的加载地址的话，那么就不用uboot的do_bootm函数来帮我们搬运内核了，这样可以节省启动时间。这就是为什么我们一般都下载uImage到
0x30007FC0的原因了！
我们所用的内核加载地址是0x30008000，而头部的大小为64个字节，所以将内核拷贝到0x30007FC0时，再加载头部的64个字节，内核正好位于0x30008000处！
现在总结bootm做了什么：
1. 读取头部
2. 将内核移动到加载地址
3. 启动内核
具体如何启动内核？
使用do_bootm_linux()，在/lib_arm/bootm.c定义，因为我们已经知道入口地址了，所以只需跳到入口地址就可以启动linux内核了，但是在这之前需要做一件事————uboot传递参数给内核！！
现在来分析do_bootm_linux()这个函数：
theKernel = (void (*)(int, int, uint))images->ep;//先是将入口地址赋值给theKernel
theKernel (0, machid, bd->bi_boot_params);//然后是调用thekernel
函数，以0，machid，bd->bi_boot_params作为参数
下面分析这三个参数：
1.machid就是uboot里设置好的板子的机器码，mini2440的是MACH_TYPE_MINI2440 (1999),内核所设置的机器码和uboot所设置的机器码必须一致才能启动内核
2.bd->bi_boot_parmas就是uboot需传递给内核的启动参数所位于的地址
3.0暂时还不知道什么作用/**********************************************/
那么uboot传给内核的启动参数是在哪里设置的呢？
其实就是在调用 theKernel (0, machid, bd->bi_boot_params);前面的一小段代码里设置的，下面我截取了部分片段：
setup_start_tag (bd);
setup_revision_tag (¶ms);
setup_memory_tags (bd);
setup_commandline_tag (bd, commandline);
setup_initrd_tag (bd, images->rd_start, images->rd_end);
setup_videolfb_tag ((gd_t *) gd);
setup_end_tag (bd);
每一个启动参数对应一个tag结构体，所谓的设置传递参数其实就是初始化这些tag的值，想了解这个结构体以及这些tag的值是如何设置的请看韦东山的书关于uboot移植章节！
下面我们看一下setup_start_tag(bd)这个函数先：
static void setup_start_tag (bd_t *bd)
{
params = (struct tag *) bd->bi_boot_params;
//在board.c中有一句gd->bd->bi_boot_params = 0x30000100，这里设置了参数存放的位置
params->hdr.tag = ATAG_CORE;
params->hdr.size = tag_size (tag_core);
params->u.core.flags = 0;
params->u.core.pagesize = 0;
params->u.core.rootdev = 0;
params = tag_next (params);
}
我们再来看下setup_commandline_tag (bd, commandline);这个函数：
static void setup_commandline_tag (bd_t *bd, char *commandline)
{
// commandline就是我们的bootargs
char *p;
if (!commandline)
return;
for (p = commandline; *p == ' '; p++);
if (*p == '\0')
return;
params->hdr.tag = ATAG_CMDLINE;
params->hdr.size =
(sizeof (struct tag_header) + strlen (p) + 1 + 4) >> 2;
strcpy (params->u.cmdline.cmdline, p);
params = tag_next (params);
}
Linux内核启动时就会去读取这些tag参数
s = getenv ("bootcmd");
debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "<UNDEFINED>");
if (bootdelay >= 0 && s && !abortboot (bootdelay))
{
run_command (s, 0);
}
2.假设bootcmd = nand read.jffs2 0x30007FC0 kernel; bootm 0x30007FC0
<1> nand read.jffs2 0x30007FC0 kernel
nand read.jffs2 0x30007FC0 kernel;
从nand读出内核：从哪里读？ 从kernel分区
放到哪里去？-0x30007FC0
下面讲解什么是分区：
就是将nand划分为几个区域，一般如下：
bootloader-》params-》kernel-》root
这些分区的划分是在/include/configs/mini2440.h中写死的：#define MTDPARTS_DEFAULT "mtdparts=nandflash0:250k@0(bootloader)," \
"128k(params)," \
"5m(kernel)," \
"-(root)"
注:@0表示从0地址开始，250k的bootloader分区可能对某些uboot不够用，这里只是举例而已。
将上面的信息换算成十六进制：
# name 大小 在nand上的起始地址
0 bootloader 0x00040000 0x00000000
1 params 0x00020000 0x00040000
2 kernel 0x00200000 0x00060000
3 root 0xfda00000 0x00260000
那么上面的nand read.jffs2 0x30007FC0 kernel就等价于：
nand read.jffs2 0x30007FC0 0x00060000 0x00200000
注：这里的read.jffs2并不是指定要什么特定的格式，而是用read.jffs2不需要块/页对齐,所以这个kernel的分区大小可以
随意定。
<2> bootm 0x30007FC0
关键函数do_bootm()
flash上存的内核：uImage
uImage = 头部+真正的内核
头部的定义如下：
typedef struct image_header {
uint32_t ih_magic; /* Image Header Magic Number */
uint32_t ih_hcrc; /* Image Header CRC Checksum */
uint32_t ih_time; /* Image Creation Timestamp */
uint32_t ih_size; /* Image Data Size */
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
uint32_t ih_dcrc; /* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch; /* CPU architecture */
uint8_t ih_type; /* Image Type */
uint8_t ih_comp; /* Compression Type */
uint8_t ih_name[IH_NMLEN]; /* Image Name */
} image_header_t;
我们需要关心的是： uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
ih_load是加载地址，即内核运行是应该位于的地方
ih_ep是入口地址，即内核的入口地址
这与uboot是类似的，uboot的加载地址是TEXT_BASE = 0x33F80000；入口地址是start.S中的_start。
其实我们把内核中nand读出来的时候是可以放在内核的任何地方的，如0x31000000，0x32000000等等，只要它不破坏uboot所占用的内存空间就可以了，如下图：
从0x33F4DF74-0x30000000都是可以用的。
那么为什么既然设定好了加载地址和入口地址内核还能随意放呢？
那是因为uImage有一个头部！头部里有加载地址和入口地址，当我们用bootm xxx的时候，
do_bootm这个函数会先去读uImage的头部以获取该uImage的加载地址和入口地址，当发现该uImage目前所处的内存地址不等于它的加载地址时，该函数会将该uImage移动到它的加载地址上，在代码中体现如下：
case IH_COMP_NONE:：
if (load != image_start)
{
memmove_wd ((void *)load, (void *)image_start, image_len, CHUNKSZ);
}
另外，当我们的内核正好处于头部指定的加载地址的话，那么就不用uboot的do_bootm函数来帮我们搬运内核了，这样可以节省启动时间。这就是为什么我们一般都下载uImage到
0x30007FC0的原因了！
我们所用的内核加载地址是0x30008000，而头部的大小为64个字节，所以将内核拷贝到0x30007FC0时，再加载头部的64个字节，内核正好位于0x30008000处！
现在总结bootm做了什么：
1. 读取头部
2. 将内核移动到加载地址
3. 启动内核
具体如何启动内核？
使用do_bootm_linux()，在/lib_arm/bootm.c定义，因为我们已经知道入口地址了，所以只需跳到入口地址就可以启动linux内核了，但是在这之前需要做一件事————uboot传递参数给内核！！
现在来分析do_bootm_linux()这个函数：
theKernel = (void (*)(int, int, uint))images->ep;//先是将入口地址赋值给theKernel
theKernel (0, machid, bd->bi_boot_params);//然后是调用thekernel
函数，以0，machid，bd->bi_boot_params作为参数
下面分析这三个参数：
1.machid就是uboot里设置好的板子的机器码，mini2440的是MACH_TYPE_MINI2440 (1999),内核所设置的机器码和uboot所设置的机器码必须一致才能启动内核
2.bd->bi_boot_parmas就是uboot需传递给内核的启动参数所位于的地址
3.0暂时还不知道什么作用/**********************************************/
那么uboot传给内核的启动参数是在哪里设置的呢？
其实就是在调用 theKernel (0, machid, bd->bi_boot_params);前面的一小段代码里设置的，下面我截取了部分片段：
setup_start_tag (bd);
setup_revision_tag (¶ms);
setup_memory_tags (bd);
setup_commandline_tag (bd, commandline);
setup_initrd_tag (bd, images->rd_start, images->rd_end);
setup_videolfb_tag ((gd_t *) gd);
setup_end_tag (bd);
每一个启动参数对应一个tag结构体，所谓的设置传递参数其实就是初始化这些tag的值，想了解这个结构体以及这些tag的值是如何设置的请看韦东山的书关于uboot移植章节！
下面我们看一下setup_start_tag(bd)这个函数先：
static void setup_start_tag (bd_t *bd)
{
params = (struct tag *) bd->bi_boot_params;
//在board.c中有一句gd->bd->bi_boot_params = 0x30000100，这里设置了参数存放的位置
params->hdr.tag = ATAG_CORE;
params->hdr.size = tag_size (tag_core);
params->u.core.flags = 0;
params->u.core.pagesize = 0;
params->u.core.rootdev = 0;
params = tag_next (params);
}
我们再来看下setup_commandline_tag (bd, commandline);这个函数：
static void setup_commandline_tag (bd_t *bd, char *commandline)
{
// commandline就是我们的bootargs
char *p;
if (!commandline)
return;
for (p = commandline; *p == ' '; p++);
if (*p == '\0')
return;
params->hdr.tag = ATAG_CMDLINE;
params->hdr.size =
(sizeof (struct tag_header) + strlen (p) + 1 + 4) >> 2;
strcpy (params->u.cmdline.cmdline, p);
params = tag_next (params);
}
Linux内核启动时就会去读取这些tag参数
