Ubuntu安裝Vim Plugin ctags及taglist

安裝ctags及taglist

1. 首先先安裝ctags

apt-get install exuberant-ctags


2. 然後到Taglist網站去下載zip檔http://vim-taglist.sourceforge.net/

(1)下載後解壓縮該檔案
# unzip taglist_45.zip
Archive: taglist_45.zip
inflating: plugin/taglist.vim
inflating: doc/taglist.txt
(2)將plugin及doc複製到家目錄的".vim"這個目錄裏,如果不存在就建一個新的".vim"

在vim裏設定功能鍵F9 - 用它來開啟/關閉taglist功能
在/etc/vim/vimrc裏加入下面1行

map <f9> :Tlist<CR>

最後一個步驟,到你的原始程式目錄裏輸入

ctags -R *.c *.h

開啟vim xxx.c按F9
你就會看見如下圖的結果

畫面分成左右兩邊,切換方式用Ctrl-W-W

左邊畫面TagList只要按Enter就會自動跳到相對應的函式或定義

右邊的畫面:
Ctrl+] : 跳到游標所指function的implement 位置 ，注意游標要在function的第一個字。
Ctrl+t : 返回到剛剛的位置。

cs find

    s: 查找C语言符号，即查找函数名、宏、枚举值等出现的地方
    g: 查找函数、宏、枚举等定义的位置，类似ctags所提供的功能
    d: 查找本函数调用的函数
    c: 查找调用本函数的函数
    t: 查找指定的字符串
    e: 查找egrep模式，相当于egrep功能，但查找速度快多了
    f: 查找并打开文件，类似vim的find功能
    i: 查找包含本文件的文件

範例: cs find t memset <-- memset="" pre="">

Linux啓動分析（2）— bootsect.S、setup.S、head.S分析[轉貼]

bootsect.S，系統引導程序，一般不超過512字節。
在PC系統結構中，綫性地址0xA0000以上，即640K以上用于圖形接口卡和BIOS自身，640K以下為系統的基本内存。如果配置更多的内存，則0x100000，即1MB處開始稱為高内存。當BIOS引導一個系統時，總是把引導扇區讀入到基本内存地址為0x7c00的地方，然後跳轉到此執行引導扇區的代碼。這段代碼將自身搬運到0x90000處，並跳轉到那繼續執行，然後通過BIOS提供的讀磁盤調用“int 0x13”從磁盤上讀入setup和内核映像。其中setup的映像讀入到0x90200處，然後跳轉到setup的代碼中。

從0x90000到0xA0000一共64K，bootsect僅占512字節，所以setup大小理論上可到63.5KB。
在Linux2.4版本以前，在最前面的512字節裏保護了一個mini “boot loader”，只要拷貝啓動代碼運行就可從軟碟啓動；但在2.6版本中不再保護這様的”boot loader”，所以必須在第一個磁盤分區上存儲一個合適的boot loader才能從軟碟啓動，軟碟、硬碟和光驅啓動都是一様的過程。
setup進行映像的解壓縮，從BIOS收集一些數據，在控制台顯示一些信息。

基本内存中開頭一部分空間是保留給BIOS自己用的，另一方面對于Linux内核的引導也需要保留一些運行空間，一共保存了64K。基本内存中用于内核映像的就是8*64K=512K，其中頂端留4K用于引導命令行及從BIOS獲取需要傳遞給内核的數據。内核映像一般都經過壓縮，壓縮後的映像和引導扇區及輔助引導程序的映像拼接在一起，成為内核的引導映像。大小不超過508K的映像稱為小映像zImage，早期版本放在0x10000位置處，否則稱為大内核bzImage，放在0x100000位置處。

CPU在bootsect時處于16位實地址模式，然後在setup的執行過程中轉入32位保護模式。
Setup從BIOS中讀取系統數據（内存大小、顯卡模式、磁盤等參數），將數據保存在0x90000-0x901FF，覆蓋了bootsect的内容。設置32位運行方式：加載中斷描述表寄存器IDTR、全局描述表寄存器GDTR；臨時設置IDT表和GDT表，並在GDT表中設置内核代碼段和數據段的描述符，在Head.S中會根據内核的需要重新設置這些描述符表；開啓A20地址綫；重新設置兩個中斷控制器8259A，將硬件中斷號重新設置為0x20和0x2f；最後設置CPU的控制寄存器CR0（機器狀態字）的保護模式比特（PE）位，從而進入32位保護模式運行；然後跳轉到head.S中的startup_32執行。

對于小内核映像放在0x10000處，Setup會把system從0x10000移到0x0000開始處。對于大内核映像，vmlinux中普通内核代碼被編譯成以PAGE_OFFSET+1MB為起始地址，在Head.S中初始化代碼把虚擬地址减去PAGE_OFFSET就能得到以1MB為起始位置的物理地址，這也正是内核映像在物理内存中的存放位置。
Head.S中的startup_32主要用于開啓頁面單元。初始化工作在編譯過程中開始進行，它先定義一個稱為swapper_pg_dir的數組，使用鏈接器指示在地址0x00101000。然後分彆為兩個頁面pg0和pg1創建頁表項。第一組指向pg0和pg1的指針放在能覆蓋1～9MB内存的位置，第二組指針放在PAGE_OFFSET+1MB的位置。一旦開始頁機制，在上述頁表和頁表項指針建立後可以保證，在内核映像中不論是采用物理地址還是虚擬地址，都可以進行正確的頁面映射。内核其他部分的頁表初始化在paging_init()中完成。映射建立後，通過設置cr0寄存器中的某位開啓頁面映射，然後通過一個跳轉指令保證指令指針的正確性。

