ubifs 應用案例

1. 環境
CPU : Freescale MX27
NAND FLASH : Samsung K9F2G08U0B, 2Gbits = 256MB
操作系統: linux
內核版本: 2.6.27

2. linux 編譯選項
2.2 支持UBI
Device Drivers  ---> 
<*> Memory Technology Device (MTD) support  --->    
    [*]   MTD partitioning support
    <*>   NAND Device Support  --->
    UBI - Unsorted block images  ---> 
        <*> Enable UBI 

2.3 支持UBIFS 文件系統
File systems  --->
Miscellaneous filesystems  --->
    <*> UBIFS file system support

3. linux 啟動命令行參數

noinitrd console=ttymxc0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs rw ip=off init=/linuxrc video=imx-fb:Innolux-WVGA

我們的flash 在內核裡被分為三個 mtd 區: bootloader, kernel, filesystem. 因此 ubi.mtd=2, 即選中第三個 mtd 分區作為 ubifs 根分區. 至於 ubi0:rootfs 則跟創建文件系統鏡像時的 *.cfg 有關.

需要注意的是, 很多 bootloader 會覆蓋 linux 本身的默認命令行參數, 所以, 如果存在這樣的 bootloader 就必須修改 bootloader 調用 linux 時的命令行參數! 否則 ubifs 完全不起作用.

4. 創建 ubifs 文件系統鏡像

mkfs.ubifs -m 2048 -e 129024 -c 992 -r filesystem_base filesystem_base.ubifs

ubifs 文件系統鏡像不能直接寫入 flash, 需要再根據這個生成的 ubifs 格式的文件系統鏡像生成 ubi 鏡像才能直接寫入 flash .

參數 "-m" : 為 flash 分頁大小, 可從 nand flash 的 datasheet 得知. 有些 flash 的分頁會有附加空間, 如我們所使用的這個 flash 每個分頁就帶有 64 字節的附加空間(1), 附加空間不計入我們的 -m 參數中!

參數 "-e" : 把 128KiB 減去一個分頁(2048)大小, 則等於 129024. 如果加載 ubifs 出現類似以下的錯誤:
UBIFS error (pid 1): validate_sb: LEB size mismatch: 131072 in superblock, 129024 real
則以那個 real 值為準!

參數 "-c" : 最大邏輯刷寫塊數量, 似乎可以是任意數值, 只要不超過邏輯塊總數即可.

5. 創建 ubi 鏡像

ubinize -o ubi.img -m 2048 -p 128KiB -s 512 -O 512 ubiimage.cfg

參數 "-m" : 參考 4. 中的 "-m" 參數

參數 "-p" : 為一次性擦除塊的大小, 可從 nand flash 的 datasheet 得知. 附加空間不計在內.

參數 "-s" : 與 -O 必須一致, 分頁子頁大小, 似乎跟 flash 的分頁組成有關, 似乎我們所用的 flash 每一頁由4 個子分頁組成, 一個子分頁為 512. 當出現以下錯誤時:
UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512.
則以 expected 值為準.

其中 ubiimage.cfg 內容如下:

[ubifs]
mode=ubi
image=filesystem_base.ubifs
vol_id=0
vol_size=100MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize

6. 燒寫並啟動

把 5. 裡生成的 ubi.img 燒寫進板子, 啟動, 當出現類似以下信息時表示, ubifs 已經成功加載:

UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd2 to ubi0
UBI: MTD device name:            "nand.rootfs"
UBI: MTD device size:            123 MiB
UBI: number of good PEBs:        985
UBI: number of bad PEBs:         6
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 985
UBI: number of PEBs reserved for bad PEB handling: 9
UBI: max/mean erase counter: 1/0

7. 註釋
(1) 附加空間可以使用也可以不用, 一般用於存儲文件系統的附帶信息.

8. 錯誤信息
8.1 UBIFS error (pid 1): validate_sb: LEB size mismatch: 131072 in superblock, 129024 real
參考 4. 參數 "-e".

8.2 UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512.
參考 5. 參數 "-s".

8.3 UBI warning: ubi_io_read_ec_hdr: no EC header found at PEB 845, only 0xFF bytes
可忽略, 剛刷寫完的, 很多這種提示.

8.4 VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0 ...
mtd分區不是 ubi 格式 或者 創建 ubi 鏡像時的 cfg 文件有誤.

UDP下嘅實時音視頻傳輸機制

經歷咗一兩年係項目當中嘅實時音視頻實踐, 覺得要實現好嘅實時音視頻傳輸實屬不易. 以下呢套UDP下嘅實現流程, 係血嘅經驗, 每一點都是來之不易.

全局要點: 視頻可跳, 但聲音不斷.

1. 發送方

(1). 開始時, 編碼I幀, 發送

