函數main_loop和u-boot命令執行

1.main_loop函數履行流程和命令解釋器
run_main_loop是board_r中函數運行列表init_fnc_t init_sequence_r[]最后1個函數，它又調用了main_loop，且run_main_loop永不返回。main_loop定義在common/main.c中：bootstage_mark_name函數調用了show_boot_progress，利用它顯示啟動進程(progress)，此處為空函數。
setenv設置環境變量ver為version_string，后者在common/cmd_version.c中定義為：

U_BOOT_VERSION_STRING在version.h中定義為：

其中U_BOOT_VERSION ，U_BOOT_DATE，U_BOOT_TIME，U_BOOT_TZ均由u-boot構建系統自動產生，
它們分別代表u-boot版本號，編譯日期和時間，和時間區。
如果定義了CONFIG_SYS_HUSH_PARSER，那末配置u-boot使用hush shell來作為履行器。hush shell是1種輕量型的shell。
cli_init用來初始化hush shell使用的1些變量。hush shell的實現機制比較復雜，以下的hush shell相干實現代碼都不做詳實跟蹤分析。
有興趣的可參見源代碼和相干的網絡文章。

run_preboot_environment_command函數從環境變量中獲得"preboot"的定義，該變量包括了1些預啟動命令，
1般環境變量中不包括該項配置。
bootdelay_process從環境變量中取出"bootdelay"和"bootcmd"的配置值，將取出的"bootdelay"配置值轉換成整數，
賦值給全局變量stored_bootdelay，最后返回"bootcmd"的配置值。bootdelay為u-boot的啟動延時計數值，計數期間內
如無用戶按鍵輸入干預，那末將履行"bootcmd"配置中的命令。
由于沒有定義CONFIG_OF_CONTROL，函數cli_process_fdt返回false，接下來履行autoboot_command，
該函數在common/autoboot.c中實現：

全局變量stored_bootdelay在上面已做說明。靜態函數abortboot中包括了CONFIG_AUTOBOOT_KEYED宏預處理分支，該宏定義用來使能用戶名密碼登錄，這里它沒有定義，而后調用了abortboot_normal，在履行的時間stored_bootdelay(秒)內，如無用戶按鍵輸入干預，那末abortboot_normal函數將返回0，否則返回1。 當無用戶按鍵干預時，接下來將調用run_command_list履行上述從環境變量中讀取的"bootcmd"配置值。注意該函數的參數s。run_command_list中調用了hush shell的命令解釋器(parse_stream_outer函數)，解釋bootcmd中的啟動命令。環境變量bootcmd中的啟動命令，用來設置linux必要的啟動環境，然后加載和啟動linux內核。u-boot啟動linux內核后，將控制權交給linux內核，至此不再返回。
如用戶在設定的bootdelay內無按鍵輸入，那末將運行cli_loop履行hush shell命令解釋器：parse_file_outer進行必要的初始化后，也將調用hush shell的命令解釋器，即parse_stream_outer函數：上面的do-while會循環命令解析器的"命令輸入解析--履行"運行模式。
其中的函數run_list履行以下的函數調用流程：
run_list-->run_list_real-->run_pipe_real
最后在函數run_pipe_real中有：
return cmd_process(...);
函數cmd_process最后完成u-boot命令的定位和履行。
2.u-boot命令履行
命令處理函數均在common/command.c中實現，上述函數cmd_process定義以下：
u-boot中使用宏U_BOOT_CMD來定義命令，該宏在include/command.h中定義以下：
U_BOOT_CMD是宏U_BOOT_CMD_COMPLETE最后1個參數_comp為NULL的特例，_comp表示變量是不是自動完成：其中包括的宏U_BOOT_CMD_MKENT_COMPLETE定義為：

上面的_CMD_HELP根據配置可選為使用完全或簡短幫助說明。_CMD_COMPLETE則根據配置決定是不是使用自動完成函數。U_BOOT_CMD_MKENT_COMPLETE宏實際上是組織輸入參數，對ll_entry_declare進行數據填充。ll_entry_declare在文件include/linker_lists.h中定義：

