全志Tina Linux嵌入式开发实战：从环境搭建到系统定制全流程指南

1. 项目概述：为什么需要一份系统级的开发指南？

在嵌入式Linux开发领域，尤其是基于全志这类主流国产芯片平台的开发，新手和老手都会面临一个共同的困境：官方文档往往散落在各处，有SDK的配置说明、有内核的移植手册、有文件系统的构建教程，但唯独缺少一份能把这些环节串联起来，从零开始构建一个完整、可运行、可调试的Tina Linux系统的“全景式”指南。你可能会在某个论坛找到一篇讲U-Boot移植的精华帖，又在另一个博客里看到根文件系统打包的脚本，但这些信息是割裂的，缺乏统一的上下文和连贯的操作逻辑。

这份《Tina Linux系统软件开发指南》就是为了解决这个问题而存在的。它不是一个简单的命令罗列文档，而是一份融合了原理、步骤、排错和实战经验的系统性工程手册。无论你是刚刚接触全志Tina SDK的嵌入式软件工程师，还是负责产品底层系统搭建的开发者，甚至是希望深入理解嵌入式Linux构建流程的爱好者，这份指南都试图为你提供一个清晰的路线图。它的核心价值在于，不仅告诉你“怎么做”，更着重解释“为什么这么做”，以及在不同方案间“如何做选择”。我们将从最基础的开发环境搭建开始，一步步深入到内核配置、驱动开发、文件系统定制、应用层集成，最终完成一个具备基础功能的可启动系统镜像。在这个过程中，你会遇到各种“坑”，而我会把那些年我踩过的坑、总结的技巧，毫无保留地分享出来。

2. 开发环境搭建与SDK深度解析

2.1 宿主机环境配置：超越官方建议的稳定组合

全志官方通常建议使用Ubuntu 14.04或16.04这类较旧的系统，主要是为了匹配其工具链和构建脚本的依赖库版本。但在今天，我们完全可以在更新的系统上（如Ubuntu 20.04 LTS）建立一个更稳定、更高效的环境。关键在于精准控制编译工具链和核心依赖库的版本，而非盲目降级整个操作系统。

首先，安装基础开发包。这一步是构建任何嵌入式Linux系统的基石。

sudo apt-get update sudo apt-get install -y build-essential subversion git-core libncurses5-dev zlib1g-dev gawk flex quilt libssl-dev xsltproc libxml-parser-perl mercurial bzr ecj cvs unzip lib32z1 lib32z1-dev lib32stdc++6 libstdc++6 libc6:i386 libstdc++6:i386 lib32ncurses5-dev

请注意上面命令中lib32*和:i386的包，它们是64位系统下编译32位ARM工具链和应用所必须的兼容库，缺失会导致各种诡异的链接错误。

接下来是工具链。Tina SDK通常自带或指定了专用的交叉编译工具链（比如arm-openwrt-linux-muslgnueabi-gcc）。我们的任务不是安装它，而是正确地将其集成到系统环境中。假设SDK解压后，工具链路径为/path/to/tina-sdk/prebuilt/gcc/linux-x86/arm/toolchain-sunxi-musl/toolchain/bin，将其加入PATH是最佳实践：

export PATH=/path/to/tina-sdk/prebuilt/gcc/linux-x86/arm/toolchain-sunxi-musl/toolchain/bin:$PATH

为了永久生效，可以将这行命令添加到你的~/.bashrc文件中。之后，执行source ~/.bashrc并运行arm-openwrt-linux-muslgnueabi-gcc -v来验证工具链是否可用。

注意：不同版本的Tina SDK可能使用不同的工具链前缀（如arm-openwrt-linux-，arm-linux-gnueabi-）。务必根据你SDK中prebuilt目录下的实际文件夹名和bin目录下的可执行文件名来确定。盲目复制命令是环境搭建失败的首要原因。

2.2 Tina SDK目录结构深度解读

进入Tina SDK根目录，你会看到一系列文件夹，理解它们各自的作用是高效开发的前提：

