很久沒有寫部落格了，由於之前的寫關於omap3530文章還沒有整理。再加上一直在找工作，找到工作後又投入到另外的平台去工作。始終在忙忙碌碌，但是對於**確實漸漸疏遠。
在做專案的時候要使用ddr3分配記憶體，不經意間使用要和mmu以及tlb打交道。因此特地寫下這篇文章以備後用。（工作就是在和遺忘作鬥爭）！
linux
在啟動之初會建立臨時頁表，但是在start_kerne函式中setup_arch又會建立正真的頁表和頁目錄。那麼兩套方案是如何過渡的？假如在mmu開啟的時候把之前的臨時頁表給覆蓋了或者修改了，會不會影響後續的啟動過程？帶著這些問題分析一下。
首先來看一下基於arm的頁表管理和mmu的行為分析：
arm上的linux（正式）頁表採用的是一級粗頁表結合二級小頁表實現4g空間的訪問。如上圖說明。
一級表 （1024 entrys）
二級表 （1024 entrys）
虛擬位址後12位offset定址空間是4096b 4k的空間
arm上的linux（臨時）頁表採用的是段式頁表，每乙個entry可以對映1m的空間，結合後面的20bits位（定址空間正好是1m）
一級表 （4096 entrys）
虛擬位址的後20位offset定址空間是1m
接著來看一下linux如何建立頁表的過程。
head.s
關鍵問題在於乙個變數swap_pgdir 1.
.macro pgtbl, rd
2. 3.
ldr \rd, =(kernel_ram_paddr - 0x4000)
4. 5.
.endm
kernel_ram_paddr = 0 x ******xx
臨時頁表使用的是段式對映，也稱之為平坦對映。那麼4g的空間劃分為1m為單位的訪問單元，需要4096個entrys。應為arm採用32位的資料線，因此每乙個entry占用乙個32位的區段，也就是4b。
正式頁表建立的過程分為二級對映也尋找index的過程。每次把線性位址劃分為兩段，每一段都作為索引根據tlb base的便宜尋找下一級的索引項。最後結合虛擬位址的最後偏移（10 bit）作為依據在4k的空間內定址。
問題來了，這兩種對映會不會應為後一種對映的建立把之前的對映破壞掉，導致linux乙個複雜的定址系統無法正常工作呢？答案肯定不會。
圖示比文字描述來的直接，還是直接上兩張圖說明問題：
由上圖可知：臨時頁表建立的空間和正式頁表建立的空間分別部署於不同的空間，因此不會出現覆蓋或者修改等現象。同時一二級頁表專案錄中的內容頁值得研究。最後兩位同時表現出來的控制邏輯，讓mmu翻譯位址的過程中有章可循。結合mmu中的ap位規定了訪問空間的屬性，是否可以訪問拒絕訪問等。
最後希望圖示可以幫助讀者理解對映的意圖。文中難免有些地方會引起歧義或者不足之初，希望linux大俠指正點評。
謝謝
linux 臨時頁表
armv8 linux4.9 檢視dma map前後mmu page table的變化的時候，有看到有的page table entry映 2m的size，這個2m的entry是何時建立的，目的是什麼是這邊部落格要弄清楚的問題。arm64 定義頁框大小的define位置如下，每乙個頁表項對映乙個頁框...
8 2 4臨時表和正式表
區別 1.不同的客戶端可以建立名字相同的臨時表而沒有衝突 2.乙個臨時表被建立僅僅在連線期間，當客戶端斷開連線時自動刪掉臨時表。3.乙個臨時表可以和乙個非臨時表有同樣的名字。4.乙個臨時表可以被重新命名只能使用alter而不能使用rename table。臨時表和記憶體表的區別是，記憶體表在伺服器重...
ARM Linux 驅動實驗專案拉力賽正式開始
從寒假到開學，再到現在，自己已經完成了ulk，ldd，linux程式設計詳解，和linux裝置驅動開發詳解 的系統學習。在這之間也做過一些arm開發板程式和主機和上的驅動實驗。但從未系統的，正式的，詳細的，規範的開始過arm linux驅動的專案開發實驗。自己規劃從明天，不是！是 從現在開始自己對a...