不是每一行代码都必须读懂，我只是大概地过一下流程
毕竟这些都是比较成熟的代码，没必要去改的
是针对我自己的板子的，硬件配置如下
cpu是s3c2410
board type 是 smdk2410
16M Nor Flash 地址是 0x0---0xFFFFFF
64M SDRAM     地址是 0x30000000---0x33FFFFFF
软件是华恒版的
ppcboot 2.0 和 linux 2.4.18
仔细分析了一下启动的流程，能更好地理解硬件和软件的配合
方便移植。
我们在flash的开始处烧写了ppcboot.bin,这是可执行的二进制文件
注意和ELF可执行性文件是有区别的。
cpu上电后可以从直接从flash地址0处取指令来执行
开始的代码在ppcboot-2.0.0\cpu\arm920t\start.s中
这里需要提一下编译链接时用到的一个很重要的链接文件
ppcboot-2.0.0\board\smdk2410\ppcboot.lds
这个文件给出了代码中各标号的基地址，和各个段的链接顺序
ENTRY(_start)
SECTIONS
{
        . = 0x00000000;

        . = ALIGN(4);
 .text      :
 {
   cpu/arm920t/start.o (.text)
   *(.text)
 }

        . = ALIGN(4);
        .rodata : { *(.rodata) }

        . = ALIGN(4);
        .data : { *(.data) }

        . = ALIGN(4);
        .got : { *(.got) }

 armboot_end_data = .;

        . = ALIGN(4);
        .bss : { *(.bss) }

 armboot_end = .;
}
可以看到程序的入口是_start标号指示的，而cpu/arm920t/start.o
则被安排在程序最开始的地方，这个标号就是在start.s中
但是还有一点是需要特别注意的，开始我也是因为这个地方而没有很好地理解程序
虽然lds中有 . = 0x00000000 这一句，指示链接基地址，不过其实这句是不起作用的，
真正的链接基地址在ppcboot-2.0.0\config.mk中指定的
LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE)
其中-Ttext $(TEXT_BASE)就是指定链接地址为TEXT_BASE的值
因而是可变的，TEXT_BASE在ppcboot-2.0.0\board\smdk2410\config.mk中定义
TEXT_BASE = 0x33F00000
ppcboot-2.0.0\config.mk是包括到Makefile中的,
在Makefile中有$(LD) $(LDFLAGS) $(OBJS) $(LIBS) $(LIBS) -Map ppcboot.map -o ppcboot
所以说起来真正的链接地址是0x33F00000,其实这样在把ppcboot拷到Ram中就可以实现无缝跳转了
.globl _start
_start: b       reset
跳到renset
reset: ldr     r0, =pWTCON
 mov     r1, #0x0
 str     r1, [r0]
..........................
 bl cpu_init_crit  //bl跳转会回来
relocate: //下面开始要把ppcboot拷到Ram中
 adr r0, _start  /* r0 <- current position of code */
 ldr r2, _armboot_start
 ldr r3, _armboot_end
 sub r2, r3, r2  /* r2 <- size of armboot */
 ldr r1, _TEXT_BASE  /* r1 <- destination address */
 add r2, r0, r2  /* r2 <- source end address */
以上代码需要注意的一点是 adr 和 ldr 的区别
adr取得是当前pc相关的偏移地址,在这里程序还是在flash中运行
所以取得地址是以0x0为基址的
而ldr取的是_armboot_start所指的值
.globl _armboot_start
_armboot_start:
 .word _start
看到它的值也是_start的地址,不过我们这里取的是绝对地址,是在链接是确定的以
TEXT_BASE为基址的.由于_start的偏移是0,所以r0是0,r2就是TEXT_BASE
copy_loop:
 ldmia r0!, {r3-r10}
 stmia r1!, {r3-r10}
 cmp r0, r2
 ble copy_loop
循环copy
 ldr r0, _armboot_end  /* set up the stack */
 add r0, r0, #CONFIG_STACKSIZE
 sub sp, r0, #12  /* leave 3 words for abort-stack */

 ldr pc, _start_armboot
_start_armboot: .word start_armboot

//通过这一句跳转到ppcboot-2.0.0\lib_arm\board.c中的start_armboot函数去执行了
start_armboot的绝对地址也是以TEXT_BASE为基址的,所以可以顺利的实现无缝跳转了.
接着下来就是一系列初始化的工作了
首先定义了一个全局的数据结构 gd_t gd_data;
DECLARE_GLOBAL_DATA_PTR 这个宏定义的是一个全局的gd_t类型的指针gd
gd = &gd_data;
这样以后就可以用gd来访问gd_data这个数据结构了
 for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
  if ((*init_fnc_ptr)() != 0) {
   hang ();
  }
 }
init_fnc_ptr中是一系列初始化函数的指针
init_fnc_t *init_sequence[] = {
 cpu_init,  /* basic cpu dependent setup */
 board_init,  /* basic board dependent setup */
 interrupt_init,  /* set up exceptions */
 env_init,  /* initialize environment */
 init_baudrate,  /* initialze baudrate settings */
 serial_init,  /* serial communications setup */
 display_banner,
 dram_init,  /* configure available RAM banks */
 display_dram_config,

 NULL,
};
基本上serial_init后我们就可以用printf函数来打印信息了.
 for (;;) {
  main_loop ();
 }
进入了主循环,在M:\ppcboot-2.0.0\common\main.c中
 {
  char c = 'y';
  unsigned long timedata;
  printf("start linux now(y/n):");
  timedata = 0;
  for (;;) {
   while (!tstc()) { /* while no incoming data */
    if (timedata++ > 3000 * 100 *3)
     goto bootm; /* timed out */
   }
  c = getc();
  }
tstc()是测试串口是否有数据输入,显然没有的话就会等待time out跳出
bootm:
  if(c == 'y'||c == 'Y'){
   strcpy(lastcommand , "bootm 30008000 30800000\r");
   flag = 0;
   rc = run_command (lastcommand, flag);
   if (rc <= 0) {
    /* invalid command or not repeatable, forget it */
    lastcommand[0] = 0;
   }
  }
  else{
   printf("\n\n");
  }
 }
这样如果串口没有输入或者输入时y Y 的话,就会去执行bootm 30008000 30800000\r这条命令
否则就会到ppcboot的命令行等待输入.
执行bootm 30008000 30800000\r这条命令会调用ppcboot-2.0.0\common\cmd_bootm.c中的
do_bootm函数,具体的命令怎样被分解,选择调用函数的机制我就不多说了,追着run_command去就是了
在do_bootm中调用了do_bootm_linux函数,这个函数在ppcboot-2.0.0\lib_arm\armlinux.c中
    ret = memcpy((void *)0x30008000, (void *)0x40000, 0x100000);
    if (ret != (void *)0x30008000)
     printf("copy kernel failed\n");
    else
    printf("copy kernel done\n");    

    ret = memcpy((void *)0x30800000, (void *)0x140000, 0x440000);
    if (ret != (void *)0x30800000)
              printf("haha failed\n");
    else
              printf("copy ramdisk done\n");

首先把kernel和ramdisk都拷到Ram相应的地方去.
    setup_linux_param(0x30000000 + LINUX_PARAM_OFFSET); //也在armlinux.c中
    #define LINUX_PARAM_OFFSET 0x100
建立要传给内核的参数,参数的地址都是固定的,所以内核也知道去这里取参数
参数格式比较复杂,我这里好像传得参数不多
void setup_linux_param(ulong param_base)
{
 struct param_struct *params = (struct param_struct *)param_base;
...............
}
只是通过一个param_struct的结构体来传参数的,不过现在一般都用另一种tag标记的传参方法
一个主要的参数时char linux_cmd[] = "initrd=0x30800000,0x440000  root=/dev/ram init=/linuxrc console=ttyS0";
 if (linux_cmd == NULL) {
  printf("Wrong magic: could not found linux command line\n");
 } else {
  memcpy(params->commandline, linux_cmd, strlen(linux_cmd) + 1);
  printf("linux command line is: \"%s\"\n", linux_cmd);
 }
是比较重要的.移植的时候常常需要修改
接着call_linux(0, 0xc1, 0x30008000); 看出来是准备调到linux去了
0xc1是machine type,这三个参数分别给了r0,r1,r2,这些都是调用内核的约定
void  call_linux(long a0, long a1, long a2)
{
__asm__(
 "mov r0, %0\n"
 "mov r1, %1\n"
 "mov r2, %2\n"
 "mov ip, #0\n"
 "mcr p15, 0, ip, c13, c0, 0\n" /* zero PID */
 "mcr p15, 0, ip, c7, c7, 0\n" /* invalidate I,D caches */
 "mcr p15, 0, ip, c7, c10, 4\n" /* drain write buffer */
 "mcr p15, 0, ip, c8, c7, 0\n" /* invalidate I,D TLBs */
 "mrc p15, 0, ip, c1, c0, 0\n" /* get control register */
 "bic ip, ip, #0x0001\n"  /* disable MMU */
 "mcr p15, 0, ip, c1, c0, 0\n" /* write control register */
 "mov pc, r2\n"
 "nop\n"
 "nop\n"
 : /* no outpus */
 : "r" (a0), "r" (a1), "r" (a2)
 );
}
mov pc, r2 就是这句吧,调到了30008000去执行内核了

接下来就到内核了吧

arm linux 启动流程之 解压内核   

Author-------Dansen-----xzd2734@163.com

