|
Gdb/Armulator 是Gdb自帶的arm7模擬器,是調試arm程序的一個好工具.而了解它的原碼結構對擴展它的IO功能有重要意義.本文介紹了從Armulator的啟動到其內部運作和IO擴展的大部分原代碼功能. 說明 源代碼用的是gdb-5.0.tar+ gdb-5.0-uclinux-armulator-20021127.patch A. 和GDB間的通迅 Armulator一般和Gdb通訊有兩種方式,其一是在Gdb內部直接調用模擬器的相關函數,另一方法則是用pipe或socket傳遞RDP協議來連接Gdb和Amulator.而第一種方法是現在Gdb/Armulator所真正使用的(第二種是早期使用的方法),下面就分析了函數直接調用法. 函數直接調用 這個方法是由Steve (sac@cygnus.com) 修改原RDP方法而來的,Steve本人的描述如下: /****************************************************** This directory contains the standard release of the ARMulator from Advanced RISC Machines, and was ftp"d from. ftp.cl.cam.ac.uk:/arm/gnu It likes to use TCP/IP between the simulator and the host, which is nice, but is a pain to use under anything non-unix. I"ve added created a new Makefile.in (the original in Makefile.orig) to build a version of the simulator without the TCP/IP stuff, and a wrapper.c to link directly into gdb and the run command. It should be possible (barring major changes in the layout of the armulator) to upgrade the simulator by copying all the files out of a release into this directory and renaming the Makefile. (Except that I changed armos.c to work more simply with our simulator rigs) ********************************************************/ db/target.c,/gdb/remote_sim.c以及在/sim/arm/wrapper.c是在Armulator和Gdb的通信中起著至關重要做用的幾個文件.所有的Gdb調試命令最后都是通過在target.h里定義的target_ops結構中的函數指針調用在/sim/arm/wrapper.c中型如sim_xxx的函數完成的.以前這些sim_xxx函數是位于/sim/common中的,是建立RDP通訊的關鍵,代碼修改后此目錄中的文件不再有用,被wrapper.c取而代之了. 以下是RDP 通訊和直接函數調用的圖示: 要清楚Armulator的執行過程就要從它的啟動說起,當你在Gdb中鍵入target sim 去激活Amulator后Gdb首先進行命令行解釋,并將current_target指針指向sim變量,即將Armulator的調試函數集賦予Gdb,隨后的函數調用堆棧如下: --%26;#224;gdbsim_open (…) in remote-sim.c. --%26;#224;sim_open(…) in /sim/arm/wrapper.c /*這里Amulator對調用參數進行分析處理*/ --%26;#224;*current_target->to_fetch_registers(-1) /*此函數指針實指向sim_fetch_register(…) in /sim/arm/wrapper.c*/ --%26;#224;sim_fetch_register(-1) /*此函數指針是在將current_target指向sim時,通過注冊target_ops 結構完成掛接的*/ sim_fetch_register (sd, rn, memory, length) { ARMword regval; init (); file://就在這,Amulator進行了初始化 … } 至此Armulator被裝載完畢,其后Gdb就是通過target_ops(定義在target.h)結構中的各個函數指針來完成對它的調試工. B. Armulator 內部機制 a. 初始化 從上述可知整個模擬器的初始化入口是在wrapper.c中的init( )函數,那么它到底又做了些什么呢? (原始的Gdb5.0中的Armulator是模擬ARM7DTMI 的,而補丁代碼修改了memory map 并添加了timer 和uart 的IO能力使其能夠模擬AT91.因為后者是對前者的增強,所以我們的分析以后者為準) Once the armulator to reset ,the ARMul_NewState will be called.And its task is to malloc a ARMul_state stuct which saves the armulator’s states and initialize it .And the ARMul_MemoryInit() will malloc 4m ram for you. #1 static void #2 init () #3 #4 static int done; #5 if (!done) #6 { #7 ARMul_EmulateInit (); file://Call this routine once to set up the emulator"s tables. #8 state = ARMul_NewState (); #9 state->bigendSig = (big_endian ? HIGH : LOW); #10 RMul_MemoryInit (state, mem_size); file://原始代碼中的內存初始,但現在無用 #11 ARMul_OSInit (state);file://預裝系統初始化 #12 ARMul_CoProInit (state); file://協處理器初始 #13 state->verbose = verbosity; #14 done = 1; #15 file://the below is added for AT91 #16 ARMul_SelectProcessor(state, ARM600); #17 ARMul_SetCPSR(state, USER32MODE); #18 ARMul_Reset(state); #19 } #20 } 因為這是補丁代碼,難免又冗余出現,實際10-11行的兩處掉用是沒有實際意義的,而12行是協處理器的初始化,因為并沒又模擬協處理器所以此處只是以備擴展. 重點的初始化過程是在ARMul_NewState(…)中的.首先它給模擬器的核心狀態結構ARMul_State分配了空間,這個結構里保存了Armulator的所有方面的狀態,包括arm寄存器,流水線狀態等等. 并賦予初值,我們以后就用state表示之.然后調用ARMul_Reset(…)進行更近一步的設置.而后者又主要完成模擬器內存結構的分配和rom映象的加載--/sim/arm/armmem.c/mem_reset(…),IO設備的狀態初始—/sim/arm/armio.c/io_reset(…),你也可在這添加你的初始代碼.到這就完成了Armulator的裝載. (大家注意到18行也調用了ARMul_Reset(…),這是一個BUG,使得模擬器進行了兩次內存分配,而浪費了系統內存.此處可刪去.) Memory map 是所有模擬器的關鍵.Armulator由AT91向其他MCU移植時Memory map又是首先要處理的.Armulator的各個內存區是由mem_bank_t結構來描述的: typedef struct mem_bank_t { ARMword (*read_word)(ARMul_State *state, ARMword addr); void (*write_word)(ARMul_State *state, ARMword addr, ARMword data); unsigned long addr, len; char *filename; } mem_bank_t; file://定義在armmem.h中 Armulator的整個內存則是又此結構的數組static mem_bank_t mem_banks[]管理的. AT91的memory map如下: static mem_bank_t mem_banks[] = { /* the yuk"s below are to work around a uClinux/mount options problem */ { real_read_word, real_write_word, 0x01000000, 0x00400000, }, /* 2.4 */ { real_read_word, _write_word, 0x01400000, 0x00400000, "boot.rom"}, { real_read_word, real_write_word, 0x02000000, 0x00400000, }, /* 2.0 */ { real_read_word, real_write_word, 0x02400000, 0x00001000, }, /* yuk!*/ { real_read_word, _write_word, 0x04000000, 0x00400000, "boot.rom"}, { real_read_word, real_write_word, 0x00000000, 0x00004000, }, { io_read_word, io_write_word, 0xf0000000, 0x10000000, }, { fail_read_word, fail_write_word, 0,0 } }; 根據mem_banks,mem_reset( )將分配空間,加載boot.rom文件. (原來的內存是由ARMul_MemoryExit( )釋放的,但補丁后的代碼就沒了釋放功能,這也是需要糾正的地方) a. 指令流 Armulator 加載完成后,就開始等待Gdb的運行命令了.最終/sim/wrapper.c/sim_resume( )是啟動arm指令執行的地方. Sim_resume( )根據Gdb的要求選擇用/sim/arm/arminit.c/ARMul_DoInstr()還是用/sim/arm/arminit.c/ARMul_DoProg()來調用 流水線模擬函數/sim/arm/armemu.c/ARMul_Emulate32().ARMul_DoInstr()和ARMul_DoProg()的區別就是一個單步執行,一個連續執行指令. ARMul_DoProg()又不停的判斷state->Emulate是否為STOP,如果是,模擬器又將停下等待Gdb的調試. 而在arm/armemu.c, /arm/armvirt.c 和 /arm/armsupp.c中的函數則模擬指令預取,指令譯碼,指令執行以及數據回寫的功能.這三個文件時可以說時Armulator的核心! b. 中斷 Armulator 的中斷機制主要靠以下兩個例程實現: 1.IntPending(): 用來檢測state中的各個中斷標志是否置位,從而判斷是否又需要中斷. 2.ARMul_Abort():當需要中斷時,用來改變處理器模式,并將pc指向相應的中斷向量. 在流水線函數ARMul_Emulate32()執行當中,有多處調用IntPending() 去檢測中斷.而Ispending() 也十分簡單,它僅僅判斷state中的四個變量: State->Exception : 中斷使能標志. State->NresetSig : reset 中斷信號. State->NirqSig : irq 中斷信號. State->NfiqSig : fiq 中斷信號. 所以當你的虛擬外設產生中斷時,你只要調用/sim/arm/armio.c/ update_int()即可: static void update_int(ARMul_State *state) { ARMword requests = state->io.intsr %26;amp; state->io.intmr; state->NfiqSig = (requests %26;amp; 0x000f) ? LOW : HIGH; state->NirqSig = (requests %26;amp; 0xfff0) ? LOW : HIGH; } b. 讀寫操作 無論是CPU指令還是Gdb調試時讀寫內存或IO空間,最后都將要落到/armvirt.c/getword(), /armvirt.c/putword()這兩個函數身上. 在原始代碼中這兩個函數馬上就進行內存數組的讀寫了.而補丁代碼的流程如下: --%26;#224;getword()/putword() --%26;#224;mmu_read_data()/mmu_write_data() in armmmu.c /*進行mmu的地址轉換和cache 查詢*/ --%26;#224; real_read_data()/real_write_data() :讀寫ram,rom io_read_data()/io_write_data() :讀寫IO空間 _write_data()/fail_read_data()/fail_write_data() :非法讀寫,如地址錯誤,rom讀操作等. 可以看出最后幾個函數的選擇是由讀寫地址在相應的mem_bank_t結構中的讀寫函數指針決定的. c. 設備同步 寫這篇文章的初衷是讓讀者能很快進入Armulator的移植和IO擴展的實際工作中去.所以這里有必要討論一下IO設備和CPU的同步問題.很顯然我們模擬的設備不能太快,也不能太慢.快了CPU正常的指令流將被堵塞,慢了就無法反映操作系統的實時性.也就是說設備的速度和指令流要有個比例關系,即要有一定的同步. Armulator 中有個很好的接口: ARMul_ScheduleEvent (ARMul_State * state, unsigned long delay, unsigned (*what) ()) in armvirt.c 它的目的就是注冊你的同步例程,并且每個時鐘周期即ARMul_Emulate32()將調用ARMul_ScheduleEvent()查看是否需要同步你的設備. 也許你在ARMul_Emulate32()中還發現了/sim/arm/armio.c/io_do_cycle(),沒錯它是AT91的timer和uart用來和指令流同步的函數,但我并不贊成你象這樣把自己的同步例程直接放入指令執行過程中,破壞代碼的結構性. a. 源文件描述 The original files The modified codes File descriptions arminit.c arminit.c 初始代碼 armemu.c armemu.c 指令流模擬 armvirt.c armvirt.c 內存讀寫 armsupp.c armsupp.c 輔助指令流模擬 armcopro.c armcopro.c 協處理器模擬(可忽略) armos.c armos.c 初始操作系統(可忽略) armmem.c 內存管理 armmmu.c Mmu模擬 armio.c IO設備模擬 wrapper.c wrapper.c 和Gdb通訊的例程 |
