跳到主要內容

發表文章

目前顯示的是 10月, 2013的文章

淺讀CuRT:task, context switch與scheduling

上一篇 整理了CuRT從硬體上電後到跳入C function前所作的事情,本篇文章則會紀錄CuRT如何準備multitasking環境,以及CuRT於執行期的行為分析。 在app/shell/main.c中,我們可以看到main()的開頭為: int main() {         SerialInit();         init_interrupt_control();         init_curt(); ... SerialInit()只是把UART port初始化,方便printf()可以正常運作。init_interrupt_control()則設定pxa255的interrupt controller可以接收外部的interrupt sources,稍後啟動的timer就會發出定期的interrupt驅動scheduling。init_curt()作的事情就比較多了點,讓我們進去瞧一瞧: void init_curt() {         int i;         for (i = 0; i < MAX_PRIO; i++) {                 prio_exist_flag[i] = false;                 init_list(&ready_list[i]);         }         init_list(&delayed_list);         init_list(&blocked_list);         init_list(&termination_wai...

淺讀CuRT:啟動流程

Jserv 所寫的 CuRT 是一個非常輕量級的kernel,運行於ARMv5( PXA255 )。很適合拿來作為熟習ARM基本架構與實驗作業系統的各項技術。今天下載後,發現在我的環境(ubuntu12.04)需要作點修改才能通過編譯並正常執行,改完索性clone了一份上 github ,以利之後實驗修改。這篇文章則是為研讀此kernel所作的一系列紀錄的開頭。 千頭萬緒,從何開始呢?ARM規範其CPU reset後從0x0的位址開始執行,從PXA255的 手冊 上可知,初始的0x0落於boot ROM的範圍: 但是觀察編譯出來的curt_image.elf可以發現,其link address都以0xa0000000為base,這段位址落於SDRAM的範圍: 由於SDRAM必須要有controller控制時序,所以應該會先由boot ROM將其設定好後再搬過去執行。以上幾件事要能夠運行成功,那麼就勢必在初始時要有一段PIC的程式作relocation(或以某種方式remap address range),等等我們便可發現確實存在這樣的一段代碼。 觀察curt_image.elf的disassembly可知道,_start是.text的起頭,此符號定義於arch/arm/mach-pxa/start.S,所以我們就從這個檔案開始看起吧。:-) .text /* exception handler vector table */ _start: b reset_handler b und_handler b swi_handler b abt_pref_handler b abt_data_handler b not_used b irq_handler b fiq_handler 這邊是典型的reset vector的部份,由於除了reset_handler以外的其他mode我目前還不感興趣,所以就直接跳到reset_handler繼續看: reset_handler:  b set_misc set_misc: ... mask_off_int_reg: /* Mask off all IRQs and FIQs */ ... init_clock_reg: /* PXA250...

scheduler實作技巧於FPGA驗證上的應用

在IC設計公司,有一部分的軟體工程師需要與IC設計師緊密合作,負責驗證相關硬體模組功能與驅動程式撰寫。在硬體設計初步完工階段,通常會先在FPGA上進行邏輯方面的軟體驗證,通常軟體在此時會以最簡單的方式,準備好C語言運行環境後,進行bare metal上的控制,確認無誤後,才送交後端進行timing的調整。如果是功能較為豐富的SoC,還會在FPGA上運行完整的作業系統(如Linux),確認在實際應用情況下,所有功能仍然如預期般執行。 bare metal控制的好處是環境單純。容易確認問題是在某個步驟所發生,而且執行效率極高。另一方面,運行作業系統的好處不言而喻,但缺點就是摻雜了太多額外不相干的環節,並且由於FPGA效能問題,一段時間能進行的測試次數相較於bare metal的環境往往少一個數量級以上。所以,我們有時會需要以bare metal為基礎,往上逐漸添加部份系統功能以協助驗證工作。 其中一項常見的需求就是: bare metal環境通常沒有多工能力,但我們需要確認某幾個硬體功能"同時"運作時,是否會有系統執行問題?(bus hanged, interrupt lost, hardware state錯亂...) 為了這項功能,許多人的選擇是想辦法運行完整的作業系統來確認,但在初期的環境準備與後續的除錯,都常常耗費大量不必要的精力與時間。所以有些人則是在bare metel的環境下,以各種怪招來實現不同硬體動作"同時"運行的效果,比如說在某個硬體的ISR中,去驅動另一個硬體的read/write。這種作法往往誨澀難懂,並且掛一漏萬。 其實如果只是要達成上述需求,我們可以有更乾淨的作法:一個簡單的scheduler。只需要準備: context switch task structure與其獨立的stack timer interrupt ramdom timeslot for task 而task間的同步機制通常直接開/關中斷,也就足夠了。不太需要實作完整的task state machine。也就是說,基本上只要將" 一步步寫嵌入式操作系統 "一書的最後一章的範例程式稍作修改,即可備妥以上基礎設施(大概不到200行C與assembly)。有圖有真相,以下是我在實際...