从后往前看下编译生成zImage的过程，我们可以找到程序的入口还是那个很重要
链接文件，找到它,生成zImage所在的目录是kernel\arch\arm\boot\compressed\
Make过程为....ld -p -X -T vmlinux.lds head.o misc.o head-s3c2410.o piggy.o
libgcc.o -o vmlinux
然后是用二进制工具objcopy把vmlinux制作成可执行的二进制映像文件zImage
这样在我们就去kernel\arch\arm\boot\compressed\目录下去找到vmlinux.lds文件
如果没有编译就不会有这个文件，因为它也是在编译过程生成的，由同一目录下的
vmlinux.lds.in生成，打开这个文件
ENTRY(_start)
SECTIONS
{
  . = LOAD_ADDR;
  _load_addr = .;

  . = TEXT_START;
  _text = .;

  .text : {
    _start = .;
    *(.start)
    *(.text)
........
入口是_start,而且入口就直接定义在这个文件中了
入口直接接着.start段,所以程序开始是从.start段开始执行的
如果看看vmlinux.lds的生成过程就应该能找到LOAD_ADDR和TEXT_START的值
实际上这两个值是由其他两个变量赋给的 ZRELADDR 和 ZTEXTADDR
在kernel\arch\arm\boot\Makefile中我们可以找到这两个变量的值
ifeq ($(CONFIG_ARCH_S3C2410),y)
ZTEXTADDR  = 0x30008000
ZRELADDR  = 0x30008000
endif
所以
LOAD_ADDR = 0x30008000
TEXT_START = 0x30008000
看一下vmlinux.lds吧
ENTRY(_start)
SECTIONS
{
  . = 0x30008000;
  _load_addr = .;

  . = 0;
  _text = .;
显然LOAD_ADDR被赋值了0x30008000
看一下TEXT_START怎么成0了，我想这应该是一个偏移吧，偏移是0
所以它还是0x30008000
接着下来就从head.s来开始看代码吧
  .section ".start", #alloc, #execinstr
/*
 * sort out different calling conventions
 */
  .align
start:
  .type start,#function
  .rept 8
  mov r0, r0
  .endr

  b 1f
  .word 0x016f2818  @ Magic numbers to help the loader
  .word start   @ absolute load/run zImage address
  .word _edata   @ zImage end address
1:  mov r7, r1   @ save architecture ID
这里一定就是程序的入口了，一般汇编程序的含义就看看英文注释就是了
有一个要注意的地方，不是一个汇编文件就是属于一个段的，不是说先执行完了
head.s再去执行head-s3c2410.s,还是要注意链接的段,显然head.s
不一会就开始了另一个段.text
  .text
  adr r0, LC0
  ldmia r0, {r1, r2, r3, r4, r5, r6, ip, sp}
  subs r0, r0, r1  @ calculate the delta offset
而我们的head-s3c2410.s呢
 .section ".start", #alloc, #execinstr
__S3C2410_start:
 bic r2, pc, #0x1f
 add r3, r2, #0x4000  @ 16 kb is quite enough...
还是属于.start段的，所以顺序执行下来时先执行head-s3c2410.s，然后再去执行
.text段。head-s3c2410.s主要是cpu的一些初始化工作。接着下来我们会需要把内核
接压缩，先说说为什么吧。还是注意到上面生成zImage的文件中有一个piggy.o，往上
追寻可以看到是piggy.o由那个真正的内核vmlinux生成的，这个vmlinux才是启动后一直在
运行的内核，原本很大，压缩以后可以方便地放在flash中，当然其实不压缩跳到它的
入口也就可以运行了。解压的内核是准备从LOAD_ADDR = 0x30008000开始的4M空间，会覆盖
我们的当前运行的代码，那样就先把内核解压到我们这个zImage+分配堆栈0x10000的最后
  cmp r4, r2  //r4 是LOAD_ADDR=0x30008000
  bhs wont_overwrite //r2 是当前代码的最底部    这里当然不会跳转
  add r0, r4, #4096*1024 @ 4MB largest kernel size
  cmp r0, r5  //r5 也是0x30008000
  bls wont_overwrite //不会跳转

  mov r5, r2  //r2是(user_stack+4096)在zImage的最后+0x10000
  mov r0, r5 
  mov r3, r7  //machine type
  bl decompress_kernel
有了r5,r0,r7作为参数，就可以调用misc.c中的decompress_kernel函数进行解压缩了
这个函数调用的gunzip函数时gcc的库函数，所以在源码中找不到的
解压在r5开始的地方，函数返回的是r0解压得到的长度。这时候我们需要对代码经行调整
  add r1, r5, r0  @ end of decompressed kernel
  adr r2, reloc_start
  ldr r3, LC1   //LC1: .word reloc_end - reloc_start
  add r3, r2, r3
1:  ldmia r2!, {r8 - r13}  @ copy relocation code
  stmia r1!, {r8 - r13}
  ldmia r2!, {r8 - r13}
  stmia r1!, {r8 - r13}
  cmp r2, r3  //这里就把从reloc_start到reloc_end这段我们需要的代码放到了
  blo 1b  //解压内核的最后，而在下面我们会将zImage都覆盖掉
  bl cache_clean_flush
  add pc, r5, r0 //调到调整后的reloc_start，在decompressed kernel后
reloc_start: add r8, r5, r0 //r5解压内核开始的地方 r0解压内核的长度
  debug_reloc_start
  mov r1, r4  //r4=0x30008000
1:
  .rept 4
  ldmia r5!, {r0, r2, r3, r9 - r13} @ relocate kernel
  stmia r1!, {r0, r2, r3, r9 - r13}
  .endr

  cmp r5, r8
  blo 1b  //这样就又把解压的真正内核移到了0x30008000处
call_kernel: bl cache_clean_flush
  bl cache_off
  mov r0, #0
  mov r1, r7   @ restore architecture number
  mov pc, r4   @ call kernel
上面就是跳到0x30008000这里去执行真正的内核了吧

arm linux 启动流程之 进入内核  

Author-------Dansen-----xzd2734@163.com

还是从编译链接生成vmlinux的过程来看吧，由一大堆.o文件链接而成，第一个就是
kernel\arch\arm\kernel\head-armv.o ,而且我们还看到了
lds链接文件kernel\arch\arm\vmlinux.lds,先把它分析一下
ENTRY(stext) //入口点是stext 应该就在head-armv.s中了
SECTIONS
{
 . = 0xC0008000;  //基址，是内核开始的虚拟地址
 .init : {   /* Init code and data  */
  _stext = .;
  __init_begin = .;
   *(.text.init)
  __proc_info_begin = .;
   *(.proc.info)
  __proc_info_end = .;
  __arch_info_begin = .;
   *(.arch.info)
  __arch_info_end = .;
  __tagtable_begin = .;
   *(.taglist)
  __tagtable_end = .;
   *(.data.init)
  . = ALIGN(16);
  __setup_start = .;
   *(.setup.init)
  __setup_end = .;
  __initcall_start = .;
   *(.initcall.init)
  __initcall_end = .;
  . = ALIGN(4096);
  __init_end = .;
 }
关于虚拟地址和物理地址的：使用MMU后，系统就会使用虚拟地址，通过MMU来指向
实际物理地址而在这里我们的0xC0008000实际物理地址就是0x30008000，
具体关于MMU的介绍参考《ARM体系结构与编程》。
到head-armv.s找到程序的入口
  .section ".text.init",#alloc,#execinstr
  .type stext, #function
ENTRY(stext)
  mov r12, r0
  mov r0, #F_BIT | I_BIT | MODE_SVC @ make sure svc mode
  msr cpsr_c, r0   @ and all irqs disabled
  bl __lookup_processor_type
  teq r10, #0    @ invalid processor?
  moveq r0, #'p'   @ yes, error 'p'
  beq __error
  bl __lookup_architecture_type
  teq r7, #0    @ invalid architecture?
  moveq r0, #'a'   @ yes, error 'a'
  beq __error
  bl __create_page_tables
  adr lr, __ret   @ return address
  add pc, r10, #12   @ initialise processor
来看看上一句跳到哪里去了
去追寻r10的值，是在__lookup_processor_type子函数中赋的
__lookup_processor_type:
  adr r5, 2f   //r5 标号2的地址 基址是0x30008000
  ldmia r5, {r7, r9, r10} //r7=__proc_info_end  r9=__proc_info_begin
  sub r5, r5, r10  //r10 标号2的链接地址   基址是0xc0008000
  add r7, r7, r5   @ to our address space
  add r10, r9, r5  //r10 变换为基址是0x30008000的__proc_info_begin
2:  .long __proc_info_end
  .long __proc_info_begin
  .long 2b
这样r10中存放的是__proc_info_begin的地址,因为现在我们还没有打开MMU
所以还是需要把基址变换到0x30008000,接着我们就去找__proc_info_begin吧
注意到在上面的vmlinux.lds中有这个标号,下来链接的是.proc.info段,
在kernel\arch\arm\mm\proc-arm920.s的最后找到了这个段
 .section ".proc.info", #alloc, #execinstr

 .type __arm920_proc_info,#object
__arm920_proc_info:
 .long 0x41009200
 .long 0xff00fff0
 .long 0x00000c1e   @ mmuflags
 b __arm920_setup
ok,这样我们就知道add pc, r10, #12跳到哪里去了,因为这个地址刚好放了条跳转语句
注意了b语句用的都是相对地址,所以不需要变换地址,反正是跳到__arm920_setup,而且
上一条语句是adr lr, __ret,设定了__arm920_setup的返回地址是__ret,所以执行完
__arm920_setup后回到head-armv.s的__ret标号继续执行.
__ret:  ldr lr, __switch_data
  mcr p15, 0, r0, c1, c0 //注意这里了,在这里打开了MMU
  mov r0, r0
  mov r0, r0
  mov r0, r0
  mov pc, lr //跳到__mmap_switched,这里已经用了虚拟地址了吧
 // 这条指令ldr lr, __switch_data加载的__mmap_switched地址就是虚拟地址啊
__switch_data: .long __mmap_switched
从__mmap_switched一路执行下来,就要调到C语言代码中去了
  b SYMBOL_NAME(start_kernel) //在kernel\init\main.c中
这个程序不是特别复杂，细心看看还是能大概看懂，我也不能去一一注释
这里有一个流程图

到了C语言中就不是很难理解了
 lock_kernel();
 printk(linux_banner);
 setup_arch(&command_line);
 printk("Kernel command line: %s\n", saved_command_line);
 parse_options(command_line);
 trap_init();
 init_IRQ();
 sched_init();
 softirq_init();
 time_init();
就是一大堆初始化工作,追着每个函数去看好了

start_kernel最后调用的一个函数
static void rest_init(void)
{
 kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);
 unlock_kernel();
 current->need_resched = 1;
  cpu_idle();
}
用kernel_thread建立了一个init进程,执行的是main.c中的init函数
 lock_kernel();
 do_basic_setup();
在do_basic_setup中调用了do_initcalls函数
各种驱动都是在do_initcalls(void)中完成的
static void __init do_initcalls(void)
{
 initcall_t *call;

 call = &__initcall_start;
 do {
  (*call)();
  call++;
 } while (call < &__initcall_end);

 flush_scheduled_tasks();
}
__initcall_start也是在vmlinux.lds中赋值的,那就需要找到.initcall.ini这个段
在kernel\include\linux\init.h中可以找到
#define __init_call __attribute__ ((unused,__section__ (".initcall.init")))
typedef int (*initcall_t)(void);
#define __initcall(fn)        \
 static initcall_t __initcall_##fn __init_call = fn
仔细研究下就发现这是把初始化函数的地址放到了.initcall.init段中
这样就可以不断调用驱动的初始化函数了
如果没有定义MODULE,那么#define module_init(x) __initcall(x);
所以如果要把驱动的编译进内核就很简单了吧
init的最后
 if (execute_command)
  execve(execute_command,argv_init,envp_init);
execute_command与ppcboot传的命令行参数是有关的哦,就是init=/linuxrc
这样就要去执行根目录下的linuxrc脚本,这个脚本会去执行busybox
而busybox又去执行/etc/init.d/rcS脚本,这个脚本又去执行/usr/etc/rc.local
完了

图1  Bootloader网络启动方式示意图

http://www.linuxforum.net/forum/showflat.php?Cat=&Board=embedded&Number=651003&page=0&view=collapsed&sb=5&o=0&fpart=1#Post651082

再读bootm源码，现象正常！

呵呵 ， 原来 tftp download到是否是 hdr->ih_load(0x30008000) 确实是有说道的。
原来对bootm源码有个地方理解错了， bootm 会根据 hdr->ih_comp 判断是否需要解压， 对于
mkimage -C none 的是不需要解压的。

1> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008040 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8040
这种情况 ，只能把 uImage download到 30008000的位置上 ，否则 从 30008040
是启动不了的。
2> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008000 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8000
这种情况download地址随便。
如果 tftp 下载地址==0x30008000 ， 就从 0x30008040 启动就肯定OK 。
详细的请看代码。
研究了一下 u-boot-1.2.0 里面的 bootm的实现代码： do_bootm_linux() 函数 ，
原来由于我用mkimage的的时候的选项是 -C none ， 所以下面的判断中 hdr->ih_comp ＝
IH_COMP_NONE
通过再读一遍代码， 也弄明白了上次问的问题， 就是 u－boot里面的解压和
内核自解压的区别： u-boot 里面的解压实际上是bootm 实现的 ， 把 mkimage -C bzip2
或者gzip 生成的 uImage进行解压 ； 而kernel的自解压是对zImage进行解压，
发生在bootm解压之后。

呵呵 ， 原来 tftp download到是否是 hdr->ih_load(0x30008000) 确实是有说道的。
原来对bootm源码有个地方理解错了， bootm 会根据 hdr->ih_comp 判断是否需要解压， 对于
mkimage -C none 的是不需要解压的。

1> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008040 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8040
这种情况 ，只能把 uImage download到 30008000的位置上 ，否则 从 30008040
是启动不了的。
2> mkimage -A arm -O linux -T kernel -C none -a 30008000 -e
30008000 -n linux-2.6.18.8 -d zImage uImage2.6.18.8-8000
这种情况download地址随便。
如果 tftp 下载地址==0x30008000 ， 就从 0x30008040 启动就肯定OK 。
详细的请看代码。
研究了一下 u-boot-1.2.0 里面的 bootm的实现代码： do_bootm_linux() 函数 ，
原来由于我用mkimage的的时候的选项是 -C none ， 所以下面的判断中 hdr->ih_comp ＝
IH_COMP_NONE
通过再读一遍代码， 也弄明白了上次问的问题， 就是 u－boot里面的解压和
内核自解压的区别： u-boot 里面的解压实际上是bootm 实现的 ， 把 mkimage -C bzip2
或者gzip 生成的 uImage进行解压 ； 而kernel的自解压是对zImage进行解压，
发生在bootm解压之后。

switch (hdr->ih_comp) {
case IH_COMP_NONE:
if(ntohl(hdr->ih_load) == addr) { //如果你是tftp 到 0x30008000那么这里就命中了。
printf (" XIP %s ... ", name); //tftp download 这里， 确实打印出来了。
} else { //否则随便download到一个地址， 流程就进入这里了。
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) //这个条件编译不成立
size_t l = len;
void *to = (void *)ntohl(hdr->ih_load);
void *from = (void *)data;
printf (" Loading %s ... ", name);
while (l > 0) {
size_t tail = (l > CHUNKSZ) ? CHUNKSZ : l;
WATCHDOG_RESET();
memmove (to, from, tail);
to += tail;
from += tail;
l -= tail;
}
#else/* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */
------------------------实际执行的是这里---------------------------------
memmove ((void *) ntohl(hdr->ih_load), (uchar *)data, len);
//从这里就可以看出一旦 tftpdownload到一个任意地址， bootm 都会把
//它（去掉header后的kernel搬运到0x30008000 的位置上，因此entry
//point 肯定要是 0x30008000 ，但是对于tftp 恰好download到
//0x30008000 的位置上的时候， 你会发现上面的代码中，就donothing
//了，因此就必须从 0x30008040

#endif/* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */
}
break;
case IH_COMP_GZIP:
printf (" Uncompressing %s ... ", name);
if (gunzip ((void *)ntohl(hdr->ih_load), unc_len, // 把它解压到ih_load的位置上去
(uchar *)data, &len) != 0) {
puts ("GUNZIP ERROR - must RESET board to recover\n");
SHOW_BOOT_PROGRESS (-6);
do_reset (cmdtp, flag, argc, argv);
}
break;
.....
省略了 gzip和 bzip2的处理 ， // 这里也说明 和 zImage的自解压是不一样的。
gzip : mkimage -C gzip ;
bzip2 mkimage -C bzip2 .
他是只uImage 本身被压缩了
default:
if (iflag)
enable_interrupts();
printf ("Unimplemented compression type %d\n", hdr->ih_comp);
SHOW_BOOT_PROGRESS (-7);
return 1;
}
//解压完毕，对于我得板子来说，是解压到 0x8000的位置上去了，这是个物理地址
puts ("OK\n");
SHOW_BOOT_PROGRESS (7);

为什么需要 safe mode（安全模式）

当用户购买一个产品后，在后续的服务中，可能还会发生一些费用，让产品开发商增加成本，如免费电话咨询，产品的维修、寄送。所以说将产品的卖出并不意味着最终的赢利。这样的情况下，产品的设计就需要更加合理，更加优化，来满足用户各种可能的需求。特别是在发生异常故障的时候，如果能引导客户自行完成诊断、修复，那么将大大降低后续的服务成本。正因为如此，产品故障时，就很需要safe mode安全模式来帮助用户完成恢复的工作。

从节约产品的成本、产品所能提供的功能上来看，safe mode 是大有裨益的。

大家所熟知的 windows 系统，也提供了 safe mode 安全模式，它就可以帮助用户解决系统不稳定，硬件冲突等诸多故障，让用户在自己可以操作的能力范围内先行对系统进行诊断与修复。在很大程度上， windows 的 safe mode 给用户与 Microsoft 都带来了很大的便利。

嵌入式Linux产品与其他IT产品不同的地方，主要是使用flash来存贮运行时的系统。它没有大的内存，没有大的存储空间，但它却也是一个完整的系统。

在通常情况下，嵌入式Linux产品的flash上的内容是不会被破坏的，也即它们会有着较好的稳定性，不会因为用户的常规使用而导致flash上的 firmware被破坏。但随着产品的更新升级，用户也需要在自己家中完成对已购买商品的更新换代。而用户大多属于非技术熟悉者，在更新升级中就可能出现种种意想不到的情况。

比如在用户做firmware升级更新时，平时不会出现问题的firmware可能在这个过程中，就面临着巨大的风险，极有可能致使用户的系统无法启动，不能正常工作。这样的情况是我们不愿意看到的，而实际中却的的确确可能会发生。

考虑这样一个场景：当用户对产品进行firmware升级时，如果在烧写flash的过程中，意外掉电，那么用户手中的产品就将无法再次启动，因为 rootfs系统已经被破坏了。用户所能做的，也只能将产品送回产商进行维修。这样来回的过程不仅耗费用户的精力，同样也会增加产品开发商的成本。在产品升级换代很快的当前市场情况下，这样的情况可能会经常发生。

如何避免这样的情况的发生呢？如果我们可以提供一个机制，在进行升级前即往flash中写入一个标记，正常完成后，再写入另一个标记来表示整个过程的正常结束，否则的话，烧写时掉电不会写入第二个标记，只有第一个标记，那么就认为产品故障，这个时候，进入另一个新的提示界面，让用户自己选择从 USB或FTP来重新升级firmware。这样的话，整个过程用户就完全可以在界面的友好提示下自己完成，方便了用户与产品开发商。

系统架构

本文以一个实际的产品为例，来说明safe mode的设计。

本系统为一个嵌入式Linux网络播放器，主要的功能为播放家庭网络中的多媒体文件，在家庭客厅等环境中有着大量的应用，它可以给用户提供更方便快捷的媒体文件的播放方式，并能充分利用家庭音响系统的巨大功能，而非PC环境下有限的外部设备，大大改善了媒体文件的播放体验。

产品所使用的flash总大小为16M。

系统包括三大部分，即bootloader，config, kernel + rootfs：

另外，/dev/mtdblock/0，在系统中对应整个flash block，即整个16M空间。

系统启动时，bootloader将kernel和根文件映象从flash上读取到RAM空间中，为内核设置启动参数，调用内核，进入application，进行媒体文件的播放。

这个通常意义上的嵌入式Linux系统，它是不带safe mode安全模式的。

这样的系统，在做系统更新升级时，主要是对kernel+rootfs部分进行升级，以此来增加系统的功能。

升级时，application主要是操作/dev/mtdblock/3设备文件：

第一步：下载新的firmware到ramfs中，也即ram disk中，比如/tmp目录下，采用的更新方式可以是USB或FTP；

第二步：read /tmp/firmware文件，并write到设备文件/dev/mtdblock/3上，即对已有的firmware进行了更新。

在升级的过程中，我们会提供友好的界面给用户，来提示下载进度与烧写flash的进度，让用户可以看到正在发生的状况。

最后烧写完成后，重新启动系统，即可进入到新的firmware中。

在通常的更新中，用户的产品配置config一般不去修改，保持用户已经做的配置选项，不能破坏。Config内容对应为/dev/mtdblock/2设备文件。

从USB/FTP 上更新时，所使用的firmware文件需要是一个更加完整的image文件，可以包括bootloader, default config, kernel+rootfs，并让application可以做到视image中的标记来决定是否需要更新bootloader、config等内容，这样会更加灵活。

在更新firmware时，如果掉电，那么kernel + rootfs部分将会出现不完整的情况，也就是说只写入了部分内容，而中途中断了，这样的话，一个不完整的系统将无法正常工作。在这样的情况下就需要safe mode安全模式了。

safe mode架构设计

Safe mode的设计中，对原来的系统增加了两个部分的内容：

kernel + rootfs，即简单的UI界面与功能；

magic number，即烧写flash的标记。

safe mode实际上也是一个kernel + rootfs部分，只是它所具有的功能只包括一些简单的界面，主要是提供网络设置，从USB/FTP下载firmware，完成对flash的烧写。

为了区分，这里，将主功能部分的kernel + rootfs称为master。

我们将safe mode存放在master的后部，预留的flash大小为4M。

Magic number只占用一个字节的大小，是在这4M的最后的部分的一个字节，也即原始系统的15872K的最后一个字节位置处。

在开始烧写flash前，将magic number设置为0x55，表示烧写的开始。烧写正常结束后，将magic number设置为0xAA，表示烧写正常结束。

如果新产品中具备了safe mode模式，那么在以后再次更新升级时，开始烧写flash时，magic number的位置将会有0x55标记，如果烧写中途掉电，在重新启动后，将由bootloader来检查magic number的值，如果内容为0x55，那么bootloader将从safemode部分读出kernel和根文件映象，再为内核设置启动参数，调用内核，进入safe mode application。

如果bootloader读到magic number为0xAA，那么说明master firmware是正常的，就将直接进入master。

所以涉及到safe mode的地方也包括了对bootloader的修改，需要在系统上电阶段也检查safe mode的magic number，这个过程是必不可少的，只有在启动阶段就检查magic number，才能跳过损坏的master系统，进入安全模式，达到恢复系统的目的。

safe mode架构实现

在safe mode的实现中，需要保持原有master部分的稳定，所以对master系统的building system不做大的改动，也就是保持safe mode的building system与master的building system共存。原则上来说，要避免对master系统带来大的冲突。

Master building system主要涉及到的编译过程为：

make

make rootfs

这个时候将得到master.bin

safe mode building system和其类似，只是make rootfs部分有所区分：

make

make smrootfs

这个时候将得到safemode.bin

最后再将master与safe

mode部分做一个合并，得到一个整的rootfs

make dualrootfs

make dist

make

dualrootfs将调用一个外部的程序make_dual.c，所做的事情是要得到一个15872K的rootfs。这个rootfs包含的内容为master.bin + safemode.bin。

本系统中一般master.bin的大小约为10000K，再加上safemode.bin的4M，总大小并未达到15872K，那么中间多出的部分，我们需要将其补０填充好。需要补充的０的大小约为15872-4*1024-10000=1776K

make_dual.c就是完成上面的合并，补０的工作。它read master.bin，write rootfs，然后write　1776K个零到rootfs中，接下来read safemode.bin，再继续write 到rootfs中。

这样就得到了完整的、带master与safe mode的rootfs。

safe mode实现中遇到的问题及其解决

体积限制：

在safe mode的开发中，首先遇到的一个问题就是如何从已有的系统中简化出一个safe mode的application环境。

对master原有系统的裁剪来得到safe mode，将会比较容易，如果从头另写一套，将会花费较大精力，稳定性也无法得到确实的保障，所以最终采用的是精简master的系统来得到safe mode的大框架。

在实现safe mode时，要做的工作的原则是做到safe mode的rootfs尽量小，低于４M，并且保持与master外围特性的一致，这样可以避免重复开发，同时代码的共用可以减少维护的不便，提高整个系统的灵活度、稳定度。

就一个能运行的嵌入系统来说，最基本的内容应该包括Linux kernel，busybox工具包、图形驱动等内容。

在本系统中，为了支持FTP下载，需要有network的支持，也即需要包括wired/wireless的支持。

为了支持USB下载方式，就需要USB monitor管理进程的支持，这个主要是保持了与master系统的一致，而没有另外去写一个体积更小的USB管理模块。

wireless模块：

本来在设计时，可以考虑不加入wireless的支持，但为了更加方便用户，保持用户的使用习惯，我们还是加入了对wireless的支持，这样也保持了与master系统的一致，但支持的代价是，safe mode的体积增大了大约250K。

在wireless module中，做了一个优化，master系统中wireless module在insmod时，是使用的rootfs中的/lib/module/wireless/XXX.o，这些未压缩的.o文件在rootfs系统中将占用较大空间，这样一来，对应的safe mode的内容将会超出４M的大小。为了解决这个问题，我们将这些wireless module压缩成wireless.tar.gz文件，放置到safemode.bin中，在Linux启动时，在/etc/rc脚本中将 wireless.tar.gz解压缩到ramfs中即／tmp/lib/module/wireless下，然后再从这里insmod安装 wireless模块。这样所做的努力，wireless module从原来的790K，缩减到了250K，而功能保持了一致。

字体：

master 系统的字体使用的是freetype2，字体文件arialbd.ttf大约为280K，这也将占用大量的空间。由于safe mode在显示界面方面没有过高的要求，能让用户看到基本的图形界面就已经达到目的了，所以在safe mode中需要将freetype去掉。但由于master模式与safe mode都使用相同的图形引擎，这样就导致了，如果在safe mode中去掉freetype，那么就需要再次重新build基础的图形库，这样在master与safe mode的单独编译过程中就需要反复去make clean这些库。这会给每次的编译带来很大的不便，每次make clean等操作会占用大量的时间，耗时耗力。

基于这个考虑，我们决定master与safe mode在编译过程中都使用相同的图形库，即都编译生成freetype库。但在运行时，safe mode不去使用freetype。也就是说，freetype库会被编译进来，但字体文件不需要加到safe mode中，这样做的代价就是编译出来的safe mode的application比完全无freetype库的情况要大100K左右，但却保持了与master相同的库结构，而freetype字体就不再需要了，也就节约出了大约280K的空间。

最终优化的结果，safe mode的4M，包括Linux kernel, buzybox, safe mode application等压缩后的大小：

后续版本的兼容：

在safe mode的设计中，对后续多个版本升级的支持也是一个需要仔细考虑的地方。因为后续版本会存在很多的不确定性，如果发出的版本不能很好地兼容后续版本，那么将会给产品带来巨大的风险。

后续版本的可能情况，主要分两种：结构分区变化不大，结构分区变化巨大。

对后续版本中变化不大的情况，也即类似master + safe mode的情况，当再次更新时，只需要操作/dev/mtdblock/3对应master，/dev/mtdblock/4对应safe mode，即可。

但如果后续版本变化非常大，那么就需要特别注意了。

可以考虑这样一个情况：如果后续的版本，需求发生了大的变化，比如需要将原来master所在的分区再分成多个分区：

那么从老版本升级到新版本时，这些分区的内容如何保证烧写后能正常工作呢？

解决的办法就是在老版本中，将后续的rootfs部分作为一个整体来操作，也就是说烧写时，是将master + part1 + part2+ safe mode作为一个整体来对待。在老版本看来，新版本中的这15872K的内容，不管它其中有多少个不同的分区，还是master + safe mode。在烧写时，还是按/dev/mtdblock/3对应master，/dev/mtdblock/4对应safe mode的方式来烧写，完成将15872K的内容完整烧写进flash即可。

为了做到这一点，在烧写中，我们将全部的15872K的内容分成两段，第一段为15872-4*1024=11776K，需要将其write到/dev/mtdblock/3中，第二段为4M，需要将其write到/dev/mtdblock/4中。这样全部的15872K的内容就完整地烧写完，而再次启动后的kernel会分辨出 master + part1 + part2 + safe mode，它们的总大小依然保持15872K不变。这整个过程中，都不用去理会新版本中到底包括哪些内容，哪些分区，只要保证是将15872K的内容全部完整地烧写进去就可以了。

整体rootfs的设计思想在这里帮了一个大忙，简化了升级更新时所需要考虑的复杂度，使设计变得更加灵活与易于维护。

这样才新发布的firmware里，如果分为多个分区，那么就保证再次升级时，将15872K的内容分成多段，写到类似/dev/mtdblock/3、4、5、6这样的设备文件里就可以了，只要保证这些区域是连续的、并且烧写的内容是全部的那15872K内容即可。

Magic number：

值得注意的是，随着不同的版本的变化，magic number的位置还是应该保持在15872K的最后一个字节的位置。但这就出现一个问题，在不同的版本中，这个magic number的位置会是在不同的partition的最后一个字节。比如某个版本可能是在/dev/mtdblock/4的最后，但再后续的版本它会变成了/dev/mtdblock/7的最后面，这样就会存在很大的不确定性。所以在一个各个版本中，写magic number标记位时，需要一个统一的方法来做到这件事。最容易想到的办法当然就是magic number这个位置相对起始位置０是不变的。而前面提到过的/dev/mtdblock/0就刚好是代表了可以操作的整个flash分区。

有了/dev/mtdblock/0，这样我们就可以open 它，seek到magic number的位置，然后write下0x55或0xAA，这样就保持了写magic number的代码的一致性，不需要根据不同的分区，多次修改操作magic number的有关函数。

Booloader：

Bootloader的修改，也涉及到对magic number的读取，它的读取就相对简单一些，直接使用magic number在RAM中映射的绝对地址即可。

Bootloader检查完magic number后，需要将相对地址为0xBC0000的safe mode的kernel + rootfs读入到RAM，然后设置启动参数，调用内核，进入safe mode提示界面。

Linux kernel：

与老的、不带safe mode的image相比，新的image里的Linux kernel从总体的角度来说，并没有大的变化。在新做的master与safe mode的image中，它们各自需要包含一个Linux kernel，这两个kernel唯一的不同就是启动时所需要的rootfs在RAM中的映射位置不同。它们都有着相同的partition分区设置，编译选项等。

Safe mode必须包含自己的Linux kernel，因为它是运行在master损坏的情况下，master kernel已经不能启动了。

总结

上面的内容是在实际开发中对safe mode的设计与实现的一个描述。从这个描述中，可以看到safe mode在嵌入式Linux产品扮演着重要的角色，对它的设计涉及到很多方面，要考虑系统的尺寸，与现有buidling环境的的兼容性，对后续版本的升级的兼容性等诸多方面。

从某种意义上来说，safe mode的设计关系到产品的成败，一个好的safe mode的设计将会给产品带来巨大的灵活性与可扩展性，大大地方便了客户与产品开发商。

关于作者

		余涛，高级软件工程师，现从事 linux 嵌入式系统的开发工作，主要研究方向嵌入系统，UPNP 多媒体播放系统。您可以通过电子邮件 yut616@21cn.com 和他联系。希望能与更多的朋友交流关于 Linux 方面的知识。

    关键词：机内码 动态编码 字库

因为汉字本身的特点，显示汉字始终是计算机在我国应用普及的一个障碍。最初，为了能在PC机上显示、处理汉字，国人发明了一种硬件设备"汉卡"，后来各种各样的采用纯软件技术的中文DOS逐渐成熟，其中、西文软件的运行速度和性能还是有明显的差距。最终在软件进入支持UNICODE、真正实现国际化的WIN95以后，硬件跨入"奔腾"时代，才实现了汉字与西文的统一显示，但是这一切是以硬件资源的飞速发展为前提的。以国际GB2312为例，一、二级汉字库共收录了6000多个汉字，每个字按16×16点阵计算，字模需要占用32字节的存储空间，整个字库的规模在200k字节以上，高点阵（24点阵以上）和矢量字库以及Windows用的TrueType字体的字库规模都是几兆字节大小，这在早期的386时代是难以想象的。单片机因为使用灵活、结构简单、体积小、成本低而在工业和生活中得到广泛应用，也正是因此，它的硬件资源很有 限，寻址和计算机能力都远低于PC机，显示汉字更受限制。人们不满足单片机系统采用LED数码管的简单显示，根据单片机的特点，开发出了很多种汉字显示方法。

1 几种常用单片机显示汉字方法

(1)采用标准字[1]

这种方法仿器中文DOS的办法，将一个标准的汉字库装入ROM存储器，再根据汉字的机内码在字库中寻址，找到对应的字模，提取后送到显示器显示。因为采用了和PC机相同的编码(机内码)，软件的开发和维护非常简单，基本上与写PC机软件差不多。而对单片机系统自身的要求则相对高多了，16×16点阵的字库需要256K字节，但是一般8位单片机的寻址能力只有64K字节，要进行存储器扩充，除增加很大一部分硬件成本外，还因为要进行存储器分页管理、地址切换，显示速度明显受影响，而且只能显示一种点阵字体。

（2）直接固化显示字模[2]

将要显示的语句中全部汉字的字模数据依次提取出来，顺序存放在存储器中，当显示时，直接取出字模数据送至显示器即可。这种方法占用空间少，程序实现简单，显示速度快；但是字模数据的提取和存储安排是一件委有繁琐的事件，要想大量显示汉字或进行程序修改几乎是不可能的，软件的可维护性很差。

(3)建立带索引的小字库[3]

将全部要显示的汉字统一建成一个小字库，字库分为2部分：索引素和字模表。索引表由若干定长记录组成，记录的内容为：汉字机内码、地址码、识别码。其中地址码是该汉字字模在字模表中的位置，识别码标志该汉字的点阵形式或字体等。字模表中按素引存放汉字字模。显示汉字时先根据待显汉字的机内码在索引表中寻找，找到对应索引记录后，读出地址码和识别码，再根据此从字模表中读出字模，送显即可。这种方法可根据实际使用对字库进行裁剪，硬件开销较小，但是要进行复杂的查询运算，字多了平均寻找时间就会变长，效率降低。

2 汉字动态编码

综上所述，我们发现：在方法1中，程序员工作量最少，但单片要机的软、硬件开销最大；方法2中，单片机的开销较少，但是编写和维护软件极为困难；方法3,介于二者之间。显然，存储空间、显示速度、软件开发维护件间存在着矛盾。受各种PC机模拟软件的启发，我们提出一种基于PC机预处理的汉字显示方法--汉字动态编码，在实际应用中较好地解决了这一问题。其基本原理如下：建立一种新的编码机制，这个汉字编码是动态的；一个编码不与某个汉字具体相联系，而仅代表某个汉字在字库中的位置（这个位置也是动态的）；用该码代替程序里字符串（C语言）或数据段（汇编语言）内汉字的机内码，单处机显示程序可根据这个新的编码直接在专门建立的动态小字库中找到字模，不用进行复杂的寻址、查找等运算，如图1所示。

实现汉字动态编码的过程就是先进行汉字识别，然后建立编码字典、提取字模、建立动态字库、改写机内码。首先扫描一遍程序文件，识别其中的汉字，将它们按出现先后顺序或机内码的大小排序，重复出现的剔除，建立了一个编码字典；根据汉字在编码字典的位置（序号），可以对汉字按区码、位码进行编码，也可以采用其它的方法编码，总之序号与它的动态编码存在一一对应关系；根据字典中每个汉字的机内码依次从PC机的汉字点阵字库中提取字模，顺序存储，建立一个小规模的动态字库，这样每个汉字的字模在字库中的位置就与其在编码字典中的序号、动态编码一一对应了。最后，再扫描一遍程序文件，按照编码字典将每个汉字的机内码改写为对应的动态编码。因为程序文件中的汉字随时会增减，编码随之而变，字库的大小也随时在变。所以称之为动态编码和动态字库。

考虑一般应用场合，1000个左右的汉字即可满足要求，按照汉字动态编码方法所需的字库仅为32K字节大小，只需要1片27256即可，几乎不用增加什么硬件。这样，字库的大小可由汉字的多少控制，程序的编写和维护可以沿用中文系统下的习惯，仅需要编写好的单片机程序用PC机进行一次预处理，程序员从繁杂的汉字处理工作中解放出来，有效地降低了软件和硬件开发成本。

3 汉字动态编码的具体实现

实现汉字动态编码的关键是建立编码字典和改写机内码。下面以是显示1行汉字"天上有个太阳，水中有个月亮"为例，说明动态编码的实现过程。

（1）汉字识别

汉字在PC机内的存储和处理是用机内码来实现的。每个汉字的机内码是唯一的，由2个字节组成，分区码和位码，为了和西文的ASCII码有区别，汉字机内码的区码和位码的取值都大于0A0H。我们要处理的源程序文件都是文本文件，存储的都是西文字符、控制符的ASCII码和中文字符的机内码，当扫描到文件中大于0A0H的字节内容时，即可判断该字节是汉字机内码的1个字节，而且肯定是成对出现，第1个字节是区别，第2个字节是位码，都大于0A0H，否则出错。

在C和汇编程序中表示字符的方式有所不同，但最终字符在文件中的存储格式是一样的。显示上面那行汉字，用C语言可以表示为：

char OneSent[]="天上有个太阳，水中有个月亮"；

printfhz（OneSent）;/*printfhz()显示函数*/

用十六进制编辑器（我们用的是UEdit32）察看文件中C语言字符串定义语句为：

63 68 61 72 20 20 4F 6E 65 53 65 6E 74 5B 5D 20 3D 20 22 CC EC C9 CF D3 D0 B8 F6 CC AB D1 F4 A3 AC CB AE D6 D0 D3 D0 B8 F6 D4 C2 C1 C1 22 20 3B 0D 0A

用汇编语言可以表示为：

ONESENT:DB '天上有个太阳，水中有个月亮'，00H

MOV DPTR,ONESENT

LCALL DISPLAY；DISPLAY是显示子程序

用十六进制编辑器察看上面用汇编语言定义字符串的那一条语句为：

4F 4E 45 53 45 4E 54 3A 44 42 20 27 CC EC C9 CF D3 D0 B8 F6 CC AB D1 F4 A3 AC CB AE D6 D0 D3 D0 B8 F6 D4 C2 C1 C1 27 2C 30 30 48 0D 0A

由此可以观察到情况确如前所述。

（2）建立编码字典

编码字典是在扫描的同时逐步建立起来的，每扫描到一个汉字（包括全角符号），即与字典中已有的字符进行比较，如没有重复，是新的字符就顺序存入字典，否则继续扫描，直至文件结属。由于每个字符都是从尾部添加的，它们的序号也是依次递增的，根据序号就可以进行动态编码了。由于显示的汉字一般都得在256个以上，即使进行动态编码，也需要用2字节编码来实现。以MCS51系列单片机和16×16点阵汉字做一优化编码示例：8051的地址指针DPTR是16位指针，由高、低2字节指针DPH、DPL组合而成，如果将存储器按0FFH（256）字节分布，修改DPH即可直接寻址到任一页，修改DPL可寻址该页的任一字节。一个16×16点阵汉字的字模是32字节大小，每页存储器正好能容纳8个汉字字模。可以优化设计动态编码的高字节指向字模的页地址（DPH），低字节指向字模在该页的首地址（DPL）。考虑地址空间的有效分配，将字库的地址放在0A000H以后（程序或数据存储器均可），动态编码的高字节要加上地址有效分配，将字库的地址放在0A000H以后（程序或数据存储器均可），动态编码的高字节要加上地址的页偏移量（大于等于0A0H）；考虑汉字与西文字符的区别，动态编码的低字节也需要加上一个大于或等于0A0H的偏移量。设某汉字在编码字典中的序号为Num，则该汉字的动态编码为：

动态编码高字节=页偏移量+Num/8

动态编码低字节=偏移量+(Num%8)×32    (1)

偏移量一般可设为0A0H。当单片机显示某个汉字时，只需将其动态编码的高字节送DPH，低字节减0A0H后送DPL，即可得到对应字模的地址指针。

（3）提取字模、建立动态字库

汉字机内码与点阵字库的详细关系可参考有关资料，它们存在如下联系：

字模首地址=（（机内码高字节-1）×94+（机内码低字节-1））×N    （2）

注：N为一个汉字点阵字模的字节数。

按照编码字典内容，根据字模首地址，依次取出汉字字模，顺序写入一个二进制文件，即建成动态字库（其它方法略），用烧录器写入EPROM，就可以使用了。

（4）编码改写

机内码是PC机识别处理汉字用的，单片机只能处理我们建立起来的动态编码，还得把程序中汉字的仅机码根据编码字典改成对应的动态编码才行。由于在编写源程序的文本编辑器中看到的是经过系统处理过的字节，看不到汉字的机内码，也无法对其进行改写。根据"汉字识别"一节所述，不经过文本编辑器，直接将动态编码（十六进制数）定改磁盘文件对应位置即可，但是处理过后的汉字在文本编辑器里会显示出乱码。

（5）汉字显示

在明白了动态编码与动态字库中字模的关系后，可以完成按照PC机下汉字显示原理进行单片机下的程序设计，编写前面的函数printhz（）或子程序的DISPLAY，可参考相关资料[4]。

4 MCS51汉字显示例程

根据上述汉字动态编码方法，我们利用Borland C++编写了PC机预处理程序，将ASM51或C51源程序用PC机预处理后，建立了动态字库和改写了机内码，并且用ASM51写了一个针对MCS51进行优化的子程序DIS_CHAR。它显示一个西文或中文字符，实现过程如图2所示。

西文字符码的显示与流字显示基本相同，将西文字库（仅数字和字符部分）装入程序存储器中，根据ASCII码的值计算出字模首地址，将字符字模依次读出，再送显示即可。

此方案不但可用于单片机系统中，还可应用于任何无中文系统支持的嵌入式系统中。根据这个思路还可设计出不同字体、点阵混合的字库，支持包含2万多个字符的新国标编码，甚至矢量字体在单片机系统中的应用也成为可能。由于技术水平有限，此方案还存在一些不足之处，如改写编码后源程序中汉字显示为乱码，不知道改码处理是否正确，操作比较繁琐。如果能采用插件技术实现此方案，编辑器中能正常显示汉字，而输出已经是改码后的程序文件，则能很好地解决上述不足。在这里，我们抛码引玉，希望有兴趣的朋友一起合作，实现单片机中文显示的广义开发平台。

动态编码预处理的C语言源程序(在BC++3.1下调试通过)见网站补充版（http://www.dpj.com.cn）

         汉字指针在指针区的偏移由公式计算:pos=((qu-16)*94+wei-1)*6。
            注:qu--区号。wei--位号。

         汉字的矢量数据格式为:控制码+坐标值。共有十种控制码,以下是控制码的 含义:

         (1)若控制码第7,6位为11,清除码,结束当前笔划,将第一个坐标与当前坐
标连线;建立新笔划,(X,Y)各占7位,由控制码的第５位开始,即:11XXXXXX XYYYYYYY。
        注:一个字节的位:
           7 6 5 4 3 2 1 0
           X X X X X X X X

         (2)若控制码小于等于0x40,之后控制码大小个字节为坐标值,每个坐标占一个字节,共有控制码大小个坐标,(X,Y)坐标各占4位,其自的最高位为符号位, 即:FXXXFYYY。

         (3)若控制码的高4位等于4,之后控制码的低4位大小个字节为坐标值,每个坐标占一个字节,共有控制码大小个坐标,(X,Y)坐标各占4位,X为正,Y为正,即:+XXXX+YYYY。

         (4)若控制码的高4位等于5,之后控制码的低4位大小个字节为坐标值,每个坐标占一个字节,共有控制码大小个坐标,(X,Y)坐标各占4位,X为负,Y为正,即:-XXXX+YYYY。

         (5)若控制码的高4位等于6,之后控制码的低4位大小个字节为坐标值,每个坐标占一个字节,共有控制码大小个坐标,(X,Y)坐标各占4位,X为负,Y为负,即:-XXXX-YYYY。

         (6)若控制码的高4位等于7,之后控制码的低4位大小个字节为坐标值,每个坐标占一个字节,共有控制码大小个坐标,(X,Y)坐标各占4位,X为正,Y为负,即:+XXXX-YYYY。

         (7)若控制码等于0x80, 其后1字节为Y坐标值, 最高位为符号位, X坐标不 变, 即:10000000 FYYYYYYY。

         (8) 若控制码等于0x90, 其后1字节为X坐标值, 最高位为符号位, Y坐标不 变,即:10000001 FXXXXXXX。

         (9) 若控制码的高4位等于8,其后1字节为Y坐标值,控制码的低4位值为X坐标值,X坐标各占4位,最高位为符号位,Y坐标各占8位,最高位为符号位, 即:1000FXXXFYYYYYYY。

         (10)若控制码的高4位等于9,其后1字节为X坐标值,控制码的低4位值为Y坐标值,Y坐标各占4位,最高位为符号位,X坐标各占8位,最高位为符号位, 即:1000FYYYFXXXXXXX。

主题：Re: 请问ucdos矢量字库算法

:    我想直接读取ucdos下的矢量字库，请问有谁知道算法？
:    急！急！急?/font>
: ?/font>


/* 矢量汉字的读取和显示 */
#include <stdio.h>
#include <graphics.h>
#define HZNUM (0xf7-0xaf)*(0xfe-0xa0) /* 除前16区外的所有汉字 */
#define HZKSIZE 128    /* 汉字的大小 */
#define START_X 0
#define START_Y 0
#define VIEW_H 256   /* 显示汉字的高度 */
#define VIEW_W 256   /* 显示汉字的宽度 */
FILE *fp;
struct hz_struct {
        unsigned long shift;  /* 偏移量 */
        unsigned int size;    /* 大小 */
 }HZ_Index[HZNUM];       /* 汉字索引 */
unsigned char buf[1024];
unsigned char dotbuf[1024];
main()
{
  long ioffset;
  int i,j;
  char ch;
  int gdriver=DETECT;
  int gmode;
  if((fp=fopen("hzksly1j","rb"))==NULL){
     printf("cano't open the HZlib!");
          exit(1);
     }
  fread(HZ_Index,sizeof(struct hz_struct),HZNUM,fp);
//if(registerbgidriver(EGAVGA_driver)<0) exit(1);
initgraph(&gdriver,&gmode,"");
cleardevice();
setcolor(LIGHTGRAY);
for(i=0; i<HZNUM;i++){
Disp_HZ(HZ_Index[i].size,HZ_Index[i].shift);
rectangle(START_X,START_Y,START_X+256,START_Y+256);
ch=getch();
cleardevice();
if(ch=='q') break;
}
closegraph();
fclose(fp);
}

/* 显示汉字 */
Disp_HZ(int length,long posi)
{
int i,j,k;
int x0,y0,x1,y1;
int hzsize;
union utype{
unsigned short size;
unsigned char str[2];
}BH;
if((fseek(fp,posi,0))!=0){
printf("seek\"clib\"error!\n");
exit(0);
}
memset(buf,0,1024);
fread(buf,length,1,fp);
hzsize=decode(buf,length);
k=0;
for(i=0;i<hzsize;i++){
BH.str[0]=dotbuf[k++];
BH.str[1]=dotbuf[k++];
if(BH.size==0)break;/* 每个汉字以0结束 */
x0=START_X+(dotbuf[k++]*VIEW_W)/HZKSIZE;
y0=START_Y+(dotbuf[k++]*VIEW_H)/HZKSIZE;
// x0=START_X+dotbuf[k++];
// y0=START_Y+dotbuf[k++];
moveto(x0,y0);
for(j=0;j<BH.size-1;j++){
x1=START_X+(dotbuf[k++]*VIEW_W)/HZKSIZE;
y1=START_Y+(dotbuf[k++]*VIEW_W)/HZKSIZE;
// x1=START_X+dotbuf[k++];
// y1=START_Y+dotbuf[k++];
lineto(x1,y1);
}
lineto(x0,y0);
}
}

/* 汉字字形还原
*/
decode(p,length)
unsigned char *p;
int length;
{
int k;
int i,count,lposi,xsum,ysum;
unsigned char b60;
char dxfh,dyfh;
char x0,dx,dy;
lposi=0;
k=2;
while((p-buf)<=length){
b60=*p&0xc0;
switch(b60){
case 0xc0:
if(k!=2){
dotbuf[lposi]=(k-lposi-2)/2;
dotbuf[lposi+1]=0;
lposi=k++;
k++;
}
x0=(*p&0x3f)<<1;
dx=(*(p+1)>>7)&0x01;
            dx=dx+x0;
            p++;
            dy=*p++&0x7f;
            dotbuf[k++]=xsum=dx;
            dotbuf[k++]=ysum=dy;
            break;
  case 0x80:
            dxfh=dyfh=1;
            switch(*p&0x30){
            case 0x00:
                      if(*p&0x08)dxfh=-1;
                      dx=*p&0x07;
                      p++;
                      if(*p&0x80)dyfh=-1;
                      dy=*p&0x7f;
                      break;
            case 0x10:
                      if(*p&0x08)dyfh=-1;
                      dy=*p&0x07;
                      p++;
                      if(*p&0x80)dxfh=-1;
                      dx=*p&0x7f;
                      break;
            case 0x20:
            case 0x30:
                      p++;
                      if(*p&0x80)dxfh=-1;
                      dx=*p&0x7f;
                      p++;
                      if(*p&0x80)dyfh=-1;
                      dy=*p&0x7f;
                      break;
            }
            p++;
            xsum+=dx*dxfh;
            ysum+=dy*dyfh;
            dotbuf[k++]=xsum;
            dotbuf[k++]=ysum;
            break;
  case 0x40:
            dxfh=*p&0x30;
            if(dxfh==0){
              dxfh=1;
              dyfh=1;
            }
            else if(dxfh==0x10){
              dxfh=-1;
              dyfh=1;
            }
            else if(dxfh==0x20){
              dxfh=-1;
              dyfh=-1;
            }
            else if(dxfh==0x30){
              dxfh=1;
              dyfh=-1;
            }
            count=*p++&0x0f;
            for(i=0;i<count;i++){
dx=*p>>4;
              dy=*p&0x0f;
              xsum+=dxfh*dx;
              ysum+=dyfh*dy;
              dotbuf[k++]=xsum;
              dotbuf[k++]=ysum;
              p++;
             }
            break;
  case 00:
           count=*p++&0x3f;
           for(i=0;i<count;i++){
if(*p&0x80) dxfh=-1;
else dxfh=1;
if(*p&0x08)dyfh=-1;
else dyfh=1;
dx=(*p&0x70)>>4;
             dy=(*p&0x07);
             xsum+=dx*dxfh;
             ysum+=dy*dyfh;
             dotbuf[k++]=xsum;
             dotbuf[k++]=ysum;
             p++;
           }
       }
   }
   dotbuf[k++]=0;
   dotbuf[k++]=0;
   dotbuf[lposi]=(k-lposi-2-2)/2;
   dotbuf[lposi+1]=0;
   return k;
 }

   To compile the YAFFS file system support as a module, choose M here:
   the module will be called yaffs.

   If unsure, say N.

   Further information on YAFFS is available at
   <http://www.aleph1.co.uk/yaffs/>.

config YAFFS_MTD_ENABLED
 bool "NAND mtd support"
 depends on YAFFS_FS
 help
   This adds the yaffs file system support for working with a NAND mtd.

   If unsure, say Y.

config YAFFS_RAM_ENABLED
 bool "yaffsram file system support"
 depends on YAFFS_FS
 help
   This adds the yaffsram file system support. Nice for testing on x86,
   but uses 2MB of RAM.  Don't enable for NAND-based targets.

   If unsure, say N.

comment "WARNING: mtd and/or yaffsram support should be selected"
 depends on YAFFS_FS && !YAFFS_MTD_ENABLED && !YAFFS_RAM_ENABLED

config YAFFS_USE_OLD_MTD
 bool "Old mtd support"
 depends on YAFFS_FS && 0
 help
   Enable this to use the old MTD stuff that did not have yaffs support.
   You can use this to get around compilation problems, but the best
   thing to do is to upgrade your MTD support. You will get better speed.

   If unsure, say N.

config YAFFS_USE_NANDECC
 bool "Use ECC functions of the generic MTD-NAND driver"
 depends on YAFFS_FS
 default y
 help
   This enables the ECC functions of the generic MTD-NAND driver.
   This will not work if you are using the old mtd.

   NB Use NAND ECC does not work at present with yaffsram.

   If unsure, say Y.

config YAFFS_ECC_WRONG_ORDER
 bool "Use the same ecc byte order as Steven Hill's nand_ecc.c"
 depends on YAFFS_FS
 help
   This makes yaffs_ecc.c use the same ecc byte order as
   Steven Hill's nand_ecc.c. If not set, then you get the
   same ecc byte order as SmartMedia.

   If unsure, say N.

config YAFFS_USE_GENERIC_RW
 bool "Use Linux file caching layer"
 default y
 depends on YAFFS_FS
 help
   Use generic_read/generic_write for reading/writing files. This
   enables the use of the Linux file caching layer.

   If you disable this, then caching is disabled and file read/write
   is direct.

   If unsure, say Y.

config YAFFS_USE_HEADER_FILE_SIZE
 bool "Use object header size"
 depends on YAFFS_FS
 help
   When the flash is scanned, two file sizes are constructed:
   * The size taken from the object header for the file.
   * The size figured out by scanning the data chunks.
   If this option is enabled, then the object header size is used,
   otherwise the scanned size is used.

   If unsure, say N.

config YAFFS_DISABLE_CHUNK_ERASED_CHECK
 bool "Turn off debug chunk erase check"
 depends on YAFFS_FS
 default y
 help
   Enabling this turns off the test that chunks are erased in flash
   before writing to them.  This is safe, since the write verification
   will fail.  Suggest enabling the test (ie. say N)
   during development to help debug things.

   If unsure, say Y.

#config YAFFS_DISABLE_WRITE_VERIFY
# bool "Disable write verify (DANGEROUS)"
# depends on YAFFS_FS && EXPERIMENTAL
# help
#   I am severely reluctant to provide this config. Disabling the
#   verification is not a good thing to do since NAND writes can
#   fail silently.  Disabling the write verification will cause your
#   teeth to rot, rats to eat your corn and give you split ends.
#   You have been warned. ie. Don't uncomment the following line.
#
#   If unsure, say N.
#

config YAFFS_SHORT_NAMES_IN_RAM
 bool "Cache short names in RAM"
 depends on YAFFS_FS
 default y
 help
   If this config is set, then short names are stored with the
   yaffs_Object.  This costs an extra 16 bytes of RAM per object,
   but makes look-ups faster.

   If unsure, say Y.
5．在/arch/arm/mach-s3c2410/mach-smdk2410.c找到smdk_default_nand_part结构，修改nand分区，如下：
struct mtd_partition smdk_default_nand_part[] = {
        [0] = {
                .name   = "vivi",
                .size   = 0x00020000,
                .offset = 0x00000000,
        },
        [1] = {
                .name   = "param",
                .size   = 0x00010000,
                .offset = 0x00020000,
        },
        [2] = {
                .name   = "kernel",
                .size   = 0x00100000,
                .offset = 0x00030000,
        },
        [3] = {
                .name   = "root",
                .size   = 0x01900000,
                .offset = 0x00130000,
        },
        [4] = {
                .name   = "user",
                .size   = 0x025d0000,
                .offset = 0x01a30000,
        }
};
注：此分区要结合vivi里面的分区来进行设置。
6．配置内核时选中MTD支持：
Memory Technology Devices (MTD)  --->
 <*> Memory Technology Device (MTD) support
  [*]   MTD partitioning support
   ……
  --- User Modules And Translation Layers
  <*> Direct char device access to MTD devices
  <*> Caching block device access to MTD devices
  ……
NAND Flash Device Drivers  --->
 <*> NAND Device Support
 <*> NAND Flash support for S3C2410 SoC
 [*]   S3C2410 NAND driver debug 
7．配置内核时选中YAFFS支持：
File systems  --->
 Miscellaneous filesystems  --->
  <*> Yet Another Flash Filing System(YAFFS) file system support
  [*]   NAND mtd support
  [*]   Use ECC functions of the generic MTD-NAND driver
  [*]   Use Linux file caching layer
  [*]   Turn off debug chunk erase check
  [*]   Cache short names in RAM
8.编译内核并将内核下载到开发板的flash中。
三、Yaffs文件系统测试：
1.内核启动之后，在启动信息里面可以看到如下内容：
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)
Scanning device for bad blocks
Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x00020000 : "vivi"
0x00020000-0x00030000 : "param"
0x00030000-0x00130000 : "kernel"
0x00130000-0x01a30000 : "root"
0x01a30000-0x04100000 : "user"
2.如果在内核里面添加了proc文件系统的支持那么你在proc里面可以看到有关yaffs的信息
~ # cat proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   sockfs
nodev   pipefs
nodev   futexfs
nodev   tmpfs
nodev   eventpollfs
nodev   devpts
nodev   ramfs
        vfat
nodev   devfs
nodev   nfs
        yaffs
nodev   rpc_pipefs
3.查看dev目录下相关目录可以看到：
~ # ls dev/mtd -al
drwxr-xr-x    1 root     root            0 Jan  1 00:00 .
drwxr-xr-x    1 root     root            0 Jan  1 00:00 ..
crw-rw-rw-    1 root     root      90,   0 Jan  1 00:00 0
cr--r--r--    1 root     root      90,   1 Jan  1 00:00 0ro
crw-rw-rw-    1 root     root      90,   2 Jan  1 00:00 1
cr--r--r--    1 root     root      90,   3 Jan  1 00:00 1ro
crw-rw-rw-    1 root     root      90,   4 Jan  1 00:00 2
cr--r--r--    1 root     root      90,   5 Jan  1 00:00 2ro
crw-rw-rw-    1 root     root      90,   6 Jan  1 00:00 3
cr--r--r--    1 root     root      90,   7 Jan  1 00:00 3ro
crw-rw-rw-    1 root     root      90,   8 Jan  1 00:00 4
cr--r--r--    1 root     root      90,   9 Jan  1 00:00 4ro

~ # ls dev/mtdblock/ -al
drwxr-xr-x    1 root     root            0 Jan  1 00:00 .
drwxr-xr-x    1 root     root            0 Jan  1 00:00 ..
brw-------    1 root     root      31,   0 Jan  1 00:00 0
brw-------    1 root     root      31,   1 Jan  1 00:00 1
brw-------    1 root     root      31,   2 Jan  1 00:00 2
brw-------    1 root     root      31,   3 Jan  1 00:00 3
brw-------    1 root     root      31,   4 Jan  1 00:00 4
4.mount、umount
建立mount目录
~ #mkdir /mnt/flash0
~ #mkdir /mnt/flash1
Mountblockdevice设备
~ #mount –t yaffs /dev/mtdblock/3 /mnt/flash0
~ #mount –t yaffs /dev/mtdblock/4 /mnt/flash1
~ #cp 1.txt /mnt/flash0
~ #cp 2.txt /mnt/flash1
查看mount上的目录，可以看到该目录下有刚才拷贝的文件，将其umount后，再次mount上来可以发现拷贝的文件仍然存在，这时删除该文件然后umount，再次mount后，可以发现拷贝的文件已经被删除，由此可以该分区可以正常读写。
5.在flash上建立根文件系统
~ # mount –t yaffs /dev/mtdblock/3 /mnt/flash0
~ #cp (your rootfs) /mnt/flash0
~ #umount /mnt/flash0
重新启动，改变启动参数：
param set linux_cmd_line "noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0"
重新启动，开发板就可以从flash启动根文件系统了。
注：这里你得在内核中添加devfs文件系统的支持，否则内核无法找到/dev/mtdblock/3目录

本文描述了将Linux移植到基于S3C2410处理器目标板上的方法与过程。介绍了目标平台和Linux，并说明了如何搭建移植环境，着重介绍了 Bootloader的架构和功能以及Linux内核的移植。结果证明该方法是可行的。移植后Linux在嵌入式系统中运行良好。

引言

嵌人式系统就是以应用为中心、以计算机技术为基础，软硬件可裁剪，适应应用系统对功能、可靠性、成本、体积、功耗等严格要求的专用计算机系统。 ARM嵌人式芯片是一种高性能、低功耗的RISC芯片。它由英国ARM公司设计,世界上几乎所有的主要半导体生产商都生产基于ARM体系机构的通用芯片， 或在其专用芯片中应用相关ARM技术。在2001年基于ARM内核的处理器占市场份额的75％，成为业界的龙头。

Linux是免费发行的、快速高效的操作系统 ，Linux的出现在计算机世界引发了一场革命。Linux操作系统以代码开放、功能强大又易于移植成为嵌入式操作新兴力量。嵌人式Linux是按照嵌人 式操作系统的要求设计的一种小型操作系统，由一个内核以及一些根据需要进行定制的系统模块组成。其内核很小 ，一般只有几百kb，即使加上其他必要的模块和应用程序，所需的存储空间也很小。它非常适合于移植到嵌入式系统中去 ，同时它具有多任务多进程的系统特征 ，有些还具有实时特征。

1 目标平台介绍

文中使用的目标平台S3C2410是SAMSUNG公司使用920T处理器内核开发的一款嵌入式处理器。S3C2410是Samsung公司专门为 PDA、Intenet设备和手持设备等专门开发的微处理器。该芯片还包含有16kB一体化的Cache/MMU，这一特性使开发人员能够将Linux和 VXwork移植到基于该处理器的目标系统中。该目标板的系统资源如下 ：

(1)CPU：S3C2410微处理器,工作频率为200MHz。

(2)Flash：16MB。

(3)SDRAM：64MB SDRAM。

(4)UART：RS-232串行接口。

(5)其他 ：14针ARM JTAG接口等。

2 交叉编译环境的建立

基于Linux操作系统的应用开发环境一般是由目标系统硬件(开发板)和宿主PC机所构成。目标硬件开发板用于运行操作系统和系统应用软件，而目标 板所用到的操作系统的内核编译、应用程序的开发和调试则需要通过宿主PC机来完成(所以称为交叉编译)。双方之间一般通过串口、并口或以太网接口建立连接 关系。单独拿出一台PC机，在该PC上安装桌面的Linux操作系统(如RedHatLinux9.0)，可以采用默认的安装选项(注意要包含FTP服 务)，这台PC作为Linux服务器，除管理员以外，一般不直接让其他人去操作。

将该Linux服务器接入局域网，并新建一些合法用户，以便其他的PC机(在此将其称为工作站)的合法用户能访问到Linux服务器。而其他的PC机(工作站)仍然使用Windows操作系统。

需要的软件工具包括 ：

(1)ftp客户端程序。

(2)Telnet工具。

(3)移植到某一特定ARM平台的Linux操作系统内核源码。

(4)GNU编译工具，可由相关网站下载。

在某工作站PC上安装ftp客户端程序和Telnet工具 ，安装完毕后应该可以在该工站PC和Linux服务器之间进行文件的传输，并在工作站PC可以通过Telnet登陆到Linux服务器(可能需要将Linux服务器 的防火墙服务关闭才能完成)。

Linux 服务器的安装：将工作站PC上的Linux操作系统内核源码压缩包和GNU编译工具通过ftp传送到Linux服务器的某个目录(如合法的用户目录)，然 后在该目录下解压，并将GNU编译工具安装到默认的工作目录即可，以上工作通过在工作站PC使用Telnet工具完成，而不需要在Linux服务器上进 行。Linux操作系统内核的编译一般有一个比较固定的步骤，会根据MakeFile文件的不同而略有差异，可参考相关文档，编译的工作在工作站PC使用 Telnet工具完成。按固定的步骤编译内核完成以后，会在相应目录生成可执行的二进制文件，通过ftp将该可执行的二进制文件传回工作站PC，然后通过 ADS或SDT下的烧写工具写入开发板的Flash即可。

3 Bootloader的架构和功能

Bootloader引导程序是嵌入式开发很重要的组成部分。它是嵌入式系统上电后执行的第一个程序，并由它最终将操作系统启动起来并将控制权交给 操作系统。Bootloader引导程序最基本的功能是对硬件系统的初始化和内核启动参数设置并启动内核。Bootloader的主要功能有：

(1)初始化CPU 的主频、SDRAM、中断、串口等硬件；

(2)启动Linux内核并提供一个RAMDISK；

(3)通过串口下载内核或RAMDISK到目标板上；

(4)将修改过的内核或RAMDISK写入到Flash内；

(5)为用户提供一个命令接口。

在嵌入式系统开发过程中，Bootloader还与主机通信，不断检测从主机传来的控制信息和数据信息，完成相应的操作。

Linux运行在保护模式下，但是当机器启动复位的时候却处于实模式下。所以写Bootloader的工作也是在实模式之下的。

Botloader的实现除了依赖于CPU的体系结构，还依赖于目标板的设置，本系统的Bootloader引导程序分为stagel和 stage2两个阶段。依赖于CPU的体系机构的代码 ，比如设备初始化等，放在stagel中，采用ARM汇编语言来实现，这样可以达到短小精悍的目的。stage2用C语言来实现，可以实现复杂的功能，同 时代码具有更好的可读性和可移植性。

●Bootloader的stage1

stage1是Bootloader一开始就执行的操作，其目的是为了stage2的执行以及随后的内核的执行，设置好一些基本的硬件环境。

包括以下步骤 ：

①屏蔽所有的中断 。为中断提供服务的通常是操作系统,因此在执行Bootloader的过程中可以不响应任何中断。中断屏蔽通过写CPU的中断屏蔽寄存器来完成。

②设置CPU的时钟频率和速度。

③初始化RAM设置系统的内存控制器的功能寄存器和各内存库控制寄存器等。

④为加载stage2准备RAM空间。

⑤拷贝stage2到RAM中。

⑥跳转到stage2的入口点。

●Bootloader的stage2

stage2的主要的功能是通过串口下载Linux内核到目标板上。

包括以下几个步骤：

①初始化本阶段要使用到的硬件设备。这通常包括：初始化至少一个串口，以便和终端用户进行I/O输出信息；初始化计时器等。

②检测系统的内存映射。所谓内存映射就是指在整个4GB物理地址空间中有哪些地址范围被分配用来寻址系统的RAM单元。

③加载内核映像和根文件系统从Flash读入到Rom中。这里包括两个方面：a．内核映像所占用的内存范围；b．根文件系统所占用的内存范围。在规划内存占用的布局时，主要考虑基地址和映像的大小两个方面。

④设置内核的启动参数。

⑤调用内核。Bootloader调用Linux内核的方法是直接跳转到内核的第一条指令处。

4 Linux内核的构建和移植

1)设置软件开发环境。

