編譯skyeye

① 如何用Skyeye代替ARM開發板來學習嵌入式

很多人想學習arm，但是大家買arm開發板是蠻貴的。
現在有個方法能不用開發板也能輕松學習arm。
但是個人還是建議買arm開發板，因為這樣成就感就會更強，學習起來更用心
首先我們知道我們在X86上運行的程序不能在ARM開發上運行。
通過交叉編譯了之後又不能在X86上運行。那怎麼辦呢？
Skyeye這個東西可以完完全全代替ARM開發板。
我們在linux系統上安裝了之後，就可以在上面運行我們交叉編譯過後的程序。
這是我看到一本書學到的是一本書名為《一步一步寫嵌入式系統》，就是在這本書上學到的。
下面就說說如何安裝和使用Skyeye。
首先我們下載Skyeye源碼包
為了更好的配合書籍我們使用和該書一樣的版本：
下載skyeye-1.3.3_rel.tar.gz，下載地址如下：
http://www.arm8.net/thread-38-1-1.html

我們把Skyeye的源碼包上傳到Ubuntu或者其他lnux系統上並解壓
輸入該命令解壓：tar xzvf skyeye-1.3.3_rel.tar.gz
解壓出來的就是我們所需要的包了！

下載來說說如何安裝Skyeye
首先我們進入skyeye根目錄，執行如下命令：
./configure
make lib
make install_lib
make
make install

如果make時有錯誤，我們就根據錯誤更新我們的Linux系統。
例如如果出現如下錯誤
Fatal error: X11/xpm.h: No such file or directory
Compilation terminated

可以通過該命令更新linux系統
sudo apt-get install libxpm-dev

現在我們來測試Skyeye是否正常
安裝目錄在/opt/skyeye/bin目錄下，執行skyeye_main.py命令，進入Skyeye命令行狀態表示安裝成功，可以正常使用。

好了下載我們就可以運行測試代碼
我們可以用最簡單的hello world，使用skyeye自身的hello world代碼。
cd /opt/skyeye/testsuite/arm_hello
/opt/skyeye/bin/skyeye_main.py -e arm_hello
看到狀態後執行start
裡面顯示「Connecting to Ubuntu:xxxx」。
然後在命令行輸入run
現在就可以列印「hello world」。

當然我們也可以改成自己的hello world
需要以下幾個文件：
Makefile , start.S hello.c

Makefile用來鏈接和編譯
start.S是一個啟動代碼
hello.c主函數

② arm-linux-gcc 交叉編譯完成後而已作什麼

模擬器……
skyeye、qemu 什麼的 arm 模擬器（其實我覺得應該叫虛擬機……只不過虛擬的不是 x86 而是 arm 架構）。

③ 我輸入arm-elf-gcc -o2 -c helloworld.c沒有提示錯誤，也沒生成目標文件，怎麼辦

解壓剛剛的那個壓縮包後，你設置的環境變數有問題，或者是許可權沒有設置正確導致的。
請按照如下步驟試驗：（教程是死的，具體的目錄和環境變數的目錄可以由你自己來改變，但是你的環境變數所指的目錄一定要正確指向你的配置文件上。）
1.下載安裝cygwin
2.將下載下來的leeos_tools_for_cygwin.tar.gz放到H:\cygwin\usr中，並用命令cd /usr和tar zxvf leeos_tools_for_Cygwin.tar.gz解壓
3.設置環境變數，依次輸入以下三條命令
echo "PATH=\$PATH:/usr/leeos_tools_for_Cygwin/bin">>/etc/profile
echo "PATH=\$PATH:/usr/leeos_tools_for_Cygwin/libexec/gcc/arm-elf/4.4.2">>/etc/profile
echo "PATH=\$PATH:/usr/leeos_tools_for_Cygwin/arm-elf/bin">>/etc/profile
然後重啟cygwin
4.用chmod 777命令把剛才設置的三個目錄下的所有exe文件都設置一下許可權。（肯定有類似批處理的那種命令可以一下把所有exe文件都設置完，但是我對linux環境不怎麼熟悉，所以在這里還是用的最原始的辦法一個一個改，還好一共也沒幾個exe文件）
5.把skyeye.exe復制到H:\cygwin\usr\leeos_tools_for_Cygwin\bin中。這樣就算把環境配置完了。

