1. 程式人生 > >u-boot 核心同時傳遞cmdline時的處理

u-boot 核心同時傳遞cmdline時的處理

預設是核心boot option裡面的config_cmdline,如果u-boot也傳引數,則會覆蓋。

u-boot傳引數方法如下:
在do_bootm_linux中:
72 #ifdef CONFIG_CMDLINE_TAG
73         char *commandline = getenv ("bootargs");
74 #endif
。。。。。。。。。。。
127 #ifdef CONFIG_CMDLINE_TAG
128         setup_commandline_tag (bd, commandline);
129 #endif
在其中會將也就是bootargs的資料作為atags的一項,傳遞給核心:
218         params->hdr.tag = ATAG_CMDLINE;
219         params->hdr.size =
220                 (sizeof (struct tag_header) + strlen (p) + 1 + 4) >> 2;
221 
222         strcpy (params->u.cmdline.cmdline, p);

核心這邊則有:
699 static int __init parse_tag_cmdline(const struct tag *tag)
700 {
701         strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
702         return 0;
703 }
704 
705 __tagtable(ATAG_CMDLINE, parse_tag_cmdline);

通過__tagtable,parse_tag_cmdline將在初始化中被呼叫,如果存在u-boot傳來的bootargs,則覆蓋掉核心原有的config_cmdline。default_command_line會由原始編譯核心時的config_cmdline變為bootargs。

繼續核心會去分析command,在setup_arch中,
771         char *from = default_command_line;
。。。。
806         memcpy(saved_command_line, from, COMMAND_LINE_SIZE);
807         saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
808         parse_cmdline(cmdline_p, from);
可以看出隨後核心將這個改變後的值進行parse,並且根據parse的結果做相應的設定。

比如首先分析記憶體:
809         paging_init(&meminfo, mdesc);
包括頁表,記憶體區域等設定。剩下的cmdline會交由後面分析,setup_arch返回後,start_kernel執行到
530         parse_args("Booting kernel", command_line, __start___param,
531                    __stop___param - __start___param,
532                    &unknown_bootoption);
就會呼叫parse_args對剩下的cmdline進行解析。

可以看出,對於cmdline的處理是以uboot為優先,但是如果將parse_tag_cmdline函式中的內容註釋掉,則起作用的就是核心了。


附帶額外說一些對記憶體的設定。cmdline裡面有類似mem=xxx這樣的設定,但初次以外,核心還必須知道ram的起始地址,因為不像x86,固定從0開始,而且每款arm的soc,記憶體地址對映都不一樣,所以核心必須知道實體地址起址是多少。

首先u-boot中會通過init_sequence指標去設定dram:
5 init_fnc_t *init_sequence[] = {
。。。
298         dram_init,              /* configure available RAM banks */
。。。
301 };
dram設定記憶體大小和起始地址:
268 int dram_init(void)
269 {       
270         gd->bd->bi_dram[0].start = PHYS_SDRAM;
271         gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
272         return 0;
273 }
PHYS_SDRAM和PHYS_SDRAM_SIZE都定義在各自的include/configs/xxx.h裡面

在do_bootm_linux裡面,有:
124 #ifdef CONFIG_SETUP_MEMORY_TAGS
125         setup_memory_tags (bd);
126 #endif
就是設定atags的記憶體區域的值:
static void setup_memory_tags (bd_t *bd)
186 {
187         int i;
188 
189         for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
190                 params->hdr.tag = ATAG_MEM;
191                 params->hdr.size = tag_size (tag_mem32);
192 
193                 params->u.mem.start = bd->bi_dram[i].start;
194                 params->u.mem.size = bd->bi_dram[i].size;
195 
196                 params = tag_next (params);
197         }
198 }