为了和目标板进行通讯，必须要在主机上终端运行仿真程序DNW。建议在宿主机上安装REDHATLinux9.0版本。以下以在SHELL模式下安装编译器和源代码为例介绍安装过程 ：

首先以ROOT身份进入系统。把REDHATLinux90的安装光盘放入光驱中，执行装载光驱命令：

moumt/dev/cdrom /nmt/cdrom

如果系统不能识别/mnt/cdrom，可以使用如下命令(假设cdrom为/dev/had)，则用mount -t iso9660 /dev/hdb/mnt。

如果在安装REDHATLinux9.0的时候已经默认安装了CDROM，以上命令不需执行,直接进入CDROM所在目录。

mkdir /usr/local/arm
mount /dev/cdrom /mnt/cdrom
cd/
cp /mnt/cdrom/bin/cross-2.95.3.tar.bz2 /usr/local/arm/
cp /mnt/cdrom/bin/Linux_for_s3c2410.gz
tar zxvf Linux_for_s3c2410.gz
cd /usr/local/arm/
tar -jxvf cross-2.95.3.tar.bz2

程序执行完后，Linux源代码和编译环境都已建立起来了。

2)Linux内核编译。

首先以ROOT身份进入系统。然后完成下列步骤，就可以在/Linux/arch/arm/boot/得到内核的映像文件zImage。