(1)．Bootsect啓動過程：
假設用LILO啓動，啓動時用户可以選擇啓動哪個操作系統。LILO將boot loader分為兩部分，一部分放到啓動分區的第一個扇區；

1. BIOS將MBR或啓動分區的第一個扇區的啓動部分加載到地址0x00007c00處；


2. 該程序將自身移到0x00096a00，建立實模式棧(從0x00098000到0x000969ff)，將LILO的第二部分加載到0x00096c00處，然後跳轉到此執行；


3. 然後第二部分程序從磁盤讀取一個可啓動的操作系統列表讓用户選擇，最後用户選擇每個OS後，boot loader可以拷貝不啓動分區或者之間拷貝内核映像到RAM中去；


4. 加載Linux内核映像時，LILO boot loader首先調用BIOS例程顯示”Loading …”信息；


5. 調用BIOS例程加載内核映像的初始化部分到RAM上，内核映像的前512字節放在0x00090000位置，setup()函數代碼放在0x00090200位置；


6. 接着調用BIOS例程裝載内核映像的其餘部分，映像可能放在低地址0x00010000(使用make zImage編譯的小内核映像)或者高地址0x00100000（使用make bzImage編譯的大内核映像）。


7. 然後跳至剛剛setup部分。

(2)．Setup.S分析
setup()匯編函數被連接器放在内核映像文件中的0x200偏移處。Setup函數必須初始化計算機中的硬件設備並為内核程序的執行建立環境。

1. 在ACPI兼容的系統中，調用BIOS例程建立描述系統物理内存布局的表。在早期系統中，它調用BIOS例程返回系統可以的RAM大小；


2. 設置鍵盤的重復延遲和速率；


3. 初始化顯卡；


4. 檢測IBM MCA總綫、PS/2鼠標設備、APM BIOS支持等；


5. 如果BIOS支持Enhanced Disk Drive Services (EDD)，將調用正確的BIOS例程建立描述系統可用硬碟的表；


6. 如果内核加載在低RAM地址0x00010000，則把它移動到0x00001000處；如果映像加載在高内存1M位置，則不動；


7. 啓動位於8042鍵盤控制器的A20 pin。


8. 建立一個中斷描述表IDT和全局描述表GDT表；


9. 如果有的話，重啓FPU單元；


10. 對可編程中斷控制器進行重新編程，屏蔽所以中斷，級連PIC的IRQ2不需要；


11. 設置CR0狀態寄存器的PE位使CPU從實模式切换到保護模式，PG位清0，禁止分頁功能；


12. 跳轉到startup_32()匯編函數, jmpi 0x100000, __BOOT_CS，終于進入内核Head.S；

(3)．Head.S分析
有兩個不同的startup_32()函數，一個在arch/i386/boot/compressed/head.S文件中，setup結束後，該函數被放在0x00001000或者0x00100000位置，該函數主要操作：

1. 首先初始化段寄存器和臨時堆棧；


2. 清除eflags寄存器的所有位；


3. 將_edata和_end區間的所有内核未初始化區填充0；


4. 調用decompress_kernel( )函數解壓内核映像。首先顯示"Uncompressing Linux..."信息，解壓完成後顯示 "OK, booting the kernel."。内核解壓後，如果時低地址載入，則放在0x00100000位置；否則解壓後的映像先放在壓縮映像後的臨時緩存裏，最後解壓後的映像被放置到物理位置0x00100000處；


5. 跳轉到0x00100000物理内存處執行；

解壓後的映像開始于arch/i386/kernel/head.S 文件中的startup_32()函數，因為通過物理地址的跳轉執行該函數的，所以相同的函數名並没有什麽問題。該函數未Linux第一個進程建立執行環境，操作如下：

1. 初始化ds,es,fs,gs段寄存器的最終值；


2. 用0填充内核bss段；


3. 初始化swapper_pg_dir數組和pg0包含的臨時内核頁表：


• 將swapper_pg_dir（0x1000)和pg0(0x2000)清空，swapper_pg_dir作為整個系統的頁目録；


• 將pg0作為第一個頁表，將其地址賦到swapper_pg_dir的第一個32位字中。


• 同時將該頁表項也賦給swapper_pg_dir的第3072個入口，表示虚擬地址0xc0000000也指向pg0。


• 將pg0這個頁表填滿指向内存前4M。


• 在cr3寄存器中存放PGD的地址，並設置cr0寄存器中的PG位，啓用分頁支持。


4. 建立進程0idle進程的内核模式的堆棧；


5. 再次清除eflags寄存器的所有位；


6. 調用setup_idt()用非空的中斷處理函數填充IDT表；


7. 將從BIOS獲取的系統參數傳遞到操作系統的第一個頁面幀；


8. 識別處理器的模式；


9. 將GDT和IDT表的地址加載到gdtr和idtr寄存器中；


10. 跳轉到start_kernel函數，這個函數是第一個C編制的函數，内核又有了一個新的開始。