類似parse_tag_cmdline,會有:
611 static int __init parse_tag_mem32(const struct tag *tag)
612 {  
613         if (meminfo.nr_banks >= NR_BANKS) {
614                 printk(KERN_WARNING            
615                        "Ignoring memory bank 0x%08x size %dKB\n",
616                         tag->u.mem.start, tag->u.mem.size / 1024);
617                 return -EINVAL;                
618         }
619         arm_add_memory(tag->u.mem.start, tag->u.mem.size);
620         return 0;
621 }  
622 
623 __tagtable(ATAG_MEM, parse_tag_mem32);

但是注意,並不是你傳了這個atag,他就會起作用,在setup_arch中有:
792         if (mdesc->fixup)
793                 mdesc->fixup(mdesc, tags, &from, &meminfo);
這個fixup函式是板級相關的,通常就是一些ram起址大小bank之類的設定函式,如果執行過了,nrbank就不為0了,那麼繼續執行後面的語句時:
795         if (tags->hdr.tag == ATAG_CORE) {
796                 if (meminfo.nr_banks != 0)
797                         squash_mem_tags(tags);
798                 parse_tags(tags);
799         }
就會呼叫squash_mem_tags把你u-boot傳入的值給幹掉,使parse_tags函式呼叫時不會處理ATAG_MEM。

參考連結:
1.http://blog.chinaunix.net/u1/46715/showart_367493.html
2.http://blog.csdn.net/cooboos/archive/2010/05/07/5567142.aspx

相關推薦

u-boot 核心同時傳遞cmdline處理

預設是核心boot option裡面的config_cmdline,如果u-boot也傳引數,則會覆蓋。 u-boot傳引數方法如下: 在do_bootm_linux中: 72 #ifdef CONFIG_CMDLINE_TAG 73         char *commandline = getenv (

u-boot向kernel傳遞裝置樹、環境變數解析

u-boot向kernel傳遞裝置樹、環境變數解析 【 do_bootm_states---wzf test states:0x1 continue ...... need_boot_fn:0x0 states:0x1 ## Flattened Device

【Android 系統開發】 編譯 Android檔案系統 u-boot 核心 並燒寫到 OK-6410A 開發板上

