來源出處 : 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) 人氣()

在编译GCC之前,先介绍一个概念——bootstrap。

bootstrap就是自己编译自己,或者说用GCC编译GCC本身。GCC的bootstrap分三个阶段,具体如下:

  1. 用系统提供的编译器编译GCC源代码,得到GCC编译器;
  2. 用步骤1得到的GCC编译同一份GCC源代码,又得到一套GCC编译器
  3. 用步骤2得到的GCC编译同一份GCC源代码,第三次得到一套GCC编译器

最后比较步骤2和步骤3得到的两套编译器是否相同,如果相同,则bootstrap成功;否则失败。


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) 人氣()

來源出處WIKI    ->    https://zh.wikipedia.org/wiki/%E5%87%BD%E5%BC%8F%E...


電腦科學中,英語:library)是用於開發軟體子程式集合。庫和執行檔的區別是,庫不是獨立程式,他們是向其他程式提供服務的代碼。

庫連結是指把一個或多個庫包括到程式中,有兩種連結形式:靜態連結動態連結,相應的,前者連結的庫叫做靜態庫後者的叫做動態庫

靜態連結

靜態連結是由連結器在連結時將庫的內容加入到可執行程式中的做法。連結器是一個獨立程式,將一個或多個庫或目的檔(先前由編譯器組譯器生成)連結到一塊生成可執行程式。

靜態連結的最大缺點是生成的執行檔太大,需要更多的系統資源,在裝入記憶體時也會消耗更多的時間。

動態連結

動態連結,在執行檔裝載時執行時,由作業系統裝載程式載入庫。大多數作業系統將解析外部參照(比如庫)作為載入過程的一部分。在這些系統上,執行檔包含一個叫做import directory的表,該表的每一項包含一個庫的名字。根據表中記錄的名字,裝載程式在硬碟上搜尋需要的庫,然後將其載入到記憶體中預先不確定的位置,之後根據載入庫後確定的庫的位址更新可執行程式。可執行程式根據更新後的庫資訊呼叫庫中的函式或參照庫中的資料。這種類型的動態載入稱為裝載(load-time)時載入,被包括WindowsLinux的大多數系統採用。裝載程式在載入應用軟體時要完成的最複雜的工作之一就是載入時連結。

其他作業系統可能在執行時解析參照。在這些系統上,可執行程式呼叫作業系統API將庫的名字、函式在庫中的編號和函式參數一同傳遞。作業系統負責立即解析然後代表應用呼叫合適的函式。這種動態連結叫做執行時連結。因為每個呼叫都會有系統開銷,執行時連結要慢得多,對應用的效能有負面影響。現代作業系統已經很少使用執行時連結。

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

對於設計嵌入式Linux系統的研發人員來說,有一個問題是必須要考慮到的,那就是記憶體的空間。 我們知道嵌入式Linux系統所用的記憶體不是軟碟、硬碟、ZIP盤、CD-ROM、DVD這
些眾所周知的大容量常規記憶體,它使用的是例如Rom,CompactFlash,M-Systems的DiskOnChip,SONY的MemoryStick,IBM 的MicroDrive等體積極小,與主板上的BIOS
大小相近,存儲容量很小的記憶體。所以怎樣盡可能的節省空間就顯的很重要。 嵌入式系統的記憶體中放置的無非是核心,檔案系統,軟體,以及自己開發的程式。
本文就從程式入手,以一個非常簡單的C程式來作個例子,通過三步來讓它減肥。

Hello.c:
#include <stdio.h>
int main ()
{
  printf ("hello,world");
  return 0;
}

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

Close

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

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

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

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

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