知識拓展：關於arm-linux-gcc命令
Linux程序員可以根據自己的需要讓 GCC在編譯的任何階段結束，以便檢查或使用編譯器在該階段的輸出信息，或者對最後生成的二進制文件進行控制，以便通過加入不同數量和種類的調試代碼來為今後的調試做好准備。和其它常用的編譯器一樣，GCC也提供了靈活而強大的代碼優化功能，利用它可以生成執行效率更高的代碼。 以文件example.c為例說明它的用法
0. arm-linux-gcc -o example example.c
不加-c、-S、-E參數，編譯器將執行預處理、編譯、匯編、連接操作直接生成可執行代碼。 -o參數用於指定輸出的文件，輸出文件名為example,如果不指定輸出文件，則默認輸出a.out 1. arm-linux-gcc -c -o example.o example.c
-c參數將對源程序example.c進行預處理、編譯、匯編操作，生成example.0文件
去掉指定輸出選項"-o example.o"自動輸出為example.o,所以說在這里-o加不加都可以 2.arm-linux-gcc -S -o example.s example.c
-S參數將對源程序example.c進行預處理、編譯，生成example.s文件 -o選項同上
3.arm-linux-gcc -E -o example.i example.c
-E參數將對源程序example.c進行預處理，生成example.i文件（不同版本不一樣，有的將預處理後的內容列印到屏幕上）

④ Skyeye怎麼用呢

g正試版下載，裡面有說怎麼用
http://spcode..com/spcode/spClick?tn=zhanruizhuo_sp&ctn=0&styleid=1588&prodid=10&tourl=http://bd.heima8.com/adskip.php?uid=0003966

⑤ 求hello world的makefile(arm-linux-gcc 4.3.2的)～

首先有個前提，那就是交叉編譯平台是否已經搭建好了。如果平台沒有問題，那麼Makefile可以這樣寫(以該文件文件名為hello.c為例)

hello:hello.c
arm-linux-gcc -o hello hello.c
arm-linux-strip hello

這樣就可以了，第一行是申明關聯，第二行是編譯，第三行是優化。
第二行和第三行前必須是Tab，否則Makefile就有錯誤。
當然也可以寫成：

CC=arm-linux-

hello:hello.c
$(CC)gcc -o hello hello.c
$(CC)strip hello

用CC來代替arm-linux-

⑥ Qemu虛擬mini2440碰到的問題，求助

我說樓主啊，你到底會不會嵌入式啊…… mini 2440 是 arm 的 CPU ，怎麼可能在 x86 機器上運行呢？ 裝個 arm 模擬器吧，這種程序很多的，skyeye、qemu 什麼的都有 arm 支持。不然就改用 x86 的編譯器編譯你的程序，再在 x86 環境下運行。

⑦ pcie可以一對多

pcie可以1對多的連接，需要對介面連接中的索引值進行設定，如下圖，需要注意的是，索引值的設置需要與上面的「pcie_num」對應，從0開始，一直到「pcie_num」 - 1，且最大不超過64.

▲圖2-5 linker連接EP設備介面

03.PCIE的BDF
每個PCIE設備在系統匯流排上都有自己的標識符，這個標識符就是BDF（Bus，Device，Function），PCIE的配置軟體（即Root的應用層，一般是PC）應當有能力識別整個PCIE匯流排系統的拓撲邏輯，以及其中的每一條匯流排（Bus），每一個設備（Device）和每一項功能（Function）。

在BDF中，Bus Number佔用8位，Device Number佔用5位，Function Number佔用3位。顯然，PCIe匯流排最多支持256個子匯流排，每個子匯流排最多支持32個設備，每個設備最多支持8個功能，如下圖所示：