• device/：这是芯片和板级配置的核心目录。里面通常按vendor/chip/（如allwinner/t113-s3/）的方式组织。在这里，你可以找到该芯片方案对应的内核配置文件（linux/）、U-Boot配置文件（uboot/）、系统分区表（sys_partition.fex）以及最重要的board.dts设备树文件。定制硬件修改，主要就在这里进行。
• kernel/：Linux内核源代码。Tina对其进行了深度定制，加入了大量全志特有的驱动和补丁。你通常不需要动这里的核心代码，但会频繁地在这里执行make kernel_menuconfig来配置内核功能。
• package/：这是OpenWrt风格的精髓所在，应用软件包目录。所有第三方软件，从基础的busybox、openssh，到复杂的多媒体框架，都以“包”的形式存在。每个包目录下都有一个Makefile，定义了如何下载、编译、安装这个软件。你要新增一个应用程序，最规范的方式就是在这里创建一个新的包。
• target/：目标系统生成目录。它定义了最终文件系统的骨架。linux/子目录下包含了一些系统启动必需的初始化脚本、预置的配置文件（如网络、服务）等。编译后生成的根文件系统会整合这里和package/里安装的内容。
• tools/：打包和烧录工具集。其中pack工具至关重要，它负责将编译好的U-Boot、内核、设备树、根文件系统等，按照sys_partition.fex的定义，打包成一个单一的.img固件文件，用于烧录到设备存储中。
• build/：OpenWrt构建系统核心。包含了一系列*.mk文件，控制着整个编译流程。普通开发者很少需要直接修改这里。
• out/：编译输出目录。所有编译产生的临时文件、最终镜像都在这里。out/{方案名}/下可以找到打包好的固件。

理解这个结构，你就知道：改硬件配置去device/，改内核去kernel/，加软件去package/，改系统默认行为去target/，最终打包用tools/pack。

2.3 初始化与首次编译：避开第一个大坑

在SDK根目录下，通常有一个build.sh或者source build/envsetup.sh的脚本。对于Tina，更常见的是后者：

source build/envsetup.sh lunch

执行lunch后，会列出所有可用的方案（platform和board的组合），你需要用数字选择与你硬件对应的方案。这个步骤至关重要，它设置了后续所有编译动作的环境变量，指向正确的device/配置。

接下来是首次完整编译。我强烈建议在第一次编译时，使用-j参数指定并行编译任务数，通常设置为你的CPU核心数+1，以加快速度。同时，为了获取最详细的编译信息以便排错，可以加上V=s参数。

make -j$(nproc) V=s

这个过程会持续几十分钟到数小时，取决于你的主机性能和网络速度（因为需要下载很多软件包源码）。这里有一个关键注意事项：编译过程很可能因为网络问题导致软件包下载失败。Tina SDK的默认下载服务器可能在国外，速度不稳定。常见的解决方案是：

1. 手动下载：编译出错时，会打印出失败的下载链接。你可以用其他下载工具（如wget或迅雷）先下载好对应的tar.gz或git仓库，然后放入dl/目录（如果没有就创建一个），再重新执行make。
2. 修改镜像源：查找SDK中repositories.conf或类似文件，或者修改package/下各个包的Makefile中的下载URL，将其替换为国内镜像站（如中科大、清华的开源镜像站）的地址。这是一劳永逸的办法，但需要一些查找和替换的工作。

首次编译成功，在out/{方案名}/目录下生成了tina_{方案名}_uart0.img之类的镜像文件，这标志着你的基础开发环境已经就绪。

3. 内核配置、驱动移植与设备树实战

3.1 内核菜单配置：按需裁剪，打造精简系统

Tina Linux的内核基于某个版本的Linux Kernel（如4.9.x），并集成了大量全志特有的驱动。对于产品开发，我们很少需要改动内核核心代码，但几乎总是需要根据产品功能来裁剪内核模块。

进入内核配置界面：

make kernel_menuconfig

这个命令会启动一个基于ncurses的文本图形界面。面对成千上万的配置项，新手容易眼花缭乱。我的策略是：

1. 确定基准：首先，使用你开发板对应的默认配置（通常lunch时已选择）。它已经使能了该方案必需的核心驱动（如CPU调度、内存管理、时钟、串口等）。
2. 功能驱动：在Device Drivers菜单下，按需添加或删除。例如：
   • 网络：Network device support->Ethernet driver support-> 找到你的PHY芯片驱动（如Realtek PHY）。
   • Wi-Fi/蓝牙：Network device support->Wireless LAN， 以及Bluetooth subsystem support。这里通常需要额外配置固件（firmware）路径。
   • 显示与触摸：Graphics support->DRM Support和Frame buffer Devices；Input device support->Touchscreens。
   • 音频：Sound card support->Advanced Linux Sound Architecture->ALSA for SoC audio support。
   • USB：USB support，根据需求选择Host或Gadget功能。