(4)．start_kernel()分析：

1. 調度器初始化，調用sched_init();


2. 調用build_all_zonelists函數初始化内存區；


3. 調用page_alloc_init()和mem_init()初始化夥伴系統分配器；


4. 調用trap_init()和init_IRQ()對中斷控制表IDT進行最後的初始化；


5. 調用softirq_init() 初始化TASKLET_SOFTIRQ和HI_SOFTIRQ；


6. Time_init()對系統日期和時間進行初始化；


7. 調用kmem_cache_init()初始化slab分配器；


8. 調用calibrate_delay()計算CPU時鐘頻率；

通過調用kernel_thread()啓動進程1init進程的内核綫程，然後該綫程再創建其他的内核綫程執行/sbin/init程序。

資料來源:
http://blog.csdn.net/cxylaf/archive/2007/05/26/1626513.aspx

Linux啓動分析（1）— 總體過程[轉貼]

系統引導過程總體介紹
啓動流程：
系統引導過程主要由以下幾個步驟組成（以硬碟啓動為例）

1. 開機；


2. BIOS加電自檢（POST——Power On Self Test），包括檢查RAM，keyboard，顯示器，軟硬磁盤等等。Intel系列的CPU首先進入的是實模式，並開始執行位於地址0xFFFF0處的代碼，也就是ROM-BIOS起始位置的代碼；


3. 搜索啓動的操作系統，根據BIOS設置，可能會依次訪問每個軟碟的第一個扇區、硬碟、CD-ROW等；一旦找到有效的啓動設備，將第一個扇區（0頭0道1扇區，也就是Boot Sector）的内容讀入内存地址0x7c00處；


4. 檢查（WORD）0000：7dfe是否等于0xaa55.若不等于則轉去嘗試其他介質；如果没有其他啓動介質，則顯示 “No ROM BASIC” ，然後當機；


5. 跳轉到0000：7c00處執行MBR中的程序bootsect.S；


6. MBR先將自己復制到0x90000處，然後將緊接其後的setup部分（第二扇區）拷貝到0x90200，將真正的内核代碼拷貝到0x100000。以上這些拷貝動作都是以bootsect.S、setup.S以及vmlinux在磁盤上連續存放為前提的；


7. bootsect.S完成加載動作後，就直接跳轉到0x90200，這裏正是setup.S的程序入口。 setup.S的主要功能就是將系統參數（包括内存、磁盤等，由BIOS返回）拷貝到 0x90000-0x901FF内存中，這個地方正是bootsect.S存放的地方，這時它將被系統參數覆蓋。以後這些參數將由保護模式下的代碼來讀取。


8. setup.S還將video.S中的代碼包含進來，檢測和設置顯示器和顯示模式。最後，setup.S將系統轉换到保護模式，並跳轉到0x100000（對于bzImage格式的大内核是 0x100000，對于zImage格式的是0x1000）的内核引導代碼，Bootloader過程結束；


9. Bootloader跳轉到0x100000, 此處為"arch/I386/init/head.S"中的startup_32， startup_32的代碼只需要設置一下全局變量，然後就跳轉到start_kernel去了；start_kernel()是"init/main.c"中的asmlinkage函數，至此，啓動過程轉入體系結構無關的通用C代碼中；


10. start_kernel()中設置與體系結構相關的環境、頁表結構初始化、Trap/IRQ初始化、核心進程調度器初始化、時間/定時器初始化、控制台初始化、核心Cache初始化、内存初始化、内部及通用等各種Cache初始化、信號量初始化、其他部分初始化(Init()及smp_init())；


11. 啓動Init()過程，創建第一個進程；Init()中，取得 run-level 信息, 執行 /etc/rc.d/rc.sysinit 脚本, 激活核心的外挂式模塊 (/etc/modules.conf), 然後init 執行 run-level 的各個脚本, 接着執行 /etc/rc.d/rc.local脚本, 最後執行 /bin/login 程序, 登入之後開始以 Shell 控管主機；


12. 啓動完成。

資料來源:
http://blog.csdn.net/cxylaf/archive/2007/05/26/1626511.aspx

SystemC 時間

SystemC支援的時間單位包括SC_FS、SC_PS、SC_NS、SC_US、SC_MS及SC_SEC，而用在時間值的資料型別都是未帶號(unsigned)64位元的整數。

enum sc_time_unit
{
    SC_FS = 0, // femtosecond
    SC_PS, // picosecond
    SC_NS, // nanosecond
    SC_US, // microsecond
    SC_MS, // millisecond
    SC_SEC // second
};

語法如下：
sc_time var_name(time_value, time_unit);

如果想要產生一個clock信號，可以使用下面的寫法：

sc_time t(20, SC_NS);
sc_clock clk("clk", t);

更詳細的範例可參考：
http://www.eecs.berkeley.edu/~hiren/docs/sc_intro.pdf

Verilog and SystemC 比較

(1)Module的寫法
Verilog
module module_name(input/output declaration)
variable declaration
computation block
endmodule

SystemC
SC_MODULE(module_name){
input/output declaration
internal variable
constructor (computation block)
};

(2)input/output定義
Verilog
Input:input var1, ...;
Output:output var2, ...;
Type

SystemC
Input:sc_in var1, ...;
Output:sc_out var2, ...;
Type

