在嵌入式 Linux 成为网络设备的实际标准之前，构建住宅网关 (RG) 或类似的设备曾经是一项昂贵且不简单的任务。实时操作系统 (RTOS) 用于这些类型的设备，例如 VxWorks 或 pSOS，相对昂贵且缺乏 RG 所需的许多功能，这些功能必须单独购买。 例如，VxWorks 5.5 配备的 TCP/IP 协议栈存在性能问题，甚至没有实现 L2 桥接，更不用说防火墙了。这种情况为许多公司创造了商机，例如 Ashley Laurent 和 Jungo，他们为各种操作系统销售 RG 软件栈。嵌入式 Linux 发行版（如 uClinux）的出现，将构建 RG 的过程简化为选择合适的硬件，编写外围设备的驱动程序以及添加某种基于 Web 的配置实用程序。 嵌入式 Linux 不仅通过提供 RTOS 中缺少或昂贵的许多重要功能来降低 RG 设备的开发和成本，而且还通过清晰的 POSIX 驱动程序模型和内核/用户模式分离，简化了驱动程序和应用程序的集成和调试。

然而，Linux 在嵌入式网络市场中的主导地位现在正受到新技术的挑战。过去，配备 ADSL、DOCSIS 和 802.11 外围设备的 RG 设备很少需要超过 10Mbps 的吞吐量。 诸如 802.11n 和 PON 之类的新技术使 100Mbps 吞吐量成为现实，这对嵌入式工程师提出了创建能够处理更高流量的 RG 的任务，而且硬件价格相同或至少相似。

在设计您自己的住宅网关之前，可能值得仔细研究一下这些设备之一。

如果您决定查看您的 802.11 接入点或 ADSL 网关的内部（这可能会使您的保修失效），您会发现一块嵌入式板，上面有一个 CPU（可能是某种 MIPS 变体）、以太网交换机、ADSL/DOCSIS 和 802.11 芯片，如图 1 所示。

图 1. RG 硬件框图

以上某些（甚至全部）可以集成到一块芯片中，形成一个片上系统 (SoC)。另一方面，您也可能会发现与笔记本电脑中相同的标准 mini-PCI (mPCI) 802.11 卡连接到嵌入式板。

您的家庭网关很可能运行 Linux。如果您想确定或者想对其进行一些破解，您必须焊接 UART 连接器，这相对容易（大多数板都启用了 UART，但没有连接器）。 软件栈通常包括某个版本的 Linux（2.4.x 内核在嵌入式世界中仍然很常见）、常用的用户空间实用程序和库、外围设备驱动程序以及配置实用程序——命令行界面 (CLI)、Web 或两者兼有，如图 2 所示。

图 2. RG 软件框图

现在您已经对构成住宅网关的要素有了大致的了解，并且假设您有可用的硬件（有关硬件的更多详细信息将在本文后面介绍），让我们看看您需要哪些软件。 最低限度，您需要内核源代码、libc 库的某个变体、基本的用户模式实用程序（至少一个 shell）以及一个交叉编译器工具链来构建所有这些。简而言之，您需要一个嵌入式 Linux 发行版。 uClinux 是一个不错的选择，因为它支持各种 CPU（不一定是没有 MMU 的 CPU，顾名思义），附带许多有用的用户模式实用程序，并且为所有软件包提供易于使用的内核风格配置系统。 与往常一样，选择不仅限于一个发行版。有各种免费和商业 Linux 发行版可供选择。

假设您的板（不仅仅是 CPU）受 uClinux 支持，构建工作镜像的过程归结为下载发行版本身和 CPU 的交叉编译器工具链，然后简单地按照构建说明进行操作。 如果您的板不受 uClinux 支持，则板制造商很可能会提供板级支持包 (BSP) — 即，使 uClinux（或某些其他 Linux 版本）适应该硬件。如果情况并非如此，您必须自己编写 BSP，这超出了本文的范围。

uClinux 发行版的主要组件当然是内核本身、uClibc 库和 BusyBox。 uClinux 内核支持无 MMU 的 CPU，但此功能在当今已不太重要。 因为添加 MMU 的成本如此之小，我预计大多数（如果不是全部）用于 RG 的嵌入式 CPU 都将具有它。 尽管如此，即使您不利用无 MMU CPU 支持，uClinux 仍然是一个很棒的发行版。 uClibc 也是如此。它最初是为了支持无 MMU 系统而创建的，例如，这些系统不能有 fork(2) 系统调用。 但是，即使您不需要此功能，它也是嵌入式系统上 glibc 的绝佳替代品，因为 glibc 对 RAM 的要求更高。 BusyBox 是标准 UNIX 实用程序的集合，针对具有低 RAM 的嵌入式系统进行了优化。 它随 uClinux 一起提供，与 uClibc 一样，除非您的系统具有足够的 RAM（通常高于 16MB），否则您通常会首选它而不是功能齐全的标准实用程序。