▲圖3-1 BDF空間分配

需要注意的是，每Bus0總是分配給RC，且每個設備必須要有功能0（Fun0），其他的7個功能（Fun1~Fun7）都是可選的。

SkyEye模擬實現PCIE設備的BAR地址設置則是在PCIE設備建模時對其配置信息結構體中對BDF進行配置。

▲圖3-2 SkyEye模擬配置BDF

04.PCIE的配置空間
PCIE有三個相互獨立的物理地址空間：設備存儲器地址空間、I/O地址空間和配置空間。配置空間是PCIE所特有的一個物理空間。由於PCIE支持設備即插即用，所以PCIE設備不佔用固定的內存地址空間或I/O地址空間，而是通過配置空間來實現地址映射的。

系統加電時，BIOS檢測PCIE匯流排，確定所有連接在PCIE匯流排上的設備以及它們的配置要求，並進行系統配置。所以，所有的PCIE設備必須實現配置空間，從而能夠實現參數的自動配置，實現真正的即插即用。

PCI匯流排規范定義的配置空間總長度為256個位元組，配置信息按一定的順序和大小依次存放。前64個位元組的配置空間稱為配置頭，一般有兩種，Type0和Type1，分別對應橋設備和終端設備。配置頭的主要功能是用來識別設備、定義主機訪問PCI卡的方式（I/O訪問或者存儲器訪問，還有中斷信息），Type0如圖4-1所示，Type1如圖4-2所示。

▲圖4-1 終端設備Type0配置頭

​

▲圖4-2 橋設備Type1配置頭

其中，配置頭中的重要寄存器意義如下：

Vendor ID：廠商ID。知名的設備廠商的ID。FFFFh是一個非法廠商ID，可它來判斷PCI設備是否存在。

Device ID：設備ID。某廠商生產的設備的ID。操作系統就是憑著 Vendor ID和Device ID 找到對應驅動程序的。

Class Code：類代碼。共三位元組，分別是類代碼、子類代碼、編程介面。類代碼不僅用於區分設備類型，還是編程介面的規范，這就是為什麼會有通用驅動程序。

IRQ Line：IRQ編號。PC機以前是靠兩片8259晶元來管理16個硬體中斷。現在為了支持對稱多處理器，有了APIC（高級可編程中斷控制器），它支持管理24個中斷。

IRQ Pin：中斷引腳。PCI有4個中斷引腳，該寄存器表明該設備連接的是哪個引腳。

Status：設備狀態字，具體每個BIT的意義見下圖4-3

Command：設備狀態字，具體含義見圖4-4

Base Address Registers：決定PCI/PCIE設備空間映射到系統空間具體位置的寄存器，映射方式有兩種，分別是IO和Memory映射，具體解析見圖4-5​

▲圖4-3 status解析圖

▲command解析圖

​

▲圖4-5 BAR解析圖

所有的PCIE終端設備在系統初始化後會在得到對應的配置空間信息，在SkyEye平台模擬也是如此。其中具體的配置信息需要手動設置，參考下圖4-6。

一般需要配置的主要有設備對象指針obj，BDF，vendor_id和device_id，以及內存映射地址BAR和其映射長度，可以按照需要配置多個BAR空間。其餘一些配置寄存器也可以手動設置，遵循Type0的配置空間格式，具體的配置空間信息可參考：

《skyeye_dev_bus_intf.h》

需要注意地是，在設置配置空間信息的時候，必須在new階段，這主要是由skyeye平台初始化順序決定的。

▲圖4-6 PCIE終端設備初始化配置空間

除去上面提到的64B空間外的其餘的192個位元組稱為本地配置空間，主要定義卡上局部匯流排的特性、本地空間基地址及范圍等。而PCIE匯流排則繼承了PCI匯流排的前256位元組外，即0x00~0xFF，還額外擴充到了4K的配置空間，即0x00~0xFFF，其擴展形式是通過一種稱為Capability的寄存器塊來完成的，下圖是具體的布局。