• C++ primitive type: int, float, char, ...
• hardware type: sc_int, sc_uint, ...
• user defined type

(3)Computation Block
Verilog
Event trigger: always@(a or b or c)
Edge trigger: always@(posedge clk)

SystemC
SC_CTOR(module_name){
SC_METHOD(function name);
sensitive << a << b << c;
...
}

參考資料: http://twins.ee.nctu.edu.tw/courses/soc_sys_overview_04fall/lab/systemc_chapter1.ppt

全加器範例程式

這是一個SystemC的全加器模型程式
共有main.cpp,module.cpp module.h三支程式
裏面有3個物件(1)full adder[全加器](2)pattern generator[訊號產生器](3)monitor[監控程式]
main.cpp

#include <systemc.h>
#include <iostream>
#include "module.h"

int sc_main(int argc, char** argv){
        sc_signal<int> a, b, carry, co, sum;

        //module ptr
        full_adder adder("adder");
        adder.carry(carry);
        adder.a(a);
        adder.b(b);
        adder.sum(sum);
        adder.co(co);

        pattern_gen pg("pattern_gen");
        pg.d_a(a);
        pg.d_b(b);
        pg.d_carry(carry);

        monitor mon("monitor waveform");
        mon.m_a(a);
        mon.m_b(b);
        mon.m_carry(carry);
        mon.m_sum(sum);
        mon.m_cout(co);


        sc_start(50, SC_NS);

        return 0;
}

module.h

#include <systemc.h>

SC_MODULE(full_adder){
        sc_in<int> carry;
        sc_in<int> a;
        sc_in<int> b;

        sc_out<int> sum;
        sc_out<int> co;


        void proc_full_adder();

        SC_CTOR(full_adder){
                SC_METHOD(proc_full_adder);
                sensitive << carry << a << b;
        }
};

SC_MODULE(pattern_gen){
        sc_out<int> d_a;
        sc_out<int> d_b;
        sc_out<int> d_carry;

        void proc_pattern_gen();

        SC_CTOR(pattern_gen){
                SC_THREAD(proc_pattern_gen);
        }
};

SC_MODULE(monitor){
        sc_in<int> m_a, m_b, m_carry, m_sum, m_cout;

        void proc_monitor();

        SC_CTOR(monitor){
                SC_THREAD(proc_monitor);
                //sensitive << m_a << m_b << m_carry << m_sum << m_cout;
                sensitive << m_a << m_b << m_carry;
        }
};

module.cpp

#include <systemc.h>
#include <iostream>
#include "module.h"
//using namespace std;

void full_adder::proc_full_adder(){
        sum = a ^ b ^ carry;
        co = (a & b) | (b & carry) | (carry & a);
}

void pattern_gen::proc_pattern_gen(){
        sc_uint<3> pattern;
        pattern = 0;

        while (1){
                d_a = pattern[0];
                d_b = pattern[1];
                d_carry = pattern[2];

                wait(5, SC_NS);
                pattern++;
        }
}

void monitor::proc_monitor(){
        while (1){
                cout << "At time " << sc_time_stamp() << "::";
                cout << "(a, b, carry): ";
                cout << m_a << m_b << m_cout;
                cout << " (sum, carry_out): " << m_sum << m_cout << endl;
                wait();
        }
}

Makefile

LIB_DIR=-L/usr/systemc/lib-linux
CPPFLAGS=-I/usr/systemc/include

LIB=-lsystemc

APP=main
OBJS = main.o module.o

$(APP):$(OBJS)
        g++ -o $@ $^ $(LIB_DIR) $(LIB)
.c.o:
        g++ $(CPPFLAGS) -c $@ $<

clean:
        rm -rf $(APP) *.o

執行結果:

At time 0 s::(a, b, carry): 000 (sum, carry_out): 00
At time 5 ns::(a, b, carry): 100 (sum, carry_out): 00
At time 10 ns::(a, b, carry): 010 (sum, carry_out): 10
At time 15 ns::(a, b, carry): 110 (sum, carry_out): 10
At time 20 ns::(a, b, carry): 001 (sum, carry_out): 01
At time 25 ns::(a, b, carry): 100 (sum, carry_out): 10
At time 30 ns::(a, b, carry): 011 (sum, carry_out): 01
At time 35 ns::(a, b, carry): 111 (sum, carry_out): 01
At time 40 ns::(a, b, carry): 001 (sum, carry_out): 11
At time 45 ns::(a, b, carry): 100 (sum, carry_out): 00

資料來源:
http://twins.ee.nctu.edu.tw/courses/soc_sys_overview_04fall/lab.html

