目前分類:未分類文章 (7)

瀏覽方式: 標題列表 簡短摘要

來源出處 : http://linuxpilot.com/space-linux

地球的資源終會有耗盡的一天,為此各國都有投入資源開發太空科技。方向之一是活用Linux等開源軟體,將資源作最有效運用。在宇宙開發產業中,Linux扮演什麼角色?

20150521geotail.jpg

轉用Linux的理由不外乎成本和安全。以國際太空站(ISS)為例,2013年5月負責管理ISS的United Space Alliance(USA),就披露ISS曾經感染病毒,因此將系統都更換為Linux。2014年1月,日本宇宙航空研究開發機構JAXA,就宣布將美日合作的太陽觀測衛星「日出」(SOLAR-B),以及磁氣圏尾部觀測衛星GEOTAIL的衛星管制功能,轉移至Linux平台上,藉此加強系統的靈活性和穩定性。

但這是否意味著Linux能在任何場景下使用呢?當然不是。例如美國的航天飛行器,採用的作業系統是Wind River公司開發的VxWorks 653,這也是中國航天飛行器系統SpaceOS的主要模仿對象。這些系統並沒有使用Linux,原因是航天飛行器的記憶體和CPU都非常的陽春。陽春到什麼程度呢?以中國天宮一號為例,其CPU速度是10MHz,記憶體只有2MB,這種配置跑Linux比較費勁,雖然也並非不可能,但如果要裁剪Linux核心才能用,就實在太麻煩了。

為什麼航天飛行器的電腦配置都這麼差?因為太空輻射、極端溫度等原因,系統首先要求的是可靠性,必須在高溫攝氏100多度、低溫攝氏零下100多度下也可正常運作。換了是一般家用電腦在這種溫度下早就掛了,所以為了對應這個極端環境,主要的硬體都被設計成很耐用的狀態,令「電腦的速度」從來都不是一個重要的指標。另外太空輻射會造成位元翻轉,頻率越高越容易被干擾,所以低頻的設計是主流

而Linux的「缺點」,就是它不是一個真正的實時作業系統。實時作業系統(RTOS)有一系列嚴格的定義,包括嚴格按照任務優先級別執行,快速的中斷回應等等,都有非常嚴格的控制。「實時」簡單的說,就是運行一個程式功能,像是進程切換的時間,是精確而且可估計的。作業系統必須能及時處理外界中斷、通訊等任務。如果不能及時回應導致數據丟失,對於一般系統而言可能問題不大,但對航天飛行器來說,嚴重的話甚至有可能造成人命傷亡。

家用系統多數情況下,要求的是系統的「均衡運行」。例如你可以同時玩遊戲、上網和聽音樂,但實時系統卻是「重要任務先執行,不重要的任務往後放」,設計理念是不一樣的。Linux的進程切換需要在核心進行,用戶狀態和核心狀態的切換,會耗費很多時間。有人會說Linux不是有個實時系統叫RT-Linux嗎?這個說得簡單一點,就是底下是一層RTOS,上面是 Linux 。這種 Linux 複雜度太高,也不能裁剪得太小。

例如嵌入式領域很流行的作業系統µC/OS-II,總共只有兩三千行程式碼,但是已經通過美國的行業認證,可以用在商業飛行器上,證明了其高效穩定性。這麼小的系統,需要的是精確可靠。作業系統需要考慮的設計細節非常多,一旦定型修改又非常麻煩,而且需要大量的測試,以NASA為例,每個新開發的功能要進行幾十個甚至上百個的測試。有人說SpaceX不是也有用Linux嗎?是的。但其飛行器上使用的,卻是VxWorks系統。事實上中國的國防軍工行業的自動化控制部分,也是VxWorks的天下。雖然號稱自主知識產權,但實際上仍然以美製系統為主流。

中國能不能寫出自己的通用作業系統呢?我覺得是可以的,只是在這個作業系統之上的應用軟體一定不夠多,最後沒人會去用。因此目前中國團隊做的作業系統,一般的目的都不是跟微軟競爭,而是滿足一些特殊需要。在基礎領域很多項目沒法做,是因為涉及專利,基礎理論專利在人家手裡。龍芯研發負責人胡偉武說過,技術問題其實不難解決,只要有錢,大可去Intel和AMD挖角。但如果開發軟體等配套服務跟不上,也是沒用的。中國錯過了電腦基礎理論發展的黃金階段,我們現在看到的,實際是幾十年前埋下的苦果。開源技術可以是合法地發展自家科技的契機,關鍵只在乎我們是否願意掌握。

