假设您有一组描述系统中内存映射设备的 c 头文件，那么制作初始运行内核的实际步骤是什么？我知道每个人都只是从实时 CD/USB 拇指驱动器等启动。但是第一个引导程序是如何制作的？
编辑：我应该指出，我实际上是在谈论 ARM 设备，我了解在典型机器上通过 BIOS 加载的基础知识，但是假设我们谈论的是自定义设备？
答案1
第一个引导程序是怎样制作的？
构建（编写和交叉编译）引导程序并不像您想象的那么困难。
我应该指出，我实际上是在谈论 ARM 设备，我了解在典型机器上通过 BIOS 加载的基本知识，但是假设我们谈论的是自定义设备？
您所提到的 BIOS 本质上是一种 PC 惯例。（CP/M 也有 BIOS，但不一定位于非易失性存储器中。）ARM CPU 通常没有或不使用 BIOS。
目前使用的典型 ARM 处理器与外围设备集成在单个 IC 上，称为系统级芯片，片上系统。主存储器（例如 DRAM）和非易失性存储器（例如 NAND 闪存）通常位于 SoC 外部，以实现最大的设计灵活性。但通常会有一个小型（可能 128KB）嵌入式 ROM（只读存储器）来初始化最小系统组件以开始引导操作。处理器重置将始终导致执行此引导 ROM。（此 ROM 确实是只读的，无法修改。代码在芯片制造期间被屏蔽到硅片中。）
每个 SoC 供应商都有自己的引导方法来加载和执行操作系统。有些供应商使用通过 GPIO 引脚读取的硬件捆绑来确定引导序列下一阶段的来源。另一个供应商可能使用有序的内存和设备列表来探测引导程序。另一种技术是分支到 NOR 闪存中的固件，可以直接执行（即 XIP，就地执行）。
引导使用 DRAM 作为主内存的系统时遇到的问题之一是硬件初始化。必须先初始化 DRAM 内存控制器，然后才能将代码加载到 DRAM 中并执行。既然初始化代码不能位于主内存中，那么它应该驻留在何处呢？
每个供应商都有自己的解决方案。有些供应商要求将内存配置数据存储在非易失性内存中，以供引导 ROM 访问。有些 SoC 集成了 SRAM（不需要像 DRAM 那样进行初始化）来执行小型引导程序。有些 SoC 使用 NOR 闪存来保存 XIP 引导程序。
一旦引导程序初始化了 DRAM，就可以使用主内存来加载引导的下一阶段。这可能是一个复杂的引导实用程序，例如 U-Boot，或者（如果引导程序能够执行）Linux 内核。请注意，在处理器重置到执行操作系统之间可能会执行多个引导程序或阶段。
启动 Linux ARM 内核的要求在以下文档中有详细说明：http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
旧版本的 Linux ARM 使用 ATAG 列表将基本配置信息传递给内核。现代版本使用设备树的编译二进制文件提供完整的板配置。
显然，“如何制作引导程序？”这个问题如果没有一定的资格就无法回答。
和 PC BIOS 一样，SoC 的引导 ROM 是专有的，不会发布（除非您签署保密协议，否则不会发布）。但大多数其他引导代码都是根据 GPL 或类似许可发布的，并且很容易获得。
附录
既然你现在提到你正在使用 Zynq 7000（使用 Xilinx SoC），Xilinx 有一个视频教程如何构建 Linux 启动映像。
该视频证实了我已经写过的内容：
1. Xilinx SoC 具有嵌入式引导 ROM（从技术上讲是第一阶段，但通常被忽略或描述为第零阶段）。2
. 有“模式引脚”用于指定下一阶段引导程序的来源。3
. 引导 ROM 将引导程序（从技术上讲是第二阶段，但通常被描述为“第一”阶段）加载到嵌入式 SRAM 中，称为 FSBL。该程序初始化 DRAM 并加载下一阶段 U-Boot。4.
U-Boot 在 DRAM 之外执行，并加载 Linux 内核。
视频演示了如何从 Xilinx 网站下载 FSBL 源代码，然后通过几个步骤进行交叉编译。“诡计”正如您所说。构建过程是直接的配置和交叉编译，我发现它比典型的应用程序包更简单/更容易。
也许您的困惑是基于启动介质的模糊性，即未指定启动映像的来源。视频提到 NAND 闪存和 SD 卡是可能的启动设备。
引导 ROM 被指示从模式引脚配置的源介质读取 FSBL 映像。
FSBL（如果它与我使用过的其他引导程序类似）旨在从配置的源介质读取 U-Boot。没有运行时替代方案。
U-Boot 力图实现其名称（“通用”），并且可以配置（使用环境变量）从各种设备加载图像（和脚本）。此外还有交互选项。
另请参阅 Xilinx wikiZynq Linux，其中声明“有关 Zynq 启动的完整信息可以在技术参考手册“。