本篇文章中用到的工具原始碼下載 : -- 光碟所含內容 : Android 引導 u-boot 原始碼, Android 核心 原始碼, Android 系統原始碼, 交叉編譯工具鏈;各項操作說明 : -- 編譯環境 : 編譯原始碼 (u-boot, 核心, Android

busybox檔案系統與簡單驅動學習(0)-u-boot核心編譯篇

一、交叉編譯環境搭建 1、4412交叉編譯工具安裝 (1)該工具位於4412提供安裝包路徑:iTOP-4412精英版光碟資料\02_編譯器以及燒寫工具\arm交叉編譯器 (2)在ubuntu下建立交叉編譯路徑: /usr/local/arm 下,將ar

u-boot與Linux核心視訊顯示介面引數配置及傳遞方案

http://blog.chinaunix.net/uid-20543672-id-3244213.html 分類: LINUX2012-06-15 11:48:54 一、一般視訊顯示介面初始化所需要的引數 眾所周知,顯示器顯示的是二維的,處理器將視訊資料通過顯示介面行、地傳送到顯示器,每行

自己寫bootloader筆記6---boot.c分析(u-boot核心傳遞引數及跳轉到核心

#include "setup.h"extern void uart0_init(void); extern void nand_read(unsigned int addr, unsigned char *buf, unsigned int len); extern void puts(char *str)

U-Boot中MAC地址設定及往核心傳遞

一、核心引數的傳遞 U-Boot向Linux驅動傳遞引數的方式有兩種,一為在系統啟動的時候由bootloader傳入,還有一種是將驅動編譯成模組,將引數作為模組載入的引數傳入。 核心通過setup介面接受Bootloader傳入的引數。方式如下: st

u-boot下延程序失效的bug調試

val boot 結果 dump pre spa quest pri 默認 最近在工作中的一個項目中,大概是將兩塊板卡相連(一塊STM32跑裸機程序,另一塊AM335x跑Linux系統),但是發現在u-boot有時無法啟動成功,需要通過一個GPIO的狀態來判斷,具體來說就是

Spring Boot @ResponseBody 轉換 JSON資料Date 型別處理方法

引用處: https://blog.csdn.net/molashaonian/article/details/53025118 https://blog.csdn.net/henianyou/article/details/81945409   解析JSON的方式:

u-boot(五)核心啟動

目錄 u-boot(五)核心啟動 概述 分割槽空間 核心檔案格式 核心複製跳轉 核心啟動 機器ID 啟動引數 (起始tag)setup_start_tag 記憶體設定 根檔案系統,啟動程式,串列

Win10 環境下 SD 卡燒錄 U-boot 出現 can not write image

技術分享 not 環境 解決 ffffff win pro proc color 解決方法:Win10 環境下 SD 卡燒錄 U-boot 時出現 can not write image

u-boot-2009 tftp下載核心及nfs系統

核心版本:3.0.35: setenv ipaddr 200.200.4.234 setenv serverip 200.200.4.233 setenv bootcmd_tftp tftpboot 0x10800000 uImage-myimx6a9 setenv bootargs

u-boot sdfuse命令燒錄分析----從SD卡載入核心

在u-boot移植過程中,由於u-boot燒錄在SD卡中,因此老是載入核心失敗,是什麼原因呢?在載入核心的列印資訊中有這樣類似的資訊: reading kernel.. 1120, 10240 MMC read: dev # 1, block # 112

移植u-boot-2011.03到S3C2440(utu2440)的方法與步驟###8. u-boot引導啟動nand flash中核心和根檔案系統cramfs和使用者檔案系統yaffs2支援

rivers/rtc/hctosys.c: unable to open rtc device (rtc0)uncorrectable error : <3>uncorrectable error : <3>end_request: I/O error, dev mtdblock2, 

編譯U-boot和Linux核心的步驟和詳解

1、準備材料 linux核心和uboot的原始碼包—- 6818GEC.tar.gz 環境:VMware12.0 Ubuntu16.04(64位) (1)先將 6818GEC.tar.gz 放在Ubuntu的共享目錄下,然後將 68

u-boot到kernel命令列引數設定及傳遞

軟體配置env的情況(CONFIG_ENV_IS_NO_WHERE=y) 1, 在u-boot/include/configs/xxx_config.h配置檔案中我們可以找到CONFIG_BOOTARGS配置項,在這裡我們可以設定要傳遞的到核心的命令列引數 u-boot/i

一 在應用中升級u-boot核心以及檔案系統

近期在做在Linux系統中做在應用中升級功能,網路傳輸資料,實現的目標是:通過網路可以對u-boot、核心、檔案系統的檔案進行修改升級。 這裡記錄一下簡單思路: 首先從全域性考慮,要實現的功能網路通訊部分和嵌入式系統對emmc的操作。 網路通訊: 該部分考慮的問題主要是使用

Beaglebone Black——理論篇beaglebone black啟動——從串列埠獲得SPL、U-BOOT,TFTP伺服器獲得核心,NFS伺服器掛載根檔案系統

          一般來講啟動一個系統所需的bootloader(SPL/MLO、u-boot.img)和根檔案系統(/boot下包含核心zImage)要麼是放在NAND Flash,或者是SD卡,或者是eMMC,或者是USB中,那麼還有一種方式,就是所需要的這些檔案全部

nfs啟動:u-boot啟動後從ubuntu tftp下載核心及裝置樹,檔案系統掛載在nfs伺服器目錄

U-Boot# setenv netargs "setenv bootargs console=${console} ${optargs}    root=/dev/nfs  rootfstype=nfsroot    nfsroot=${serverip}:${rootpath}   ip=${ipaddr

核心解析U-boot傳入的machid

machid 在沒有裝置樹的時候,machine相關的初始化函式都在類似arch/arm/mach-s3c24xx的目錄下。 圖中圈住的machine,他們都屬於arm/mach-s3c24xx體系,在核心配置s3c24xx時,都會被編進核心。