ryan0988 發表在 痞客邦 留言(3) 人氣()

Open source 常見的 toolchain,就非 gcc 和 binutils 系列莫屬。然而,商業公司提供的 toolchain,往往必需安裝在特定目錄,這總是惹惱有潔癖者,如我。然而,若將 toolchain 任意搬動位置,則會曝露 gcc 的一個缺陷,gcc 找不到其它幅程式或 library 。這是因為 gcc 假設 library 和 toolchain 會安裝在固定位置,於是在 build toolchain 時,就將這些路徑設定死。於是,對於不想重新 build toolchain,或只拿到 binary 的 user 而言,就必需使用 -nostdlib 這個參數,然後加上一堆 -I 和 -L 參數,使 gcc 能正確的找到 library 。

另外,一些 toolchain ,因為平台的因素,無法使用 gcc 預設好的參數內容。於是要強迫使用者必需下一堆固定的參數,例如: Android 就在其 build system 裡,為 gcc 設定一堆和平台相關的參數,像是 -mthumb。於是,若使用該 toolchain 自行開發軟體,就誓必要找出這些參數,並正確的設定為 gcc 的參數。這完全是一堆苦工。其實,只要作 toolchain 的人多用點心,使用 toolchain 其實可以不用這麼累。

sysroot

一般而言,gcc 會到 /usr/lib 和 /usr/include 下找 library 、 header files 和其它一些 start files 、 end files。當我們在 build gcc 設定 --prefix=/path/to/xxx ,則 gcc 安裝到 /path/to/xxx ,也在該目錄下的 lib/ 和 include/ 找 library 和 header 。旦,若裝 gcc 移到其它目錄時, gcc 會找不到這些 library 。這時,我們可以在呼叫 gcc 時,給予 --sysrooot=/new/path/to/xxx 參數。如此,gcc 就會改以 /new/path/to/xxx 為參考目錄,去搜尋所需的幅程式和 library 等。

然而,要注意的是, ld 必需要能 support --sysroot。這必需在 configure binutils 時,給予 --sysroot=xxx 參數。xxx 可以是任意目錄,不一定是實際安裝的位置。這個參數的主要目的是使 ld 啟動 --sysroot 的功能。

Spec File

--sysroot 解決了一部分問題,但有更大部分的問題是 toolchain 往往要你設定一些固定參數。例如,你會需要設定一些 header file 的目錄,並且設定一些平台有關的參數。這些設定往往又臭又長,很容易出錯。其實,這些參數可以寫在 spec file 裡,使用者就不用一再的重復指定這些參數。例如,以下是我為 Android 設定的 spec file 的內容

%rename cc1_android old_cc1_android
%rename cc1plus_android old_cc1plus_android
*android_root:
%R/../../../../../
*android_product:
generic
*ccflags:
%{!march=:-march=armv5te} %{!mtune=:-mtune=xscale} -mthumb \
-fno-strict-aliasing -finline-limit=64 -mthumb-interwork \
-fno-short-enums \
-D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5TE__ \
-isystem %(android_root)bionic/libc/arch-arm/include/ \
-isystem %(android_root)bionic/libc/include \
-isystem %(android_root)bionic/libstdc++/include \
-isystem %(android_root)bionic/libc/kernel/common \
-isystem %(android_root)bionic/libc/kernel/arch-arm \
-isystem %(android_root)bionic/libm/include \
-isystem %(android_root)bionic/libm/include/arch/arm \
-isystem %(android_root)bionic/libthread_db/include \
-include %(android_root)system/core/include/arch/linux-arm/AndroidConfig.h \
-isystem %(android_root)system/core/include/arch/linux-arm/
*cc1_android:
%(old_cc1_android) %(ccflags)
*cc1plus_android:
%(old_cc1plus_android) %(ccflags)
                                