您需要两个不属于 uClinux 的重要软件。 第一个软件是引导加载程序，它通常驻留在 ROM 中（至少部分），负责将 Linux 镜像从闪存加载到 RAM 并执行一些硬件初始化。 不幸的是，uClinux 没有标准的引导加载程序。 事实上，嵌入式世界中没有引导加载程序的标准，您也不能使用 PC 引导加载程序，例如 GRUB 或 LILO。 您的硬件制造商几乎肯定会提供引导加载程序，我强烈建议您使用它。 如果它不支持 Linux，通常更容易采用它而不是将不同的引导加载程序移植到您的硬件。 如果您仍然选择移植引导加载程序，Das U-Boot 是一个不错的选择，还有许多其他选择。

第二个缺失的部分是基于 Web 的图形用户界面 (GUI)，大多数用户都期望从 RG 中获得它。 大多数（如果不是全部）当前可用的 RG 都具有从头开始编写的 Web 界面。 然而，随着 X-Wrt 项目的引入，情况不再如此，X-Wrt 项目是 OpenWrt 项目的组件之一，如果您正在构建 RG，您几乎肯定会想查看它。 OpenWrt 是 Linksys WRT 路由器（以及其他路由器）的 Linux 发行版。

再加上一些 init 脚本编写，您就完成了，除了外围设备（802.11、ADSL 等）驱动程序，这是另一篇文章的主题。

现在到了真正有趣的部分——选择（甚至更好，设计）您的硬件。 MIPS 是这些类型设备中最常用的 CPU 架构，较旧的设备使用 MIPS32 4K 内核，而较新的设备可能使用 MIPS32 24K 内核。 由于 MIPS 24K 在相同的时钟速率下比 MIPS 4K 慢约 3%（由于流水线更长），因此仅当您真正需要大约 400MHz 的时钟速率时才使用它才有意义。 然而，基准测试表明，网络设备受内存和 I/O 限制，而不是受 CPU 限制（毕竟，转发数据包没有太多的数字运算，除了稍后讨论的少数例外），因此您可能只有在要使用 DDR RAM 而不是 SDRAM（后者限制为 133MHz）时才需要这些高时钟速率。

另一种选择是 MIPS32 34K 的新（至少在嵌入式世界中）多线程 (MT) 技术，它可以具有可配置数量的虚拟处理元素 (VPE) 和线程上下文 (TC)。 在不深入细节的情况下，这项技术是 Intel 超线程的更灵活的等效技术，它有助于 CPU 在进程和线程级别利用并行性（与超标量处理器可以很好地利用的指令级别并行性相比）。 这可以在某些情况下提高性能，尤其是在有几个并发进程或线程受 I/O 或内存限制时，但基准测试表明情况并非总是如此。 此外，MT 具有开销——MIPS 34K 在相同的时钟速率下比 MIPS 24K 稍慢，并且在启用对称多处理 (SMP) 的情况下编译 Linux 内核时，Linux 内核会稍微变慢。

您可能应该考虑的另一个 CPU 是 MIPS 最接近的竞争对手——ARM。 出于历史原因，它在这些特定设备中的使用频率低于 MIPS。 ARM7 非常流行、体积小且功耗低；然而，对于 RG 来说，它显然太慢了。 如果您决定使用 ARM，您应该考虑 ARM9 或 ARM10 系列处理器之一，就 RG 应用程序而言，主要区别在于性能、功耗和成本。

RAM 和闪存的选择是显而易见的；您至少需要 8MB 的 RAM 和 2MB 的闪存。 然而，随着内存价格的下降，我预计未来的设备将具有 64MB 的 RAM 和 4MB 的闪存。 出于同样的原因，您可能必须使用 DDR 而不是 SDRAM——因为 SDRAM 实际上比 DDR 更昂贵。

假设您将使用制造商提供的参考设计板之一（无论如何，板设计超出了本文的范围），您就可以测试您的全新 RG 了。 不幸的是，您将感到非常惊讶。 您的 CPU 将在不太合理的带宽下卡顿。

一种可能的解决方案是使用功能更强大（且价格贵得多）的 CPU，例如 Intel IXP 或 Freescale PowerQUICC 网络处理器。 例如，533MHz IXP425 将毫不费力地维持这种流量。 不幸的是，为了保持竞争力，RG 制造商无法负担得起这些高端处理器，因此需要更具创造性的解决方案。

这是下一代 RG 的挑战——使用低端硬件实现高吞吐量。 一种可能的解决方案是将 RG 的整个数据路径卸载到硬件，就像高端核心路由器的工作方式一样，高端核心路由器通常仅将通用 CPU 用于管理和控制。 有一些芯片可以为低端 RG 市场做到这一点，例如 Realtek RTL8650B/RTL8651B，它们可以在硬件中进行路由、NAT 和防火墙。 当然，与 Linux TCP/IP 协议栈相比，该实现是有限的，但是硬件可以配置为在遇到无法处理的数据包时捕获 CPU，以便大多数数据包将在不中断 CPU 的情况下从一个接口转发到另一个接口。 然而，这种方法存在许多问题，最严重的问题是硬件 TCP/IP 协议栈仅限于固定接口（RTL8650 的情况为 MII）。 将其他接口（如 802.11、DOCSIS 和 xDSL）连接到该逻辑将很困难，在某些情况下甚至是不可能的。 因此，我认为虽然这种方法在某些特定情况下可能有效，但在一般情况下这是一个错误的想法。