在shell命令下输入命令进行内核配置：

make menuconfig

该命令执行之后生成文件.config。它保存这个配置信息,下一次再执行make menuconfig的时候将生成新的.config文件。

输入命令 ：make dep

输入命令 ：make clean

输入命令 ：make zImage

通过各个目录的Makefile进行，将会在各个目录下生成一系列目标文件，上述步骤完成后，就完成了对Linux的编译工作。

Linux内核的编译、修改、移植实际上与上层的应用程序，如命令解释器shell、登陆程序login相关。这些程序应根据需要重新定制。

利用终端仿真程序DNW和Bootloader引导程序通过串口就可以把Linux内核移植到目标系统板。移植完成后，Linux就可以在目标系统板上运行了。

5 结束语

摘　要：介绍了一款优秀的嵌入式BootLoader—U-Boot，详细讲解了它的运行原理，着重讨论了其在S3C2410上的移植过程，并对移植结果进行了测试。

关键词：U-Boot；S3C2410；移植；BootLoader 

        引　言 

        BootLoader 是嵌入式系统软件开发的第一个环节，它紧密地将软硬件衔接在一起，对于一个嵌入式设备后续的软件开发至关重要。BootLoader还涉及到许多硬件相关 的知识，对于普通的嵌入式开发板，它又是不可跳过的步骤，所以做好它的移植工作是必须的，对于后续的开发工作也是有益的。U-Boot是当前比较流行、功 能强大的BootLoader，它操作简便，可以支持多种体系结构的处理器，同时提供了完备的命令体系。 S3C2410是三星公司一款基于ARM920T的嵌入式通用处理器。本文的移植平台就是以S3C2410 为核心的HHARM9-EDU-R2开发板，这块开发板的硬件资源配置较为完善。主要硬件资源有：S3C2410处理器；1片Intel TE28f128FLASH ( 16M)；2片Hynix HY57V561620 SDRAM(64M)；10/100M自适应网络芯片DM9000； USBHost/Device；RS232×2/RS485×1串口；LQ035FLM08L 256K色TFT真彩LCD显示屏；全功能JTAG调试口等。 

        U-Boot简介 

        U -Boot是Das U-Boot的简称，是由denx软件中心依照GPL 发布的公共软件，作为系统启动的引导模块，U-Boot支持多种处理器架构，比如Power-PC、ARM、MIPS和x86等。 目前，U-Boot源代码在sourceforge网站的社区服务器中， Internet上有一群自由开发人员对其进行维护和开发，它的项目主页是http：//sourceforge.net/ projects/ u-boot。当下载并解压U-Boot 源码包后，会形成如下的目录结构：board，和一些已有开发板有关的文件；common，实现各种U-Boot 命令的C 文件；cpu，CPU相关文件，其中的子目录都是以U-Boot 所支持的CPU命名的；disk，disk驱动的分区处理代码；doc，文档；drivers，通用设备驱动程序；fs，支持文件系统的文件； include，头文件，对各种硬件平台支持的汇编文件，系统的配置文件和对文件系统支持的文件；net：与网络有关的代码； lib-arm，与ARM体系结构相关的代码；tools，创建S-Record 格式文件和U-Boot Images的工具。 

        本文中U-Boot的移植就是根据HHARM9-EDU-R2开发板的硬件资源在以上的目录中修改或者添加相关源文件，并且重新编译的过程。移植工作开始之前，了解U-Boot的运行过程是十分必要的。 

        U- Boot 运行过程分析 

        U -Boot编译后的代码定义一般不超过100kB，并且这100 kB又分成两个阶段来执行。第一阶段的代码在start.s中定义，大小不超过10 kB，它包括从系统上电后在0x00000000 地址开始执行的部分。这部分代码运行在Flash中，它包括对S3C2410的一些寄存器的初始化和将U-Boot的第二阶段代码从Flash拷贝到 SDRAM中。除去第一阶段的代码，剩下的部分都是第二阶段的代码。 第二阶段的起始地址是在第一阶段代码中指定的，被复制到SDRAM后，就从第一阶段跳到这个入口地址开始执行剩余部分代码。 第二阶段主要是进行一些BSS 段设置，堆栈的初始化等工作，最后会跳转到main-loop函数中，接受命令并进行命令处理。图1 给出了U-Boot的详细的运行过程包括对内核的设置、装载及调用过程。 

        图1　U-Boot运行过程

        了解了U-Boot 的运行过程以后，我们还必须确定开发板的地址空间分布，才可以进行源码的修改和移植工作。 地址空间的分布部分依赖于开发板的硬件配置及CPU 的复位地址。 本文中开发板的地址空间如图2 所示。 

        图2  开发板地址空间分布 

        U-Boot的移植与测试 

         为了使移植工作更加快捷，应当选择U-Boot当前发布的最新版本1.1.2 (尽管通过CVS可以得到U-Boot1.1.3，但其正在开发，尚未发布，不宜使用) 。 因为最新的版本可以提供尽可能多的处理器核及开发板的支持。 对于U-Boot-1.1.2 而言，它不仅提供对ARM- 920T内核的支持，而且直接提供了对于S3C2410 的板级支持，这使移植工作量相对减少。 

        支持ARM- 920T内核的代码修改 

        由于U-Boot-1.1.2 提供对ARM-920T 内核的直接支持，所以本步骤不需要做任何工作，本文为了让读者了解BootLoder 移植的通用模式，在此只是稍加提示。 

        配置自己的开发板 

        建立自己开发板的目录和相关文件。 

        1) 在include/ configs目录中以smdk2410.h为模板添加头文件S3C2410. h(cp smdk2410.h S3C2410.h) 。 这个文件是开发板的配置文件，它包括开发板的CPU、系统时钟、RAM、Flash系统及其它相关的配置信息。 

        2) 在board/目录下创建S3C2410目录。拷贝smdk2410目录下所有文件到S3C2410目录下，共有如下六个文件：flash.c、 memsetup.c、S3C2410.c、Makefile、U-Boot .lds 和config.mk，根据开发板实际情况对各个文件进行修改。 

        ◆flash.c.U-Boot读、写和删除Flash 设备的源代码文件。由于不同开发板中Flash 存储器的种类各不相同，所以，修改flash.c时需参考相应的Flash 芯片手册。它包括如下几个函数： 

        unsigned long flash-init (void )，Flash初始化；