參數_type為cmd_tbl_t，這里定義1個cmd_tbl_t結構體，并把它放在符號段.u_boot_list_2_"#_list"_2_"#_name中，其中的_list和_name根據宏參數進行字符串替換。
下面，我們舉例說明上述宏的實現機制。比如有以下的定義：即
帶入宏參及其展開為 ：
其中的ll_entry_declare帶入宏參及其展開為 ：
其中的U_BOOT_CMD_MKENT_COMPLETE帶入宏參及其展開為:
那末上述U_BOOT_CMD_COMPLETE終究展開為：
其中的cmd_tbl_t定義為：

該結構體包括了命令名，命令實現函數，命令使用簡短說明usage的輸出字符串，幫助回調函數，參數變量自動完成函數等。u-boot使用該結構體來描寫1個完全的命令。

U_BOOT_CMD_COMPLETE宏用來定義1個cmd_tbl_t結構體變量，初始化該結構體中的相應成員，并把該結構體變量寄存在4字節對齊的.u_boot_list_2_cmd_2_env符號段中。如前所述，宏U_BOOT_CMD將最后1個參數_comp置為NULL，對U_BOOT_CMD_COMPLETE做了進1步的封裝。所有使用U_BOOT_CMD和U_BOOT_CMD_COMPLETE定義的命令最后都集中放在以.u_boot_list_2_cmd_2開頭的符號段中。即.u_boot_list_2_cmd_2_##name，這里的name是命令名。

我們回到函數上述的命令處理函數cmd_process，被其調用的find_cmd將根據命令名查找相應的cmd_tbl_t變量符號段，其實現以下：

ll_entry_start定義以下：
那末，在上述函數find_cmd中，語句  
定義1個包括0個字節的數組start[0]，且把它放在.u_boot_cmd_2_list_1段中，該段屬性為unsued。注意在u-boot.lds中有：
.u_boot_list中所有符號是按字符表的前后順序排列的，.u_boot_list_2_list_1會放在所有使用U_BOOT_CMD和U_BOOT_CMD_COMPLETE
定義的符號段的最前面，即.u_boot_cmd_2_list_1為以.u_boot_list_2_cmd_2開頭的符號段中的第1個。它定義為0個字節的數組start[0]，
編譯器其實不為它分配存儲空間，那末它將指向以.u_boot_list_2_cmd_2開頭的符號段中的第1個符號。
同理ll_entry_end用end[0]來標識.u_boot_list_2_cmd_2_xxx段的結尾，接下來的函數ll_entry_count返回的就是start - end的值，
即符號段.u_boot_list_2_cmd_2_xxx總字節長度。然后調用find_cmd_tbl，根據傳入的.u_boot_list_2_cmd_2_xxx段的首地址和
函數ll_entry_count 返回的長度，根據命令名查找相應的符號段，即相命令對應的cmd_tbl_t結構體變量，然后返回該結構體指針。
find_cmd_tbl的實現以下：
查找到命令名對應的cmd_tbl_t結構體變量后，cmd_process接下來將調用函數cmd_call履行cmd_tbl_t中的命令。
cmd_process中相應的代碼段以下：
變量ticks用來記錄命令的履行時間，repeatable為命令是不是自動重復履行標志。這兩個變量都將返回到上層的調用函數。
函數cmd_call利用傳入的參數，直接調用cmdtp->cmd，即：
 (cmdtp->cmd)(cmdtp, flag, argc, argv)；
最后，如果命令履行的返回值為CMD_RET_USAGE，代表命令履行出錯，且置標CMD_RET_USAGE ，那末將調用cmd_usage，
輸出簡短的命令使用幫助信息。cmd_usage實現以下：
3.u-boot中的子命令
部份u-boot的命令包括子命令，如env命令，它由子命令save,set,edit等組成。類似的還有sf命令。這些主命令履行時必須指定子命令。
u-boot中子命令的實現不再使用上面的gcc關鍵字section來指定段，只是直接定義了1個cmd_tbl_t表，并使用子命令及其運行參數初始化該表。對上述討論中使用U_BOOT_CMD定義的命令，它們是散放在文件各處的，很難用1個全局的cmd_tbl_t表將這些命令統1定義初始化。而子命令不同，它只定義在1個或少許文件中，該cmd_tbl_t表為static類型，可以在定義時直接填充。固然，主命令還是由宏U_BOOT_CMD來定義引入。