3. 文件系统：在File systems下，确保你的根文件系统格式被支持（如ext4,squashfs），以及可能用到的FUSE、NTFS、FAT等。
4. 关键原则：对于不确定的选项，可以查看其帮助（按?键）。帮助信息通常会说明这个功能是编译进内核（y）、编译成模块（m）还是不编译（n）。一个实用的技巧是：对于非启动必须的、较大的驱动，尽量编译成模块（m），这样它们不会增大内核镜像，可以在系统启动后根据需要动态加载（insmod），有助于减少内核体积和启动时间。

配置完成后，保存退出。配置会被保存到device/config/chips/{芯片}/configs/{板型}/linux/{版本}/下的某个defconfig文件中。务必记得执行make重新编译内核，配置更改才会生效。

3.2 设备树剖析与硬件适配

在现代嵌入式Linux中，设备树（Device Tree,.dts文件）是描述硬件资源的唯一标准方式。它取代了旧时代内核中大量的板级硬编码文件。在Tina SDK中，主要的设备树源文件通常位于device/config/chips/{芯片}/configs/{板型}/board.dts。

一个典型的board.dts结构如下：

/dts-v1/; / { model = "My Product Board"; compatible = "allwinner,t113-s3", "allwinner,sun8iw20p1"; cpus { // CPU核心定义 }; memory { // 内存大小定义，如 reg = <0x40000000 0x8000000>; // 起始地址0x40000000，大小128MB }; chosen { // 内核启动参数，根文件系统位置等 bootargs = "console=ttyS0,115200 earlyprintk panic=5 rootwait root=/dev/mmcblk0p2"; stdout-path = "serial0:115200n8"; }; soc { // 片上系统外设 pio: pinctrl@2000000 { // 引脚复用配置，这是硬件适配的关键！ uart0_pins_a: uart0@0 { pins = "PF2", "PF4"; // 指定UART0的TX、RX使用的引脚 function = "uart0"; // 功能复用为uart0 drive-strength = <10>; }; led_pin: led_pin@0 { pins = "PH10"; function = "gpio_out"; }; }; uart0: serial@2500000 { compatible = "snps,dw-apb-uart"; reg = <0x02500000 0x400>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_UART0>; resets = <&ccu RST_BUS_UART0>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins_a>; // 引用上面定义的引脚配置 status = "okay"; }; mmc0: mmc@4020000 { // SD卡/ eMMC控制器 status = "okay"; }; }; leds { compatible = "gpio-leds"; led1 { label = "sys_led"; gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; // PH10, 引用pio控制器，第7组(PH)，第10个引脚 linux,default-trigger = "heartbeat"; }; }; };

硬件适配的核心工作就是修改这个board.dts文件：

• 改串口：如果你的调试串口从UART0换到了UART2，就需要修改chosen节点的stdout-path，并确保uart2节点使能且pinctrl指向正确的引脚。
• 增外设：比如添加一个I2C接口的传感器。你需要：1) 在soc节点下找到i2c控制器节点（如i2c0），确保其status = “okay”；2) 在该i2c节点下，添加一个子节点来描述你的传感器设备，包括compatible字符串（用于匹配驱动）、reg（I2C地址）等。
• 调引脚：任何GPIO、外设接口的变更，都要在pinctrl节点下定义对应的引脚复用组，并在外设节点中通过pinctrl-0属性引用它。

修改board.dts后，需要编译成二进制设备树 blob（.dtb）：

make kernel_menuconfig # 确保配置正确 make

编译后，生成的.dtb文件会位于内核输出目录（如out/{方案名}/compile_dir/target/linux-*/）或最终的镜像打包目录中。

3.3 外设驱动集成：模块与内置的选择

对于内核已经支持的通用外设（如USB网卡、特定型号的EEPROM），驱动集成很简单：在内核菜单中使能对应的驱动选项即可。

对于需要自己移植或修改的驱动，通常有两种方式：