　　int flash-erase (flash-info-t *info，ints-first，ints -last)，Flash擦除；
　　volatile static int write- hword (flash-info-t *info，ulong dest ， ulong data) ，Flash 写入；
　　int write-buff (flash-info-t *info，uchar *src ，ulong addr，ulong cnt)，从内存复制数据。 

        由于本文开发板所用flash芯片为IntelTE28f128，在board/ cmi目录中有此flash.c，只需对其稍加修改即可使用。 

        ◆memsetup.c.初始化时钟、SMC控制器和SDRAM控制器。为了以后能用U-Boot的GO命令执行修改过的用loadb或tftp下载的U-Boot.在标记符“0：”上加入五句：
　　 
        mov r3，pc
　　ldr r4，= 0x3FFF0000
　　and r3，r3，r4 / /以上三句得到实际起动的内存地址
　　aad r0，r0，r3 / /用GO 命令调试uboot时，启动地址在RAM
　　add r2，r2，r3 / /把初始化内存信息的地址，加上实际起动地址 

        ◆S3C2410.C.设置各种总线时钟，打开数据Cache和指令Cache，并设置相关内存参数。 

        ◆Makefile.修改：OBJS ：= S3C2410.o flash.omemsetup.o 

        ◆U-Boot.lds.作如下修改： 

        .text 
        { 
        cpu/ arm920t/ start.o ( .text) 
* (.text) 
        } 

        ◆config.mk.用于设置程序连接的起始地址，因为会在U-Boot 中增加功能，所以留下6M 的空间，修改33F80000 为33A00000。 

        实现网卡的驱动程序 
        在drivers/目录中以dm9000x.c和dm9000x.h为模板添加网口设备控制程序dm9000.c和dm9000.h，其中dm9000.c主要包括以下函数： 

        int eth-init (bd-t *bd)，初始化网络设备； 
        int eth-send(volatile void *，int)，发送数据包； 
        int eth-rx(void)，接收数据包。 
        void eth-halt (void)，关闭网络设备； 

        为了方便网络设备的数据读写操作，还定义了如下函数： 

        static int dm9000-probe (void)，搜索DM9000芯片，分配空间并登记之； 
        static u16 phy-read(int)，从Phyxcer寄存器读取一个字； 
        static void phy-write ( int，u16)，写一个字到Phyxcer 寄存器； 
        static u16 read-srom-word (int)，从SROM 读取一个字数据； 
        static u8 DM9000-ior (int)，从I/ O 口读取一个字节； 
        static void DM9000-iow(int reg，u8 value)，写一个字节到I/ O 口； 
        最后在drivers/Makefile中加入dm9000.o。 

        修改Makefile 文件     
        在U-Boot-1.1.2/Makefile中ARM92xT Systems注释下面加入以下两行： 
        S3C2410-config ：unconfig
　　@./ mkconfig ＄( @：-config = ) arm arm920tS3C2410     

        其中“arm”是CPU的种类，arm920t是ARM CPU对应的代码目录，S3C2410是自己开发板对应的目录。 

        交叉编译器安装在：/ path/ armv4l-unknown -linux-目录下，所以把CROSS-COMPILE 设置成相应的路径： CROSS-COMPILE = / path/ arm4l-unknown-linux - 

        生成目标文件并进行测试 
        依次运行以下命令：     

        # make clean 
        # make S3C2410-config 
        # make 

        之后会生成三个文件： 

        U-Boot ——ELF 格式的文件， 可以被大多数Debug 程序识别； 
        U-Boot.bin ——二进制文件，纯粹的U-Boot 

        二进制执行代码，不保存ELF 格式和调试信息。 这个文件一般用于烧录到用户开发板中；U-Boot .srec ——Motorola S-Record格式，可以通过串行口下载到开发板中。 

        测试与应用 
        1) 测试 
        利用编制好的Flash烧写程序，通过JTAG口将生成的二进制文件U-Boot。bin烧入Flash的零地址。 烧录成功后，拔掉JTAG调试线并复位开发板，从Minicom终端输出如下信息： 

        U-Boot 1.1.2 (Jul 20 2005-09 ：34 ：21) 
        U-Boot code ： 33F00000-> 33F1952C BSS：-> 33F1D870         
        RAM Configuration ： 
        Bank # 0 ： 30000000 64 MB 
        Flash Memory Start 0x0000000 
        Device ID of the Flash is 18 
        Flash ： 16 MB 
        Write 18 to Watchdog and it is 18 now 
        In ： serial 
        Out ： serial 
        Err ： serial 
        SMDK2410 # 

         串口输出的以上信息表明，CPU和串口已正常工作。通过U-Boot提供的命令flinfo和mtest可以测试Flash和RAM。经过测试，可以正确 地读出Flash信息及读写RAM，表明Flash 和DRAM 已正确初始化。 用tftp命令传输宿主机tftpboot目录下任一小文件到RAM成功，说明网卡芯片也成功驱动。 

        2) 简单应用 
        U -Boot的主要作用是用来引导内核。因此，通过U-Boot引导一个特定的内核，可以进一步测试其移植的稳定性。 而使用U-Boot引导内核有两种不同的方法。第一种方法是直接将内核映象文件和根文件系统烧写入Flash，使用此方法，U-Boot在启动时将 Flash中的内核映象及根文件系统读入RAM指定位置并从同一位置启动内核。 第二种方法是将内核映象文件和根文件系统下载至RAM中直接启动(而不是从Flash中读入RAM) ，此种方法不需要烧写Flash。笔者为了减少烧写Flash的次数，在本文中采用第二种方法，其步骤如下： 

        SMDK2410 # tftp 30008000 zImage 
        SMDK2410 # tftp 30800000 ramdisk.Image.gz         
        SMDK2410 # go 30008000 

         上述指令执行的过程中，未出现异常，内核成功启动，并最终进入Shell提示符“ # ”。在Shell提示符下输入内核编译时定制的各个命令，均可以正常运行。另外编写简单C程序，并用交叉编译器编译之，最终生成的可执行文件能够在开发板 上正常运行。上述事实说明内核经过U-Boot引导已稳定运行在开发板上。此次应用，进一步验证了U-Boot移植的稳定性。至此，移植工作告一段落。 

        结　语 

         目前，笔者移植的U-Boot已经能稳定地运行在开发板上，这使得Linux内核的调试脱离了BDM调试器，节约了大量的开发时间，大大提高了效率，是对 后续嵌入式开发的有力支持。 当然，U-Boot只是一款好用的BootLoader，嵌入式Linux的开发存在很多技术细节，只有根据实际情况不断修改、调试、总结，才能获得更大 的成功。

Jonathan Bartlett/A>
技术总监, New Media Worx
2004 年 11 月 29 日

本文将对 Linux™ 程序员可以使用的内存管理技术进行概述，虽然关注的重点是 C 语言，但同样也适用于其他语言。文中将为您提供如何管理内存的细节，然后将进一步展示如何手工管理内存，如何使用引用计数或者内存池来半手工地管理内存，以及如何使用垃圾收集自动管理内存。/BLOCKQUOTE>

为什么必须管理内存
内存管理是计算机编程最为基本的领域之一。在很多脚本语言中，您不必担心内存是如何管理的，这并不能使得内存管理的重要性有一点点降低。对实际编程来说，理解您的内存管理器的能力与局限性至关重要。在大部分系统语言中，比如 C 和 C++，您必须进行内存管理。本文将介绍手工的、半手工的以及自动的内存管理实践的基本概念。

追溯到在 Apple II 上进行汇编语言编程的时代，那时内存管理还不是个大问题。您实际上在运行整个系统。系统有多少内存，您就有多少内存。您甚至不必费心思去弄明白它有多少内存，因为每一台机器的内存数量都相同。所以，如果内存需要非常固定，那么您只需要选择一个内存范围并使用它即可。

不过，即使是在这样一个简单的计算机中，您也会有问题，尤其是当您不知道程序的每个部分将需要多少内存时。如果您的空间有限，而内存需求是变化的，那么您需要一些方法来满足这些需求：

• 确定您是否有足够的内存来处理数据。
• 从可用的内存中获取一部分内存。
• 向可用内存池（pool）中返回部分内存，以使其可以由程序的其他部分或者其他程序使用。

实现这些需求的程序库称为 分配程序（allocators），因为它们负责分配和回收内存。程序的动态性越强，内存管理就越重要，您的内存分配程序的选择也就更重要。让我们来了解可用于内存管理的不同方法，它们的好处与不足，以及它们最适用的情形。