(2). 接著, 發P幀 ( 聲音與視頻編碼是不同的, 每次真實發送幀前, 讀取錄音緩沖區, 並打包 ), 發N個P幀後, 跳到(1)

(3). 如果在發P幀過程中, 接收到對方發來的 "重發I 幀" 請求, 馬上放棄目前所編碼的幀(視頻幀,不是聲音幀), 跳轉到 (1)

2. 接收方
(1). 建立幀列表, 至少存儲3幀以上才開始播放, 使用順序插入法, 尋找相應幀序號的位置, 並插入.

(2). 播放開始時, 不停從幀列表中取得一幀(由於此時幀列表是順序的,故此取列表頭的那一幀即可), 如果是P幀時則放棄, 直到找到I幀才開始真正播放. 聲音幀不需要等I幀, 只要按著順序播放即可.

(3). 播放過程中, 不停從幀列表中取得一幀進行播放( 聲音播放與視頻播放線程需要分開!!切記! )

(4). 當視頻播放線程發現聲音播放的幀號大於正要播放的視頻2幀以上時, 馬上放棄當前播放的視頻, 並請求對方 "重發I幀", 並一直讀取到幀緩沖列表中大於等於音頻幀號的視頻 "I" 幀為止, 再播放 ( 此處是解決音視頻不同步的情況, 即視頻慢於音頻並隨時間累積 )

(5). 如果在(3) 當中, 發現掉幀了( 要播放的幀號不等於上一次播放的幀號 +1 ), 請求對方 "重發I幀", 並等待下一個 "I幀" (針對的是視頻幀, 音頻幀只要是大於上一次播放的幀號即可以播放 )

3. 上面缺了任何一點, 都會導致播放出現問題.

班得瑞(Bandari)

最近先至發現原來有十幾首好好聽嘅歌，原來喺屬於 Bandari 兩個專輯嘅音樂。再搜索咗一下呢個樂隊嘅信息，好似幾有意思甘，似乎眾說紛紜，有人話呢個樂隊係假嘅，亦有人話呢個樂隊衹係平時好低調，仲有人話 Bandari 係瑞士唱片公司 Audio Video Communications AG（簡稱AVC）嘅產品，似乎最後一種講法比較靠譜，上他們的主頁可以揾到 Bandari 嘅專輯。

似乎 Bandari 華人區更受歡迎，試下係Google搜索一下就知道，如果查英文，基本揾唔到真正同 Bandari 專輯有關嘅信息，但搜索中文網頁就一大堆。

但無關系啦，只要好聽就得~~話知佢係假定系真啦~~

終於可以用Google音樂下載啦~~

　　前一排，聽講Google可以免費下載正版音樂，好開心，於是上Google，發現真係有Google音樂下載！但呢個試聽同下載服務僅對中國大陸境內提供。

　　但係好失望，我一點下載就彈出個網頁話 “403 forbidden”，頂！我本來就係大陸境內，冇理由唔得咖？！開始我以為係瀏覽器嘅安全選項問題，於是我將D防火牆啊、安全選項啊全部關晒，但係都唔得，搞左幾日，上網抄左幾日都冇見到有講呢個問題，無法子啦，只好唔搞~~

　　後尾翻到公司，啱好見到個同事用Google音樂聽緊歌，我以為係公司可以，於是嗱嗱臨開機試下，點知又係唔得，甘就出奇啦，我地公司係用一個IP出口嘅，冇理由，佢得我唔得咖？！於是我比較左下我台機同同事台機有乜唔同，比較之下先發現，佢個DNS同我個DNS唔一樣，改左個DNS之後，掂晒！！終於可以下載啦！

　　因為我用開嘅係 OpenDNS，所以所有我用嘅機都會設置個DNS為OpenDNS 嘅地址，估計係中國境內 Google 音樂下載網址解釋僅對中國境內DNS有效，所以在國際DNS服務器內解釋呢個地址到其它位置，於是通過OpenDNS解釋到其它嘅IP導致出現 forbidden 嘅現象。

點解要點解?

　　記得係大學果陣，有一次有個課程設計要做一個C語言嘅詞法解釋器。

　　果陣起左個念頭想做一個通用嘅語言編譯器，即係一個萬能既語言編譯器，類似於C語言編譯器、Pascal編譯器等等，但係唔需要硬性為每個語言寫程式（GCC就係呢類型嘅實作），只需要寫一個簡單嘅詞法語法配置文本文檔即可以支持編譯出不同平台嘅程式（二進制文件格式）。

　　後來同老師講左下自己嘅諗法同埋一D唔成熟嘅思路，同埋打算用幾十年時間嚟做呢樣嘢。

