step 5：
MTD設備初始化。
關於什麼是MTD，為什麼要使用MTD，MTD技術的架構是什麼，等等，可以參考《Linux MTD原始碼分析》。
vivi採用Linux kernel的架構，所以把Linux kernel的MTD子系統借用過來了，做了一些縮減。可以簡單地看成：Flash硬件驅動層和MTD設備層。這樣，最後統一的接口向vivi提供。
還是以nand flash啟動這個情景為主線，對MTD初始化流程進行分析。下面先從入口開始。
ret = mtd_dev_init(); |
利用source insight跟蹤，看一下此函數的接口定義部分：
/* * VIVI Interfaces */ #ifdef CONFIG_MTD int write_to_flash(loff_t ofs, size_t len, const u_char *buf, int flag); int mtd_dev_init(void); #else #define write_to_flash(a, b, c, d) (int)(1) #define mtd_dev_init() (int)(1) #endif |
可見，vivi在配置的時候是必須配置MTD功能部分的。如果不配置MTD，那麼CONFIG_MTD就不存在定義。由此導致寫flash的動作實際上是沒有的。也就是說，無法完成寫flash的動作。當然，在這裡可以做測試，就是使用MTD子系統的vivi把分區等都設置好。然後重新編譯一下vivi，把mtd功能去除，做簡單的修改（把bon_cmd部分從【lib/command.c】中去掉，否則編譯不通過），生成大小為35152字節。給開發板重新開機，利用老的vivi燒寫nand flash的vivi分區，完成後做一下reset，於是沒有MTD功能的vivi就跑起來了。但是，這樣的bootloader僅僅適合於最終的產品階段，不適合開發，沒什麼太大的價值。
下面【drivers/mtd/mtdcore.c】，看看mtd_dev_init函數，核心部分就是調整mtd_init函數（【drivers/mtd/maps/s3c2410_flash.c】）。
int mtd_init(void) { int ret; #ifdef CONFIG_MTD_CFI ret = cfi_init(); #endif #ifdef CONFIG_MTD_SMC ret = smc_init(); #endif #ifdef CONFIG_S3C2410_AMD_BOOT ret = amd_init(); #endif |
可見，vivi現在支持三種類型的存儲接口，一種是CFI，也就是Intel發起的一個flash的接口標準，主要就是intel的nor flash系列；一種是smc，記憶卡系列接口，nand flash就是通過這個接口實現讀寫的；一種是AMD的flash系列。選擇什麼啟動方式，就要選擇相應的配置項。
核心部分根據配置應該調用smc_init函數。-->【drivers/mtd/maps/s3c2410_flash.c】。這裡最為核心的就是兩個數據結構，一個是mtd_info，位於【include/mtd/mtd.h】，如下：
mtd_info是表示MTD設備的結構，每個分區也被表示為一個mtd_info，如果有兩個MTD設備，每個設備有三個分區，那麼在系統中就一共有6個mtd_info結構。關於mtd_info，在《Linux MTD原始碼分析》中講解非常透徹，不過需要注意的是，在vivi的實現中沒有使用mtd_table，另外priv指向的是nand_info，這些都是與Linux下不同的地方，主要是為了簡化。另一個是nand_info，這個結構則包含了nand flash的所有信息。
所謂的初始化，其實就是填充處理上述兩個數據結構的過程。填充完畢之後，後續的工作都會基於此展開。下面開始看smc_init的代碼。
mymtd = mmalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip)); this = (struct nand_chip *)(&mymtd[1]); |
在這裡，第一句參考前面heap的實現代碼，重點看第二句代碼。這句代碼是有一定的技巧性，但是也存在著很大的風險。其中，mymtd是指向struct mtd_info的指針，那麼mymtd[1]實際上是等效於*(mymtd + 1)的數學計算模式，注意mymtd並非數組，這裡僅僅利用了編譯器翻譯的特點。對於指針而言，加1實際上增加的指針對應類型的值，在這裡地址實際上增加了sizeof(struct mtd_info)，因為前面分配了兩塊連續的地址空間，所以&(*(mymtd + 1))實際上就是mtd_info數據結構結束的下一個地址，然後實現強制轉換，於是this就成為了nand_chip的入口指針了。但是，這裡必須要把握好，因為這個地方是不會進行內存的檢查的，也就是說，如果你使用了mymtd[2]，那麼仍然按照上述公式解析，雖然可以運算，可是就是明顯的指針遺漏了，可能會出現意料不到的結果。
瞭解清楚了，mymtd指向mtd_info的入口，this指向nand_chip的入口。
memset((char *)mymtd, 0, sizeof(struct mtd_info)); memset((char *)this, 0, sizeof(struct nand_chip)); |
mymtd->priv = this; |
上述原始碼首先初始化這兩個結構體，即均為0.然後利用priv把二者聯繫起來，也就是mymtd通過其成員priv指向this，那麼mymtd中的抽閒操作函數，比如read、write等，真正的是通過this來實現的。很明顯，this的實現部分屬於flash硬件驅動層，而mymtd部分則屬於MTD設備層，二者的聯繫就是通過成員priv實現的。
接下來首先是初始化nand flash設備，這跟前面的基礎實驗一致。
/* set NAND Flash controller */ nfconf = NFCONF; /* NAND Flash controller enable */ nfconf |= NFCONF_FCTRL_EN; /* Set flash memory timing */ nfconf &= ~NFCONF_TWRPH1; /* 0x0 */ nfconf |= NFCONF_TWRPH0_3; /* 0x3 */ nfconf &= ~NFCONF_TACLS; /* 0x0 */ NFCONF = nfconf; |
然後填充nand flash的數據結構的一個實例this，分成了兩個部分，nand flash基本操作函數成員的初始化、其餘訊息的填寫。
/* Set address of NAND IO lines */ this->hwcontrol = smc_hwcontrol; this->write_cmd = write_cmd; this->write_addr = write_addr; this->read_data = read_data; this->write_data = write_data; this->wait_for_ready = wait_for_ready; /* Chip Enable -> RESET -> Wait for Ready -> Chip Disable */ this->hwcontrol(NAND_CTL_SETNCE); this->write_cmd(NAND_CMD_RESET); this->wait_for_ready(); this->hwcontrol(NAND_CTL_CLRNCE); smc_insert(this); |
上面這些都不難理解，感覺在結構體設計上還是比較出色的，把成員和相應的操作封裝起來，面向對象的一種方法。下面看smc_insert，無非還是按照結構體填寫相應的信息，細節部分就不深入探討了。
inline int smc_insert(struct nand_chip *this) { /* Scan to find existance of the device */ if (smc_scan(mymtd)) { return -ENXIO; } /* Allocate memory for internal data buffer */ this->data_buf = mmalloc(sizeof(u_char) * (mymtd->oobblock + mymtd->oobsize)); if (!this->data_buf) { printk("Unable to allocate NAND data buffer for S3C2410.\n"); this->data_buf = NULL; return -ENOMEM; } return 0; } |
第一部分掃瞄填充mymtd數據結構。後面主要用於nand flash的oob緩衝處理。具體部分可以參考《s3c2410完全開發》。
這裡重點是學習一種結構體的構造技巧。
首先構造一級數據結構，表示抽像實體。例如：
struct nand_flash_dev { char * name; int manufacture_id; int model_id; int chipshift; char page256; char pageadrlen; unsigned long erasesize; }; |
然後構造實例集合，表現形式就是一個大的數組。
static struct nand_flash_dev nand_flash_ids[] = { {"Toshiba TC5816BDC", NAND_MFR_TOSHIBA, 0x64, 21, 1, 2, 0x1000}, // 2Mb 5V ... .... {"Samsung K9D1G08V0M", NAND_MFR_SAMSUNG, 0x79, 27, 0, 3, 0x4000}, // 128Mb {NULL,} }; |
這樣修改擴展等等後續的操作就簡便多了。抽像的能力及其訓練在讀程式碼的時候是可以很好的學習的，在vivi中，多處都採用了這種設計原則，應該掌握並利用。
step 6：
此部分的功能是把vivi可能用到的所有私有參數都放在預先規劃的內存區域，大小為48K，基地址為0x
33df0000。在內存的分配示意圖方面，《s3c2410完全開發》已經比較詳盡，就不放在這裡了。到此為止，vivi作為bootloader的三大核心任務：initialise various devices, and eventually call the Linux kernel,passing information to the kernel.，現在只是完成第一方面的工作，設備初始化基本完成，實際上step 6是為啟動Linux內核和傳遞參數做準備的，把vivi的私有信息，內核啟動參數，mtd分區信息等都放到特定的內存區域，等待後面兩個重要工作使用（在step 8完成，後面的step 7也是為step 8服務的）。這48K區域分為三個組成部分：MTD參數、vivi parameter、Linux啟動命令。每塊的具體內容框架都一致，以vivi param tlb這個情景為主線進行分析：
入口：
init_priv_data(); |
進入【lib/priv_data/rw.c】--init_priv_data()
int init_priv_data(void) { int ret_def; #ifdef CONFIG_PARSE_PRIV_DATA int ret_saved; #endif ret_def = get_default_priv_data(); #ifdef CONFIG_PARSE_PRIV_DATA ret_saved = load_saved_priv_data(); if (ret_def && ret_saved) { printk("Could not found vivi parameters.\n"); return -1; } else if (ret_saved && !ret_def) { printk("Could not found stored vivi parameters."); printk(" Use default vivi parameters.\n"); } else { printk("Found saved vivi parameters.\n"); } #else if (ret_def) { printk("Could not found vivi parameters\n"); return -1; } else { printk("Found default vivi parameters\n"); } #endif return 0; |
下面分為兩步：首先讀取預設設置到特定的內存區域，然後讀取nand flash的param區域的信息，如果讀取成功，就覆蓋掉前面的預設設置。首先看第一步，get_default_priv_data--get_default_param_tlb-->
int get_default_param_tlb(void) { char *src = (char *)&default_vivi_parameters; char *dst = (char *)(VIVI_PRIV_RAM_BASE + PARAMETER_TLB_OFFSET); int num = default_nb_params; if (src == NULL) return -1; /*printk("number of vivi parameters = %d\n", num); */ *(nb_params) = num; //參數表的長度不可以超過預設內存的大小 if ((sizeof(vivi_parameter_t)*num) > PARAMETER_TLB_SIZE) { printk("Error: too large partition table\n"); return -1; } //首先複製magic number memcpy(dst, vivi_param_magic, 8); //預留下8個字節作為擴展 dst += 16; //複製真正的parameter memcpy(dst, src, (sizeof(vivi_parameter_t)*num)); return 0; } |
內存的入口地址為VIVI_PRIV_RAM_BASE+PARAMETER_TLB_OFFSET，開始的8個字節放magic number，這裡vivi定義為「VIVIPARA」，後面空下8個字節，留作擴展，從第17個字節開始放置真正的param。這裡用到了多處技巧，第一處就是上面剛剛介紹過的數據結構構造技巧，這裡的vivi_parameter_t就是一級數據結構：
typedef struct parameter { char name[MAX_PARAM_NAME]; param_value_t value; void (*update_func)(param_value_t value); } vivi_parameter_t; |
利用其構造了預設的成員表：
vivi_parameter_t default_vivi_parameters[] = { { "mach_type", MACH_TYPE, NULL }, { "media_type", MT_S3C2410, NULL }, { "boot_mem_base", 0x30000000, NULL }, { "baudrate", UART_BAUD_RATE, NULL }, { "xmodem_one_nak", 0, NULL }, { "xmodem_initial_timeout", 300000, NULL }, { "xmodem_timeout", 1000000, NULL }, { "ymodem_initial_timeout", 1500000, NULL }, { "boot_delay", 0x1000000, NULL } }; |
我們這時就可以很清楚的看到param show列出的配置參數了。
另外一個技巧就是計算數組長度。
int default_nb_params = ARRAY_SIZE(default_vivi_parameters); |
其中ARRAY_SIZE為：
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) |
這是從Linux kernel中拿來的，也是值得學習和利用的地方。
在load階段內無非就是找到param分區，然後根據配置，找到相應的flash硬體驅動（這就是MTD層的作用所在，不過可以看出nand chip的databuf確實沒有起到作用，現在也未看出這部分究竟用在何處）。然後就是讀操作。當然，讀取出來的信息先放到臨時緩衝區，判斷前面的magic number，如果符合則說明是正確的分區信息，然後把信息從臨時緩衝區複製到對應的預設配置區，這樣就完成了真正的配置。
其實這個地方可以改進。首先看看param分區是否有合適的分區信息，如果有，直接讀取到vivi parameter區域，不需要再讀取預設的配置訊息；如果沒有合適的分區信息，然後讀取預設的配置信息。這樣在用戶修正了分區信息時，不必再讀取預設的配置信息，這也算是一處優化。
step 7：
調整add_command()函數，增加vivi作為終端時命令的相應處理函數。其實，這種機制還是比較簡單的，就是利用了連結表。
整個命令處理機制及其初始化的實現是在【lib/command.c】中完成的，包括添加命令、查找命令、執行命令、解析命令行等等。具體的命令函數則在相應的模塊裡面，這樣形成了一個2層的軟件架構：頂部管理層+底部執行層。維護的核心就是一個數據結構user_command：
typedef struct user_command { const char *name; void (*cmdfunc)(int argc, const char **); struct user_command *next_cmd; const char *helpstr; } user_command_t; |
第一個成員是指向name字符串的指針，第二個成員就是命令的處理函數，第三個成員是指向下一個命令，第四個成員是幫助信息。如果你想添加一個命令，那麼首先需要構造一個數據結構user_command的實例，比如：
user_command_t help_cmd = { "help", command_help, NULL, "help [{cmds}] \t\t\t-- Help about help?" }; |
然後實現命令的真正處理函數command_help。
void command_help(int argc, const char **argv) { user_command_t *curr; /* help <command>. invoke <command> with 'help' as an argument */ if (argc == 2) { if (strncmp(argv[1], "help", strlen(argv[1])) == 0) { printk("Are you kidding?\n"); return; } argv[0] = argv[1]; argv[1] = "help"; execcmd(argc, argv); return; } printk("Usage:\n"); curr = head_cmd; while(curr != NULL) { printk(" %s\n", curr->helpstr); curr = curr->next_cmd; } } |
構造好之後，需要把它加入鏈表，也就是在init_builtin_cmds中增加add_command(&help_cmd);，其中add_command的實現如下：
void add_command(user_command_t *cmd) { if (head_cmd == NULL) { head_cmd = tail_cmd = cmd; } else { tail_cmd->next_cmd = cmd; tail_cmd = cmd; } /*printk("Registered '%s' command\n", cmd->name);*/ } |
這樣，自己如果增加新的程序，就按照如上的步驟添加即可。
其餘具體命令的實現暫時不做解釋。
step 8：
根據情況，要麼進入vivi的命令行交互界面，要麼直接啟動內核。關於此部分的流程分析，有了前面的基礎和經驗，是不難理解的。很容易通過vivi的列印信息得知進行到了第幾步，《s3c2410完全開發》在過程上講解的也很清楚。所以不打算具體分析了。現在翻閱網上資料，有一個問題實際上模模糊糊，如下：
vivi作為bootloader的一個重要的功能就是向Linux kernel傳遞啟動參數，這個情景究竟是如何完成的呢？雖然網上討論很多，但是因為vivi具有一點特殊性，所以使得理解上有一定的困難。現在已經比較清晰了，算是回答網友的一個問題，也算是總結，就bootloader如何於kernel傳遞參數，作為一個情景進行詳盡的分析。事先需要說明的是，我們假定vivi為A，Linux kernel為B，A要傳給B東西，這就是一個通信的過程。要想通信，至少我們得有一個約定，那就是協議。現在存在的協議有兩種，一種是基於struct param_struct，不過這種因為其局限性即將作廢；一種是基於tags技術。基本的框架就是A必須按照協議設置好參數，B呢，就需要來讀取解析這些參數。它們之間必須配合好，如果配合不好，那麼，kernel是無法引導成功的。現在嵌入式系統的移植，很多時候kernel引導不起來，部分原因就直接來自於參數傳遞問題。但是設計到這個問題，不能不分析Linux kernel的引導過程。現在還不想細緻到程式碼層，只是根據部分程式碼把Linux kernel啟動至獲取引導參數的過程從整體上瞭解清楚，必要的時候輔助相應的程式碼。這部分內容的詳細分析，專門在下篇總結中完成。
沒有留言:
張貼留言