Zircon 使用入门

检出 Zircon 源代码

本指南假定 Fuchsia 项目已签出到 $FUCHSIA_DIR,并且已配置 fx

使用默认工具链构建 Zircon

fx 命令封装了用于配置、构建和与 Fuchsia 交互的各种工具。fx set 命令用于指定产品和主板架构。例如,如需将 build 目标设置为 Zircon 以模拟 arm64,请运行以下命令:

fx set bringup.qemu-arm64

Fuchsia 使用产品的概念来创建一组 build 目标。启动产品是具有最少功能集的最小产品。

以下命令会输出其他产品配置的列表:

fx list-products

以下命令会输出已定义的板架构的列表:

fx list-boards

如需执行 build,请运行以下命令:

fx build

构建结果保存在 $FUCHSIA_DIR/out/default 中。

明确设置目标工具链

默认情况下,Fuchsia 使用 clang 工具链。可以使用 fx setvariants 实参将其设置为 gcc

fx set bringup.x64 --variant gcc

您还可以使用变体标志来启用 ASan。

为所有目标构建 Zircon

您可以使用 fx multi 为所有目标平台进行 build,并使用包含所有 build 规范的文件。每个目标的输出都位于 $FUCHSIA_DIR/out/<product>.<board>.variant 中。多 build 规范的一个示例是 bringup-cq,它近似于为 CQ 测试构建的内容。

请先针对所有目标平台进行构建,然后再提交,以确保构建在所有架构上都能正常运行。

QEMU

如果您仅在实际硬件上进行测试,可以跳过此步骤,但模拟器非常适合进行快速本地测试,因此通常值得安装。

如需了解如何使用 Zircon 构建和使用 QEMU,请参阅 QEMU

构建工具链(可选)

如果预构建的工具链二进制文件不适合您,您可以从原始的上游来源构建自己的工具链。

  • 默认情况下,或者如果您使用 variants = [ "clang" ]variants = [ "asan" ] 进行构建,则使用 Clang 工具链来构建 Zircon。
  • 默认情况下,Clang 工具链也用于构建主机端代码,但任何支持 C++14 的构建主机工具链都应能正常运行。
  • 此外,还提供 GCC 工具链。

根据您希望如何构建 Zircon,构建其中一个或另一个,或者同时构建两者。

GCC 工具链

我们使用 GNU binutils 2.301 和 GCC 8.2,并使用 --enable-initfini-array --enable-gold 进行配置,对于 x86-64 使用 --target=x86_64-elf --enable-targets=x86_64-pep,对于 ARM64 使用 --target=aarch64-elf

对于 binutils,我们建议使用 --enable-deterministic-archives,但该开关不是获取有效 build 所必需的。

对于 GCC,必须在 make 命令行中传递 MAKEOVERRIDES=USE_GCC_STDINT=provide。这应确保 stdint.h GCC 安装是可独立运行的(源代码中为 stdint-gcc.h),而不是使用 #include_next 并期望在其他位置安装另一个 stdint.h 文件的安装。

只需要 C 和 C++ 语言支持,不需要 libgcc 以外的其他目标库,因此您可以使用各种 configure 开关来停用其他内容,并使 GCC 本身的构建速度更快,使用的存储空间更少,例如 --enable-languages=c,c++ --disable-libstdcxx --disable-libssp --disable-libquadmath。如需了解详情,请参阅 GCC 安装文档。

您可能需要各种其他 configure 开关或其他前提条件才能在特定主机系统上进行构建。请参阅 GNU 文档。

Clang/LLVM 工具链

我们使用 Clang 的主干快照,并经常更新到新的快照。任何支持 x86_64aarch64 的最新 Clang build 应该都可以。您需要一个也包含运行时库的工具链。我们通常还会为宿主以及 *-fuchsia 目标使用相同的 Clang build。如需详细了解我们如何构建 Clang,请参阅此处

为工具链设置 build 实参

如果您使用的是预构建的工具链,则可以跳过此步骤,因为 build 会自动找到它们。

设置指向您安装的工具链的 build 实参:

fx set bringup.x64 --variant clang --args clang_tool_dir = "<absolute path to>/clang-install/bin/"

