168.htm

pcb设计资料初学者难得的入门资料包含工厂制作过程

    代码量最大的部分是被核心直接调用的底层支持部分，这部分代码在arch/xxx/ker <br>
nel下(xxx是平台名称)。这些代码重写了内核所需调用的所有函数。因为接口函数是固 <br>
定的，所以这里更象是为硬件平台编写API。不同的系统平台，主要有以下几方面的不同 <br>
： <br>
    进程管理底层代码：从硬件系统的角度来看，进程管理就是CPU的管理。在不同的硬 <br>
件平台上，这有很大的不同。CPU中用的寄存器结构不同，上下文切换的方式、现场的保 <br>
存和恢复、栈的处理都不同，这些内容主要由CPU开发手册所描述。通常来说，CPU的所 <br>
有功能和状态对于Linux不一定有意义。实现时，需要在最小的开发代价和最好的系统性 <br>
能之间加以权衡。 <br>
* BIOS接口代码：这一名称似乎并不太准确，因为它沿用了PC一贯的叫法。但在不致引 <br>
起混淆的情况下我们还是这么叫它。在通用平台上，通常有基本输入输出系统供操作系 <br>
统使用，在PC上是BIOS，在SPARC上是PROM，在很多非通用系统上甚至并没有这样的东西 <br>
。多数情况下，Linux不依赖基本输入输出系统，但在某些系统里，Linux需要通过基本 <br>
输入输出系统中得到重要的设备参数。移植中，这部分代码通常需要完全改写。 <br>
* 时钟、中断等板上设备支持代码：即使在同一种CPU的平台上，也会存在不同的板上外 <br>
设，异种CPU平台上更是如此。不同的系统组态需要不同的初始化代码。很典型的例子就 <br>
是MIPS平台，看看arc/mips/的代码，与其它系统比较一下就知道。因为MIPS平台被OEM <br>
得最广，在嵌入式领域应用最多（相对其它几种CPU而言）。甚至同一种MIPS芯片被不同 <br>
厂家封装再配上不同的芯片组。因此要为这些不同的MIPS平台分别编写不同的代码。 <br>
* 特殊结构代码：如多处理器支持等。其实每一种CPU都是十分特殊的，熟悉x86平台的 <br>
人都知道x86系列CPU著名的实模式与虚模式的区别，而在SPARC平台上根本就没有这个概 <br>
念。这就导致了很大的不同：PC机上的Linux在获得控制权后不久就开始切换到虚模式， <br>

SPARC机器上则没有这段代码。又如电源管理的支持更是多种多样，不同的CPU有着不同 <br>
的实现方式（特殊的电源管理方式甚至被厂商标榜）。在这种情况下，除非放弃对电源 <br>
管理的支持，否则必须重写代码。 <br>
    还有一部分代码量不多，但不能忽视的部分是在arch/xxx/mm/下的内存管理部分。 <br>
所有与平台相关的内存管理代码全部在这里。这部分代码完成内存的初始化和各种与内 <br>
存管理相关的数据结构的建立。Linux使用了基于页式管理的虚拟存储技术，而CPU发展 <br>
的趋势是：为了提高性能，实现内存管理的功能单元统统被集成到CPU中。因此内存管理 <br>
成为一个与CPU十分相关的工作。同时内存管理的效率也是最影响系统性能的因素之一。 <br>
内存可以说是计算机系统中最频繁访问的设备，如果每次内存访问时多占用一个时钟周 <br>
期，那就有可能将系统性能降低到不可忍受。在Linux系统里，不同平台上的内存管理代 <br>
码的差异程度是令人吃惊的，可以说是差异最大的。不同的CPU有不同的内存管理方式， <br>
同一种CPU还会有不同的内存管理模式。Linux是从32位硬件平台上发展起来的操作系统 <br>
，但是现在已经有数种64位平台出现。在64位平台上，可用内存范围增大到原来的232倍 <br>
，其间差异可略窥一斑了。鉴于这部分代码的重要性和复杂性，移植工作在这里变得相 <br>
当谨慎。有些平台上甚至只是用最保守的内存管理模式。如在SPARC平台上的页面大小可 <br>
以是多种尺寸，为了简单和可靠起见，SPARC版的Linux只是用了8K页面这一种模式。这 <br>
一状况直到2.4版才得以改善。 <br>
    除了上面所讲的之外，还有一些代码需要考虑，但相对来说次要一些。如浮点运算 <br>
的支持。较完美的做法是对FPU编程，由硬件完成浮点运算。但在某些时候，浮点并不重 <br>
要，甚至CPU根本就不支持浮点。这时候就可以根据需求来取舍。 <br>
    对于内核移植的讨论到此为止。实际上，还有一些移植工作需要同时考虑，但很难 <br>
说这是属于内核范畴还是属于驱动程序范畴，比如说显示设备的支持，和内核十分相关 <br>

，但在逻辑上又不属于内核，并且在移植上也更像是驱动程序的开发。因此不在这里讨 <br>
论。 <br>
  (2)系统移植 <br>
    当内核移植完毕后，可以说所有的移植工作就已经完成大半了。就是说，当内核在 <br>
交叉编译成功后，加载到目标平台上正常启动，并出现类似VFS: Can抰 mount root fi <br>
le system的提示时，则表示可以开始系统移植方面的工作了。系统移植实际上是一个最 <br>
小系统的重建过程。许多Linux爱好者有过建立Linux系统应急盘的经验，与其不同的是 <br>
，你需要使用目标平台上的二进制代码生成这个最小系统。包括：init、libc库、驱动 <br>
模块、必需的应用程序和系统配置脚本。一旦这些工作完成，移植工作就进入联调阶段 <br>
了。 <br>
    一个比较容易的系统部分移植办法是：先着手建立开发平台上的最小系统，保证这 <br>
套最小系统在开发平台上正确运行。这样可以避免由于最小系统本身的逻辑错误而带来 <br>
的麻烦。由于最小系统中是多个应用程序相互配合工作，有时出现的问题不在代码本身 <br>
而在系统的逻辑结构上。 <br>
    Linux系统移植工作至少要包括上述的内容，除此之外，有一些看不见的开发工作也 <br>
是不可忽视的，如某个特殊设备的驱动程序，为调试内核而做的远程调试工作等。另外 <br>
，同样的一次移植工作，显然符合最小功能集的移植和完美移植是不一样的；向16位移 <br>
植和向64位移植也是不一样的。 <br>
    在移植中通常会遇见的问题是试运行时锁死或崩溃，在系统部分移植时要好办些， <br>
因为可以容易地定位错误根源，而在核心移植时确实很让人头疼。虽然可以通过串口对 <br>
运行着的内核进行调试，但是在多任务情况下，有很多现象是不可重现的。又如，在初 <br>
始化的开始，很多设备还没法确定状态，甚至串口还没有初始化。对于这种情况没有什 <br>

么很好的解决办法，好的开发/仿真平台很重要，另外要多增加反映系统运行状态的调试 <br>
代码；再者要吃透硬件平台的文档。硬件平台厂商的专业支持也是很重要的。 <br>
    还有一点很重要：Linux本身是基于GPL的操作系统，移植时，可以充分发挥GPL的优 <br>
势，让更多的爱好者参与进来，向共同的目标前进。 <br>
-- <br>
  <br>
  <br>
※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.73.189] <br>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="143.htm">上一层</a>][<a href="169.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>