C 风格的内存分配程序
C 编程语言提供了两个函数来满足我们的三个需求：

• malloc：该函数分配给定的字节数，并返回一个指向它们的指针。如果没有足够的可用内存，那么它返回一个空指针。
• free：该函数获得指向由 malloc 分配的内存片段的指针，并将其释放，以便以后的程序或操作系统使用（实际上，一些 malloc 实现只能将内存归还给程序，而无法将内存归还给操作系统）。

物理内存和虚拟内存
要理解内存在程序中是如何分配的，首先需要理解如何将内存从操作系统分配给程序。计算机上的每一个进程都认为自己可以访问所有的物理内存。显然，由于同时在运行多个程序，所以每个进程不可能拥有全部内存。实际上，这些进程使用的是 虚拟内存。

只是作为一个例子，让我们假定您的程序正在访问地址为 629 的内存。不过，虚拟内存系统不需要将其存储在位置为 629 的 RAM 中。实际上，它甚至可以不在 RAM 中 —— 如果物理 RAM 已经满了，它甚至可能已经被转移到硬盘上！由于这类地址不必反映内存所在的物理位置，所以它们被称为虚拟内存。操作系统维持着一个虚拟地址到物理地址的转换的表，以便计算机硬件可以正确地响应地址请求。并且，如果地址在硬盘上而不是在 RAM 中，那么操作系统将暂时停止您的进程，将其他内存转存到硬盘中，从硬盘上加载被请求的内存，然后再重新启动您的进程。这样，每个进程都获得了自己可以使用的地址空间，可以访问比您物理上安装的内存更多的内存。

在 32-位 x86 系统上，每一个进程可以访问 4 GB 内存。现在，大部分人的系统上并没有 4 GB 内存，即使您将 swap 也算上， 每个进程所使用的内存也肯定少于 4 GB。因此，当加载一个进程时，它会得到一个取决于某个称为 系统中断点（system break）的特定地址的初始内存分配。该地址之后是未被映射的内存 —— 用于在 RAM 或者硬盘中没有分配相应物理位置的内存。因此，如果一个进程运行超出了它初始分配的内存，那么它必须请求操作系统“映射进来（map in）”更多的内存。（映射是一个表示一一对应关系的数学术语 —— 当内存的虚拟地址有一个对应的物理地址来存储内存内容时，该内存将被映射。）

基于 UNIX 的系统有两个可映射到附加内存中的基本系统调用：

• brk：brk() 是一个非常简单的系统调用。还记得系统中断点吗？该位置是进程映射的内存边界。 brk() 只是简单地将这个位置向前或者向后移动，就可以向进程添加内存或者从进程取走内存。
• mmap：mmap()，或者说是“内存映像”，类似于 brk()，但是更为灵活。首先，它可以映射任何位置的内存，而不单单只局限于进程。其次，它不仅可以将虚拟地址映射到物理的 RAM 或者 swap，它还可以将它们映射到文件和文件位置，这样，读写内存将对文件中的数据进行读写。不过，在这里，我们只关心 mmap 向进程添加被映射的内存的能力。 munmap() 所做的事情与 mmap() 相反。

如您所见， brk() 或者 mmap() 都可以用来向我们的进程添加额外的虚拟内存。在我们的例子中将使用 brk()，因为它更简单，更通用。

实现一个简单的分配程序
如果您曾经编写过很多 C 程序，那么您可能曾多次使用过 malloc() 和 free()。不过，您可能没有用一些时间去思考它们在您的操作系统中是如何实现的。本节将向您展示 malloc 和 free 的一个最简化实现的代码，来帮助说明管理内存时都涉及到了哪些事情。

要试着运行这些示例，需要先 复制本代码清单，并将其粘贴到一个名为 malloc.c 的文件中。接下来，我将一次一个部分地对该清单进行解释。

在大部分操作系统中，内存分配由以下两个简单的函数来处理：

• void *malloc(long numbytes)：该函数负责分配 numbytes 大小的内存，并返回指向第一个字节的指针。
• void free(void *firstbyte)：如果给定一个由先前的 malloc 返回的指针，那么该函数会将分配的空间归还给进程的“空闲空间”。

malloc_init 将是初始化内存分配程序的函数。它要完成以下三件事：将分配程序标识为已经初始化，找到系统中最后一个有效内存地址，然后建立起指向我们管理的内存的指针。这三个变量都是全局变量：

清单 1. 我们的简单分配程序的全局变量

int has_initialized = 0; void *managed_memory_start; void *last_valid_address;

如前所述，被映射的内存的边界（最后一个有效地址）常被称为系统中断点或者 当前中断点。在很多 UNIX® 系统中，为了指出当前系统中断点，必须使用 sbrk(0) 函数。 sbrk 根据参数中给出的字节数移动当前系统中断点，然后返回新的系统中断点。使用参数 0 只是返回当前中断点。这里是我们的 malloc 初始化代码，它将找到当前中断点并初始化我们的变量：

清单 2. 分配程序初始化函数

/* Include the sbrk function */ #include <unistd.h> void malloc_init() { /* grab the last valid address from the OS */ last_valid_address = sbrk(0); /* we don't have any memory to manage yet, so *just set the beginning to be last_valid_address */ managed_memory_start = last_valid_address; /* Okay, we're initialized and ready to go */ has_initialized = 1; }

现在，为了完全地管理内存，我们需要能够追踪要分配和回收哪些内存。在对内存块进行了 free 调用之后，我们需要做的是诸如将它们标记为未被使用的等事情，并且，在调用 malloc 时，我们要能够定位未被使用的内存块。因此， malloc 返回的每块内存的起始处首先要有这个结构：

清单 3. 内存控制块结构定义

struct mem_control_block { int is_available; int size; };

现在，您可能会认为当程序调用 malloc 时这会引发问题 —— 它们如何知道这个结构？答案是它们不必知道；在返回指针之前，我们会将其移动到这个结构之后，把它隐藏起来。这使得返回的指针指向没有用于任何其他用途的内存。那样，从调用程序的角度来看，它们所得到的全部是空闲的、开放的内存。然后，当通过 free() 将该指针传递回来时，我们只需要倒退几个内存字节就可以再次找到这个结构。

在讨论分配内存之前，我们将先讨论释放，因为它更简单。为了释放内存，我们必须要做的惟一一件事情就是，获得我们给出的指针，回退 sizeof(struct mem_control_block) 个字节，并将其标记为可用的。这里是对应的代码：

清单 4. 解除分配函数

void free(void *firstbyte) { struct mem_control_block *mcb; /* Backup from the given pointer to find the * mem_control_block */ mcb = firstbyte - sizeof(struct mem_control_block); /* Mark the block as being available */ mcb->is_available = 1; /* That's It! We're done. */ return; }

如您所见，在这个分配程序中，内存的释放使用了一个非常简单的机制，在固定时间内完成内存释放。分配内存稍微困难一些。以下是该算法的略述：

清单 5. 主分配程序的伪代码

1. If our allocator has not been initialized, initialize it. 2. Add sizeof(struct mem_control_block) to the size requested. 3. start at managed_memory_start. 4. Are we at last_valid address? 5. If we are: A. We didn't find any existing space that was large enough -- ask the operating system for more and return that. 6. Otherwise: A. Is the current space available (check is_available from the mem_control_block)? B. If it is: i) Is it large enough (check "size" from the mem_control_block)? ii) If so: a. Mark it as unavailable b. Move past mem_control_block and return the pointer iii) Otherwise: a. Move forward "size" bytes b. Go back go step 4 C. Otherwise: i) Move forward "size" bytes ii) Go back to step 4

我们主要使用连接的指针遍历内存来寻找开放的内存块。这里是代码：

清单 6. 主分配程序

void *malloc(long numbytes) { /* Holds where we are looking in memory */ void *current_location; /* This is the same as current_location, but cast to a * memory_control_block */ struct mem_control_block *current_location_mcb; /* This is the memory location we will return. It will * be set to 0 until we find something suitable */ void *memory_location; /* Initialize if we haven't already done so */ if(! has_initialized) { malloc_init(); } /* The memory we search for has to include the memory * control block, but the users of malloc don't need * to know this, so we'll just add it in for them. */ numbytes = numbytes + sizeof(struct mem_control_block); /* Set memory_location to 0 until we find a suitable * location */ memory_location = 0; /* Begin searching at the start of managed memory */ current_location = managed_memory_start; /* Keep going until we have searched all allocated space */ while(current_location != last_valid_address) { /* current_location and current_location_mcb point * to the same address. However, current_location_mcb * is of the correct type, so we can use it as a struct. * current_location is a void pointer so we can use it * to calculate addresses. */ current_location_mcb = (struct mem_control_block *)current_location; if(current_location_mcb->is_available) { if(current_location_mcb->size >= numbytes) { /* Woohoo! We've found an open, * appropriately-size location. */ /* It is no longer available */ current_location_mcb->is_available = 0; /* We own it */ memory_location = current_location; /* Leave the loop */ break; } } /* If we made it here, it's because the Current memory * block not suitable; move to the next one */ current_location = current_location + current_location_mcb->size; } /* If we still don't have a valid location, we'll * have to ask the operating system for more memory */ if(! memory_location) { /* Move the program break numbytes further */ sbrk(numbytes); /* The new memory will be where the last valid * address left off */ memory_location = last_valid_address; /* We'll move the last valid address forward * numbytes */ last_valid_address = last_valid_address + numbytes; /* We need to initialize the mem_control_block */ current_location_mcb = memory_location; current_location_mcb->is_available = 0; current_location_mcb->size = numbytes; } /* Now, no matter what (well, except for error conditions), * memory_location has the address of the memory, including * the mem_control_block */ /* Move the pointer past the mem_control_block */ memory_location = memory_location + sizeof(struct mem_control_block); /* Return the pointer */ return memory_location; }

这就是我们的内存管理器。现在，我们只需要构建它，并在程序中使用它即可。

运行下面的命令来构建 malloc 兼容的分配程序（实际上，我们忽略了 realloc() 等一些函数，不过， malloc() 和 free() 才是最主要的函数）：

清单 7. 编译分配程序

gcc -shared -fpic malloc.c -o malloc.so

该程序将生成一个名为 malloc.so 的文件，它是一个包含有我们的代码的共享库。

在 UNIX 系统中，现在您可以用您的分配程序来取代系统的 malloc()，做法如下：

清单 8. 替换您的标准的 malloc

LD_PRELOAD=/path/to/malloc.so export LD_PRELOAD

LD_PRELOAD 环境变量使动态链接器在加载任何可执行程序之前，先加载给定的共享库的符号。它还为特定库中的符号赋予优先权。因此，从现在起，该会话中的任何应用程序都将使用我们的 malloc()，而不是只有系统的应用程序能够使用。有一些应用程序不使用 malloc()，不过它们是例外。其他使用 realloc() 等其他内存管理函数的应用程序，或者错误地假定 malloc() 内部行为的那些应用程序，很可能会崩溃。ash shell 似乎可以使用我们的新 malloc() 很好地工作。

如果您想确保 malloc() 正在被使用，那么您应该通过向函数的入口点添加 write() 调用来进行测试。

我们的内存管理器在很多方面都还存在欠缺，但它可以有效地展示内存管理需要做什么事情。它的某些缺点包括：

• 由于它对系统中断点（一个全局变量）进行操作，所以它不能与其他分配程序或者 mmap 一起使用。
• 当分配内存时，在最坏的情形下，它将不得不遍历 全部进程内存；其中可能包括位于硬盘上的很多内存，这意味着操作系统将不得不花时间去向硬盘移入数据和从硬盘中移出数据。
• 没有很好的内存不足处理方案（ malloc 只假定内存分配是成功的）。
• 它没有实现很多其他的内存函数，比如 realloc()。
• 由于 sbrk() 可能会交回比我们请求的更多的内存，所以在堆（heap）的末端会遗漏一些内存。
• 虽然 is_available 标记只包含一位信息，但它要使用完整的 4-字节 的字。
• 分配程序不是线程安全的。
• 分配程序不能将空闲空间拼合为更大的内存块。
• 分配程序的过于简单的匹配算法会导致产生很多潜在的内存碎片。
• 我确信还有很多其他问题。这就是为什么它只是一个例子!

其他 malloc 实现
malloc() 的实现有很多，这些实现各有优点与缺点。在设计一个分配程序时，要面临许多需要折衷的选择，其中包括：

• 分配的速度。
• 回收的速度。
• 有线程的环境的行为。
• 内存将要被用光时的行为。
• 局部缓存。
• 簿记（Bookkeeping）内存开销。
• 虚拟内存环境中的行为。
• 小的或者大的对象。
• 实时保证。

每一个实现都有其自身的优缺点集合。在我们的简单的分配程序中，分配非常慢，而回收非常快。另外，由于它在使用虚拟内存系统方面较差，所以它最适于处理大的对象。

还有其他许多分配程序可以使用。其中包括：

• Doug Lea Malloc：Doug Lea Malloc 实际上是完整的一组分配程序，其中包括 Doug Lea 的原始分配程序，GNU libc 分配程序和 ptmalloc。 Doug Lea 的分配程序有着与我们的版本非常类似的基本结构，但是它加入了索引，这使得搜索速度更快，并且可以将多个没有被使用的块组合为一个大的块。它还支持缓存，以便更快地再次使用最近释放的内存。 ptmalloc 是 Doug Lea Malloc 的一个扩展版本，支持多线程。在本文后面的 参考资料部分中，有一篇描述 Doug Lea 的 Malloc 实现的文章。
• BSD Malloc：BSD Malloc 是随 4.2 BSD 发行的实现，包含在 FreeBSD 之中，这个分配程序可以从预先确实大小的对象构成的池中分配对象。它有一些用于对象大小的 size 类，这些对象的大小为 2 的若干次幂减去某一常数。所以，如果您请求给定大小的一个对象，它就简单地分配一个与之匹配的 size 类。这样就提供了一个快速的实现，但是可能会浪费内存。在 参考资料部分中，有一篇描述该实现的文章。
• Hoard：编写 Hoard 的目标是使内存分配在多线程环境中进行得非常快。因此，它的构造以锁的使用为中心，从而使所有进程不必等待分配内存。它可以显著地加快那些进行很多分配和回收的多线程进程的速度。在 参考资料部分中，有一篇描述该实现的文章。

众多可用的分配程序中最有名的就是上述这些分配程序。如果您的程序有特别的分配需求，那么您可能更愿意编写一个定制的能匹配您的程序内存分配方式的分配程序。不过，如果不熟悉分配程序的设计，那么定制分配程序通常会带来比它们解决的问题更多的问题。要获得关于该主题的适当的介绍，请参阅 Donald Knuth 撰写的 The Art of Computer Programming Volume 1: Fundamental Algorithms 中的第 2.5 节“Dynamic Storage Allocation”（请参阅 参考资料中的链接）。它有点过时，因为它没有考虑虚拟内存环境，不过大部分算法都是基于前面给出的函数。

在 C++ 中，通过重载 operator new()，您可以以每个类或者每个模板为单位实现自己的分配程序。在 Andrei Alexandrescu 撰写的 Modern C++ Design 的第 4 章（“Small Object Allocation”）中，描述了一个小对象分配程序（请参阅 参考资料中的链接）。

基于 malloc() 的内存管理的缺点
不只是我们的内存管理器有缺点，基于 malloc() 的内存管理器仍然也有很多缺点，不管您使用的是哪个分配程序。对于那些需要保持长期存储的程序使用 malloc() 来管理内存可能会非常令人失望。如果您有大量的不固定的内存引用，经常难以知道它们何时被释放。生存期局限于当前函数的内存非常容易管理，但是对于生存期超出该范围的内存来说，管理内存则困难得多。而且，关于内存管理是由进行调用的程序还是由被调用的函数来负责这一问题，很多 API 都不是很明确。

因为管理内存的问题，很多程序倾向于使用它们自己的内存管理规则。C++ 的异常处理使得这项任务更成问题。有时好像致力于管理内存分配和清理的代码比实际完成计算任务的代码还要多！因此，我们将研究内存管理的其他选择。

半自动内存管理策略

引用计数
引用计数是一种 半自动（semi-automated）的内存管理技术，这表示它需要一些编程支持，但是它不需要您确切知道某一对象何时不再被使用。引用计数机制为您完成内存管理任务。

在引用计数中，所有共享的数据结构都有一个域来包含当前活动“引用”结构的次数。当向一个程序传递一个指向某个数据结构指针时，该程序会将引用计数增加 1。实质上，您是在告诉数据结构，它正在被存储在多少个位置上。然后，当您的进程完成对它的使用后，该程序就会将引用计数减少 1。结束这个动作之后，它还会检查计数是否已经减到零。如果是，那么它将释放内存。

这样做的好处是，您不必追踪程序中某个给定的数据结构可能会遵循的每一条路径。每次对其局部的引用，都将导致计数的适当增加或减少。这样可以防止在使用数据结构时释放该结构。不过，当您使用某个采用引用计数的数据结构时，您必须记得运行引用计数函数。另外，内置函数和第三方的库不会知道或者可以使用您的引用计数机制。引用计数也难以处理发生循环引用的数据结构。

要实现引用计数，您只需要两个函数 —— 一个增加引用计数，一个减少引用计数并当计数减少到零时释放内存。

一个示例引用计数函数集可能看起来如下所示：

清单 9. 基本的引用计数函数

/* Structure Definitions*/ /* Base structure that holds a refcount */ struct refcountedstruct { int refcount; } /* All refcounted structures must mirror struct * refcountedstruct for their first variables */ /* Refcount maintenance functions */ /* Increase reference count */ void REF(void *data) { struct refcountedstruct *rstruct; rstruct = (struct refcountedstruct *) data; rstruct->refcount++; } /* Decrease reference count */ void UNREF(void *data) { struct refcountedstruct *rstruct; rstruct = (struct refcountedstruct *) data; rstruct->refcount--; /* Free the structure if there are no more users */ if(rstruct->refcount == 0) { free(rstruct); } }

REF 和 UNREF 可能会更复杂，这取决于您想要做的事情。例如，您可能想要为多线程程序增加锁，那么您可能想扩展 refcountedstruct，使它同样包含一个指向某个在释放内存之前要调用的函数的指针（类似于面向对象语言中的析构函数 —— 如果您的结构中包含这些指针，那么这是 必需的）。

当使用 REF 和 UNREF 时，您需要遵守这些指针的分配规则：

• UNREF 分配前左端指针（left-hand-side pointer）指向的值。
• REF 分配后左端指针（left-hand-side pointer）指向的值。

在传递使用引用计数的结构的函数中，函数需要遵循以下这些规则：