1. 作为内核模块：将驱动源码放在kernel/drivers/的相应子目录下（如kernel/drivers/char/），并修改该目录的Kconfig和Makefile，添加你的驱动配置项和编译规则。然后在kernel_menuconfig中就可以找到并编译它。这种方式灵活，便于调试和更新。
2. 作为Tina软件包：对于更上层的、或者与内核耦合不紧的驱动/内核模块，可以将其制作成一个Tina/OpenWrt的软件包，放在package/kernel/目录下。这需要编写一个OpenWrt风格的Makefile，定义如何下载、打补丁、编译和安装这个内核模块。这样做的好处是，可以通过Tina的包管理系统（make menuconfig）来统一管理它的编译开关，并且编译产物（.ko文件）会被自动安装到根文件系统的相应位置。

一个重要的实操心得：在调试新硬件驱动时，务必先确保内核能正常启动到命令行。先注释掉或禁用所有新加的、不确定的驱动和设备树节点，让系统最简启动。然后，通过dmesg命令查看内核日志，确认核心外设（如MMC、网络控制器）是否被正确识别。接着，再逐一使能你添加的驱动，每加一个就重启测试一次，并用lsmod查看模块是否加载，用ls /dev或cat /proc/device-tree查看设备节点是否创建。这种“增量式”的调试方法，能帮你快速定位问题是出在设备树、内核配置还是驱动代码本身。

4. 根文件系统定制与软件包管理

4.1 OpenWrt包管理系统：灵活定制的核心

Tina继承了OpenWrt强大的包管理系统。执行make menuconfig（注意，不是kernel_menuconfig），你会进入一个类似内核配置的界面，但这里配置的是用户空间的软件包。

界面主要分为几大类别：

• Base system：基础系统组件，如busybox（嵌入式Linux的瑞士军刀）、初始化系统（procd）、基础工具等。除非你很清楚在做什么，否则不要轻易改动这里的默认配置。
• Kernel modules：这里对应的是那些被编译成内核模块的驱动。你可以在这里选择哪些模块被编译并打包进镜像。
• Libraries：各种运行时库，如libc、zlib、openssl、libpthread等。
• Network：网络相关的软件，如防火墙（firewall）、网络配置（netifd）、SSH服务器（dropbear）、Web服务器（uhttpd）等。
• Utilities：实用工具，如文件操作（coreutils）、进程查看（ps）、磁盘工具（fdisk）等。
• Sound、Multimedia等：特定功能的软件包。

如何添加一个自定义应用？标准做法是在package/目录下创建一个新的文件夹，例如package/utils/myapp/。在这个文件夹里，至少需要两个文件：