Android 的 header files 就散置在一堆目錄,於是 build system 就指定了一堆參數。如果你自己寫個小程式,又不使用 Android 的 build system 時,就必需自己指定這些參數。於是,有人寫了一個 perl 的小程式,作為 gcc 的 wrapper ,幫你指定一些參數。其實不用這麼麻煩,只需像上例一樣,設定一個 spec file ,在執行 gcc 時加上一個參數就能自動套用這些參數

  • gcc -specs myandroid.specs

spec file 設計的很有彈性,可以對參數列的內容進行修改,也可以加入條件性的參數。像上例 {!march=:...} 就是指定,當參數列沒有指定 -march= 的參數時,就在 cc1 的參數例加入 -march=armv5te。另外我還指定了一些巨集和 -system 指定一些 header file 的路徑。而這些路徑是相對於 %R ,也就是 --sysroot 所指定的路。例如 --sysroot=/my/path/to/the/kkk/ ,則 %(android_root)bionic/libm/include/arch/arm 就會對應到 /my/path/to/th/kkk/../../../../../bionic/libm/include/arch/arm 。

更進一步

--sysroot 的預設內容,其實是可以設定成相對於 gcc 本身的位置。在 configure 時,若

configure --with-sysroot='${exec_prefix}/xxx'
                                                        

則編譯出來的 gcc ,其 sysroot 就會相對於其執行路徑。如此 user 甚至不必再手動指定 --sysroot 。

結論

有了 spec files ,我們只需設定 -specs 和 --sysroot 兩個參數就能解決所有的問題。其實在建 toolchain 時,應該再多花一點時間,幫 user 作好 spec files 。這樣的 toolchain 才方便使用。 關於 spec file 更詳細的內容,請參考 Spec Files


ryan0988 發表在 痞客邦 留言(0) 人氣()

按各地址起作用的顺序,uboot引導linux核心啟動涉及到以下地址:

  1. load address:
  2. entry point: 这两个地址是mkimage时指定的
  3. bootm address:bootm为uboot的一个命令,以此从address启动kernel
  4. kernel运行地址:在具体mach目录中的Makefile.boot中指定,为kernel启动后实际运行的物理地址
    mkimage -n 'linux-3.2.1' -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008000 -d zImage uImage
            

理论上因为mkimage要为zImage加上0x40字节的header,所以entry point = load address + 0x40

但由于uboot 的bootm对uImage处理不是简单的go操作,其对前三个地址都有比较判断,所以在实际的操作中,就分为两种不同的情况:

1. bootm地址和load address一样

  此种情况下,bootm不会对uImage header后的zImage进行memory move的动作,而会直接go到entry point开始执行。因此此时的entry point必须设置为load address + 0x40。如果kernel boot过程没有到uncompressing the kernel,就可能是这里设置不对。

boom address == load address == entry point - 0x40

具体细节可参看uboot代码common/cmd_bootm.c中bootm_load_os函数的实现:

switch (comp) {
        case IH_COMP_NONE:
                if (load == blob_start || load == image_start) {
                        printf("   XIP %s ... ", type_name);
                        no_overlap = 1;
                } else {
                        printf("   Loading %s ... ", type_name);
                        memmove_wd((void *)load, (void *)image_start,
                                        image_len, CHUNKSZ);
                }
                *load_end = load + image_len;
                puts("OK\n");
                break;

2. bootm位址和load address不一樣(但需要避免出現memory move時出現覆盖導致zImage被破壞的情況)

  此種情況下,bootm會把uImage header後的zImage move到load address(見上方程式碼),然后go到entry point開始執行。 由此知道此时的load address必須等於entry point。

boom address != load address == entry point

ryan0988 發表在 痞客邦 留言(0) 人氣()

SDHC,全名「Secure Digital High Capacity」,是SD卡協會(SD Card Association)在2006年3月發表的Secure Digital高容量版本。SD卡協會有強制規定,所有符合SDHC規範的裝置都必須標明「SDHC」標誌。

容量上限

SDHC與SD的主要差異在於,舊版本用FAT16檔案系統,意思是管理檔案所在位置的表格用16位元表示,所以最多只能管理65536個範圍,再考慮每個範圍能儲存32KB的資料量,所以65536 × 32KB = 2GB,SD卡容量上限只能到達2GB。為解決FAT16格式可支援容量有限的問題,SDHC改用了FAT32格式;依規格定義,容量最大可達到32GB。

  • 發布SDHC的時候,制定了三種不同的級數(Class),分別是Class 2、Class 4及Class 6,表示該記憶卡穩定的最小存取速度[1]
  • 後來,增加了Class 10及全新制定的UHS(Ultra High Speed Class)。
    • UHS目前有兩個等級,就是U1與U3。
等級 速度
SDHC Speed Class 2.svg Class 2 2 MB/s
SDHC Speed Class 4.svg Class 4 4 MB/s
SDHC Speed Class 6.svg Class 6 6 MB/s
SDHC Speed Class 10.svg Class 10 10 MB/s
UHS Class 1.png UHS Class 1 10 MB/s
UHS Class 3.png UHS Class 3 30 MB/s


SDXCSecure Digital eXtended Capacity)為SD卡的新一代標準,於2009年CES消費電子展提出,為遵循SD 3.0規範之規格。

