在新ARM板上移植U-Boot和Linux指南

序言

从支持一个定制板子在U-Boot和Linux中的过程中得到经验
以一个带有知名SoC（i.MX6）且IP已经得到支持的板子为例，这次讨论几乎不涉及编码技能，
更多地聚焦在U-Boot部分

一般原则

如果您有您的BSP（板级支持包）的源代码，请编译并运行BSP以：
1. 验证您正在工作的IP（知识产权/硬件模块）能够与某些代码一起工作
2. 拥有一个参考代码
3. 拥有一个您可以用于调试的代码
专注于正确配置RAM和UART
提交
一次处理一个IP
提交

定制板介绍

基于i.MX6的模块，带有扩展板，
以太网，I2C，SPI，NAND，eMMC，SD卡读卡器，USB设备，EEPROM，
GPIO，UART，音频（I2S），HDMI，LVDS，PCIe，USB主机，RTC，电源管理集成电路（PMIC）

U-Boot移植

U-Boot 状态

持续从板头文件定义迁移到Kconfig选项，
持续从手动驱动探测迁移到驱动模型

U-Boot 目录结构

arch/
与架构或平台相关的所有内容：设备树（DTS）、CPU初始化、引脚复用控制器、DRAM、时钟等...
board/
特定于板子的代码（初始化、引脚复用配置等），指定板头文件的Kconfig文件，板文件，路径，板文件的Makefile，
configs/
所有板子的默认配置（defconfigs）
drivers/
include/
所有头文件
include/configs/
所有板子的头文件
...

U-Boot新板支持工作流程

创建板文件
创建板Kconfig文件
创建板Makefile
创建板defconfig
创建板头文件
在架构的Kconfig中包含板的Kconfig
在其CPU的Kconfig中定义TARGET Kconfig选项
一些平台共享公共文件，因此只需要一个defconfig

创建板文件

board/my_vendor/my_board/my_board.c

声明全局数据指针
可以在代码中使用全局变量gd
在ARM架构中，对于ARM32等于硬件寄存器r9，对于ARM64等于x18
用于在启动后非常早期的"某些内存"中存储信息，这些内存在系统初始化期间可用（直到我们设置好内存控制器，可以使用RAM）
查看include/asm-generic/global_data.h可以了解它能存储哪些类型的信息。

创建板Kconfig文件

board/my_vendor/my_board/Kconfig

SYS_VENDOR 和 SYS_BOARD 用于标识目录，这样 make 命令能找到编译所需的文件
- 如果两者都存在
  board/SYS_VENDOR/SYS_BOARD/
- 如果省略了 SYS_VENDOR
  board/SYS_BOARD/
- 如果省略了 SYS_BOARD
  board/SYS_VENDOR/common/
SYS_CONFIG_NAME 用于标识板头文件
include/configs/SYS_CONFIG_NAME.h

创建板Makefile文件

board/my_vendor/my_board/Makefile

创建板defconfig文件

configs/my_board_defconfig

在这里放置任何可以在Kconfig（菜单配置）中选择的内容
驱动程序、特性、U-Boot行为、库等

include/configs/my_board.h

引入板子的Kconfig文件

arch/arm/Kconfig or
arch/arm/mach-imx/mx6/Kconfig

定义板子的TARGET Kconfig选项

arch/arm/mach-imx/mx6/Kconfig

U-Boot初始化序列

U-Boot会运行两组函数列表，其目的是在用户访问控制台之前初始化或配置特定的IP
第一个列表定义在common/board_f.c文件中的static init_fnc_t init_sequence_f[]数组
第一个列表负责初始化DRAM，映射它，并在工作后重新定位引导程序代码
第二个列表定义在common/board_r.c文件中的static init_fnc_t init_sequence_r[]数组
只有当定义了常量时，才会运行某些函数（例如，定义CONFIG_BOARD_EARLY_INIT_F以运行board_early_init_f()）
任何返回非零值的函数都会停止初始化序列，并使U-Boot无法启动
在初始化序列有问题时定义DEBUG
并非所有"特性"在所有函数中都可用（例如，board_early_init_f()中没有udelay）。

驱动选择

从具有相同IP的板子中获取灵感
检查相应子系统中的驱动程序

专注于驱动程序的行为
然后查看寄存器、位偏移、掩码等
检查未定义的宏或常量
查找被ifdef块包围的代码片段
- 在子系统的Makefile中查找这个驱动程序的对象文件

使用grep搜索CONFIG_MY_DRIVER
- 如果在某些Kconfig文件中是可见符号 => 添加到板子的defconfig中
- 如果在某些Kconfig文件中是非可见符号或未定义 => 添加到板头文件中
确保你的驱动程序被编译（查找my_driver.o）
驱动程序文件位于drivers/mtd/nand/nand_mxs.c
使用CONFIG_NAND_MXS来编译驱动程序
使用CONFIG_SYS_MAX_NAND_DEVICE和CONFIG_SYS_NAND_BASE常量来配置设备

驱动选择 - NAND示例

configs/my_board_defconfig

include/configs/my_board.h

board/my_vendor/my_board.c

关于设备树的说明

设备树的迁移始于2012年，代码正逐渐迁移，逐个驱动程序，逐个子系统
驱动模型需要使用设备树
大多数驱动程序有大量的CONFIG_DM条件编译块
- 你不能真正基于每个驱动程序选择启用DM支持
子系统核心代码也是如此
我没有深入研究，因为我们要么不需要，要么需要完全支持设备树，而NAND框架还没有迁移到DM。

Linux Kernel 移植

Linux内核新板支持工作流程

1. 创建板子的设备树
2. 将板子的DTB添加到架构DTS Makefile中
3. 为你的板子创建一个默认配置（defconfig）

Device Tree

一个特殊DTS（设备树源）格式的文件
纯粹描述了你的板子的硬件
通过兼容字符串将IP与驱动程序匹配
文档可以在Documentation/devicetree/bindings中找到
有关设备树是什么以及如何编写的更深入解释，请访问：设备树详细介绍视频。

创建板子的设备树

arch/arm/boot/dts/imx6s-my-board.dts

将DTB添加到架构DTS Makefile中

arch/arm/boot/dts/Makefile

为你的板子创建一个默认配置（defconfig）

从SoC系列的defconfig开始（例如imx_v6_v7_defconfig），如果没有，从架构的defconfig开始（例如multi_v7_defconfig）
从defconfig中删除无用的SoC系列、驱动程序和特性
添加你想要编译的驱动程序的CONFIG
- 使用grep搜索驱动程序的基本名称是正确的方法
- 大多数驱动程序依赖于子系统或其他选项，如果你的驱动程序没有选择它们，你也需要将它们添加到你的defconfig中
PCIe驱动程序正在探测但未枚举设备
- 驱动程序在BSP中工作，发现缺少对电源管理器的支持是罪魁祸首
- 迅速编写了一个40行的补丁并提交给了上游
以太网驱动程序缺少在BSP中设置的PHY复位后延迟
- 迅速编写了一个20行的补丁并提交给了上游。