1. Makefile：这是包的定义文件。一个最简单的例子：

   include $(TOPDIR)/rules.mk PKG_NAME:=myapp PKG_VERSION:=1.0 PKG_RELEASE:=1 include $(INCLUDE_DIR)/package.mk define Package/myapp SECTION:=utils CATEGORY:=Utilities TITLE:=My custom application DEPENDS:=+libc endef define Package/myapp/description This is a custom application for my product. endef define Build/Prepare mkdir -p $(PKG_BUILD_DIR) $(CP) ./src/* $(PKG_BUILD_DIR)/ endef define Build/Configure # 如果有configure脚本，在这里调用 endef define Build/Compile $(MAKE) -C $(PKG_BUILD_DIR) \ CC="$(TARGET_CC)" \ CFLAGS="$(TARGET_CFLAGS)" \ LDFLAGS="$(TARGET_LDFLAGS)" endef define Package/myapp/install $(INSTALL_DIR) $(1)/usr/bin $(INSTALL_BIN) $(PKG_BUILD_DIR)/myapp $(1)/usr/bin/ endef $(eval $(call BuildPackage,myapp))

2. src/目录：里面放置你的应用程序源代码和它的编译脚本（如Makefile）。

创建好后，在make menuconfig的相应类别（如Utilities）里就能找到myapp，选中它，保存退出，然后执行make。编译系统会自动编译你的应用，并将其可执行文件安装到根文件系统的镜像中。

4.2 文件系统镜像构建：从JFFS2到EXT4的选择

在make menuconfig的Target Images子菜单下，你可以配置最终生成的根文件系统镜像格式。常见的有：

• squashfs：一种只读的压缩文件系统。它非常节省空间，并且因为只读，具有很好的抗断电损坏能力。通常与可读写的overlayfs（基于jffs2或ubifs）结合使用，系统运行时所有修改都保存在overlay分区。这是OpenWrt/Tina的默认和推荐方式。
• ext4/ext2：传统的可读写Linux文件系统。功能完整，但不如squashfs紧凑，且对突然断电更敏感。如果你的产品需要频繁写入大量数据，且对存储空间不敏感，可以考虑。
• jffs2/ubifs：专为Flash存储设计的可读写文件系统。jffs2适用于NOR Flash，ubifs适用于NAND Flash。它们通常用作overlay分区。

如何选择？对于大多数嵌入式产品，我的建议是：使用squashfs作为只读根文件系统 +jffs2（NOR）或ubifs（NAND）作为可写overlay。这样既保证了系统核心的稳固性（只读部分不会被破坏），又保留了保存配置和日志的能力。配置路径在make menuconfig->Target Images-> 勾选Build squashfs root filesystem，并在Root filesystem overlay size或相关选项中设置overlay分区大小。

4.3 系统初始化和自启动服务

Tina使用procd作为初始化系统（类似PC上的systemd）。用户定义的服务通常放在/etc/init.d/目录下。一个简单的服务脚本示例（/etc/init.d/myapp）：

#!/bin/sh /etc/rc.common # 这是OpenWrt服务脚本的标准开头 START=95 # 启动顺序，数字越大越靠后 STOP=10 # 停止顺序 USE_PROCD=1 # 使用procd管理 start_service() { procd_open_instance procd_set_param command /usr/bin/myapp procd_set_param respawn # 进程崩溃后自动重启 procd_set_param stdout 1 # 重定向stdout到log procd_set_param stderr 1 # 重定向stderr到log procd_close_instance }

这个脚本定义了一个由procd监管的服务，它会自动启动/usr/bin/myapp，并在其意外退出时重新启动。你需要给脚本添加可执行权限（chmod +x /etc/init.d/myapp），然后使用/etc/init.d/myapp enable来使其在系统启动时自动运行。enable命令实际上是在/etc/rc.d/下创建了一个指向该脚本的软链接（如S95myapp）。

注意事项：服务脚本的启动顺序（START值）很重要。如果你的应用依赖于网络，那么它的START值必须大于网络服务（如network，通常是10或20）的START值，例如设为95。否则，可能会在网络未就绪时启动，导致连接失败。

5. 系统打包、烧录与深度调试

5.1 分区表配置与镜像打包

在将内核、文件系统等组件烧录到设备存储（如eMMC、SPI NAND）之前，需要定义它们在存储介质上的布局，这就是分区表。在Tina中，分区表由sys_partition.fex文件定义（通常位于device/config/chips/{芯片}/configs/{板型}/目录下）。

一个典型的sys_partition.fex文件内容如下：

[partition_start] [partition] name = bootloader size = 3072 downloadfile = "bootloader.fex" user_type = 0x8000 [partition] name = boot size = 32768 downloadfile = "boot.fex" user_type = 0x8000 [partition] name = rootfs size = 1048576 downloadfile = "rootfs.fex" user_type = 0x8000 [partition] name = overlay size = 524288 user_type = 0x8000

• name：分区名称，在Linux中可能会映射为/dev/mmcblk0pX。
• size：分区大小，单位是扇区（通常1扇区=512字节）。32768扇区 = 16MB。
• downloadfile：该分区对应的镜像文件。bootloader.fex通常是U-Boot，boot.fex包含内核和设备树，rootfs.fex是根文件系统。
• user_type：分区属性，0x8000通常表示普通可读写分区。

关键点：overlay分区通常没有downloadfile，因为它是一个初始为空的、用于存储运行时数据的可读写分区。rootfs分区的大小必须大于你编译出的squashfs镜像大小，并预留一定余量。

配置好分区表后，在SDK根目录执行make或pack命令，tools/pack工具会根据分区表，将各个.fex文件打包成一个完整的.img文件。这个.img文件就是可以用于烧录的最终固件。

5.2 烧录方法与选型：从PhoenixSuit到LiveSuit

全志平台常用的烧录工具有：

1. PhoenixSuit：这是最通用、最稳定的量产烧录工具。它通过USB将设备置于FEL模式（强制下载模式）进行烧录。操作步骤通常是：设备断电 -> 按住设备上的“下载键”（如FEL按钮） -> 上电 -> 连接USB到电脑 -> 打开PhoenixSuit选择固件 -> 开始烧录。这种方式会擦除整个存储，包括所有分区。
2. LiveSuit：较旧的工具，部分老型号芯片使用，操作类似。
3. SD卡启动卡量产：对于支持从SD卡启动的芯片，可以制作一张特殊的SD卡（使用dd命令写入bootloader和特殊签名），设备从该SD卡启动后，会自动将SD卡中的完整固件烧录到内部存储（如NAND/eMMC）中。这种方式适合在产线进行批量烧录。
4. OTA升级：对于已出货的设备，通过网络进行远程升级。这需要在系统内运行一个升级客户端（如sysupgrade），并准备好差分包或完整包。Tina/OpenWrt原生支持sysupgrade机制。

烧录避坑指南：

• 驱动问题：在Windows上使用PhoenixSuit，最常见的问题是USB驱动未正确安装。需要根据芯片型号（如T113, F133）安装对应的USB FEL驱动。设备进入FEL模式后，在Windows设备管理器中应能看到一个USB FEL或Allwinner相关的设备。
• 权限问题：在Linux下使用sunxi-tools（包含sunxi-fel）进行命令行烧录，需要将当前用户加入plugdev组，或者使用sudo。
• 烧录失败：如果烧录过程卡住或报错，首先检查USB线是否良好，尝试更换USB口。其次，确认设备是否确实进入了FEL模式（某些板子需要短接测试点）。最后，检查固件.img文件是否完整、分区表配置是否合理（特别是分区大小是否足够）。

5.3 系统级调试与问题排查实战

系统启动失败是嵌入式开发的家常便饭。掌握系统性的排查方法至关重要。

1. 串口控制台是生命线：确保你的开发板串口（通常是UART0）正确连接到PC，并使用终端工具（如minicom,picocom,PuTTY）以正确的波特率（通常是115200）打开。这是你获取内核启动日志的唯一可靠途径。

2. 解读启动日志：

• U-Boot阶段：上电后最先看到的是U-Boot的输出。关注点：DDR初始化是否成功（DRAM:信息）、是否识别到启动介质（MMC:）、是否成功加载了内核（Loading Kernel...）、设备树（Loading Device Tree...）。如果卡在这里，问题可能在U-Boot本身、存储介质或启动参数。
• 内核解压与早期启动：看到Uncompressing Linux...和内核版本信息，说明U-Boot成功移交了控制权。如果在此之后没有任何输出或立即复位，可能是内核镜像损坏、设备树地址错误或内核严重崩溃。
• 内核启动中期：打印大量硬件初始化信息。重点关注：
  • Failed to initialize或probe failed：某个驱动初始化失败。
  • Cannot open root device或VFS: Unable to mount root fs：根文件系统挂载失败。这是最常见的问题之一。检查内核命令行参数（bootargs）中的root=是否正确指向了你的根文件系统分区（如root=/dev/mmcblk0p2），以及内核是否支持该文件系统类型（如ext4,squashfs）。
  • Kernel panic：内核严重错误。后面的调用栈（Call trace:）是定位问题的关键。
• 用户空间启动：内核挂载根文件系统成功后，会启动第一个用户进程（通常是/sbin/init或/etc/preinit）。如果在这里卡住，可能是文件系统损坏、init程序不存在或没有执行权限、或者/etc/inittab//etc/rc.d脚本有语法错误。

3. 高级调试工具：

• dmesg：查看完整的内核环状缓冲区日志。
• logread：查看procd和系统服务的日志。
• mount：查看当前挂载的文件系统，确认overlay是否正确挂载。
• df -h：查看磁盘空间使用情况，overlay分区是否已满。
• /proc和/sys文件系统：这两个虚拟文件系统提供了大量内核和硬件状态信息。例如：
  • cat /proc/cmdline：查看实际传递给内核的启动参数。
  • cat /proc/device-tree/model：查看设备树中定义的板卡型号。
  • ls /sys/class/gpio/：查看GPIO接口。
  • ls /sys/bus/i2c/devices/：查看已识别的I2C设备。

4. 网络调试：如果系统成功启动了网络，可以通过ssh（dropbear）登录，这比串口方便得多。确保在make menuconfig中选中Network->dropbear，并配置好root密码或SSH密钥。

一个典型的排错案例：系统启动后，串口有输出但卡在Please press Enter to activate this console.，无法进入命令行。

• 分析：这说明内核已成功启动并尝试启动控制台，但/bin/sh或指定的shell可能不存在或无法执行。
• 排查：
  1. 检查bootargs中的console=参数是否正确。
  2. 检查根文件系统中/bin/sh是否存在（如果是squashfs，可以先在编译主机上unsquashfs解压查看）。
  3. 检查/etc/inittab或/etc/rc.d中的启动脚本是否有语法错误导致无限循环。可以尝试在bootargs中加入init=/bin/sh来绕过初始化脚本，直接进入shell。如果能进入，就证明是初始化脚本的问题。

6. 性能优化与存储管理进阶

6.1 系统启动时间优化

对于许多嵌入式产品，快速启动是硬性要求。优化启动时间是一个系统工程：

1. 内核裁剪：在kernel_menuconfig中，移除所有不必要的驱动、文件系统、调试符号（Kernel hacking-> 减少调试选项，关闭KGDB等）、网络协议支持。一个更小的内核加载和解压更快。
2. 减少内核模块：将非启动必须的驱动编译为模块，并在启动后需要时再加载（modprobe）。避免在启动初期加载大量模块。
3. 优化init进程：分析/etc/rc.d/下的启动脚本，将非紧急的服务延迟启动（增大START值），或将一些初始化工作放到后台进行。使用procd的udevtrigger可以并行处理设备发现，比串行脚本快。
4. 文件系统选择：squashfs+lzma压缩率最高，但解压需要时间。如果存储空间充裕，可以考虑使用gzip压缩（解压更快）甚至不压缩。对于overlay，jffs2在NOR上挂载很快，而ubifs在NAND上挂载需要扫描，可能较慢。
5. 预链接：对于使用动态链接库的系统，可以在制作根文件系统时运行prelink，减少运行时动态链接的开销。
6. 测量工具：使用bootchart工具可以可视化分析启动过程，精确找到耗时最长的阶段。

6.2 Flash存储寿命与Overlay管理

使用Flash存储（尤其是NAND）时，必须考虑其擦写次数有限的特性。

• 避免频繁写入：将频繁写入的目录（如/var/log,/tmp）挂载为tmpfs（内存文件系统）。可以在/etc/fstab或启动脚本中添加：tmpfs /var/log tmpfs defaults,size=10M 0 0。
• 使用日志文件系统：ubifs和jffs2本身就是为Flash设计的，比ext4（不带data=ordered或data=journal选项）更适合。
• Overlay分区维护：overlay分区是唯一可写的部分，所有系统运行时产生的修改（安装的软件包、更改的配置、日志）都存储在这里。需要定期检查其使用率（df -h），避免写满。写满会导致系统行为异常。可以设置日志轮转（logrotate）来管理日志大小。
• 减少不必要的写操作：例如，将系统时间同步（NTP）的间隔调大，或者只在有网络连接时同步；关闭不必要的调试日志输出。

6.3 构建系统加速与持续集成

当项目变大，每次make都全量编译会非常耗时。可以利用以下技巧加速开发：

• 并行编译：始终使用make -j$(nproc)。
• 增量编译：修改应用层代码（package/下的软件包）后，可以单独编译该包：make package/myapp/compile V=s。编译完成后，再单独安装到镜像：make package/myapp/install，最后重新打包镜像。
• 启用ccache：ccache可以缓存之前的编译结果，极大加速重复编译。在make menuconfig->Global build settings-> 选中Compiler cache。首次编译会稍慢，后续编译速度提升明显。
• 搭建本地下载镜像：在公司内网搭建一个dl/目录的镜像服务器，所有开发机都从该服务器下载源码包，可以彻底解决下载慢的问题。
• 版本控制：将你定制过的device/目录、package/下的自定义包、关键的配置文件（如.config,sys_partition.fex）纳入Git等版本控制系统。而庞大的kernel/和build/目录可以通过.gitignore忽略，因为它们可以从原始SDK恢复或本身就是只读的。

嵌入式Linux系统开发，尤其是基于Tina这样的高度集成化SDK，是一个连接硬件、内核、驱动、应用和构建系统的综合性工程。这份指南试图为你勾勒出这条路径上的主要路标和潜在沟坎。真正的精通，源于在具体项目中的反复实践、踩坑和总结。当你成功让一块裸板跑起你自己定制的Linux系统，并稳定地提供服务时，那种成就感，便是对这份复杂工作最好的回报。记住，耐心阅读日志、大胆假设、小心验证，是解决所有嵌入式问题的通用法则。