不是每一行代码都必须读懂，我只是大概地过一下流程
毕竟这些都是比较成熟的代码，没必要去改的
是针对我自己的板子的，硬件配置如下
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;
i