通常，尽可能多地保留软件是一个好主意，因为它更容易开发和调试。 另一种优化方法是基于 RG（以及一般的网络应用程序）受内存限制的观察，因此改进内存访问将非常有益。 为了便于讨论，让我们将数据和代码分开。 就代码而言，我们希望尽可能将其保留在缓存中。 理想情况下，我们希望整个关键路径例程——即，从一个驱动程序的接收函数到 TCP/IP 协议栈再到另一个驱动程序的发送函数，始终保留在缓存中。 这对于大多数只有 32K 缓存的嵌入式处理器来说是不可能的。 然而，可以证明，Linux 2.6 关键路径——即，在防火墙和 NAT 配置下，包括以太网驱动程序的发送和接收例程，95% 的时间使用的函数可以容纳在 64K 缓存中，并且市场上有一些带有 64K 缓存的嵌入式处理器。 如果您的 CPU 没有那么多缓存，而是有暂存 SRAM，您可以修改 Linux 链接器脚本以将某些例程放置在 SRAM 内存区域中。

如果您想测试上述观察结果（或计算您的特定应用程序需要多少缓存），请使用 OProfile，这是一个用于 Linux 的系统范围的分析器，它允许您分析用户模式应用程序、内核和驱动程序，并支持许多嵌入式架构以及 objdump（或任何其他实用程序），它将向您显示每个例程需要多少内存。

至于数据，绝对有必要确保所有网络驱动程序都遵循零拷贝方法，并且将频繁访问的数据结构放置在暂存 SRAM 中可能是明智之举。

另一种优化方法是上述两种方法的混合——使用分析器，找到 CPU 密集度最高的代码段，并将此特定功能卸载到硬件。 事实证明，与网络相关的两个最 CPU 密集型任务是 IPSec 和 UDP/TCP 校验和计算。 非常方便（并且不足为奇）的是，两者都具有用于硬件卸载的明确定义的架构。 UDP 和 TCP 校验和卸载非常有利，因为如果在硬件中接收时进行检查并在硬件中传输时进行计算，则 CPU 将永远不必将整个数据包带入缓存，从而显着减少内存访问次数。 另一方面，IPSec 的用处较小，因为 RG 很少是 IPSec 终止点——通常 IPSec (VPN) 流量会通过并在 PC 上终止。

我绝对不推荐的另一种方法，但一些制造商正在采用这种方法，因为它实际上比上述方法更便宜，那就是通过创建各种类型的“快速路径”来“优化”Linux。 例如，如果 L2 桥接性能不令人满意，则可以将数据包从一个网络驱动程序直接传递到另一个网络驱动程序，从而消除至少一个上下文切换和其他一些代码，从而提高性能。 虽然它在一般情况下不起作用，但它适用于 RG，在 RG 中，制造商控制整个系统，包括所有驱动程序和内核本身。 这种方法的最大问题在于，它实际上削弱了库存 Linux 内核，限制了功能并引入了错误。 这些修改很少提交给 Linux 内核邮件列表，即使提交了，也永远不会被接受。 但是，它们确实会进入您在商店中可以找到的某些产品。

使用上述步骤，您应该能够相对轻松地构建基于 Linux 的 RG。 如果性能成为问题，如果您不能使用高端处理器，则几乎肯定会出现这种情况，请遵循上述优化指南。 而且，始终最好在您的特定系统上运行分析器，以发现其他瓶颈。

尽管本文讨论了 RG，但大多数结论和指南都适用于任何嵌入式网络系统。

Linux 优化 RG 系统的问题实际上引出了一个更大且更具争议性的话题。 开源社区与为商业公司工作的嵌入式开发人员之间似乎存在严重的沟通问题。 一方面，添加到内核的功能有时会损害小型嵌入式系统的性能。 另一方面，一些公司对 Linux 的改进并不总是能回到主内核树中，通常是因为它们做得不正确。 这种沟通不畅的一个很好的例子是 2.6 内核本身，它包含了许多针对嵌入式系统的重大改进，但性能有所下降。 结果，大量的嵌入式系统仍然运行 2.4 内核。 造成这种沟通不畅的原因可能是半导体公司通常从事嵌入式软件开发，他们发现很难接受开源的想法，但也可能是因为开源社区对嵌入式系统不太感兴趣，因为它们比 PC 更难破解。 我相信第一个问题最终会消失，因为半导体公司了解他们如何从开源中受益，并且我尽我所能地在任何地方解释。 至于第二个问题，本文的信息之一是，破解嵌入式系统很容易而且非常酷，而且您实际上可能已经拥有了硬件。