在SD 3.0規格下,低容量記憶卡仍使用FAT32,SD 3.0規定之最高速度為104MB/s[1];而高容量則於SD 4.0中規範最大容量可高達2TB,採用的檔案系統是微軟專利exFAT規格。SD 4.0規範將最高速度提升至312MB/s。SDHC所採用的FATFAT32Ext2於SDXC仍可使用,SDXC電子介面規格仍與SDHC相容。

限制

SDXC卡可使用SDHC規格之裝置,但有以下之限制:

  1. SDHC讀卡裝置只能支援SDXC的UHS104速度[1],高速的SDXC卡(SD 4.0規格)於SDHC讀卡裝置上可能無法辨識。
  2. 目前可支援SDXC的作業系統為:Linux(對於exFAT檔案系統需要使用受限驅動)、Windows 8Windows 7Windows Vista SP1+、Windows XP SP2或SP3 with KB955704[2], Windows Server 2008 R2Windows Server 2012Windows Server 2008 SP1+, Windows Server 2003 SP2 or SP3 with KB955704[2], Windows CE 6+, Mac OS X Snow Leopard (Intel-based), OS X Lion, OS X Mountain Lion, OS X Mavericks。

另外,使用和選購記憶卡時,必須注意相容性。SDHC和SDXC記憶卡與現有SD 1.1讀卡裝置並不相容,記憶卡並不支援向下相容。

ryan0988 發表在 痞客邦 留言(0) 人氣()

Secure Digital縮寫SD,全名為Secure Digital Memory Card,中文翻譯為安全數位卡[1][2],為一種記憶卡,被廣泛地於攜帶型裝置上使用,例如數位相機個人數位助理多媒體播放器等。SD卡的技術是建基於MultiMedia卡格式上。SD卡有比較高的資料傳送速度,而且不斷更新標準。大部份SD卡的側面設有防寫控制,以避免一些資料意外地寫入,而少部分的SD卡甚至支援數位版權管理的技術。SD卡的大小為32mm × 24mm × 2.1mm,但官方標準亦有記載「薄版」1.4mm厚度,與MMC卡相同。

SD卡提供不同的速度,它是按CD-ROM的150 KB/s為1倍速(記作「1x」)的速率計算方法來計算的。基本上,它們能夠比標準CD-ROM的傳輸速度快6倍(900KB/s),而高速的SD卡更能傳輸66x(9900KB/s=9.66MB/s,標記為10MB/s)以及 133x 或更高的速度。一些數位相機需要高速SD卡來更流暢地拍攝影片,以及使得相片連拍更為迅速。直至2005年12月,大部分裝置跟從SD卡的1.01規格,而更高速至133x的裝置亦跟從1.1規格。

2006年3月發布的SDHC標準(SD 2.0),重新定義了SD卡的速度規格,分為三檔:Class 2、4、6,代表寫入速度分別為2MB/s、4MB/s、6MB/s。隨著科技的進步,有廠商生產了更高速的SDHC卡。廠商一般會直接在這些SD卡上標註速度,例如R90/W60代表讀寫速度達到每秒90MB和60MB。2010年發布了新的SD 3.0,定義了SDXCUHS,並新增了Class 10。

設有SD卡插槽的裝置能夠使用較薄身的MMC卡,但是標準的SD卡不能插入MMC卡插槽。插上轉接器後SD卡能夠用於CF卡PCMCIA卡上,而miniSD卡microSD卡亦能插上轉接器在SD卡插槽使用。一些USB連接器能夠插上SD卡;而且一些讀卡器亦能夠插上SD卡,並由許多連接埠如USB、FireWire等存取使用。

