最近為了畢業論文花了兩個禮拜左右的時間
研究關於Linux Performance Monitoring的相關技術
從原本完全不知道如何做Performance的Monitoring
到發現原來有不少Open Sourced的Performance Monitoring的Tools
像是：SystemTap、LTTng、Ftrace等工具...
以及其底層所實做的技術：Kprobes、Tracepoints、Ptrace...等
在試過幾個不同的技術後
最後決定Kernel Space Tracing
使用Performance Overhead較高 (因為需要插入Breakpoint instructions)
但可以在不更動所欲偵測程式的source code的情況下做Dynamic Analysis的Kprobes
而User Space Tracing則打算使用GNU GDB底層所使用的Ptrace
(原本打算使用Ptrace的增進版 - Utrace，不過由於尚未支援ARM平台所以只好作罷...)
另外為了能讓資料由Kernel Space pass到User Space的Overhead降到最低
所以還稍微研究了Relay (前身為Relayfs)
以及為了提供nanosecond等級的時間精準度
所打算使用的hrtimer (High Resolution Timer)
但人算不如天算...
原先想說大概基本所需要技術都研究的差不多了
剩下的就是跟老師討論實做在我們3D Chip平台上所需的細節後
就可以真正開始設計這套系統...
結果沒想到今天在報告關於Kprobes的進度後
老師又丟了一個新的議題要我解決：
算出Process Context Switch所花的時間
啊吼... 這下真的是在我頭上投下了一個超大顆的震撼彈!!
(難不成是要我去修改Linux Kernel的Scheduler?! 囧rz)
因為不管是Kprobes或是Ptrace...
其原理都是在fucntion的entry或是exit處甚至是function內部再加上int 3的assembly code
(x86、x86_64平台上的breakpoint instruction，也就是soft interrupt)
在對CPU發出soft interrupt後再將控制權轉交給其他的handlers
如此就可以透過此方法來計算function enter及return的timestamps
進而計算出function所花的執行時間，達到Performance Monitoring的功能
但由於Context Switch發生的時間點完全無法預測
因此也無法得知需要在哪個部位下breakpoints
原本是想找理由"婉拒"的
但沒想到老師搬出Linux的time程式
說可以測量出real、user、sys這三種時間
我之前就記得這個程式也只是單純計算程式在User Space及Kernel Space的執行時間
並沒有特別將Context Switch的時間給計算出來...
但因為討論的當下並沒有明確的證據可以證明
老師又很堅持他的論點，所以只好妥協... QQ
果然之後查了user就是程式在User Space所執行的時間
sys就是程式在Kernel Space所執行的時間
而且時間精準度只有second等級 (頂多到millisecond...)
底層實做方法則是透過wait3() system call來實做的
雖然沒有很仔細的好好trace過time的source code
但感覺起來用Kprobes、Ptrace所算出來的時間可能還更精準一點?!
不過有個好消息是我有可能不用作硬體整合
可以專心開發Performance Monitoring Tool了!! (喔耶~ \(●口●)/)
但看來Context Switch的問題勢必是會被要求得解決了?! QQ
目前查了一些資料 是的確有計算Context Switch的Benchmark
(像是：LMbench)
不過還不知道其底層所實做的方法為何就是...
(倒是覺得自己越來越像是在OS Lab了... XDDD)
目前還有另外一個隱憂就是目前測試都是在x86的平台上做的
天曉得移植到板子的ARM平台後又會發生啥鬼事情?!
還有root filesystem若有缺少所需使用的Library可能也得自行想辦法加入... QQ
果然就如同學長所說的
若是他能預測老師的想法他早就畢業了...
這次報告前完全沒想到會有Context Switch相關的問題要解決
沒想到老師還是給它揪了出來!!
老師的想法果真是很難預測..... QQ
就連才要在台灣待兩個月的德國佬今天也被我們老師assign工作要做了
原本以為兩個月的時間應該光瞭解一些基礎知識就差不多要回國哩
但老師還是assign他要用SystemC做一個Flash Memory版的cache
甚至還要求能轉換成RTL下到FPGA上
(不過我想這點時間能完成SystemC modules大概就很不錯了...)
實驗室真的是越來越"強大"了!! <囧>
2010年8月14日 星期六
2010年7月22日 星期四
Recently...
唸研究所滿一年了...
馬上也就要碩一升碩二了~
時間過得真快...
也體會了不少黑暗學術界的辛酸血淚... QQ
當初進研究所的時候是想要專心研究Embedded Linux的
雖然還是有做到Device Driver相關的Maintenance
不過最後還是被老闆抓去做硬體整合... Orz
能有機會學到以前輔大不太常碰到的硬體是個還蠻難得的機會
而且軟體寫久了也會想瞭解一下最底層的硬體是怎樣在運作的
不過整合最討厭的就是得先等到別人開發到一定的程度後才能開始工作
(就某方面來說這也很像Device Driver的開發
必須等到軟/硬體都有一定的程度侯才能驗證自己寫的是否正確無誤... QQ)
再加上設計者不是自己
因此只能單純就Bus上的行為來觀察IP是否正常運作
沒問題的話倒還好...
機車的就是當問題發生的時候常常不知道為啥會出錯!!!!!
有可能是我們自己整合的時候有修改到錯的地方
也有可能是他們本身設計上的錯誤...
雖然目前主要還是學長在處理這方面的問題
不過看了真的是覺得沒啥勁.....
而且之後還要把我們實驗室的CPU和ICE一起給整進去
最後還要能Tape out成一顆晶片回來!!
(聽說光排隊等Tape out就要一、兩個月?! QQ)
一想到就整個頭很大..................... <囧>
原本以為自己碩士畢業論文大概就是跟軟/硬體整合相關的了
沒想到上週老闆又提起了當初他所提的軟/硬體效能監測工具的東西出來
這次再被提就真的是逃不掉了...
硬著頭皮就是得給它做出來才行!!
一開始對軟體的效能監測一直都沒啥頭緒
只知道用最簡單的printf()或是printk()來印出所執行的時間
但這些function calls本身的overhead就非常重
而且若想要移植到新的應用程式就得重新寫過
對效能和可移植性來說都是非常不好的方法
再加上在有OS的情況下因為OS Scheduler的關係...
要針對各個應用程式來監測便變得更加的困難
因此勢必得從Kernel層本身來下手
在書上無意間看到了LTTng (Linux Trace Toolkit Next Generation) 這套工具
查了以後才發現這是套非常強大的Open-Sourced的軟體
不但可以針對Kernel Space及User Space來監測其效能
甚至還提供了LTTV (LTTng Viewer) 這套GUI介面的軟體來分析其所擷取的效能分析結果
而且最棒的是作者在他的官方網頁上都有放他所投出去的Papers和Presentations
連他自己的博士論文都完整的放在網頁上供人點閱
也就此瞭解到了不少Kernel Source本身
或是別人release的Kernel Patches來協助完成tracing / debugging的功能
像是：
GNU GDB和strace所使用的ptrace() system call
Kprobes
LTTng作者：Mathieu Desnoyers (神人!!) 所開發的Kernel Marker和Tracepoints
IBM工程師特別針對Device Driver tracing / debugging的Linux Driver Tracing Interface (DTI)
以及relay (前身為relayfs)
希望在研究後也可以設計出自己一套基本的軟/硬體效能監測的工具!! XDDD
另外Linux Symposium也是一個超棒的研討會
很多Mainline Linux Kernel所包含的技術都有在這研討會上發表過Papers
(還蠻希望未來能有一天可以參加這種研討會的... XDDD)
前兩天還去上了國家晶片研究中心(CIC)開的Bootloader的課程
對程式底層架構、Linker script和U-boot也終於是有了一點概念...
不過ARM的assembly code實在是很不熟!! QQ
雖然還沒開始正式接觸到硬體設計的部份
不過就目前來說還是對Linux Kernel比較有興趣點... >M<"
而且這也比較符合當初進研究所希望做的Linux Kernel相關研究
自己也能比較有自己的進度 不用每次都要等別人修改
(但Overloading也跟著變重很多就是... QQ)
還不曉得最近看的東西是否真的可以用在我們實驗室的平台上
x86或x64平台的支援還是比ARM要完整的多了...
而且我們實驗室用的板子是廠商自己開發的
相對於有Open-Sourced支援的Versatile平台限制可能也會多了不少?!
還是得花時間再研究一下其可行性才行.....
希望這真的是我最後的畢業題目了...
之前做的事情對老師來說真的只是在"練功"
而且就"練功"而言來說還真的是不太好練... <囧>
現在的Overloading已經接近滿載!!
而且還有要帶學弟...etc 的事情要弄
再被assigned其他的東西要做我就真的是要先自爆嚕!!!!! (●皿●)"
另外最重要的當然就是希望能兩年準時畢業啦!! XDDD
馬上也就要碩一升碩二了~
時間過得真快...
也體會了不少黑暗學術界的辛酸血淚... QQ
當初進研究所的時候是想要專心研究Embedded Linux的
雖然還是有做到Device Driver相關的Maintenance
不過最後還是被老闆抓去做硬體整合... Orz
能有機會學到以前輔大不太常碰到的硬體是個還蠻難得的機會
而且軟體寫久了也會想瞭解一下最底層的硬體是怎樣在運作的
不過整合最討厭的就是得先等到別人開發到一定的程度後才能開始工作
(就某方面來說這也很像Device Driver的開發
必須等到軟/硬體都有一定的程度侯才能驗證自己寫的是否正確無誤... QQ)
再加上設計者不是自己
因此只能單純就Bus上的行為來觀察IP是否正常運作
沒問題的話倒還好...
機車的就是當問題發生的時候常常不知道為啥會出錯!!!!!
有可能是我們自己整合的時候有修改到錯的地方
也有可能是他們本身設計上的錯誤...
雖然目前主要還是學長在處理這方面的問題
不過看了真的是覺得沒啥勁.....
而且之後還要把我們實驗室的CPU和ICE一起給整進去
最後還要能Tape out成一顆晶片回來!!
(聽說光排隊等Tape out就要一、兩個月?! QQ)
一想到就整個頭很大..................... <囧>
原本以為自己碩士畢業論文大概就是跟軟/硬體整合相關的了
沒想到上週老闆又提起了當初他所提的軟/硬體效能監測工具的東西出來
這次再被提就真的是逃不掉了...
硬著頭皮就是得給它做出來才行!!
一開始對軟體的效能監測一直都沒啥頭緒
只知道用最簡單的printf()或是printk()來印出所執行的時間
但這些function calls本身的overhead就非常重
而且若想要移植到新的應用程式就得重新寫過
對效能和可移植性來說都是非常不好的方法
再加上在有OS的情況下因為OS Scheduler的關係...
要針對各個應用程式來監測便變得更加的困難
因此勢必得從Kernel層本身來下手
在書上無意間看到了LTTng (Linux Trace Toolkit Next Generation) 這套工具
查了以後才發現這是套非常強大的Open-Sourced的軟體
不但可以針對Kernel Space及User Space來監測其效能
甚至還提供了LTTV (LTTng Viewer) 這套GUI介面的軟體來分析其所擷取的效能分析結果
而且最棒的是作者在他的官方網頁上都有放他所投出去的Papers和Presentations
連他自己的博士論文都完整的放在網頁上供人點閱
也就此瞭解到了不少Kernel Source本身
或是別人release的Kernel Patches來協助完成tracing / debugging的功能
像是：
GNU GDB和strace所使用的ptrace() system call
Kprobes
LTTng作者：Mathieu Desnoyers (神人!!) 所開發的Kernel Marker和Tracepoints
IBM工程師特別針對Device Driver tracing / debugging的Linux Driver Tracing Interface (DTI)
以及relay (前身為relayfs)
希望在研究後也可以設計出自己一套基本的軟/硬體效能監測的工具!! XDDD
另外Linux Symposium也是一個超棒的研討會
很多Mainline Linux Kernel所包含的技術都有在這研討會上發表過Papers
(還蠻希望未來能有一天可以參加這種研討會的... XDDD)
前兩天還去上了國家晶片研究中心(CIC)開的Bootloader的課程
對程式底層架構、Linker script和U-boot也終於是有了一點概念...
不過ARM的assembly code實在是很不熟!! QQ
雖然還沒開始正式接觸到硬體設計的部份
不過就目前來說還是對Linux Kernel比較有興趣點... >M<"
而且這也比較符合當初進研究所希望做的Linux Kernel相關研究
自己也能比較有自己的進度 不用每次都要等別人修改
(但Overloading也跟著變重很多就是... QQ)
還不曉得最近看的東西是否真的可以用在我們實驗室的平台上
x86或x64平台的支援還是比ARM要完整的多了...
而且我們實驗室用的板子是廠商自己開發的
相對於有Open-Sourced支援的Versatile平台限制可能也會多了不少?!
還是得花時間再研究一下其可行性才行.....
希望這真的是我最後的畢業題目了...
之前做的事情對老師來說真的只是在"練功"
而且就"練功"而言來說還真的是不太好練... <囧>
現在的Overloading已經接近滿載!!
而且還有要帶學弟...etc 的事情要弄
再被assigned其他的東西要做我就真的是要先自爆嚕!!!!! (●皿●)"
另外最重要的當然就是希望能兩年準時畢業啦!! XDDD
2010年5月6日 星期四
Embedded Linux mounting NFS in VMWare
今天一整個下午都在研究...
為啥我要mount我Host端架的NFS Server會一直mount不到
看CDK板的Spec. 說明看了老半天
IP一直換換換 結果每次要mount NFS的時候都會出現：
mount: RPC: Unable to receive; errno = No route to host
而且不管由Host端的OS ping板子
或是由板子ping回Host端的OS 都ping不到...
搞了一整個下午才發現原來因為我是用Windows + Linux @ VMWare
然後NFS Server也是架在VMWare裡面的Linux
但只設定了板子和Linux的IP
忘了設定Windows網卡的IP
所以不管是Linux @ VMWare → Windows → CDK板
或是CDK板 → Windows → Linux @ VMWare
都會因為Windows的網卡沒有設在同一個網段
所以中間的連線會被斷掉...
試了一整個下午才想到有可能是這個原因
浪費了自己一個下午的時間在那邊IP改過來改過去的...
多個VMWare在中間就真的要多注意一下中間橋接連線的設定... QQ
最後補上各個部份網路的設定：
Linux @ VMWare：
----------------------------------------------
IP address：10.168.1.166
Network Mask：255.255.255.0
GateWay IP：10.168.1.254
Windows：
----------------------------------------------
IP address：10.168.1.168
Network Mask：255.255.255.0
GateWay IP：10.168.1.254
CDK板：
----------------------------------------------
IP address：10.168.1.214
Network Mask：255.255.255.0
GateWay IP：10.168.1.254
其實只要確定IP address都是在同一個網段 + 使用同一個Gateway
就可以透過跳線來做連線了...
另外如果是用筆電的話記得也要把無線網路給關掉
不然VMWare可能會變成去抓無線網路的連線
導致連不到我們想要連線的網卡...
還有如果使用的NFS Server屬於比較舊版本的
就必須在mount的時候加上：-o nolock 的參數
nolock 參數是禁用文件鎖 (disable file locking) 的功能
不然在mout的時候就會出現：
portmap: server localhost not responding, timed out
RPC: failed to contact portmap (errno -5)
portmap: server localhost not responding, timed out
RPC: failed to contact portmap (errno -5)
lockd_up: makesock failed, error=-5
portmap: server localhost not responding, timed out
RPC: failed to contact portmap (errno -5)
mount: mounting 10.168.1.166:/home/sys3d/Desktop/3DG on 3DG failed
的錯誤訊息...
加上 -o nolock 參數後就可以正常mount NFS的資料夾了：
mount -t nfs -o nolock 10.168.1.166:/home/sys3d/Desktop/3DG 3DG
(正確不會有錯誤訊息)
不過令我有點納悶的是我是用Ubuntu 10.04 LTS當我Host端的OS
NFS也是用apt套件直接安裝最新版的...
結果還是要加上 -o nolock 參數
那不知道到底怎樣才不算舊版的NFS Server哩...?! Orz
P.S. HyperTerminal我覺得PuTTY比minicom好用多了... XDDD
為啥我要mount我Host端架的NFS Server會一直mount不到
看CDK板的Spec. 說明看了老半天
IP一直換換換 結果每次要mount NFS的時候都會出現：
mount: RPC: Unable to receive; errno = No route to host
而且不管由Host端的OS ping板子
或是由板子ping回Host端的OS 都ping不到...
搞了一整個下午才發現原來因為我是用Windows + Linux @ VMWare
然後NFS Server也是架在VMWare裡面的Linux
但只設定了板子和Linux的IP
忘了設定Windows網卡的IP
所以不管是Linux @ VMWare → Windows → CDK板
或是CDK板 → Windows → Linux @ VMWare
都會因為Windows的網卡沒有設在同一個網段
所以中間的連線會被斷掉...
試了一整個下午才想到有可能是這個原因
浪費了自己一個下午的時間在那邊IP改過來改過去的...
多個VMWare在中間就真的要多注意一下中間橋接連線的設定... QQ
最後補上各個部份網路的設定：
Linux @ VMWare：
----------------------------------------------
IP address：10.168.1.166
Network Mask：255.255.255.0
GateWay IP：10.168.1.254
Windows：
----------------------------------------------
IP address：10.168.1.168
Network Mask：255.255.255.0
GateWay IP：10.168.1.254
CDK板：
----------------------------------------------
IP address：10.168.1.214
Network Mask：255.255.255.0
GateWay IP：10.168.1.254
其實只要確定IP address都是在同一個網段 + 使用同一個Gateway
就可以透過跳線來做連線了...
另外如果是用筆電的話記得也要把無線網路給關掉
不然VMWare可能會變成去抓無線網路的連線
導致連不到我們想要連線的網卡...
還有如果使用的NFS Server屬於比較舊版本的
就必須在mount的時候加上：-o nolock 的參數
nolock 參數是禁用文件鎖 (disable file locking) 的功能
不然在mout的時候就會出現：
portmap: server localhost not responding, timed out
RPC: failed to contact portmap (errno -5)
portmap: server localhost not responding, timed out
RPC: failed to contact portmap (errno -5)
lockd_up: makesock failed, error=-5
portmap: server localhost not responding, timed out
RPC: failed to contact portmap (errno -5)
mount: mounting 10.168.1.166:/home/sys3d/Desktop/3DG on 3DG failed
的錯誤訊息...
加上 -o nolock 參數後就可以正常mount NFS的資料夾了：
mount -t nfs -o nolock 10.168.1.166:/home/sys3d/Desktop/3DG 3DG
(正確不會有錯誤訊息)
不過令我有點納悶的是我是用Ubuntu 10.04 LTS當我Host端的OS
NFS也是用apt套件直接安裝最新版的...
結果還是要加上 -o nolock 參數
那不知道到底怎樣才不算舊版的NFS Server哩...?! Orz
P.S. HyperTerminal我覺得PuTTY比minicom好用多了... XDDD
2010年4月16日 星期五
Linux device driver access physical address
一般我們在寫嵌入式系統 Stand alone (Non-OS) 的程式時
如果想存取一段Physcial address
通常我們會以下面的方式來定義指標：
#define CLCDC_BASE (volatile unsigned long *) 0x10120000;
如果想要取得其值則會定義為：
#define CLCDC_R0 *((volatile unsigned long *) 0x10120000);
如此在存取CLCDC_R0值時，就是在對該Physical address做存取：
CLCDC_R0 = 123;
但如果現在在有OS的情況下
由於OS會有記憶體保護的機制
因此user space的應用程式都無法如同Stand alone的程式直接對某段Physical address做存取
至於device driver也必須使用ioremap()函式來將一段Physical address映射到一段Virtual address才能夠存取：
void * ioremap(unsigned long phys_addr, unsigned long size);
今天剛好有機會測試到這兩種方法在Linux內所會造成結果的差別...
因為VersatilePB板上的Color LCD Controller (CLCDC)
(其在VersatilePB板上的Base address為：0x1012000，Size為：64KB)
會在啟動時將記憶體某一個區段map為frame buffer來使用
而其使用的記憶體位置會存在CLCDC中的某一個register內
因為要將資料輸出到frame buffer中
因此必須先取得該register所存放frame buffer的physical address...
一開始是先使用一般嵌入式系統Stand alone (Non-OS) 程式的方式來取得該值：
static unsigned long clcdc_base = *((volatile unsigned long *) 0x10120000);
再將我要輸出的資料指定給frame_buffer變數
結果可以正常Compile
但放到QEMU所模擬的VersatilePB環境，insmod時...
就會噴出：
Unable to handle kernel paging request at virtual address 10120000
的錯誤訊息...
在搜尋一些網頁後才發現一般這樣使用在Kernel中會被視為Virtual address
但因為Kernel並沒有map這段Virtual address到某段Physical address
所以沒辦法做轉換，因此噴出錯誤訊息...
正確的使用方法應該先將此Physical address透過ioremap()函式映射到一段Virtual address
之後再對該Virtual address做存取：
static unsigned long clcdc_base = ioremap(0x10120000, 64 * 1024);
如此便可正確存取到CLCDC的registers了...
事後想想其實自己原本就有利用ioremap()來存取我們3D晶片上的registers
結果想再新增一個功能頭腦反而就轉不過來了... <囧>
不過這也算是一個還不錯的經驗...
發現原來就算是在kernel space中也是必須透過ioremap()才能存取Physcial address的...
P.S.
根據定義... ioremap()所回傳的Virtual address
是不可被直接存取，而是必須間接透過Kernel所提供的存取函式的
ex：ioread8()、ioread16()、ioread32()、iowrite8()、iowrite16()、iowrite32()、memset_io()、memcpy_fromio()、memcpy_toio() ...etc
但這次改之前OS Lab所留下來的device driver
卻發現全都是直接存取ioremap()所回傳的Virtual address
或許這不是正確的寫法?!
(不過仍然可以跑就是.....)
哪天有機會再把它改掉看看是不是也能正常使用?! XDDD
最近device driver寫得差不多了
(改人家寫的都馬寫得很快... Orz)
原本畢業論文要做效能分析的程式被中途喊卡
老闆改叫我去接學長做軟/硬體整合的工作
原先進來這個實驗室的時候就是只想focus在OS部份，不想看wave form的!!
看來這下真的是沒得選了... QQ
接下來就要開始嗑 AMBA AHB / AXI 的bus protocal spec. 哩...
或許能有這個機會接觸到平常碰不太到的硬體也是個不錯的經驗?!
希望最後不會做不出來就好... QQ
不過最好佳在的是現在老闆"有機會"放寬他的條件，大家都有機會兩年畢業了.......................... 吧?!
誠心希望這張支票最後不會跳票... (●皿●)"
如果想存取一段Physcial address
通常我們會以下面的方式來定義指標：
#define CLCDC_BASE (volatile unsigned long *) 0x10120000;
如果想要取得其值則會定義為：
#define CLCDC_R0 *((volatile unsigned long *) 0x10120000);
如此在存取CLCDC_R0值時，就是在對該Physical address做存取：
CLCDC_R0 = 123;
但如果現在在有OS的情況下
由於OS會有記憶體保護的機制
因此user space的應用程式都無法如同Stand alone的程式直接對某段Physical address做存取
至於device driver也必須使用ioremap()函式來將一段Physical address映射到一段Virtual address才能夠存取：
void * ioremap(unsigned long phys_addr, unsigned long size);
今天剛好有機會測試到這兩種方法在Linux內所會造成結果的差別...
因為VersatilePB板上的Color LCD Controller (CLCDC)
(其在VersatilePB板上的Base address為：0x1012000，Size為：64KB)
會在啟動時將記憶體某一個區段map為frame buffer來使用
而其使用的記憶體位置會存在CLCDC中的某一個register內
因為要將資料輸出到frame buffer中
因此必須先取得該register所存放frame buffer的physical address...
一開始是先使用一般嵌入式系統Stand alone (Non-OS) 程式的方式來取得該值：
static unsigned long clcdc_base = *((volatile unsigned long *) 0x10120000);
再將我要輸出的資料指定給frame_buffer變數
結果可以正常Compile
但放到QEMU所模擬的VersatilePB環境，insmod時...
就會噴出：
Unable to handle kernel paging request at virtual address 10120000
的錯誤訊息...
在搜尋一些網頁後才發現一般這樣使用在Kernel中會被視為Virtual address
但因為Kernel並沒有map這段Virtual address到某段Physical address
所以沒辦法做轉換，因此噴出錯誤訊息...
正確的使用方法應該先將此Physical address透過ioremap()函式映射到一段Virtual address
之後再對該Virtual address做存取：
static unsigned long clcdc_base = ioremap(0x10120000, 64 * 1024);
如此便可正確存取到CLCDC的registers了...
事後想想其實自己原本就有利用ioremap()來存取我們3D晶片上的registers
結果想再新增一個功能頭腦反而就轉不過來了... <囧>
不過這也算是一個還不錯的經驗...
發現原來就算是在kernel space中也是必須透過ioremap()才能存取Physcial address的...
P.S.
根據定義... ioremap()所回傳的Virtual address
是不可被直接存取，而是必須間接透過Kernel所提供的存取函式的
ex：ioread8()、ioread16()、ioread32()、iowrite8()、iowrite16()、iowrite32()、memset_io()、memcpy_fromio()、memcpy_toio() ...etc
但這次改之前OS Lab所留下來的device driver
卻發現全都是直接存取ioremap()所回傳的Virtual address
或許這不是正確的寫法?!
(不過仍然可以跑就是.....)
哪天有機會再把它改掉看看是不是也能正常使用?! XDDD
最近device driver寫得差不多了
(改人家寫的都馬寫得很快... Orz)
原本畢業論文要做效能分析的程式被中途喊卡
老闆改叫我去接學長做軟/硬體整合的工作
原先進來這個實驗室的時候就是只想focus在OS部份，不想看wave form的!!
看來這下真的是沒得選了... QQ
接下來就要開始嗑 AMBA AHB / AXI 的bus protocal spec. 哩...
或許能有這個機會接觸到平常碰不太到的硬體也是個不錯的經驗?!
希望最後不會做不出來就好... QQ
不過最好佳在的是現在老闆"有機會"放寬他的條件，大家都有機會兩年畢業了.......................... 吧?!
誠心希望這張支票最後不會跳票... (●皿●)"
2010年3月16日 星期二
Google Sites...
今天被專題生問到我畢業專題Drupal的東西
因為他們軟工也想架一個簡單賣東西的網站
好奇問了一他怎會知道我做這個
結果才發現原來他是看到我Google Sites的文章
那時候做的Portfolio被學弟無聊逛到...
真是懷念~
果然放在網路上的東西很有可能會在某一天被某人給挖出來... XDDD
倒是Portfolio都沒在更新了...
等研究所唸完可以再把東西好好給它更新一下
希望這不會是兩、三年以後的事..... QQ
想到這就想到我們大四電子商務的osCommerce!!
一門很喇賽又很歡樂的課...
當初修得還蠻快樂的說~
還讓我想到當時有個女的不知道是喝酒還是嗑藥?!
在台上一直瘋言瘋語的... 真是有趣~ XDDD
雖然osCommerce的模組化真的是很鳥...
(還要修改程式碼才能把新的模組給加上去 =M=a)
跟Drupal來說完全沒得比~
但osCommerce的確比較符合他們的需求
至少不用再去找特別的模組就可以達到他們的基本要求了...
所以最後還是推薦他們使用osCommerce
喚起我大學的回憶..... >///<
因為他們軟工也想架一個簡單賣東西的網站
好奇問了一他怎會知道我做這個
結果才發現原來他是看到我Google Sites的文章
那時候做的Portfolio被學弟無聊逛到...
真是懷念~
果然放在網路上的東西很有可能會在某一天被某人給挖出來... XDDD
倒是Portfolio都沒在更新了...
等研究所唸完可以再把東西好好給它更新一下
希望這不會是兩、三年以後的事..... QQ
想到這就想到我們大四電子商務的osCommerce!!
一門很喇賽又很歡樂的課...
當初修得還蠻快樂的說~
還讓我想到當時有個女的不知道是喝酒還是嗑藥?!
在台上一直瘋言瘋語的... 真是有趣~ XDDD
雖然osCommerce的模組化真的是很鳥...
(還要修改程式碼才能把新的模組給加上去 =M=a)
跟Drupal來說完全沒得比~
但osCommerce的確比較符合他們的需求
至少不用再去找特別的模組就可以達到他們的基本要求了...
所以最後還是推薦他們使用osCommerce
喚起我大學的回憶..... >///<
訂閱：
文章 (Atom)