EFI UGA & Simple Pointer[轉貼］

年前學習了有關UGA & Simple Pointer的知識，今天拿出來，總結一下。方便自己以後的理解和查閲。
UGA
UGA是 Universal Graphics Adapter （通用圖形適配器）的縮寫。在本質上講，UGA 是一個EFI driver。它在OS導入前和OS運行時都能被使用。

1，Universal Graphics Adapter Protocols主要描述了有關在EFI環境下的圖象顯示。這個部分包含了 UGA Draw Protocols 和 UGA I/O protocol 。前者描述了如何在 pre-OS space 繪入圖象，在圖象屏幕上顯示出來；後者描述了如何訪問圖象屏幕，以及支持視頻控制器的子設備，例如：圖象顯示設備。同時，後者的目標是在 OS 當前的環境下，實現初步的使用。

2，UGA ROM 是一個軟件的概念，它的目標是來支持可預知圖形硬件，并不要求VGA硬件。（不是很清楚）

3，UGA Draw Protocol 支持三個成員函數，來支持 pre-OS space 有限的圖形需求。這些成員函數允許調用者draw到虚擬的 frame buffer 裏面，來獲得當前的視頻模式，以及設置視頻模式。這些簡單的原始函數已經能充分的滿足pre-OS firmware code的總的需要。

4，在 EFI_UGA_DRAW_PROTOCOL 基本圖形操作是 Blt（Block Transfer）。Blt操作允許數據讀出和寫入視頻適配器的視頻存儲器裏。frame buffer 視頻顯示是由一組像素。每個像素在視頻顯示上的位置由 X 和 Y 坐標描述。X 代表了一個掃描行。一個掃描行是指顯示的水平的像素大小。 software Blt buffer 也是由一組像素來組成的。在buffer 裏的第一個元素是Pixel (0, 0) 。Blt buffer 可以看成是一系列的掃描行。一個像素在視頻顯示上的位置和 Blt buffer 裏相對應的轉化：Blt buffer array index = Y * Width + X 。Blt buffer 裏描述像素是有32位，字節0到字節2分彆代表了在像素中紅，緑，藍三色各含的成分，字節3是保留位，始終為0。

5，UGA I/O Protocol 支持I/O 請求模式，目的在于給 OS high performance driver 提供服務。這些I/O請求是經由 EFI_UGA_IO_PROTOCOL DispatchService() 成員函數來訪問的。I/O請求服務包含的能力由 EFI_UGA_DRAW_PROTOCOL 來支持。

6，EFI_UGA_DRAW_PROTOCOL 的三個成員函數：GetMode（）、SetMode（）、Blt（）；
EFI_UGA_IO_PROTOCOL 的成員函數：CreateDevice（）、DeleteDevice（）、DispatchService（）；

Simple Pointer
1，指定一個簡單的方法來進入指針設備。通常説來，主要是指鼠標。EFI_SIMPLE_POINTER_PROTOCOL 允許返回指針設備的有關信息。這包含了按鍵的狀態和最新訪問時鼠標的運動狀態。

2，每個EFI_SIMPLE_POINTER_PROTOCOL都必須安裝Handle 來給EFI Drivers和EFI App提供一些服務讓它們來利用。同時，EFI_DEVICE_PATH 也必須安裝同様的Handle。

相關的概念理解：
1，EBC：
對于不同的處理器和平台，Option ROMs要求有不同的可執行的映像。EFI定義了EFI 字節碼編譯器（EBC）虚擬機來處理這些不同。這個虚擬器的注釋器是firmware的一部分。C語言能够被編譯成EBC，然後和相關的驅動連接，在注釋器上運行。
C語言編譯成 EBC ，同時創建 EBC 映像，它可以被系統在 EFI1.10、UEFI2.0，或更後的Spec下執行。這些系統包含 EBC 注釋器，EBC 注釋器加載和解釋 EBC image，允許 image 能够在多種平台和機制上執行，包括那些基于英特爾? 安騰?處理器, 32位英特爾? 架構處理器,以及64位英特爾體系架構處理器。

2，OPROM：
(Option ROM) Firmware 在適配器卡上控制可啓動的外圍設備。系統 BIOS 會詢查 option ROMs，來確定有哪些設備可以被啓動導入。
(Option ROM) Firmware on adapter cards that control bootable peripherals. The system BIOS interrogates the option ROMs to determine which devices can be booted.

Option ROM 有固件組成，由系統 BIOS 來調用。舉例來説：適配器卡控制導入設備，設備可能包含固件，一旦 Option ROM 被加載，固件用來將設備連接到系統。
An Option ROM typically consists of firmware that is called by the system BIOS. For example, an adapter card that controls a boot device might contain firmware that is used to connect the device to the system once the Option ROM is loaded.

資料來源：
http://blog.sina.com.cn/s/blog_4b265789010008fy.html
EFI Image綜述

EFI Driver Template Code

#include "Tiano.h"
#include "EfiDriverLib.h"
#include "DrvSampleSetup.h"
#include "DrvSample.h"

//
// Local function declarations
//
EFI_STATUS
DrvSampleEntry (
  IN EFI_HANDLE           ImageHandle,
  IN EFI_SYSTEM_TABLE     *SystemTable
  );

EFI_DRIVER_ENTRY_POINT (DrvSampleEntry)

EFI_STATUS
DrvSampleEntry (
  IN EFI_HANDLE           ImageHandle,
  IN EFI_SYSTEM_TABLE     *SystemTable
  )
/*++

Routine Description:

  DrvSample driver entry point function.

Arguments:

  ImageHandle   - image handle for this driver image
  SystemTable   - pointer to the EFI System Table

--*/
{
  EFI_STATUS  Status;
  EFI_HANDLE  Handle;

  Status = EFI_SUCCESS;
  Handle = NULL;
  EfiInitializeDriverLib (ImageHandle, SystemTable);
  //
  // TODO: Add implementation code
  //
  //
  // Initialize our setup/forms data
  //
  Status = SetupInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our driver binding protocol
  //
  Status = DriverBindingProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our driver diagnostics protocol
  //
  Status = DriverDiagnosticsProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our component name protocol
  //
  Status = ComponentNameProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our driver configuration protocol
  //
  Status = DriverConfigurationProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  return Status;
}

資料來源：
http://blog.sina.com.cn/s/blog_4b265789010006gu.html
EFI Programming on Mac OS X

Simple Guide for Porting Android Kernel[轉貼]

作者：劉旭暉colorant@163.com轉載請註明出處
http://blog.csdn.net/colorant/

移植Android的kernel到實際的硬件平台上，很多人很早就做過這件事了，不過相關的文檔和經驗總結不多，我就寫一個吧，也為了自己記錄一下大致的流程，以後好繼續。

1. Android內核Porting相關背景知識

1.1 運行平台
Google的Android平台到今天為止（2008-2-27），應用部分還是以二進制的Binary的形式發布的，其编譯的目標平台是ARM926EJ-S的CPU屬於ARMV5T的版本，所以ARMV4架購的CPU平台無法使用其二進制代碼。關於這點，可以参考下面這篇文章，Benno在此做了詳細的理論分析和代碼測試：http://benno.id.au/blog/2007/11/21/android-neo1973 . 所以目前只有基於ArmV5或以上的架構的平台可以實際運行Android。

1.2 軟件環境

SDK下載：

KERNEL，模擬環境等SRC包下載： http://code.google.com/p/android/downloads/list

1.2.1 Kernel

到M5-r14 release為止，Android的Kernel是基於Linux2.6.23的內核開發的，主要添加了一個名為Goldfish的虛擬CPU以及Android所需相關特定驅動代碼。你需要一個支持EABI的內核作為你內核Porting的起點（最低版本？不知道，只要EABI OK，應該沒有本質區別，但是，Android的很多驅動依賴於2.6.23的內核API，版本越低的內核，移植修改內核相關代碼的工作量越大）

1.2.2 Toolchain

SDK中的內核使用的是4.2.1版本的GCC，基本上，你需要的是一個支持EABI的工具鏈，比如你可以使用Codesourcery的最新工具鏈： http://www.codesourcery.com/

1.2.3 其他工具

Android的Emulator是一個很好的仿真工具，其底層是基於QEMU來實現的，可以使用SDK中的adb工具登陸Emulator的控制台，和控制台交換文件等，用於獲取你所需的信息。

1.3 相關論壇資源

http://benno.id.au/blog/

http://groups.google.com/group/android-internals

http://groups.google.com/group/android-developers

2. Porting 基本思路

2.1 所需資源

2.1.1 硬件

首先，當然是需要一個可以用來向上porting的硬件開發板了，對硬件的需求除了上面說的，需要ArmV5+兼容的CPU以外，最低要求基本需要64M+的內存，64M-128M+的FLASH（取決於你加載文件系統的方式，如果可以透過網絡使用NFS-ROOT或者MMC卡等來存放文件系統的話，這個應該就無所謂了)

