_text_phy_base:
.word cfg_phy_uboot_base
start.s
中使用_text_phy_base
存放物理基址。這個變數很重要,因為我們在 u-boot 中使用 mmu ,在 mmu 沒有開啟之前,需要這個變數來保證程式能在正確的位址執行
通過在 u-boot 原始碼中全域性搜尋可以發現,cfg_phy_uboot_base
定義在uboot/include/configs/x210_sd.h
中
#define memory_base_address 0x30000000..
.#define cfg_phy_uboot_base memory_base_address + 0x3e00000
cfg_phy_uboot_base
這個巨集是在memory_base_address
的位置上偏移了 0x3e00000 的空間
.globl _bss_start
_bss_start:
.word __bss_start
.globl _bss_end
_bss_end:
.word _end
_bss_start
_bss_end
這兩個變數之前也在鏈結指令碼中見過
bss 段通常是指用來存放程式中未初始化的或者初始化為0的全域性變數和靜態變數的一塊記憶體區域
reset:
/* * set the cpu to svc32 mode and irq & fiq disable
*/@;mrs r0,cpsr
@;bic r0,r0,#0x1f
@;orr r0,r0,#0xd3
@;msr cpsr,r0
msr cpsr_c, #0xd3 @ i & f disable, mode: 0x13 - svc
到這裡就是 u-boot 真正的復位**了
msr指令用亍將運算元的內容傳送到程式狀態暫存器的特定域中
cpsr是 arm 架構的當前程式狀態暫存器,而cpsr_c是程式狀態暫存器的後8位,也就是控制位
cpsr 暫存器的描述如下
i 和 f 位對應的是 irq 和 fiq 中斷的標誌位,置1為關閉
因為模式位是前5位控制的,所以 0xd3 相當於 0x13,對應的就是 svc(管理)模式
再加上**中的注釋,我們就可以知道這段**的作用就是讓處理器進入 svc 模式並關閉中斷
這裡是為了初始化一些重要的暫存器和記憶體的時鐘
cpu_init_crit 只會在重啟的時候執行,當 u-boot 在 ram 中的時候不會執行
這部分做了這些事
重新初始化開啟 l2 cache
重新整理 l1 的資料和指令 cache
關閉 mmu
讀取啟動介質選擇
## 讀取啟動資訊
ldr r0, =pro_id_base @ pro_id_base=e000 0000
ldr r1, [r0,#omr_offset] @ omr_offset=0000 0004
bic r2, r1, #0xffffffc1
這段**目的是從 e000 0004 這個暫存器讀取電平資訊,這個暫存器是 om 引腳的位址。通過設定 om 引腳的電平,就可以設定 u-boot 的啟動介質
bic 的作用是為了清除無關的位,方便後面進行啟動介質的判斷
/* nand boot */
cmp r2, #0x0 @ 512b 4-cycle
moveq r3, #boot_nand
.../* sd/mmc boot */
cmp r2, #0xc
moveq r3, #boot_mmcsd
/* nor boot */
cmp r2, #0x14
moveq r3, #boot_nor
通過判斷前面存入 r2 的值,得到不同的啟動介質的資訊
從圖中可以看出 0xd0036000 是 sram 的位址空間,此時 ddr 還沒有初始化完成,只能使用不需要初始化的 sram
通過 sub 建立了乙個 stack,再讓 fp(棧幀指標)指向 stack 的開頭(fp 用作棧的開頭,sp 作為棧的當前位置,fp 和 sp 一起組成了乙個棧幀)
設定 stack 是為了用來儲存 lr 的值,因為當前是被呼叫的子函式中, lr 中儲存著當前子函式的範圍位址,如果直接使用 bl 呼叫子函式,就會丟失當前子函式的返回位址
所以在子函式中呼叫子函式時,需要先將當前的 lr 壓棧
關於 sp fp pc lr 暫存器有空會說說的,我也是在學習彙編才接觸到這些暫存器,也是在看了些資料才稍微了解了些
個人部落格
uboot啟動階段簡要概述分析
1.uboot的啟動階段可分為兩部分 1 第一階段為彙編階段,在內部sram中執行。2 第二階段為c語言階段,第二階段是在ddr中執行階段。2.各階段主要完成的功能 1 第一階段主要完成內容 2 第二階段主要完成內容 如果說第一階段主要完成的是soc內部的初始化,則第二階段主要完成的就是開發板級別的...
uboot啟動第二階段之x load分析
開發板 dm3730 虛擬機器 ubuntu 14.04 編譯器 arm none linux gnueabi x loader 這幾天小小的研究了一下linux的啟動機制 所裡這裡做個小小的總結吧 現在一般的晶元的linux啟動機制是這樣的 上電自執行romcode也就是在rom裡固化的 romc...
uboot分析 uboot啟動核心
u boot啟動核心概述 u boot啟動完成後,最終進入到main loop 迴圈中。若在bootdelay倒計時為0之前,u boot控制台有輸入,則進入命令解析 執行的迴圈 若控制台無輸入,u boot將啟動核心。u boot啟動核心可歸結為以下四個步驟 1 將核心搬移至ddr中 2 校驗核心...