▲圖4-6 PCIE配置空間擴展結構圖

在原來的配置空間中，有一個寄存器指定了第一個Capability的位置，而第一個Capability又指定下一個Capability，構成了一串Capability，具體如下圖所示，由於Capability的作用各不相同，且目前SkyEye關於此功能設置還未完善，這里不再贅述。

▲圖4-7 Capability寄存器關系圖

05.PCIE的建模模擬
5.1注冊介面
對PCIE終端設備進行建模，設備需要注冊兩個介面，分別是memory_space和pcie_config_intf，其中pcie_config_intf介面聲明在文件《skyeye_dev_bus_intf.h》中，主要用來傳送其配置信息，如下所示：

▲圖5-1 PCIE終端設備介面注冊

注冊介面實現後，需要對配置空間信息進行設置，具體操作參考第四節的內容。

5.2 BAR內存空間讀寫
在上一節設置完BAR的地址信息後，就需要實現不同的BAR地址映射功能，而我們主要通過memory_space介面實現，參考如下結構，讀寫同理。

▲圖5-2 PCIE終端設備BAR地址映射介面

需要注意的是，PCIE終端設備中的memory_space介面中的第二個參數addr代表實際的映射地址，與以往的代表地址偏移不同。

打開CSDN APP，看更多技術內容

