硬件平台：bf561 软件平台：u-boot-1.1.6，gcc for blackfin，visual dsp 5.0 我们知道，u-boot的运行过程是首先进行一些初始化化工作，然后在一个死循环中不断接收串口的命令并进行解释执行，下面我们就看看执行部分代码的实现，见common/main.c中的run_command： int run_command (const char *cmd, int flag) { …        while (*str) {         …                 /* find macros in this token and replace them */               process_macros (token, finaltoken);                 /* Extract arguments */               if ((argc = parse_line (finaltoken, argv)) == 0) {                      rc = -1;   /* no command at all */                      continue;               }                 /* Look up command in command table */               if ((cmdtp = find_cmd(argv[0])) == NULL) {                      printf ("Unknown command '%s' - try 'help'/n", argv[0]);                      rc = -1;   /* give up after bad command */                      continue;               }                 /* found - check max args */               if (argc > cmdtp->maxargs) {                      printf ("Usage:/n%s/n", cmdtp->usage);                      rc = -1;                      continue;               }         …                 /* OK - call function to do the command */               if ((cmdtp->cmd) (cmdtp, flag, argc, argv) != 0) {                      rc = -1;               }                 repeatable &= cmdtp->repeatable;                 /* Did the user stop this? */               if (had_ctrlc ())                      return 0; /* if stopped then not repeatable */        }          return rc ? rc : repeatable; } 很简单的一个过程，扩展宏定义 -> 分析命令及其参数 -> 查找命令 -> 执行命令，有意思的地方在查找命令上(common/command.c)： cmd_tbl_t *find_cmd (const char *cmd) {        cmd_tbl_t *cmdtp;        cmd_tbl_t *cmdtp_temp = &__u_boot_cmd_start;     /*Init value */        const char *p;        int len;        int n_found = 0;          /*         * Some commands allow length modifiers (like "cp.b");         * compare command name only until first dot.         */        len = ((p = strchr(cmd, '.')) == NULL) ? strlen (cmd) : (p - cmd);          for (cmdtp = &__u_boot_cmd_start;             cmdtp != &__u_boot_cmd_end;             cmdtp++) {               if (strncmp (cmd, cmdtp->name, len) == 0) {                      if (len == strlen (cmdtp->name))                             return cmdtp; /* full match */                        cmdtp_temp = cmdtp;   /* abbreviated command ? */                      n_found++;               }        }        if (n_found == 1) {                     /* exactly one match */               return cmdtp_temp;        }          return NULL; /* not found or ambiguous command */ } 看起来还是很简单的一个过程，在一个命令数组中查找是否有指定名称的命令。问题是，在这里使用的两个符号__u_boot_cmd_start和__u_boot_cmd_end，在所有的C文件中都找不到它们的定义，那么它们的空间从哪里来呢？这些分散在不同文件中的结构体又是如何能够放在同一个数组中呢？ 答案就在board/bf561-ezkit/u-boot.lds.s中，这个文件其实就是一个链接文件，类似于VDSP中的LDF文件，see see：  ___u_boot_cmd_start = .;  .u_boot_cmd : { *(.u_boot_cmd) }  ___u_boot_cmd_end = .; 这几句话的意思其实就是指示链接器将所有.u_boot_cmd数据段中的内容全部放在一起，而且___u_boot_cmd_start和___u_boot_cmd_end是不会占用任何存储空间的，它们只是用来指示地址的两个符号而已。那么数据段的定义在哪里呢？看看U_BOOT_CMD的宏定义吧（include/command.h）： #define Struct_Section __attribute__ ((unused,section (".u_boot_cmd")))   #define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) / cmd_tbl_t __u_boot_cmd_##name Struct_Section = {#name, maxargs, rep, cmd, usage, help} __attribute__ ((unused,section (".u_boot_cmd")))就指示编译器将这些用U_BOOT_CMD定义的结构体放在.u_boot_cmd这个数据段中。 如果要在VDSP中编译u-boot，那么就需要在LDF文件中也定义这样一个数据段：       .u_boot_cmd       {                ___u_boot_cmd_start = .;                INPUT_SECTIONS(common.dlb(.u_boot_cmd) common.dlb(__u_boot_cmd))                ___u_boot_cmd_end = .;       } > MEM_SDRAM_U_BOOT 不过让人郁闷的是：如果在一个定义命令的C文件中没有一个函数被其它文件引用，VDSP在链接时将认为这是一个多余的文件，从而不会将这个文件中的函数链接进来，当然就无法使用其中定义的这些命令，如cmd_load.c。 解决的办法可以是在这些文件中添加一个空函数，并在主函数中调用它们，这样VDSP就会把这个文件链接进来了。