• 在函数的起始处 REF 每一个指针。
• 在函数的结束处 UNREF 第一个指针。

以下是一个使用引用计数的生动的代码示例：

清单 10. 使用引用计数的示例

/* EXAMPLES OF USAGE */ /* Data type to be refcounted */ struct mydata { int refcount; /* same as refcountedstruct */ int datafield1; /* Fields specific to this struct */ int datafield2; /* other declarations would go here as appropriate */ }; /* Use the functions in code */ void dosomething(struct mydata *data) { REF(data); /* Process data */ /* when we are through */ UNREF(data); } struct mydata *globalvar1; /* Note that in this one, we don't decrease the * refcount since we are maintaining the reference * past the end of the function call through the * global variable */ void storesomething(struct mydata *data) { REF(data); /* passed as a parameter */ globalvar1 = data; REF(data); /* ref because of Assignment */ UNREF(data); /* Function finished */ }

由于引用计数是如此简单，大部分程序员都自已去实现它，而不是使用库。不过，它们依赖于 malloc 和 free 等低层的分配程序来实际地分配和释放它们的内存。

在 Perl 等高级语言中，进行内存管理时使用引用计数非常广泛。在这些语言中，引用计数由语言自动地处理，所以您根本不必担心它，除非要编写扩展模块。由于所有内容都必须进行引用计数，所以这会对速度产生一些影响，但它极大地提高了编程的安全性和方便性。以下是引用计数的益处：

• 实现简单。
• 易于使用。
• 由于引用是数据结构的一部分，所以它有一个好的缓存位置。

不过，它也有其不足之处：

• 要求您永远不要忘记调用引用计数函数。
• 无法释放作为循环数据结构的一部分的结构。
• 减缓几乎每一个指针的分配。
• 尽管所使用的对象采用了引用计数，但是当使用异常处理（比如 try 或 setjmp()/ longjmp()）时，您必须采取其他方法。
• 需要额外的内存来处理引用。
• 引用计数占用了结构中的第一个位置，在大部分机器中最快可以访问到的就是这个位置。
• 在多线程环境中更慢也更难以使用。

C++ 可以通过使用 智能指针（smart pointers）来容忍程序员所犯的一些错误，智能指针可以为您处理引用计数等指针处理细节。不过，如果不得不使用任何先前的不能处理智能指针的代码（比如对 C 库的联接），实际上，使用它们的后果通实比不使用它们更为困难和复杂。因此，它通常只是有益于纯 C++ 项目。如果您想使用智能指针，那么您实在应该去阅读 Alexandrescu 撰写的 Modern C++ Design 一书中的“Smart Pointers”那一章。

内存池
内存池是另一种半自动内存管理方法。内存池帮助某些程序进行自动内存管理，这些程序会经历一些特定的阶段，而且每个阶段中都有分配给进程的特定阶段的内存。例如，很多网络服务器进程都会分配很多针对每个连接的内存 —— 内存的最大生存期限为当前连接的存在期。Apache 使用了池式内存（pooled memory），将其连接拆分为各个阶段，每个阶段都有自己的内存池。在结束每个阶段时，会一次释放所有内存。

在池式内存管理中，每次内存分配都会指定内存池，从中分配内存。每个内存池都有不同的生存期限。在 Apache 中，有一个持续时间为服务器存在期的内存池，还有一个持续时间为连接的存在期的内存池，以及一个持续时间为请求的存在期的池，另外还有其他一些内存池。因此，如果我的一系列函数不会生成比连接持续时间更长的数据，那么我就可以完全从连接池中分配内存，并知道在连接结束时，这些内存会被自动释放。另外，有一些实现允许注册 清除函数（cleanup functions），在清除内存池之前，恰好可以调用它，来完成在内存被清理前需要完成的其他所有任务（类似于面向对象中的析构函数）。

要在自己的程序中使用池，您既可以使用 GNU libc 的 obstack 实现，也可以使用 Apache 的 Apache Portable Runtime。GNU obstack 的好处在于，基于 GNU 的 Linux 发行版本中默认会包括它们。Apache Portable Runtime 的好处在于它有很多其他工具，可以处理编写多平台服务器软件所有方面的事情。要深入了解 GNU obstack 和 Apache 的池式内存实现，请参阅 参考资料部分中指向这些实现的文档的链接。

下面的假想代码列表展示了如何使用 obstack：

清单 11. obstack 的示例代码

#include <obstack.h> #include <stdlib.h> /* Example code listing for using obstacks */ /* Used for obstack macros (xmalloc is a malloc function that exits if memory is exhausted */ #define obstack_chunk_alloc xmalloc #define obstack_chunk_free free /* Pools */ /* Only permanent allocations should go in this pool */ struct obstack *global_pool; /* This pool is for per-connection data */ struct obstack *connection_pool; /* This pool is for per-request data */ struct obstack *request_pool; void allocation_failed() { exit(1); } int main() { /* Initialize Pools */ global_pool = (struct obstack *) xmalloc (sizeof (struct obstack)); obstack_init(global_pool); connection_pool = (struct obstack *) xmalloc (sizeof (struct obstack)); obstack_init(connection_pool); request_pool = (struct obstack *) xmalloc (sizeof (struct obstack)); obstack_init(request_pool); /* Set the error handling function */ obstack_alloc_failed_handler = &allocation_failed; /* Server main loop */ while(1) { wait_for_connection(); /* We are in a connection */ while(more_requests_available()) { /* Handle request */ handle_request(); /* Free all of the memory allocated * in the request pool */ obstack_free(request_pool, NULL); } /* We're finished with the connection, time * to free that pool */ obstack_free(connection_pool, NULL); } } int handle_request() { /* Be sure that all object allocations are allocated * from the request pool */ int bytes_i_need = 400; void *data1 = obstack_alloc(request_pool, bytes_i_need); /* Do stuff to process the request */ /* return */ return 0; }

基本上，在操作的每一个主要阶段结束之后，这个阶段的 obstack 会被释放。不过，要注意的是，如果一个过程需要分配持续时间比当前阶段更长的内存，那么它也可以使用更长期限的 obstack，比如连接或者全局内存。传递给 obstack_free() 的 NULL 指出它应该释放 obstack 的全部内容。可以用其他的值，但是它们通常不怎么实用。

使用池式内存分配的益处如下所示：

• 应用程序可以简单地管理内存。
• 内存分配和回收更快，因为每次都是在一个池中完成的。分配可以在 O(1) 时间内完成，释放内存池所需时间也差不多（实际上是 O(n) 时间，不过在大部分情况下会除以一个大的因数，使其变成 O(1)）。
• 可以预先分配错误处理池（Error-handling pools），以便程序在常规内存被耗尽时仍可以恢复。
• 有非常易于使用的标准实现。

池式内存的缺点是：

• 内存池只适用于操作可以分阶段的程序。
• 内存池通常不能与第三方库很好地合作。
• 如果程序的结构发生变化，则不得不修改内存池，这可能会导致内存管理系统的重新设计。
• 您必须记住需要从哪个池进行分配。另外，如果在这里出错，就很难捕获该内存池。

垃圾收集
垃圾收集（Garbage collection）是全自动地检测并移除不再使用的数据对象。垃圾收集器通常会在当可用内存减少到少于一个具体的阈值时运行。通常，它们以程序所知的可用的一组“基本”数据 —— 栈数据、全局变量、寄存器 —— 作为出发点。然后它们尝试去追踪通过这些数据连接到每一块数据。收集器找到的都是有用的数据；它没有找到的就是垃圾，可以被销毁并重新使用这些无用的数据。为了有效地管理内存，很多类型的垃圾收集器都需要知道数据结构内部指针的规划，所以，为了正确运行垃圾收集器，它们必须是语言本身的一部分。

收集器的类型

• 复制（copying）： 这些收集器将内存存储器分为两部分，只允许数据驻留在其中一部分上。它们定时地从“基本”的元素开始将数据从一部分复制到另一部分。内存新近被占用的部分现在成为活动的，另一部分上的所有内容都认为是垃圾。另外，当进行这项复制操作时，所有指针都必须被更新为指向每个内存条目的新位置。因此，为使用这种垃圾收集方法，垃圾收集器必须与编程语言集成在一起。
• 标记并清理（Mark and sweep）：每一块数据都被加上一个标签。不定期的，所有标签都被设置为 0，收集器从“基本”的元素开始遍历数据。当它遇到内存时，就将标签标记为 1。最后没有被标记为 1 的所有内容都认为是垃圾，以后分配内存时会重新使用它们。
• 增量的（Incremental）：增量垃圾收集器不需要遍历全部数据对象。因为在收集期间的突然等待，也因为与访问所有当前数据相关的缓存问题（所有内容都不得不被页入（page-in）），遍历所有内存会引发问题。增量收集器避免了这些问题。
• 保守的（Conservative）：保守的垃圾收集器在管理内存时不需要知道与数据结构相关的任何信息。它们只查看所有数据类型，并假定它们 可以全部都是指针。所以，如果一个字节序列可以是一个指向一块被分配的内存的指针，那么收集器就将其标记为正在被引用。有时没有被引用的内存会被收集，这样会引发问题，例如，如果一个整数域中包含一个值，该值是已分配内存的地址。不过，这种情况极少发生，而且它只会浪费少量内存。保守的收集器的优势是，它们可以与任何编程语言相集成。

Hans Boehm 的保守垃圾收集器是可用的最流行的垃圾收集器之一，因为它是免费的，而且既是保守的又是增量的，可以使用 --enable-redirect-malloc 选项来构建它，并且可以将它用作系统分配程序的简易替代者（drop-in replacement）（用 malloc/ free 代替它自己的 API）。实际上，如果这样做，您就可以使用与我们在示例分配程序中所使用的相同的 LD_PRELOAD 技巧，在系统上的几乎任何程序中启用垃圾收集。如果您怀疑某个程序正在泄漏内存，那么您可以使用这个垃圾收集器来控制进程。在早期，当 Mozilla 严重地泄漏内存时，很多人在其中使用了这项技术。这种垃圾收集器既可以在 Windows® 下运行，也可以在 UNIX 下运行。

垃圾收集的一些优点：

• 您永远不必担心内存的双重释放或者对象的生命周期。
• 使用某些收集器，您可以使用与常规分配相同的 API。

其缺点包括：

• 使用大部分收集器时，您都无法干涉何时释放内存。
• 在多数情况下，垃圾收集比其他形式的内存管理更慢。
• 垃圾收集错误引发的缺陷难于调试。
• 如果您忘记将不再使用的指针设置为 null，那么仍然会有内存泄漏。

结束语
一切都需要折衷：性能、易用、易于实现、支持线程的能力等，这里只列出了其中的一些。为了满足项目的要求，有很多内存管理模式可以供您使用。每种模式都有大量的实现，各有其优缺点。对很多项目来说，使用编程环境默认的技术就足够了，不过，当您的项目有特殊的需要时，了解可用的选择将会有帮助。下表对比了本文中涉及的内存管理策略。

表 1. 内存分配策略的对比

策略	分配速度	回收速度	局部缓存	易用性	通用性	实时可用	SMP 线程友好
定制分配程序	取决于实现	取决于实现	取决于实现	很难	无	取决于实现	取决于实现
简单分配程序	内存使用少时较快	很快	差	容易	高	否	否
GNU malloc	中	快	中	容易	高	否	中
Hoard	中	中	中	容易	高	否	是
引用计数	N/A	N/A	非常好	中	中	是（取决于 malloc 实现）	取决于实现
池	中	非常快	极好	中	中	是（取决于 malloc 实现）	取决于实现
垃圾收集	中（进行收集时慢）	中	差	中	中	否	几乎不
增量垃圾收集	中	中	中	中	中	否	几乎不
增量保守垃圾收集	中	中	中	容易	高	否	几乎不

数字代表计算机的语言。您的计算机如何使用字母来与程序和其他计算机进行通信？一种方法是把字符集 （字符集：一组共享一些关系的字母、数字和其他字符。例如，标准 ASCII 字符集包括字母、数字、符号和组成 ASCII 代码方案的控制代码。）转换为数字形式。

在 20 世纪 60 年代，标准化的需要带来了美国标准信息交换码 (ASCII) （ASCII：将英语中的字符表示为数字的代码。为每个字符分配一个介于 0 到 127 之间的数字。大多数计算机都使用 ASCII 表示文本和在计算机之间传输数据。）（发音为 ask-kee）。ASCII 表包含 128 个数字，分配给了相应的字符 （字符：字母、数字、标点或符号。）。ASCII 为计算机提供了一种存储数据和与其他计算机及程序交换数据的方式。

ASCII 格式的文本不包含像黑体、斜体或字体等格式信息。当您使用 Microsoft 记事本或把文件作为纯文本保存在 Microsoft Office Word 中时，就会使用 ASCII。您可能读到过招聘广告，公司要求提供 ASCII 格式的简历。这意味着无论您是用电子邮件、传真或打印文本发送简历，公司希望您的简历中不含任何特殊格式。大公司可能用光学字符识别 (OCR) （OCR：将文本图像（如扫描的文档）转换为实际的文本字符。也称为文本识别。） 扫描软件来扫描简历和 ASCII 格式的文本。

在文档中插入 ASCII 字符

注释  该功能需要 Excel、FrontPage、InfoPath、OneNote、Outlook、PowerPoint、Project、Publisher、Word 或 Visio。

除了在键盘上键入字符外，您也可以使用该符号的字符代码作为键盘快捷键。例如，要插入度数符号，在按住 ALT 的同时在数字键盘上键入 0176。

• 要从下面的图表中插入 ASCII 字符，在按住 ALT 的同时键入等价的十进制数字。

  例如，要插入度数符号，在按住 ALT 的同时在数字键盘上键入 0176。

  注释  必须使用数字键盘来键入数字，而不是键盘。如果您的键盘需要打开 Num Lock 键才能在数字键盘上键入数字，请务必打开它。

ASCII 打印字符

数字 32–126 分配给了能在键盘上找到的字符，当您查看或打印文档时就会出现。数字 127 代表 DELETE 命令。

ASCII 打印字符表

扩展 ASCII 打印字符

扩展的 ASCII 字符满足了对更多字符的需求。扩展的 ASCII 包含 ASCII 中已有的 128 个字符（数字 0–32 显示在下图中），又增加了 128 个字符，总共是 256 个。即使有了这些更多的字符，许多语言还是包含无法压缩到 256 个字符中的符号。因此，出现了一些 ASCII 的变体来囊括地区性字符和符号。

例如，许多软件程序把 ASCII 表（又称作 ISO 8859-1）用于北美、西欧、澳大利亚和非洲的语言。

扩展的 ASCII 打印字符表

ASCII 非打印控制字符

ASCII 表上的数字 0–31 分配给了控制字符，用于控制像打印机等一些外围设备。例如，12 代表换页/新页功能。此命令指示打印机跳到下一页的开头。

ASCII 非打印控制字符表

ASCII 之外

另一个更新的字符表称为 Unicode （Unicode：Unicode Consortium 开发的一种字符编码标准。该标准采用多（于一）个字节代表每一字符，实现了使用单个字符集代表世界上几乎所有书面语言。）。 因为 Unicode 表大得多，它可以表示 65,536 个字符，而 ASCII 表只能表示 128 个字符，扩展的 ASCII 表也只能表示 256 个字符。这一更大的容量使不同语言的大多数字符都能包含在同一个字符集中。

* 分布式网络（ Scatternet ）：是由多个独立、非同步的微微网形成的。

* 主设备（ Master unit ） : 在微微网中，如果某台设备的时钟和跳频序列用于同步其他设备，则称它为主设备。

* 从设备（ Slave unit ）：非主设备的设备均为从设备。

* MAC 地址 (MAC address) ：用 3 比特表示的地址，用于区分微微网中的设备。

* 休眠设备（ Parked units ）：在微微网中只参与同步，但没有 MAC 地址的设备。

* 监听及保持方式（ Sniff and Hold mode ）：指微微网中从设备的两种低功耗工作方式。

  2． 蓝牙技术工作原理

 1） 蓝牙的无线通信技术特征

蓝牙的无线通信技术采用每秒 1600 次的快跳频和短分组技术，减少干扰和信号衰落，保证传输的可靠性； 以时分方式进行全双工通信，传输速率设计为 1MHz ； 采用前向纠错 (FEC) 编码技术，减少远距离传输时的随机噪声影响； 其工作频段为非授权的工业、医学、科学频段（ 2.4GHz 的 ISM 频段），保证能在全球范围内使用这种无线通用接口和通信技术； 话音采用抗衰落能力很强的连续可变斜率调制 (CVSD) 编码方式以提高话音质量； 采用频率调制方式，降低设备的复杂性。
2 ）拓扑结构
蓝牙系统支持点对点以及点对多点通信。几个相互独立、以特定方式连接在一起的微微网构成分布式网络，各微微网由不同的跳频序列来区分。在同一微微网中，所有的用户均用同一跳频序列同步。拓扑结构如图 1 所示。

  图 1 分布式网络

          3 ）连接建立的过程及其工作状态的转换
在微微网建立之前，所有设备都处于就绪 (STANDBY) 状态。在该状态下，未连接的设备每隔 1.28 秒监听一次消息，设备一旦被唤醒，就在预先设定的 32 个跳频频率上监听信息。跳频数目因地区而异，但 32 个跳频频率为绝大多数国家所采用。 连接进程由主设备初始化。如果一个设备的地址已知，就采用寻呼消息 (Page message) 建立连接；如果地址未知，就采用紧随寻呼消息的查询消息 (Inquiry message) 建立连接。查询消息主要用来查询地址未知的设备 ( 如公用打印机、传真机等 ) ，它与寻呼消息类似，但需要附加一个周期来收集所有的应答。在寻呼状态 (PAGE state) ，主设备在 16 个跳频频率上发送一串相同的页信息给从设备，如果没有收到应答，主设备就在另外的 16 个跳频频率上发送寻呼消息。主设备到从设备的最大时延为两个唤醒周期（ 2.56 秒），平均时延为半个唤醒周期（ 0.64 秒）。
  在微微网中，无数据传输的设备转入节能工作状态。主设备可将从设备设置为保持方式 (HOLD mode) ，此时，只有内部定时器工作；从设备也可以要求转入保持方式。设备由保持方式转出后，可以立即恢复数据传输。连接几个微微网或管理低功耗器件（如温度传感器）时，常使用保持方式。监听方式 (SNIFF mode) 和休眠方式（ PARK mode ）是另外两种低功耗工作方式。在监听方式下，从设备监听网络的时间间隔增大，其间隔大小视应用情况由编程确定；在休眠方式下，设备放弃了 MAC 地址，仅偶尔监听网络同步信息和检查广播信息。各节能方式依电源效率高低排列为：休眠方式→保持方式→监听方式。
