Tiny Core Linux 以其仅 16MB 的极简镜像著称，而其面向 Raspberry Pi 的移植版本 PiCore 则是嵌入式 Linux 领域的独特存在。与 Raspbian 或 Raspberry Pi OS 不同，PiCore 采用完全 RAM 优先的运行模式，系统启动后从内存中执行，SD 卡内容在重启后不被修改 —— 这种设计使其成为嵌入式开发、轻量级容器运行时和硬件资源受限场景的理想选择。本文从 ARM 架构适配、Bootloader 定制与硬件驱动裁剪三个维度，解析 PiCore 移植工程的核心技术要点。
ARM 架构适配：从 x86 到 ARMv6/ARMv8 的跨越
PiCore 的移植首先要解决的是指令集架构层面的兼容性问题。Tiny Core Linux 最初基于 x86 架构构建，其核心组件（包括 Tiny Core Linux 特有的 FLTK/FLWM 桌面环境、BusyBox 工具链）均需要针对 ARM 架构重新编译。PiCore 维护者为不同的树莓派型号提供了独立的镜像文件，分别对应 ARMv6（Pi Zero、Pi 1）、ARMv7（Pi 2）和 ARMv8（Pi 3、Pi 4，兼容 ARMv7 模式）架构。这一分层策略确保了二进制兼容性，同时也意味着开发者需要为每个架构变体维护独立的扩展包仓库。
在核心库层面，PiCore 采用了 uClibc 作为 C 标准库替代 glibc，这一选择显著降低了内存占用。uClibc 的静态链接支持使得大多数基础工具可以直接编译为独立的可执行文件，无需依赖额外的动态链接库，进一步压缩了镜像体积。对于 ARMv8 架构，PiCore 还引入了 AArch64 指令集支持，使得在 Pi 3B+ 及以上型号上可以运行 64 位操作系统，获得更好的内存寻址能力和计算性能。
Bootloader 定制：U-Boot 与设备树的深度整合
树莓派不同于传统的 PC 平台，它没有标准的 BIOS/UEFI 固件，而是依赖 GPU 固件加载 Bootloader。PiCore 的启动流程涉及多层引导：首先，树莓派 GPU 读取 SD 卡启动分区中的 bootcode.bin 和 start.elf，初始化 GPU 后加载 U-Boot 作为第二阶段引导程序。U-Boot 随后读取设备树文件（.dtb），根据具体的树莓派型号配置硬件外设，最后加载 Linux 内核并启动 init 系统。
PiCore 对 U-Boot 进行了针对性定制，主要体现在三个方面。其一是启动参数的精简：相比桌面发行版动辄数十行的内核命令行，PiCore 的启动参数通常控制在 10 个以内，重点包括 root=/dev/ram0（强制使用初始 RAM 磁盘作为根文件系统）和 base=（指定扩展包加载的内存起始地址）。其二是设备树的裁剪：树莓派的默认设备树包含了大量外设节点，而 PiCore 只保留核心外设支持（USB、以太网、SD 卡），禁用蓝牙、Wi-Fi、HDMI 音频等可选功能，以降低内核体积。其三是 U-Boot 环境变量的固化：通过将网络引导配置（MAC 地址、DHCP 选项）写入 U-Boot 环境变量，PiCore 实现了上电即联网的无人值守部署能力。
硬件驱动裁剪：极致精简的代价与权衡
PiCore 的设计哲学是 “按需加载”，这在内核驱动层面体现为极度克制的内置驱动集合。与 Raspbian 默认加载数十个内核模块不同，PiCore 的内核镜像仅包含最少数量的必需驱动：CPU 频率管理驱动、SD 卡驱动、USB 控制器驱动、以太网驱动以及基本的输入设备驱动。其他硬件功能（如蓝牙、Wi-Fi、硬件编解码器）均通过可选扩展包在运行时加载。
这种设计带来了显著的优势：内核镜像体积可以控制在 4MB 以内（相比 Raspbian 的 40MB+ 内核），启动时间缩短至 3-5 秒（从通电到 shell 可用），内存占用在基础运行状态下低于 80MB。然而，它也要求开发者具备一定的问题排查能力 —— 当某个硬件功能失效时，用户需要手动诊断是缺少内核驱动还是缺少用户空间工具。例如，在 Pi 4 上启用桌面环境时，用户需要依次加载 mesa 图形驱动、Xorg 服务器和 flwm 窗口管理器，每一步都依赖正确的扩展包组合。
对于有进一步裁剪需求的高级用户，PiCore 提供了内核配置文件的访问路径。通过交叉编译工具链在 x86 机器上重新编译内核，开发者可以进一步禁用不需要的内核选项（如 NFS、CIFS、IPv6 等），将内核体积再压缩 20-30%。这一过程虽然技术门槛较高，但为超低资源场景（如 512MB RAM 的 Pi Zero）提供了可行的优化路径。
工程实践：扩展机制与持久化策略
PiCore 的扩展包机制是其区别于其他轻量级发行版的核心特色。扩展包（.tcz 文件）本质上是轻量化的 SquashFS 镜像，通过 tce-load 命令可以动态加载到内存中。默认情况下，扩展包存储在 SD 卡的 tce 目录下，加载时解压到 tmpfs 内存文件系统。由于整个系统运行在 RAM 中，任何对文件系统的修改都需要通过 filetool.sh -b 命令手动备份到 SD 卡，否则重启后将丢失。
在实际部署中，一个典型的 PiCore 启动流程如下：首先将镜像写入 SD 卡，修改启动分区中的 config.txt 以适应具体硬件配置；然后通过网线或 Wi-Fi 适配器连接网络，设置静态 IP 或启用 DHCP；最后使用 tce-load 加载必要的扩展包（如 openssh、nginx、python3），并将常用扩展包添加到启动脚本中实现自动加载。这一流程的复杂度高于传统发行版，但也赋予了用户对系统行为的完全控制权 —— 没有任何后台服务会在用户不知情的情况下运行。
从系统监控的角度看，PiCore 的极简设计也带来了独特的监控需求。由于系统高度依赖内存，内存使用率的实时监控尤为重要；扩展包的动态加载机制意味着 /tmp 和 /var 目录会随着使用时间增长而积累临时文件，定期清理是维护系统稳定性的必要操作。此外，网络连接的可靠性直接影响扩展包的加载，因此对网络接口状态的监控也是生产环境部署的关键环节。
资料来源：PiCore 官方发布说明与社区文档（tinycorelinux.net）、Brezular's Blog 关于 PiCore 首次启动的实践指南。