　　老師同我講（大概意思）：「呢種編譯器到目前都未出現，起碼證明呢樣嘢難度好高或者幾乎唔可能實現，點解要做呢D無用功呢？何況你做咗出嚟，佢又有乜價值呢？又有乜市場呢？何況做通用嘅編譯器你嘅編譯速度就自然比特定嘅編譯器速度慢，甘你呢個編譯器又有乜用呢？」

　　聽到老師甘講，有D愕然，講真啦，老師講得係啱，但係……我只係想做呢樣嘢，無話想攞佢嚟用，只係想做，點解一定要有用、一定要有價值、一定要有市場啫？就好似細路嘅玩具咁，只係因為有興趣，想玩就玩啫，當時亦係甘回答嘅。

　　人嘅一生，短短百年，雖則現實一分錢可以逼死英雄漢，但我覺得人一世物一世，樣樣事情都講錢、講有用、講意義未免太無意思啦，更有意思嘅事情例如靜靜的聽一首歌、諗辦法實現一個自己諗法嘅程式、嘗試一個月坐看夕陽西下、學習一下道家無為之法……人死如燈滅，生前嘅一切名聲、金錢、榮譽、利欲終將歸於塵土，千百年後或許無人知道你、或許有人知道你，又如何？一切不過碌碌，重不如趁住生命尚存做D自己鍾意嘅事情。遊戲人間亦係個唔錯的人生態度。

　　好彩一直堅持自己選擇自己嘅道路，而家做嘅係自己喜歡嘅編程工作，雖然唔係做自己最鍾意嘅遊戲引擎，但只要係寫程式我就好開心啦，何況而家通常寫嘅系嵌入式程式同埋驅動程式，都系自己鍾意做嘅部分，而家好開心~~~

Linux or ReactOS ?

　　用左 Linux 嚟做開發有一段時間，慢慢發覺，Linux 原來面對嘅用戶群應該喺程式撰寫員先至啱 =_=b

　　剛開始用 Ubuntu 時，諗住佢好似 Windows 咁樣好容易上手嘅，點知到喺使用嘅過程中遇到好多奇奇怪怪嘅問題，Google 之後，先知道又翻到石器時代，大多數問題唔可以通過 GUI 嚟解決，基本上呢D問題都要直接喺命令行底下解決，或者需要從某D源代碼重新編譯安裝，慢慢咁，到最後，習慣左連GUI都唔用，只用命令行。講真啦，都喺鍾意乜嘢都用鼠標喺各個GUI裡面跳來跳去呢種直觀嘅方式嚟解決問題 -_-|||

　　直到上年年尾，發現左一個好玩嘅 OS —— ReactOS，佢哋既目標似乎喺要做一個開源板嘅 Windows NT 內核 OS！哇哈哈，全部繼承左 Windows 系列嘅操作方式，而且完全兼容 Windows NT 及以上 OS 嘅軟體同埋驅動程式！！特別喺驅動程式，雖然話有唔少硬體開始有 Linux 嘅驅動程式并且有成班人喺喥開發支持舊硬體嘅驅動程式，但仲喺有唔少廠商為左方便只開發 Windows 平台嘅驅動程式，咁樣如果你買左果D硬體，你焗住只能喺 Windows 下用啦。

　　下載左個 ReactOS 嚟玩左一下，發覺佢已經可以跑起身，同個 Windows 2000 好鬼似。可以開一D類似於 FireFox 2.0 之類嘅軟件，只喺佢仲處於非常唔穩定嘅開發程度，經常郁下就死機藍屏。不過佢哋嘅開發進度好快，睇左下，平均每日有成十個修改提交，唔知幾時可以真正進入實用嘅階段呢，真喺好期待！

　　比較 Linux 同埋 ReactOS，我覺得 ReactOS 嘅理念會更有前景，畢竟好多公司或者家庭購買左嘅軟體硬體都只能用喺 Windows 上，如果可以直接轉到呢個 ReactOS 上，買左新機後，就可以慳翻筆買 OS 嘅錢，畢竟叫個個都轉到 Linux 底下確實系有難度，特別喺遇著好似我大姐夫D甘嘅人，用 Windows 只會點鼠標，又唔願學新嘢，叫佢去用 Linux 估計同儸佢條命差唔多……

　　Linux？唉，如果界面嘅易用性同埋速度可以提高上去，估計可以搶到 Windows 平台部分做開發嘅人員、願意嚐新的人同埋打算慳成本而進行平台轉換嘅團體。

啓明星

今日瀏覽網頁，無意中查左下啓明星，先知道，原來啓明星即系金星，亦系古時所講既「太白」或者「長庚」。傍晚出現時就稱之為「長庚」，清晨出現時稱「啟明」。其它既稱呼仲有：殷星，大正，營星，明星，觀星，大衣，大威，太（白＋皋），終星，大相，大囂，爽星，太皓，序星。

可以通過維基百科查詢到更詳細的金星資料