4 ）蓝牙对语音和数据的支持
  为了保证各种使用场合的应用，蓝牙的基带协议是电路交换和分组交换的组合，可以同时支持语音和数据的传输。该技术支持两种连接方式：面向连接（ SCO ）方式，主要用于话音传输；无连接 (ACL) 方式，主要用于分组数据传输。

在同一微微网中，不同的主从设备可以采用不同的连接方式，在一次通信中，连接方式可以任意改变。每一连接方式可支持 16 种不同的分组类型，其中控制分组有 4 种，是 SCO 和 ACL 通用的分组，两种连接方式均采用时分双工 （ TDD ）通信。 SCO 为对称连接，每一个话音通道支持 64kbps 的同步话音，支持限时话音传送，主从设备无需轮询即可发送数据。 SCO 的分组既可以是话音又可以是数据，当发生中断时，只有数据部分需要重传。 ACL 是面向分组的连接，它支持对称和非对称两种传输流量： ACL 的非对称连接支持正向速率 721kbps 、反向应答速率为 57.6kbps 的；对称连接速率为 432.6kbps 。 ACL 也支持通过广播方式发送信息。在 ACL 方式下，主设备控制链路带宽，负责从设备带宽的分配；从设备依轮询发送数据。

        3 、蓝牙硬件模块的组成

1. 无线射频（ RF ）单元
           蓝牙系统的天线发射功率符合 FCC 关于 ISM 波段的要求。系统的最大跳频速率为 1600 跳 / 秒，在 2.402GHz 到 2.480GHz 之间，采用 79 个 1MHz 带宽的频点。系统设计的通信距离为 10 米（ 0db ），如果增加发射功率（ 20db ），这一距离也可以达到 100 米。

2. 基带（ Baseband,BB ）和链路管理（ LinkManager,LM ）单元

BB 负责跳频和蓝芽数据及信息帧的传输。 LM 负责连接的建立和拆除。它们实现的功能包括：对 SCO 和 ACL 连接方式的支持；差错控制，可以采用多种检纠错方式，其中包括前向纠错编码 (FEC) ；物理层的认证与加密；链路管理。
4. 蓝牙软件协议栈的介绍

1 ）协议栈结构

底部协议层包括链路管理协议（ Link Manager Protocol, LMP ）和基带（ Baseband ）控制部分。链路管理协议实现链路的建立、认证及链路配置等。其中的服务项目包括：接收和发送数据、设备号请求、链路地址查询、建立连接、认证与加密、协商并建立连接方式、确定分组的帧类型、设置监听方式、设置保持方式以及设置休眠方式等。基带（ Baseband ）控制部分负责跳频和蓝芽数据及信息帧的传输，包括对纠错编码的支持，对 SCO 和 ACL 包的组织，流控等。

中间协议层包括逻辑链路控制和适应协议（ Logical Link Control and Adaptation Protocol,L2CAP ）、服务发现协议（ Service Discovery Protocol,SDP ）、串口仿真协议 RFCOMM 和电话通信协议（ Telephony Control Protocol,TCS ），对象交换协议（ Object Exchange ， OBEX) 。 L2CAP 完成数据的拆装、服务质量和协议复用等功能，是其他上层协议实现的基础。 SDP 为上层应用程序提供一种机制来发现网络中可用的服务及其特性。 RFCOMM 基于 ETSI 标准 TS07.10 在 L2CAP 上仿真 9 针 RS232 串口的功能。 TCS 提供蓝芽设备间话音和数据的呼叫控制信令。对象交换协议（ Object Exchange ， OBEX) 是 Extended Systems 公司为红外通信的高层应用开发的协议，现在已成功的应用于蓝牙协议栈中。

在 BB 和 LM 上与 L2CAP 之间还有一个主机控制接口层（ Host Controller Interface,HCI ）。 HCI 是蓝芽协议中软硬件之间的接口，它提供了一个调用下层 BB 、 LM 、状态和控制寄存器等硬件的统一命令接口。 HCI 协议以上的协议软件实体运行在主机上，而 HCI 以下的功能由蓝牙模块来完成，二者之间通过一个对两端透明的传输层进行交互。

2）在Makefile中加入
bks2410_config : unconfig
 @./mkconfig $(@:_config=) arm arm920t bks2410 NULL s3c24x0
我把我的板子起名叫bks2410，可以依自己的喜好修改

3）建立board/bks2410目录，拷贝board/smdk2410下的文件到board/bks2410目录，将smdk2410.c更名为bks2410.c

4）cp include/configs/smdk2410.h include/configs/bks2410.h

5）将arm-linux-gcc的目录加入到PATH环境变量中，我的是目录/opt/eldk/usr/bin:/opt/eldk/bin

6）测试编译能否成功：
make bks2410_config
make all ARCH=arm
生成u-boot.bin就OK了

7）依照你自己开发板的内存地址分配情况修改board/bks2410/memsetup.S文件，我的程序：
#include <config.h>
#include <version.h>

#define BWSCON 0x48000000

/* BWSCON */
#define DW8    (0x0)
#define DW16    (0x1)
#define DW32    (0x2)
#define WAIT    (0x1<<2)
#define UBLB    (0x1<<3)

#define B1_BWSCON    (DW32)
#define B2_BWSCON    (DW16)
#define B3_BWSCON    (DW16 + WAIT + UBLB)
#define B4_BWSCON    (DW16)
#define B5_BWSCON    (DW16)
#define B6_BWSCON    (DW32)
#define B7_BWSCON    (DW32)

/* BANK0CON */
#if 0
#define B0_Tacs    0x0 /*  0clk */
#define B0_Tcos    0x0 /*  0clk */
#define B0_Tacc    0x7 /* 14clk */
#define B0_Tcoh    0x0 /*  0clk */
#define B0_Tah    0x0 /*  0clk */
#define B0_Tacp    0x0
#define B0_PMC    0x0 /* normal */
#endif

#define B0_Tacs    0x3 /*  0clk */
#define B0_Tcos    0x3 /*  0clk */
#define B0_Tacc    0x7 /* 14clk */
#define B0_Tcoh    0x3 /*  0clk */
#define B0_Tah    0x3 /*  0clk */
#define B0_Tacp    0x1
#define B0_PMC    0x0 /* normal */

/* BANK1CON */
#if 0
#define B1_Tacs    0x0 /*  0clk */
#define B1_Tcos    0x0 /*  0clk */
#define B1_Tacc    0x7 /* 14clk */
#define B1_Tcoh    0x0 /*  0clk */
#define B1_Tah    0x0 /*  0clk */
#define B1_Tacp    0x0
#define B1_PMC    0x0
#endif

#define B1_Tacs    0x3 /*  0clk */
#define B1_Tcos    0x3 /*  0clk */
#define B1_Tacc    0x7 /* 14clk */
#define B1_Tcoh    0x3 /*  0clk */
#define B1_Tah    0x3 /*  0clk */
#define B1_Tacp    0x3
#define B1_PMC    0x0

#define B2_Tacs    0x0
#define B2_Tcos    0x0
#define B2_Tacc    0x7
#define B2_Tcoh    0x0
#define B2_Tah    0x0
#define B2_Tacp    0x0
#define B2_PMC    0x0

#if 0
#define B3_Tacs    0x0 /*  0clk */
#define B3_Tcos    0x3 /*  4clk */
#define B3_Tacc    0x7 /* 14clk */
#define B3_Tcoh    0x1 /*  1clk */
#define B3_Tah    0x0 /*  0clk */
#define B3_Tacp    0x3     /*  6clk */
#define B3_PMC    0x0 /* normal */
#endif

#define B3_Tacs    0x0 /*  0clk */
#define B3_Tcos    0x0 /*  4clk */
#define B3_Tacc    0x7 /* 14clk */
#define B3_Tcoh    0x0 /*  1clk */
#define B3_Tah    0x0 /*  0clk */
#define B3_Tacp    0x0     /*  6clk */
#define B3_PMC    0x0 /* normal */

#define B4_Tacs    0x0 /*  0clk */
#define B4_Tcos    0x0 /*  0clk */
#define B4_Tacc    0x7 /* 14clk */
#define B4_Tcoh    0x0 /*  0clk */
#define B4_Tah    0x0 /*  0clk */
#define B4_Tacp    0x0
#define B4_PMC    0x0 /* normal */

#define B5_Tacs    0x0 /*  0clk */
#define B5_Tcos    0x0 /*  0clk */
#define B5_Tacc    0x7 /* 14clk */
#define B5_Tcoh    0x0 /*  0clk */
#define B5_Tah    0x0 /*  0clk */
#define B5_Tacp    0x0
#define B5_PMC    0x0 /* normal */

#define B6_MT    0x3 /* SDRAM */
#define B6_Trcd     0x1
#define B6_SCAN    0x1 /* 9bit */

#define B7_MT    0x3 /* SDRAM */
#define B7_Trcd    0x1 /* 3clk */
#define B7_SCAN    0x1 /* 9bit */

/* REFRESH parameter */
#define REFEN    0x1 /* Refresh enable */
#define TREFMD    0x0 /* CBR(CAS before RAS)/Auto refresh */
#define Trp    0x0 /* 2clk */
#define Trc    0x3 /* 7clk */
#define Tchr    0x2 /* 3clk */
#define REFCNT    1113 /* period=15.6us, HCLK=60Mhz, (2048+1-15.6*60) */
/**************************************/

_TEXT_BASE:
 .word TEXT_BASE

.globl memsetup
memsetup:
 /* memory control configuration */
 /* make r0 relative the current location so that it */
 /* reads SMRDATA out of FLASH rather than memory ! */
 adr     r0, SMRDATA
 /*ldr r1, _TEXT_BASE*/
 /*sub r0, r0, r1*/
 ldr r1, =BWSCON /* Bus Width Status Controller */
 add     r2, r0, #13*4
0:
 ldr     r3, [r0], #4
 str     r3, [r1], #4
 cmp     r2, r0
 bne     0b

 /* everything is fine now */
 mov pc, lr

 .ltorg
/* the literal pools origin */

SMRDATA:
    .word (0+(B1_BWSCON<<4)+(B2_BWSCON<<8)+(B3_BWSCON<<12)+(B4_BWSCON<<16)+(B5_BWSCON<<20)+(B6_BWSCON<<24)+(B7_BWSCON<<28))
    .word ((B0_Tacs<<13)+(B0_Tcos<<11)+(B0_Tacc<<8)+(B0_Tcoh<<6)+(B0_Tah<<4)+(B0_Tacp<<2)+(B0_PMC))
    .word ((B1_Tacs<<13)+(B1_Tcos<<11)+(B1_Tacc<<8)+(B1_Tcoh<<6)+(B1_Tah<<4)+(B1_Tacp<<2)+(B1_PMC))
    .word ((B2_Tacs<<13)+(B2_Tcos<<11)+(B2_Tacc<<8)+(B2_Tcoh<<6)+(B2_Tah<<4)+(B2_Tacp<<2)+(B2_PMC))
    .word 0x1f7c/*((B3_Tacs<<13)+(B3_Tcos<<11)+(B3_Tacc<<8)+(B3_Tcoh<<6)+(B3_Tah<<4)+(B3_Tacp<<2)+(B3_PMC))*/
    .word ((B4_Tacs<<13)+(B4_Tcos<<11)+(B4_Tacc<<8)+(B4_Tcoh<<6)+(B4_Tah<<4)+(B4_Tacp<<2)+(B4_PMC))
    .word ((B5_Tacs<<13)+(B5_Tcos<<11)+(B5_Tacc<<8)+(B5_Tcoh<<6)+(B5_Tah<<4)+(B5_Tacp<<2)+(B5_PMC))
    .word ((B6_MT<<15)+(B6_Trcd<<2)+(B6_SCAN))
    .word ((B7_MT<<15)+(B7_Trcd<<2)+(B7_SCAN))
    .word ((REFEN<<23)+(TREFMD<<22)+(Trp<<20)+(Trc<<18)+(Tchr<<16)+REFCNT)
    .word 0x31
    .word 0x30
    .word 0x30
   
8）在board/bks2410加入NAND Flash读函数，建立nand_read.c，加入如下内容(copy from vivi)：
#include <config.h>

#define __REGb(x) (*(volatile unsigned char *)(x))
#define __REGi(x) (*(volatile unsigned int *)(x))
#define NF_BASE  0x4e000000
#define NFCONF  __REGi(NF_BASE + 0x0)
#define NFCMD  __REGb(NF_BASE + 0x4)
#define NFADDR  __REGb(NF_BASE + 0x8)
#define NFDATA  __REGb(NF_BASE + 0xc)
#define NFSTAT  __REGb(NF_BASE + 0x10)

#define BUSY 1
inline void wait_idle(void) {
    int i;

    while(!(NFSTAT & BUSY))
      for(i=0; i<10; i++);
}

#define NAND_SECTOR_SIZE 512
#define NAND_BLOCK_MASK  (NAND_SECTOR_SIZE - 1)

/* low level nand read function */
int
nand_read_ll(unsigned char *buf, unsigned long start_addr, int size)
{
    int i, j;

    if ((start_addr & NAND_BLOCK_MASK) || (size & NAND_BLOCK_MASK)) {
        return -1; /* invalid alignment */
    }

    /* chip Enable */
    NFCONF &= ~0x800;
    for(i=0; i<10; i++);

    for(i=start_addr; i < (start_addr + size);) {
      /* READ0 */
      NFCMD = 0;

      /* Write Address */
      NFADDR = i & 0xff;
      NFADDR = (i >> 9) & 0xff;
      NFADDR = (i >> 17) & 0xff;
      NFADDR = (i >> 25) & 0xff;

      wait_idle();

      for(j=0; j < NAND_SECTOR_SIZE; j++, i++) {
 *buf = (NFDATA & 0xff);
 buf++;
      }
    }

    /* chip Disable */
    NFCONF |= 0x800; /* chip disable */

    return 0;
}

9）修改board/bks2410/Makefile为
OBJS := bks2410.o flash.o nand_read.o

10）修改cpu/arm920t/start.S文件
在ldr pc, _start_armboot之前加入：
#ifdef CONFIG_S3C2410_NAND_BOOT
  bl    copy_myself
 
  @ jump to ram
  ldr   r1, =on_the_ram
  add  pc, r1, #0
  nop
  nop
  1:    b     1b          @ infinite loop
 
on_the_ram:
#endif

在_start_armboot: .word start_armboot之后加入：
#ifdef CONFIG_S3C2410_NAND_BOOT
copy_myself:
  mov r10, lr
@ reset NAND
  mov r1, #NAND_CTL_BASE
  ldr   r2, =0xf830           @ initial value
  str   r2, [r1, #oNFCONF]
  ldr   r2, [r1, #oNFCONF]
  bic  r2, r2, #0x800              @ enable chip
  str   r2, [r1, #oNFCONF]
  mov r2, #0xff         @ RESET command
  strb r2, [r1, #oNFCMD]
  mov r3, #0                   @ wait

1:add  r3, r3, #0x1
  cmp r3, #0xa
  blt   1b
2:ldr   r2, [r1, #oNFSTAT]      @ wait ready
  tst    r2, #0x1
  beq  2b
  ldr   r2, [r1, #oNFCONF]
  orr  r2, r2, #0x800              @ disable chip
  str   r2, [r1, #oNFCONF]

@ get read to call C functions (for nand_read())
  ldr   sp, DW_STACK_START       @ setup stack pointer
  mov fp, #0                    @ no previous frame, so fp=0

@ copy vivi to RAM
  ldr   r0, =UBOOT_RAM_BASE
  mov     r1, #0x0
  mov r2, #0x20000
  bl    nand_read_ll
  tst    r0, #0x0
  beq  ok_nand_read

#ifdef CONFIG_DEBUG_LL
  bad_nand_read:
  ldr   r0, STR_FAIL
  ldr   r1, SerBase
  bl    PrintWord
1:b     1b          @ infinite loop
  #endif

ok_nand_read:
#ifdef CONFIG_DEBUG_LL
  ldr   r0, STR_OK
  ldr   r1, SerBase
  bl    PrintWord
#endif

@ verify
  mov r0, #0
  ldr   r1, =UBOOT_RAM_BASE
  mov r2, #0x400     @ 4 bytes * 1024 = 4K-bytes
go_next:
  ldr   r3, [r0], #4
  ldr   r4, [r1], #4
  teq   r3, r4
  bne  notmatch
  subs r2, r2, #4
  beq  done_nand_read
  bne  go_next

notmatch:
#ifdef CONFIG_DEBUG_LL
  sub  r0, r0, #4
  ldr   r1, SerBase
  bl    PrintHexWord
  ldr   r0, STR_FAIL
  ldr   r1, SerBase
  bl    PrintWord
#endif
1:b     1b
done_nand_read:
#ifdef CONFIG_DEBUG_LL
  ldr   r0, STR_OK
  ldr   r1, SerBase
  bl    PrintWord
#endif
  mov pc, r10
@ clear memory
@ r0: start address
@ r1: length
  mem_clear:
  mov r2, #0
  mov r3, r2
  mov r4, r2
  mov r5, r2
  mov r6, r2
  mov r7, r2
  mov r8, r2
  mov r9, r2

clear_loop:
  stmia      r0!, {r2-r9}
  subs r1, r1, #(8 * 4)
  bne  clear_loop
  mov pc, lr

#endif @ CONFIG_S3C2410_NAND_BOOT

在文件的最后加入：
   .align     2
DW_STACK_START:
 .word      STACK_BASE+STACK_SIZE-4

11）修改include/configs/bks2410.h文件，添加如下内容：
/*
 * Nandflash Boot
 */
#define CONFIG_S3C2410_NAND_BOOT 1
#define STACK_BASE    0x33f00000
#define STACK_SIZE    0x8000
#define UBOOT_RAM_BASE    0x33f80000
/* NAND Flash Controller */
#define NAND_CTL_BASE            0x4E000000
#define bINT_CTL(Nb)        __REG(INT_CTL_BASE + (Nb))
/* Offset */
#define oNFCONF               0x00
#define oNFCMD                0x04
#define oNFADDR               0x08
#define oNFDATA               0x0c
#define oNFSTAT               0x10
#define oNFECC                0x14

12）重新编译u-boot
make all ARCH=arm

13）通过jtag将u-boot烧写到flash中就可以从NAND flash启动了

我的u-boot启动信息：

U-Boot 1.1.3 (May  6 2006 - 18:13:59)

U-Boot code: 33F80000 -> 33F967C4  BSS: -> 33F9AAAC
RAM Configuration:
Bank #0: 30000000 64 MB
Flash: 512 kB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
BKS2410 #