eCos仿真目标机(2)――安装

原文：http://ecos.sourceware.org/docs-latest/ref/synth-install.html
译文：http://blog.csdn.net/zoomdy/article/details/17147519
mingdu.zheng <at> gmail <dot> com

安装――准备使用仿真目标机（Synthetic target）。

宿主机软件

为了获得仿真目标机的完整功能，用户必须编译安装I/O辅助进程ecosynth以及其它支持文件。没有辅助进程的情况下开发仿真目标机应用也是可以的，但是仅有少量的I/O设备可用。相关代码位于仿真目标机架构HAL组件包的host子目录，编译辅助进程使用标准的configure、make和make install三部曲。

编译宿主机软件主要有两种方法。一种是同时编译通用的宿主机软件以及所有组件包内的宿主机软件，包括I/O辅助进程。这种方法要在eCos仓库的根目录下运行configure脚本，这个脚本会自动查找packages目录下组件包内的宿主机软件。详细情况请阅读eCos仓库根目录下的README.host文件。需要注意的是：如果已经有一个编译目录（build tree），但该编译目录未包含仿真机架构HAL，那么需要重新运行eCos仓库根目录下的configure脚本，因为只有在配置过程才会查找宿主机软件的组件包。

另一种方法是仅仅编译指定组件包的宿主机软件。这种方法要创建一个合适的编译目录（build directory）然后运行configure脚本。需要注意的是在源代码目录下直接编译是不允许的。

cd <somewhere suitable>
mkdir synth_build
cd synth_build
<repo>/packages/hal/synth/arch/<version>/host/configure <options>
make
make install

宿主机软件使用了大量的Tcl/Tk并且要求8.3以上版本。Tcl/Tk版本是通过configure脚本检查的。默认情况下使用安装在/usr目录下的系统Tcl。如果选择其它版本，那么应当使用最近安装的Tcl，其安装路径可以通过选项--with-tcl=<path>、--with-tcl-header=<path>和--with-tcl-lib=<path>指定。有关这些选项的更多信息请阅读eCos仓库根目录下的README.host文件。

如果希望指定安装路径，那么使用--prefix=<path>选项指定安装路径。默认安装路径为/usr/local。必须将安装路径的bin子目录添加到用户的PATH环境变量中，否则eCos应用没有办法查找和执行I/O辅助进程ecosynth。

由于I/O辅助进程ecosynth是eCos应用自动加载运行的而不是用户显示调用的，因此ecosynth不是安装在bin子目录，而是和其它支持文件一起放在libexec子目录。在配置过程可以通过选项--exec-prefix=<path>或--libexecdir=<path>指定libexec的自定义路径，但是这些选项不能应用在I/O辅助进程的配置，因为eCos应用是另外单独编译的并不知道宿主机软件是如何配置的，如果更改默认值那么eCos应用将找不到I/O辅助进程ecosynth。

工具链

为常规嵌入式目标机开发eCos应用时需要使用目标机架构配套的交叉编译器以及相关的工具（例如链接器）。为仿真目标机开发eCos应用则要简单得多，因为你只需要使用Linux发行版提供的标准GNU工具链（gcc、g++、ld等），或者其它你用来编译Linux应用程序的工具链。

使用上述工具时有一个限制：当前的gdb不支持仿真目标机的多线程调试。gdb认为仿真目标机eCos应用程序与普通的Linux应用程序没有区别，因此它假设所有线程都是通过调用C库提供的pthread_create函数创建。事实上在这里这种假设不会成立，因为eCos应用程序不会链接到Linux系统的C库。因此gdb无法探测到eCos线程的创建，在gdb看来eCos应用就是单线程应用。解决这个限制在理论上是可行的，但是要对gdb进行全面改造。

理论上可以在其它系统上开发仿真目标机应用，例如运行Windows系统的PC机，然后将编译结果拷贝到另外的运行Linux系统的机器上执行。但是这没什么用：如果有可用的Linux机器，那么通常该机器也可以用来编译eCos和应用。如果因为某些原因需要或希望在其它机器上编译，那么就需要一个合适的交叉编译器和相关工具。如果应用将在使用x86处理器的PC上运行，那么配套的交叉编译器前缀应该是i686-pc-linux-gnu。更多信息可以查阅各类GNU工具链的安装指南。

准备硬件

为eCos开发准备真实的嵌入式系统目标机是非常棘手的事情。第一步通常是安装合适的调试固件，通常是RedBoot。这意味着要使用RedBoot模板创建和编译一个特别的eCos配置，然后使用某种方法把生成的RedBoot映像下载到目标机Flash芯片中。典型情况下，还需要建立一个可工作的串口连接，还有可能需要建立网络连接。虽然没有哪个步骤是特别复杂的，但是有很多种情况会导致错误，而且很难断定到底发生了什么。当然，一些开发板制造商为了让他们的用户更容易上手已经在出售的开发板上预装了RedBoot，即便是这样仍然需要建立宿主机和目标机的通信连接。

上述问题没有哪个会发生在仿真目标机中，你要做的是编译一个常规的eCos配置，把你的应用程序和生成的eCos库文件链接在一起，最终得到一个可执行文件，可以在Linux上直接运行这个可执行文件，也可以使用gdb调试这个可执行文件。使用仿真目标机还会带来非常有趣的副作用：应用程序开发可以在任何真实硬件准备就绪之前展开。

典型情况下，仿真目标机应用的内存映像使用只读的ROM区域保存所有代码和只读数据，以及使用可读写的RAM区域保存数据。这些内存区域的默认加载地址和大小与开发环境使用的平台有关。请注意应用程序总是在ROM之外执行的情况：很多开发用的真实嵌入式目标机会在ROM中运行RedBoot固件，而应用程序代码和数据则加载到RAM中；通常这种情况会在最终产品中改变，RedBoot固件会被替换成eCos应用本身，eCos应用配置成ROM启动并且执行适当的硬件初始化。因此仿真目标机实际上仿真的是最终产品的行为，而不是开发环境。在实践中，这并不重要，虽然将代码放在只读存储器中可以帮我们发现应用程序代码的一些问题。