概況


容量:

SD : <= 2GB

SDHC: >2GB - 32GB

SDXC: >32GB - 2TB

ryan0988 發表在 痞客邦 留言(0) 人氣()

多媒體記憶卡Multimedia CardMMC卡)是一種快閃記憶卡標準。在1997年由西門子SanDisk共同開發,技術基於東芝NAND快閃記憶技術,因此比早期基於Intel NOR快閃記憶技術的記憶卡(例如CF卡)更細小。MMC卡大小與一張郵票差不多,約24mm x 32mm x 1.5mm。

MMC卡原本使用1bit串聯接口,但較新的標準則容許同時傳送4 bit或8 bits的資料。近年MMC卡技術已差不多完全被SD卡所代替;但由於MMC卡仍可被兼容SD卡的設備所讀取,因此仍有其作用。

目前MMC卡的的容量多達 2 GB,並且用於幾乎所有使用存儲卡的設備上,如行動電話數字音頻播放機(music player)、數位相機個人數碼助理(PDA)中。由於Secure Digital的出現,幾乎沒有公司將MMC插槽做進他們的設備中,但是稍微窄一點兒的、針腳兼容(pin腳相容)的MMC卡可以用在所有支援SD卡的設備上。然而,少數一些公司,最著名的如諾基亞,仍然全部地支援MMC。

Multi_Media_Card_front.jpg     32 MB MMC 卡

Multi_Media_Card_back.jpg   MMC卡背面


衍生規格

eMMC

eMMC (Embedded Multi Media Card) 為MMC協會所訂立的、主要是針對手機產品為主的內嵌式存儲器標準規格。eMMC的一個明顯優勢是在封裝中集成了一個控制器,它提供標準接口並管理快閃記憶體,使得手機廠商就能專注於產品開發的其它部分,並縮短向市場推出產品的時間。這些特點對於希望通過縮小光刻尺寸和降低成本的NAND供應商來說,同樣的重要。

ryan0988 發表在 痞客邦 留言(0) 人氣()

CompactFlashCF卡)最初是一種用於可攜式電子設備的數據儲存設備,於1994年首次由SanDisk公司生產並制定了相關規範。它的物理格式曾被多種設備所採用。從外形上CF卡可以分為兩種:CF I型卡以及稍厚一些的CF II型卡。從速度上它可以分為CF卡、高速CF卡(CF+/CF 2.0規範)、CF3.0、CF4.0,更快速的CF4.1標準也在2007年被採用。CF II型卡槽主要用於微型硬碟等一些其他的設備。

CF是與出現更早且尺寸更大的PCMCIA I型內存卡競爭的第一批快閃記憶體標準之一,它最初是建立在英特爾的NOR Flash的基礎上,之後改為使用NAND Flash。CF是最老也是最成功的標準之一,尤其在早期的專業數位相機市場。

CF卡可以透過轉接卡直接用於PCMCIA卡插槽,也可以通過讀卡器連接到多種常用的埠,如USBFirewire等。另外,由於它具有較大的尺寸(相對於較晚出現的小型存儲卡而言),大多數其他格式的存儲卡可以通過適配器在CF卡插槽上使用,其中包括SD卡MMC卡Memory Stick DuoXD卡以及SmartMedia卡等。

CompactFlash.jpg

CompactFlash.jpg

概述

由於使用的NOR Flash儲存密度低於較新的NAND Flash,CF卡的體積是90年代初期出現的三種存儲卡中最大的(另兩種是Miniature Card—MiniCard和SmartMedia卡)在之後,CF卡也改用了NAND Flash,另外,IBM的微型硬盤使用CF II型介面,但並不是固態硬碟日立希捷也有製造微型硬碟。

CompactFlash的電氣特性與PCMCIA-ATA接口一致,但外形尺寸較小。

連接器為43毫米寬,外殼的深度是36毫米,厚度分3.3毫米(CF I型卡)和5毫米(CF II型卡)兩種

CF I型卡可以用於CF II型卡插槽,但CF II型卡由於厚度的關係無法插入CF I型卡的插槽中。CF閃存卡多數是CF I型卡。

ryan0988 發表在 痞客邦 留言(0) 人氣()

Close

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