编译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.