2.1.2 軟件

除了上述kernel和tools chain，為了方便調試，最好有靜態編譯的Busybox和Strace等工具。 也可以從Benno的blog上下載到他編譯好的版本。也可以從Benno的blog上下載到他編譯好的版本。

2.2 基本流程

下載Android內核代碼

(1).下載官方2.6.23内核
(2).製作Android和2.6.23内核的diff文件
(3).去除diff文件中和Goldfish和QEMU相關的代碼，如果你的系統已經支持YAFFS2，還可以去除這部分代碼去除diff文件中和Goldfish和QEMU相關的代碼，然後將diff文件Patch到你自己的内核上，如果需要，修改内核相關文件代碼使得patch能夠順利完成。將diff文件Patch到你自己的內核上，如果需要，修改內核相關文件代碼使得patch能夠順利完成。 (這部分大概是主要的工作量，如果你的内核版本差得比較遠的話)
(4).如果必要，修改你的内核代碼中Framebuffer的驅動，使其Virtual_yres 等於兩倍的Yres，並實際分配兩倍分辨率大小的framebuffer内存。

配置內核，確保下列內容得到配置：
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y
CONFIG_BINDER=y
CONFIG_ANDROID_LOG=y
CONFIG_ANDROID_POWER=y
CONFIG_ANDROID_POWER_STAT=y

*從SDK中獲取Android的文件系統，基本上你只需要System etc sbin init這幾個目錄/文件就可以了，其它自建，其中data目錄是有內容的，但是這個目錄的內容可以由Android在啟動時動態的創建出來。
*可以使用adb工具在EMULATOR先tar包裝，再拷貝出來。M3的release也可以從benno那裡直接拿到他抓出來的文件系統
*確保你的dev目錄下有足夠系統啟動的設備節點，如console等，其它的節點Android在啟動過程中會自動創建出來。
*使用NFSROOT或者chroot等手段Android的文件系统。

啟動流程的大致外在表現分階段依次是：

Ø LCD上出現Android幾個字符
Ø LCD短時間的Blank
Ø LCD上出現一個左右滾動的紅色滾動條 (如果有問題，基本上就死在這一步了)
Ø 進入主界面
目前為止我的狀態是：鍵盤可以工作，觸摸屏有響應但是未校準，位置不對，啟動最後階段以及之後啟動新的程序，出現Vmalloc分配內存Failed問題，導致如Brower等應用程序不能完全啟動。 其它網絡等東東還沒開始看呢。

