📚 课程目录第3章 Linux系统基础

3. Linux系统基础

在S32G这类面向车载网关与实时控制的异构SoC上，Linux并不是“装上去就能跑”的通用操作系统，而是需要围绕芯片外设、启动流程和实时性目标重新裁剪与配置的工程产物。理解Linux内核架构、设备树、根文件系统、交叉编译工具链以及Yocto项目，是后续把Linux与RTOS、AUTOSAR或实时补丁集成起来的前提。本节从整体结构出发，逐层拆解这五个基础构件之间的关系。

一、Linux内核架构：从用户空间到硬件

Linux采用宏内核设计，核心服务运行在内核态，用户程序通过系统调用进入内核。对S32G而言，最需要关注的是与硬件直接相关的几个子系统：进程调度、内存管理、虚拟文件系统（VFS）、网络协议栈、设备驱动模型以及中断管理。S32G包含Cortex-A53应用核与Cortex-M7实时核，Linux通常运行在A53集群上，通过驱动访问CAN、以太网、PCIe、SD/eMMC等外设。

内核源码目录结构本身反映了架构划分：arch/arm64存放ARM64体系结构相关代码，drivers/按总线与设备类型组织驱动，kernel/负责调度与核心机制，fs/实现文件系统，net/实现协议栈。移植S32G时，主要工作集中在arch/arm64/boot/dts/freescale/下的设备树、drivers/下的外设驱动以及defconfig内核配置。

内核配置决定了哪些驱动被编译进内核（=y）、哪些编译为模块（=m）、哪些完全不参与构建。S32G的BSP通常提供s32g_defconfig作为起点，再按项目裁剪。

二、设备树：把硬件描述从代码中分离

ARM64平台普遍采用设备树（Device Tree）描述硬件。设备树源文件.dts经编译生成.dtb，由Bootloader在启动时传给内核。内核解析设备树后，为每个节点匹配相应驱动。这样同一份内核镜像可以适配不同板级配置，而不必为每块板子重新编译内核。

设备树的核心概念包括：节点（node）、属性（property）、兼容性字符串（compatible）、地址与中断（reg、interrupts）、时钟与引脚（clocks、pinctrl）。以S32G的CAN控制器为例，典型节点会声明寄存器基址、中断号、时钟源和收发器引脚，驱动通过compatible匹配后完成初始化。

can0: can@401c8000 {
    compatible = "fsl,s32g-can";
    reg = <0x0 0x401c8000 0x0 0x4000>;
    interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&clks CAN0_CLK>;
    status = "okay";
};

设备树常见误区是“改了dts但没重新编译dtb”或“节点status仍为disabled”。调试时可通过/proc/device-tree查看内核实际解析到的节点，确认驱动是否绑定成功。

三、根文件系统：Linux用户空间的载体

内核启动完成后需要挂载根文件系统（rootfs），才能运行init及用户程序。rootfs包含/bin、/etc、/lib、/dev、/proc、/sys等目录。嵌入式场景常用BusyBox构建精简rootfs，或用Yocto生成完整发行版。S32G项目通常将rootfs放在eMMC、SD卡或通过NFS挂载，便于开发阶段快速迭代。

启动参数root=与rootfstype=决定内核从哪里加载rootfs。若rootfs缺少/dev/console或init，系统会停在“Kernel panic - not syncing: No init found”。因此构建rootfs时必须确保设备节点、动态库和初始化脚本完整。

四、交叉编译工具链与Yocto项目

S32G的A53核无法直接在开发初期运行完整编译环境，因此采用交叉编译：在x86_64主机上使用aarch64工具链生成ARM64目标代码。工具链通常包含aarch64-poky-linux-gcc、ld、objcopy等。编译内核时通过ARCH=arm64与CROSS_COMPILE=aarch64-poky-linux-指定目标架构。

export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-
make s32g_defconfig
make -j$(nproc) Image dtbs modules

Yocto项目则进一步把工具链、内核、Bootloader、rootfs和SDK的构建流程标准化。它通过配方（recipe）、层（layer）和配置（conf）描述“如何构建”。S32G的BSP通常以meta-freescale层形式提供，开发者新增自己的meta-xxx层来叠加定制。Yocto的核心价值是可复现：同一套配方在不同机器上生成一致的镜像。

构件	作用	S32G典型对象	常见问题
内核	进程、内存、驱动、协议栈	linux-imx / s32g内核	配置裁剪过度导致外设缺失
设备树	描述板级硬件与引脚	s32gxxx.dts / .dtb	节点未使能或地址错误
根文件系统	提供用户空间与初始化	BusyBox / Yocto rootfs	缺少init或动态库
交叉工具链	在主机生成目标代码	aarch64-poky-linux-	架构或sysroot不匹配
Yocto	标准化构建与镜像生成	meta-freescale + 自定义层	层依赖或配方版本冲突

五、案例场景：从零构建一个可启动镜像

假设要为S32G板卡构建一个带CAN与以太网支持的Linux镜像，流程如下：

准备Yocto环境，检出对应BSP版本，初始化oe-init-build-env。
在bblayers.conf中加入meta-freescale与自定义层，在local.conf中设置MACHINE为S32G目标板。
通过bitbake core-image-minimal生成内核、dtb与rootfs。
检查设备树中CAN、以太网节点是否为okay，确认驱动已编译进内核。
将镜像写入SD/eMMC，设置Bootloader启动参数，观察串口日志直到进入登录提示。

开发阶段可先用NFS挂载rootfs，避免每次修改用户程序都重新烧写存储介质；量产阶段再切换为eMMC或SD启动。

六、误区与复盘

常见误区有三类。第一，把设备树当成“配置文件”随意修改，却忽略驱动与compatible的匹配关系，导致节点存在但驱动不加载。第二，交叉编译时混用主机库与目标库，出现“cannot find -lxxx”或运行时段错误，应通过--sysroot严格隔离。第三，Yocto构建失败后直接改源码而不改配方，导致下次构建被覆盖，正确做法是新增.bbappend或补丁文件。

复盘时建议保留每次构建的local.conf、层列表和内核配置差异，形成可追溯的构建记录。只有把内核、设备树、rootfs、工具链和Yocto视为一个整体，才能在S32G上稳定地运行Linux，并为后续实时系统集成打下可靠基础。