wiggler是完成一個從并口到jtag header串行信號的轉換功能,僅僅是一個電路,wiggler上面沒有固件。調試軟件向并口寫入調試命令,通過wiggler即可轉換成相應的jtag信號。開發(fā)機上的調試軟件客戶端(sdt中的axd,ads中的adw,gdb client)不需要作改動,但是需要調試服務器,比如cfly網站上的jtag.exe,以及redhat網站上提到的gdb-server for multiiice。調試服務器要做的是把來自調試器的命令轉換成合適的對并口的訪問,并口得到的信號通過wiggler直接轉換成jtag信號。比如,jtag.exe我猜想它是一個在某個已知端口等待的服務器程序(用dumpbin可以看到它引入了socket dll ws2_32.dll),sdt axd調試器本身支持遠程調試,所以可以在開發(fā)環(huán)境中把遠程IP設置成本機ip地址和jtag.exe所等待的端口號。這樣,axd的調試命令就會由jtag.exe得到,他根據這些命令(具體的協議為arm的rdi/adp?)向并口寫入合適的值。
再舉一個例子,redhat網站上提到的gdb-server-multiice(cygwin)。本來sdt支持通過multiice的調試(multiice的實現原理應該比較向下面的bdigdb),sdt通過集成一個multice.dll插件(相當于上面提到的jtag.exe的腳色,只不過它因為是arm 公司的產品,他們清楚sdt的插件機制,所以該dll可以集成到sdt中去)訪問multiice,multiice負責根據收到的命令轉換成對板子jtag口的訪問。但gdb不支持通過multiice調試,為了在cygwin中通過multiice用gdb調試目標機,可以在開發(fā)機上跑一個gdbserver。該gdbserver做的和gdb交互(根據gdb遠程調試協議),然后將得到的調試命令轉換成multiice.dll的相關調用,就是說它通過multiice.dll將命令發(fā)出去,而不是像jtag.exe那樣直接發(fā)給并口,也就是說這里其實又多了一層間接。
仔細想一下,其實連接jtag仿真器的pc,與運行調試器客戶端的pc其實應該可以不是同一個機器的。這是因為axd和gdb都支持遠程調試,即使在一臺機器上也是通過遠程網絡連接的方式訪問jtag.exe/gdb-server-multiice。有條件的不妨試一試驗證一下,反正我沒這個條件,我連一臺arm目標板都沒有 :
bdigdb是一個比較高級的ocd 仿真器,它可以調試Linux內核。他本身就是一個帶有mcu(好像是68000)、flash、ram的典型的嵌入式系統(tǒng)。他還有cpld,針對不同的目標處理器,它只需要更新cpld和固件即可實現對另一種目標的支持。哪位解釋一下這里cpld的道理?我是真的搞不懂硬件的東東阿。
其固件應該是實現了一個gdbserver,所以開發(fā)機上的調試器客戶端(gdb client)就不需要做任何修改。gdb客戶端使用gdb的調試協議通過ethernet接口與bidgdb上的gdbserver交互(比如,target remote ip_of_bdigdb port_of_gdbserver_on_bdigdb),bdigdb上的gdbserver根據得到的命令決定應該向jtag口寫如什么命令。另外,bdigdb得一大特點是支持帶mmu的linux內核調試,我猜想他可能是在gdbserver的實現中集成了一個從虛擬地址到物理地址的轉換機制,調試時gdbserver將從gdb來得虛擬地址轉換成物理地址,再根據該物理地址去訪問目標機內存空間。至于轉換機制如何得到,與linux在具體體系結構上的實現有關,比如在x86上一般物理地址加上0xc0000000就得到虛擬地址,在其他體系
結構入ppc,xscale上也可能有相應的轉換辦法,這個有待研究。對了,據說abtron bdi跟montavista linux關系密切,聽說montavista特意在arch/xxx/kernel/head-xxx.s中加入了針對bdi調試的的支持代碼。如果沒有這個支持的話,一般.....也許....好像....就是剛才提到的用把虛擬地址減去0xc0000000來轉換了,呵呵,還得研究
www.ocdemon.com 網站上free software欄目下,提供了上面提到的適合于gdb的gdbserver,它叫l(wèi)ibremote。libremote可以支持多種目標機。