3. 一些TIPS

*Android會對文件使用memory mapped的方式進行操作，JFFS2不支持這種操作，所以要使用別的文件系統。 當然也有繞過去的辦法，自己搜一下吧。
*為了方便測試，可以修改/etc/init.rc，註釋掉runtime，dbus-daemon，Xzygote等相關內容，在init啟動以後再手工啟動這些進程：

/system/bin/app_process -Xzygote /system/bin –zygote &
/system/bin/dbus-daemon –system –nofork & /system/bin/dbus-daemon –system –nofork &
sleep 1; sleep 1;
/system/bin/runtime & /system/bin/runtime &

*Android的Init位於根目錄下，所以如果你需要直接啟動Init，可以在內核參數命令行中用init=/init來指定，或者chroot目錄/init來指定。 當然，啟動/bin/sh以後，再手動啟動/init也是可以的。
*/dev/binder /dev/alarm /dev/log/*等文件是最重要的幾個設備節點，由於這幾個設備節點號的主次設備號是動態分配的，所以，最好確認你的文件系統中的這幾個設備節點的主次設備號是否正確。 如果不知道如何確認，直接删除掉再重啟動。
*如果flash速度太慢或者nfs網絡連接太差，可以將data tmp這兩個目錄mount到內存裡，前提是你的內存足夠大。
*如果啟動過程中，紅色滾動條速度太快（和emulator裡的表現比較），runtime或者system_server進程CPU佔用率接近100%，那麼你可以修改一下你的framebuffer代碼中pan_display相關的函數的代碼，保證其調用返回時得到足夠的幀同步延遲時間。 據Google的swetland給我的說法是：This is usually indicative of lack of vsync/pageflip in the fb driver.The surfaceflinger believes it will be limited by the vsync rate and the startup animation depends on that.
*目前的Android的內核代碼有M3-r20和M5-r14兩個版本，這兩個版本對binder和power兩個驅動做了較大的修改，上層的文件系統和內核必須配套使用。 (另，我的板子上，M5版本可以跑起来，M3的版本會出現段錯誤，沒跑起來：(如果一個版本實在跑不起來，不妨試試別的版本)
*使用strace去跟踪問題！

There are some reference sites for research listed below:
http://wiki.droiddocs.net/Compilation_of_Android_kernel
http://benno.id.au/blog/
http://code.google.com/p/androidbmi/
http://www.anddev.org/
android內核編譯方法: http://blog.chinaunix.net/u/26691/showart_468007.html

http://code.google.com/p/android/downloads/list 下載emulator以及kernel. 下載而來的SDK可以檢視其rootfs,再對照 http://blog.chinaunix.net/u/26691/showart_468007.html or http://wiki.droiddocs.net/Compilation_of_Android_kernel 來編譯出自己的 kernel 給 emulator來掛載. kernel config file在 陈罡的blog亦可下載取得. 在上一篇 adnroid news 裡面有一些研究出來的心得與 URL 可以供參考學習.

想知道Android模擬器裏的Kernel config設定檔嗎?
命令:adb pull /proc/config.gz .
上面那行指令可以把Kernel config取出來看唷!

轉載來源:
http://rider51.wordpress.com/2008/05/13/simple-guide-for-porting-android-kernel/

Android模擬器adb命令介紹

在SDK的Tools文件夾下包含着Android模擬器操作的重要命令adb，adb的全稱為(Android Debug Bridge就是調試橋的作用。通過adb我們可以在Eclipse中方面通過DDMS來調試Android程序，說白了就是debug工具。

adb的工作方式比較特殊採用監聽Socket TCP 5554等端口的方式讓IDE和Qemu通訊，默認情況下adb會daemon相關的網絡端口，所以當我們運行Eclipse時adb進程就會自動運行。

1.通過adb可以輕鬆的執行Linux Shell命令，進入設備或模擬器的shell：adb shell就可以進入模擬器的shell環境中。也可以執行各種Linux的命令，其命令格式為：adb shell command
範例:
adb shell dir 就是列舉目錄，在Linux中根目錄為/而不是Windows上的C磁碟、D磁碟
adb shell dmesg 會列印出Linux的debug訊息。
2.安裝apk程序到模擬器則執行adb install android123.apk，這樣名為android123的安裝包就會安裝到Android模擬器中，前提是android123.apk文件需要放到SDK\Tools目錄下。
3.向emulator傳送文件，使用adb push android123.txt /tmp/android123.txt命令可以把SDK\Tools下的android123.txt文件傳輸到模擬器的/tmp/文件夾中，需要注意的是/tmp/文件夾中內容會在Android模擬器重新啟動時清空。除了說明了使用ADT插件中DDMS外，如圖
4.從Android模擬器中回傳文件到電腦
通過adb pull /tmp/android123.txt android123.txt命令就會把模擬器的tmp文件夾下android123.txt文件回傳到電腦SDK\Tools目錄下。

繼續android adb命令相關介紹，除了可以方便的安裝apk文件、pc和Android模擬器互傳資料外還有Android Debug Bridge一些輔助的功能。
1.如果在Eclipse中發現有* daemon not running. starting it now *的提示可以結束adb
adb kill-server

2.顯示android模擬器狀態
adb devices 端口號等信息，執行後會顯示TCP端口號
adb get-product 獲取設備型號
adb get-serialno 獲取序列號

3.等待正在運行的設備
adb wait-for-device

4.端口轉發
adb forward adb forward tcp:5555 tcp:1234 實現將默認的TCP 5555端口轉發到1234端口上

5.查看bug報告
adb bugreport

Android - How to mount the SDCard image file to Android Emulator

(1)首先必須產生SDCard的image file
mksdcard: create a blank FAT32 image to be used with the Android emulator
usage: mksdcard [-l label]
if is a simple integer, it specifies a size in bytes
if is an integer followed by 'K', it specifies a size in KiB
if is an integer followed by 'M', it specifies a size in MiB

ex:mksdcard 1024M sdcard.iso

(2)讓SDCard連到Android Emulator
a:./emulator -sdcard ~/.android/SDK-1.0/sdcard.iso
b:用Eclipse中設定程式的Open Run Dialog裏,Target頁籤的Aditional Emulator Command Line Option中加入啟動參數 -sdcard scard.iso

(3)透過adb傳收檔案到emulator
adb push
adb pull
ex:
adb push ~/mp3/audio.mp3 /sdcard/audio.mp3

linux底下也可以使用,來管理
mount -o loop sdcard.img android_sdcard

(4)進入emulator的shell
adb shell


資料來源:
http://www.android123.com.cn/moniqi/54.html
http://www.android123.com.cn/moniqi/55.html
http://blackdidi.wordpress.com/2008/10/10/android-how-to-mount-the-sdcard-image-file-to-android-emulator/
http://www.android123.com.cn/moniqi/48.html

官方ADB文件:
http://code.google.com/android/reference/adb.html

EFI介紹之二——框架結搆（Framework）[轉貼]

這個就是Intel設計出來的一個完整的EFI BIOS示意圖，其中綠色的部分就是Framework，我現在從下至上一一介紹。

1）Hardware 這個沒有什麼好說的，就是指我們的平台，主板。

2）Framework，一個大的“H”型結搆，好像一個大的容器，兩端都能裝東西，裝入協議和接口，下端的協議用來訪問硬件，上端協議用來和操作系統進行交互，而兩端的協議進行通信的橋梁就是Framework所設計出的兩個基本模塊：DXE Foundation和PEI Foundation。之所以有兩個，是因為在BIOS過程中分兩個階段，他們各自包含了一個稱之為調度器（Dispatcher）的東西，來調度執行子模塊。這兩個Foundation里面到底有哪些東西，我會在後面的文章中繼續介紹。Framework還包含了Framework Driver，它實現了除Foundation之外的功能，比如訪問硬件的接口等等，注意，它僅僅包含接口而已，不包含接口的實現。

3）Platform Drivers，這個是和具體硬件平台相關的驅動，訪問硬件接口的實現，前一篇文章已經提到，EFI在設計的時候就考慮到跨平台，所以我們在這里看到了他把何平台有有關的東西做到了一個模塊里面，那樣在移植到其他平台的時候，只需要換掉這個部分就可以了。

注：在這里我們經常會看到"Driver"這個詞，我想說明一下，這個“Driver”和我們日常所聽到的驅動程序有點不一樣，可以翻譯成接口，我覺得更加恰當一些。

4）EFI Drivers，這個指一個符合EFI 驅動標准（EFI Driver Modle）的驅動程序，EFI的標准化甚至滲透到了驅動層面，為了兼容性，也制定了驅動標准，凡是符合此標准的程序，都可以在所有的EFI BIOS上直接運行，而不需要任何改動。這樣也給做外圍設備的廠商提供了方便，他們在編寫設備驅動程序的時候，只需要去了解驅動模型就好，而不要去研究整個EFI BIOS，也不用考慮不同的EFI BIOS會有不兼容這個問題。

5）Capatibility Support Module（CSM）為了兼容現有的匯編語言編寫的設備驅動程序和操作系統，而提供了這個部分，計算機領域都要考慮向前兼容的問題，直到BIOS的所有部分都符合EFI標准，這個模塊才會拿掉，不過現階段，這個東西還會存在很長一段時間，因為目前使用EFI BIOS的操作系統很少，Mac OS，Vista+SP1，Linux也正在准備，前景很好：），還有重要的一點，就是現階段的一些操作系統不可能很快就被淘汰，Dos到今天還在廣泛使用。

6）EFI，再往上一層黃色薄薄的一層，EFI本身所表示的就是接口，所以我們可以看到，在Framework這幅圖里面，它只占了很少的一部分，僅僅提供了OS和Framework之間的接口而已。絕大多數工作，都是在Framework中完成。

7）OS，最上面灰色的部分，這幅圖里面有兩種OS，一種是支持EFI的操作系統，另一種是傳統的（Windos XP/98，DOS等等），後者在啟動過程中還需要CSM支持，用Int 19H中斷，所以它放在了CSM的正上方，而支持EFI的操作系統，是不要CSM支持的，它的啟動方式是EFI標准所規定的，這個我們在後面繼續介紹。

資料來源:
http://blog.csdn.net/lpg123/archive/2008/08/30/2853502.aspx