或者对于 GCC:

fx set bringup.x64 --variant gcc --args gcc_tool_dir = "<absolute path to>/gcc-install/bin/"

请注意,*_tool_dir 应包含尾随斜杠。如果 PATH 中的 clanggcc 适用于 Zircon,您只需使用空前缀即可。

将文件复制到 Zircon 以及从 Zircon 复制文件

配置本地链路 IPv6 后,您可以使用 fx cp 将文件复制到设备或从设备复制文件。

包括其他用户空间文件

Zircon build 会创建一个 bootfs 映像,其中包含系统启动所需的用户空间组件(设备管理器、一些设备驱动程序等)。内核能够包含由 QEMU 或引导加载程序作为 ramdisk 映像提供的第二个 bootfs 映像。

如需创建此类 bootfs 映像,请使用在 build 过程中生成的 zbi 工具。它可以为源目录(在这种情况下,指定目录及其子目录中的每个文件都会包含在内)或通过清单文件(该文件会逐个指定要包含的文件)组装 bootfs 映像。

$BUILDDIR/tools/zbi -o extra.bootfs @/path/to/directory

echo "issue.txt=/etc/issue" > manifest
echo "etc/hosts=/etc/hosts" >> manifest
$BUILDDIR/tools/zbi -o extra.bootfs manifest

在启动的 Zircon 系统上,bootfs 中的文件将显示在 /boot 下,因此在上述清单示例中,“hosts”文件将显示在 /boot/etc/hosts 中。

网络启动

网络启动通过两种机制实现:Gigaboot 和 Zirconboot。Gigaboot 是基于 EFI 的引导加载程序,而 zirconboot 是一种机制,可让最小的 Zircon 系统充当 Zircon 的引导加载程序。

在通过 EFI 启动的系统(例如 Acer 和 NUC)上,这两种方法都可行。在其他系统上,zirconboot 可能是网络启动的唯一选项。

通过 Gigaboot

GigaBoot20x6 引导加载程序使用简单的网络启动协议(通过 IPV6 UDP),无需任何特殊的主机配置或特权访问权限即可使用。

它通过利用 IPV6 链路本地寻址和多播来实现此目的,从而允许正在启动的设备广播其可启动性,并允许主机找到该设备并向其发送系统映像。

$BUILDDIR/tools/bootserver $BUILDDIR/zircon.bin

# if you have an extra bootfs image (see above):
$BUILDDIR/tools/bootserver $BUILDDIR/zircon.bin /path/to/extra.bootfs

默认情况下,bootserver 将继续运行,并且每次观察到 netboot 信标时,都会将内核(以及 bootfs,如果已提供)发送到相应设备。如果您传递 -1 选项,bootserver 将在成功启动后退出。

通过 Zirconboot

Zirconboot 是一种机制,可让 Zircon 系统充当 Zircon 本身的引导加载程序。Zirconboot 使用的启动协议与上述 Gigaboot 相同。

如需使用 zirconboot,请通过内核命令行将 netsvc.netboot=true 实参传递给 zircon。当 zirconboot 启动时,它会尝试从所连接主机上运行的启动服务器中提取并启动到 Zircon 系统。

查看网络日志

Zircon 的默认 build 包含一个网络日志服务,该服务通过链路本地 IPv6 UDP 多播系统日志。请注意,这只是一个快速的临时解决方案,协议肯定会在某个时间点发生变化。

目前,如果您在 QEMU 上运行 Zircon 时使用了 -N 标志,或者在具有受支持的以太网接口(ASIX USB 适配器或 NUC 上的 Intel 以太网)的硬件上运行 Zircon,loglistener 工具将观察通过本地链接广播的日志:

$BUILDDIR/tools/loglistener

调试

如需了解有关在 Zircon 环境中进行调试的随机提示,请参阅调试

贡献更改


  1. binutils 2.30 版本在 aarch64-elfx86_64-elf 配置中存在一些无害的 make check 失败。这些问题已在实际构建的上游 binutils-2_30-branch git 分支中修复。但 2.30 版在构建 Zircon 时运行正常;只是在自己的测试套件中出现了一些虚假故障。