SkyEye：針對飛行模擬器的模擬解決方案
飛行員訓練、飛機的設計和開發、對飛機特性和控制處理質量管理的研究都離不開飛行模擬器的支持。只有對飛機模擬器進行模擬，才能實現D等級的全功能飛行模擬，高安全、高可靠的天目全數字實時模擬軟體SkyEye可提供完整解決方案。
繼續訪問
知識丨軟體定義汽車的價值
通過軟硬體分層解耦架構，汽車開發將進入到以軟體為核心的迭代開發新模式——軟硬體不僅可以同步進行平台化開發，還可保持差異化上市和持續升級迭代，從而大大縮短產品的研發周期。
繼續訪問
SkyEye助力飛控軟體Debug
在嵌入式系統飛速發展的飛行控制領域，軟硬體緊耦合的情況使得只有快速定位軟體問題並找到問題出現的根本原因，才能最大程度地降低調試成本，縮短開發周期。
繼續訪問
軟體：汽車的最新驅動
隨著汽車產業「新四化」的加速推動，智能汽車已成為各國科技發展戰略重點，在社會數字化轉型的浪潮下逐漸形成跨領域協作、多技術融合的汽車產業新賽道，軟體定義汽車已成為行業趨勢與共識。
繼續訪問
嵌入式軟體開發為什麼需要DevOps？
為什麼嵌入式軟體開發對DevOps的接受度越來越高？點擊文章，一探究竟。
繼續訪問
SkyEye攜手DigiThread，共同助力衛星領域數字化進程
隨著衛星的技術進步及其應用領域的不斷拓展，衛星總體設計及應用模擬迫切需要先進模擬工具的強有力支持。
繼續訪問
基於模型的設計（MBD）在汽車ECU軟體開發中的實踐
基於模型的設計（MBD）是整車廠在當前激烈的競爭環境下的最優選，但如何選擇一套應用MBD、以模型為核心，且能處理從需求、設計、代碼生成到測試的開發工具？點擊原文了解詳情。
繼續訪問
汽車領域CI/CD
CI/CD在傳統IT行業早已風靡多時，但汽車行業相比於傳統IT行業有一定差異性。點擊原文了解詳情。
繼續訪問
知識丨軟體定義汽車下的整車開發
新一輪科技革命和產業變革方興未艾，作為新技術集成應用最佳載體之一的汽車正加速向智能化轉型，智能汽車已成為全球汽車產業發展的戰略方向。整車電子系統功能復雜度呈指數級上升，軟體佔比持續增大。
繼續訪問
汽車領域：自動化編譯框架
如何提供自動化編譯框架用於解決硬體平台的切換以及屏蔽硬體差異，以更好地實現應用的快速開發和部署，是軟體研發的一個重要課題。
繼續訪問
基於ModelCoder的汽車懸掛系統建模
懸掛系統主要功能為支持車身、改善乘坐感覺。懸掛系統綜合多種作用力，決定著汽車行駛過程的穩定性、舒適性和安全性，是整車廠需要考量的重要汽車部件之一。
繼續訪問
汽車領域：雙態敏捷開發模型
「軟體定義汽車」的時代，軟體在整車製造中的重要性日漸凸顯。但不同於其他行業的軟體開發，汽車行業有自己獨特的軟體開發要求。
繼續訪問
嵌入式軟體測試的10條秘訣
點擊鏈接，了解嵌入式軟體測試10條秘訣。
繼續訪問
淺議飛機狀態監控
安全問題一貫是全球航空業的重中之重，隨著航空裝備的日益發展，飛機性能不斷提高、功能不斷完善，飛機系統結構愈加復雜，與之對應的維護保障成本也日益提升，如何解決這一問題依然是是航空從業者需要研究的課題。
繼續訪問
第三屆中國雲計算基礎架構開發者大會成功舉辦！
2022年11月6日，第三屆中國雲計算基礎架構開發者大會在浙江杭州成功舉辦！
繼續訪問
知識丨淺談軌道交通信號系統的測試類型與測試方法
本文對測試過程進行簡單的介紹和分類，探討不同的測試方法和不同測試階段的結合，並對未來測試發展進行初步討論。
繼續訪問
汽車領域：基礎軟體驗證平台
汽車電子的高速發展決定了基礎軟體所面臨的要求將會更加嚴格，其要求會覆蓋軟體的安全性、穩定性、可擴展性等方方面面。為了提高軟體質量，降低軟體應用風險，構建高安全、高可靠性、高效率實施的基礎軟體驗證平台則是必不可少的一環。
繼續訪問
35位大咖3.3萬人觀看｜第17屆CLK大會圓滿落幕，精彩回放已上線
分享回放鏈接和演講課件，歡迎點擊觀看。
繼續訪問
電動汽車安全概述
在虛擬測試環境中任意注入故障，可隨時暫停或反向執行，在該環境下缺陷可穩定復現。
繼續訪問
什麼是「軟體定義汽車」
「軟體定義汽車」即軟體將深度參與到汽車的定義、開發、驗證、銷售、服務等過程中，並不斷改變和優化各個過程，是汽車從基於硬體的產品向軟體為中心的電子設備不斷轉變的結果。
繼續訪問
pcie通信

⑧ arm 的linux支持什麼 模擬器與X86的linux在軟體安裝上有何區別

arm CPU 性能不好，而且也沒有 x86 CPU 一些提高性能的模塊。

不過 arm 下面的 Linux 一般用非針對 x86 進行代碼優化的模擬器都是可以編譯運行的。
沒有針對優化的代碼，性能一般比較差，在一個本來性能就不好的 arm 上面，就更差了。
GB 、FC 還能模擬出來，GBA 和 SFC 就必須找 arm 優化或者演算法特殊設計的模擬器代碼了。或者找性能高的 arm CPU 。

與 x86 的 Linux 上軟體安裝的區別嘛。你可以考慮 arm 2Ghz CPU + 1G 內存 ＋ 160G 硬碟。不過明確的告訴你，沒這種配置，arm + 64M RAM + 128M ROM 對於開發人員就已經屬於奢侈了。128M 和安裝完 2G 的系統肯定會有區別。
什麼區別就看如何簡化系統了。比如減少功能庫，使用輕量級的 X 系統。這個具體實現就因人而異了。對應的軟體縮水，那麼軟體肯定也要適應縮水裝他才行。

LiveCD 里 slax 已經夠輕型了。不過他也有 200M 以上。

⑨ skyeye在make 安裝過程中出錯

能不能說下你的 系統環境。。。 編譯器版本
錯誤信息 再多帖點
你下載的是skyeye 提供的windows環境包嗎？

⑩ Android Makefile中是 如何識別 TARGET_PRODUCT 的

TARGET_PRODUCT 來決定編譯定製proct.

首先， 編譯Android 代碼 通常情況下使用：

# make showcommands

這實際上等價於下面的完整命令 （具體參見 build/core/envsetup.mk ）

# TARGET_ARCH=arm TARGET_PRODUCT=generic TARGET_BUILD_TYPE=release make showcommands

可見，默認情況下編譯系統認為TARGET_PRODUCT 是generic 的

那如何編譯特定產品的Android呢？

這就需要查看Android Makefile是如何解析環境變數TARGET_PRODUCT的。

Android Makefile 的引用關系是這樣的

Makefile -> build/core/main.mk -> build/core/config.mk -> build/core/envsetup.mk -> build/core/proct_config.mk

在build/core/proct_config.mk 中編譯系統首先調用 build/core/proct.mk中定義的函數get-all-proct-makefiles ，來

遍歷整個vendor 的子目錄， 找到vendor下所有的 AndroidProcts.mk, 不同子目錄下的AndroidProcts.mk 中定義了不同的 PRODUCT_NAME, PRODUCT_DEVICE 等信息，（我們也可以通過 打開build/core/proct_config.mk 中的#$(mp-procts) 語句使控制台編譯的時候輸出所有proct 的信息） ， 接著build/core/proct_config.mk 會調用resolve-short-proct-name 將TARGET_PRODUCT匹配的AndroidProcts.mk 中定義的 PRODUCT_DEVICE 賦值給TARGET_DEVICE。

有了這個TARGET_DEVICE, 再回到 build/core/config.mk，

會include $(TARGET_DEVCIE)/BoardConfig.mk

board_config_mk := /
$(strip $(wildcard /
$(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk /
vendor/*/$(TARGET_DEVICE)/BoardConfig.mk /
))

include $(board_config_mk)

而這個配置文件BoardConfig.mk 決定了目標系統編譯屬性，比如使用ALSA還是不是 GENERIC_AUDIO 等等

另外在這里TARGET_DEVICE 宏也決定了TARGET_DEVICE_DIR， 因為TARGET_DEVICE_DIR 取的是上面提到的BoardConfig.mk 的路徑。

TARGET_DEVICE_DIR := $(patsubst %/,%,$(dir $(board_config_mk)))

當然Android 的Ob目標輸出也是由TARGET_DEVICE決定，見build/core/envsetup.mk

TARGET_OUT_ROOT_release := $(OUT_DIR)/target
TARGET_OUT_ROOT_debug := $(DEBUG_OUT_DIR)/target
TARGET_OUT_ROOT := $(TARGET_OUT_ROOT_$(TARGET_BUILD_TYPE))

TARGET_PRODUCT_OUT_ROOT := $(TARGET_OUT_ROOT)/proct

PRODUCT_OUT := $(TARGET_PRODUCT_OUT_ROOT)/$(TARGET_DEVICE)

再回到 build/core/main.mk, 編譯系統接著做的一個件事情是，遍歷所有字目錄，找到所有Android.mk文件，並將這些Android.mk文件include 進來

#
# Typical build; include any Android.mk files we can find.
#

subdir_makefiles := /
$(shell build/tools/findleaves.py --prune=out --prune=.repo --prune=.git $(subdirs) Android.mk)

include $(subdir_makefiles)

我們再來看其中的

./build/target/board/Android.mk

，對了它引用了

include $(TARGET_DEVICE_DIR)/AndroidBoard.mk

由上面TARGET_DEVICE_DIR的定義，這下又進入了

vendor 下TARGET_DEVICE指向的目錄了，這個mk文件中定義了特定Proct需要編譯和安裝app 和 script.