嵌入式Linux之uboot移植

Posted 2021-06-03 大奥特曼打小怪兽

一、嵌入式Linux系统组成

嵌入式Linux系统一般由以下几部分组成：

• 引导加载程序，包括固化在固件中的boot代码和BootLoader两大部分。有些CPU在运行BootLoader之前会先运行一段固化程序，比如x86的CPU会先运行Bios中的固件，然后才运行硬盘的第一个分区(MBR)中的BootLoader，但是在大多的嵌入式系统中，是没有固件的，BootLoader就是上电后执行的第一个程序。 

• linux内核：特定于嵌入式板子的定制内核以及内核的启动参数，内核的启动参数可以是内核默认的，也可以是由BootLoader传递给它的。

• 文件系统： 包括根文件系统和建立于Flash内存设备上的文件系统，里面包含了linux系统能够运行所必须的应用程序、库等等，比如可以给用户提供LInux的控制界面shell程序、动态链接的程序时所需要的glibc或uClibc库等。

• 用户应用程序    特定于用户的应用程序，它们也存储在文件系统中，有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面，常用的嵌入式GUI有：Qtopia和MinGUI等。显然，在嵌入式系统的固态存储设备上有相应的分区来存储它们。

在Flash存储器中，它们的分布一般如下：

 二、BootLoader

Bootloader是在操作系统运行之前执行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射表，从而建立适当的系统软硬件环境，为最终调用操作系统内核做好准备。

对于嵌入式系统，Bootloader是基于特定硬件平台来实现的。因此，几乎不可能为所有的嵌入式系统建立一个通用的Bootloader，不同的处理器架构都有不同的Bootloader。Bootloader不但依赖于CPU的体系结构，而且依赖于嵌入式系统板级设备的配置。对于2块不同的嵌入式板而言，即使它们使用同一种处理器，要想让运行在一块板子上的Bootloader程序也能运行在另一块板子上，一般也都需要修改Bootloader的源程序。 反过来，大部分Bootloader仍然具有很多共性，某些Bootloader也能够支持多种体系结构的嵌入式系统。

例如，U-Boot就同时支持PowerPC、ARM、MIPS和X86等体系结构，支持的板子有上百种。通常，它们都能够自动从存储介质上启动，都能够引导操作系统启动，并且大部分都可以支持串口和以太网接口。

本节将对各种Bootloader总结分类，分析它们的共同特点。以U-Boot为例，详细讨论Bootloader的设计与实现。

2.1 u-boot工程简介

最早，DENX软件工程中心的Wolfgang Denk基于8xxrom的源码创建了PPCBOOT工程，并且不断添加处理器的支持。后来，Sysgo Gmbh把ppcboot移植到ARM平台上，创建了ARMboot工程。然后以ppcboot工程和armboot工程为基础，创建了U-Boot工程。

现在U-Boot已经能够支持PowerPC、ARM、X86、MIPS体系结构的上百种开发板，已经成为功能最多、灵活性最强并且开发最积极的开放源码BootLoader。目前仍然由DENX的Wolfgang Denk维护。

u-boot的源码包可以从sourceforge网站下载，还可以订阅该网站活跃的U-Boot Users邮件论坛，这个邮件论坛对于U-Boot的开发和使用都很有帮助。

u-boot软件包下载网站：https://ftp.denx.de/pub/u-boot/。

DENX相关的网站：http://www.denx.de/re/DPLG.html。

u-boot git仓库：https://gitlab.denx.de/u-boot/u-boot。

2.2 U-Boot源码结构

从网站上下载得到u-boot源码包，例如：u-boot-2016.05.tar.bz2 （最新的u-boot版本已经不支持s3c2440）。

解压就可以得到全部u-boot源程序。在顶层目录下有20个子目录：

分别存放和管理不同的源程序。这些目录中所要存放的文件有其规则，可以分为3类。 

1. 第1类目录与处理器体系结构或者开发板硬件直接相关； ·
2. 第2类目录是一些通用的函数或者驱动程序； 
3. 第3类目录是U-Boot的应用程序、工具或者文档。

下面列出了U-Boot顶层目录下各级目录存放原则：

• api： 硬件无关的功能函数的API。uboot移植时基本不用管，这些函数是uboot本身使用的。
• arch： 与体系结构相关的代码。比如 arm、 avr32、 m68k 等，我们现在用的是 ARM 芯片，所以只需要关心 arm 文件夹即可。
• board：存放电路板相关的目录文件，主要包含SDRAM、FLASH驱动，例如：samsung/smdk2410、samsung/smdk5250等目录。
• cmd：命令相关代码。
• common：common是普遍的普通的，这个文件夹下放的是一些与具体硬件无关的普遍适用的一些代码。譬如控制台实现、crc校验的。但是更多的主要是两类：一类是cmd开头的，是用来实现uboot的命令系统的；另一类是env开头的，是用来实现环境变量的。
• cpu： 这个目录是SoC相关的，里面存放的代码都是SoC相关初始化和控制代码（譬如CPU的、中断的、串口等SoC内部外设的，包括起始代码start.S也在这里）。里面很多子文件夹，每一个子文件夹就是一个SoC系列。
• configs:此文件夹为 uboot 配置文件， uboot 是可配置的，但是你要是自己从头开始一个一个项目的配置，那就太麻烦了，因此一般半导体或者开发板厂商都会制作好一个配置文件。我们可以在这个做好的配置文件基础上来添加自己想要的功能，这些半导体厂商或者开发板厂商制作好的配置文件统一命名为“xxx_defconfig”， xxx 表示开发板名字，这些 defconfig 文件都存放在 configs文件夹。
• disk： 磁盘有关的。
• doc：文档目录，里面存放了很多uboot相关文档，这些文档可以帮助我们理解uboot代码。
• drivers：顾名思义，驱动。这里面放的就是从linux源代码中扣出来的原封不动的linux设备驱动，主要是开发板上必须用到的一些驱动，如网卡驱动、Inand/SD卡、NandFlash等的驱动。要知道：uboot中的驱动其实就是linux中的驱动，uboot在一定程度上移植了linux的驱动给自己用。但是linux是操作系统而uboot只是个裸机程序，因此这种移植会有不同，让我说：uboot中的驱动其实是linux中的驱动的一部分。
• dts：设备树。
• examples：示例代码。
• fs：filesystem，文件系统。这个也是从linux源代码中移植过来的，用来管理Flash等资源。
• include：头文件目录。uboot和linux kernel在管理头文件时都采用了同一个思路，就是把所有的头文件全部集中存放在include目录下，而不是头文件跟着自己对应的c文件。所以在uboot中头文件包含时路径结构要在这里去找。
• lib：架构相关的库文件。这类文件夹中的内容移植时基本不用管。
• Licenses:许可证相关文件。
• net： 网络相关的代码，譬如uboot中的tftp nfs ping命令 都是在这里实现的。
• post：加电自检程序。
• scripts：脚本文件。
• test：测试代码。
• tools：里面是一些工具类的代码。譬如mkimage。

U-Boot的源代码包含对几十种处理器、数百种开发板的支持。可是对于特定的开发板，配置编译过程只需要其中部分程序。这里具体以S3C2440 ARM920T处理器为例，具体分析S3C2410处理器和开发板所依赖的程序，以及U-Boot的通用函数和工具。

2.3 U-Boot编译

我们将下载的U-Boot通过samba上传到ubuntu服务器上：

复制uboot到/word/hardware路径下，解压u-boot-2016.tar.bz2：

cd /work/sambashare
mv u-boot-2016.05.tar.bz2 /work/hardware
cd /work/hardware
sudo apt-get install  bzip2
tar -jxvf   u-boot-2016.05.tar.bz2
cd  u-boot-2016.05

uboot的编译分为两步：配置、编译:

(1) 配置选择所要使用的board ，我调试使用的是S3C2440,但是configs目录下没有smdk2440_defconfig这个文件，只有smdk2410_defconfig，因此执行如下命令，生成.config文件：

make smdk2410_defconfig

(2) 编译、执行make命令，生成u-boot:

 make ARCH=arm CROSS_COMPILE=arm-linux-

CROSS-COPILE是在Makefile文件中定义的变量，是用来指定交叉工具链，ARCH用来指定处理器架构。此外，我们可以在u-boot的顶层Makefile中定义：

CROSS_COMPILE=arm-linux-
ARCH=arm

这样就省去了每次编译都要在控制台输入的麻烦。

编译成功后会生成一个u-boot.bin,可以烧写到开发板上,不过一般是用不起来的,需要进一步修改。

三、u-boot编译过程目标依赖分析

3.1 u-boot目标依赖关系图

根据以上目标依赖关系图，为了分析方便，将整个目标依赖图分为三部分：_all、u-boot、prepare。

3.2 目标_all

从顶层的Makefile开始查找，首先找到的目标为_all，128行：

# That\'s our default target when none is given on the command line
PHONY := _all
_all:

在Makefile中，.PHONY后面的target表示的也是一个伪造的target, 而不是真实存在的文件target，注意Makefile的target默认是文件。

紧接着会对_all伪目标添加all伪目标依赖，194行：

# If building an external module we do not care about the all: rule
# but instead _all depend on modules
PHONY += all
ifeq ($(KBUILD_EXTMOD),)
_all: all
else
_all: modules
endif

当我们定义了M变量或者SUBDIRS时表示编译一个外部模块，显然我们并没有编译一个外部模块。因此伪目标_all依赖al。

all自身依赖于$(ALL-y)，803行：

all:        $(ALL-y)
ifneq ($(CONFIG_SYS_GENERIC_BOARD),y)
    @echo "===================== WARNING ======================"
    @echo "Please convert this board to generic board."
    @echo "Otherwise it will be removed by the end of 2014."
    @echo "See doc/README.generic-board for further information"
    @echo "===================================================="
endif
ifeq ($(CONFIG_DM_I2C_COMPAT),y)
    @echo "===================== WARNING ======================"
    @echo "This board uses CONFIG_DM_I2C_COMPAT. Please remove"
    @echo "(possibly in a subsequent patch in your series)"
    @echo "before sending patches to the mailing list."
    @echo "===================================================="
endif

3.3 目标$(ALL-y)

$(ALL-y)定义了最终需要生成的所有文件，731行

# Always append ALL so that arch config.mk\'s can add custom ones
ALL-y += u-boot.srec u-boot.bin u-boot.sym System.map u-boot.cfg binary_size_check

ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin
ifeq ($(CONFIG_SPL_FSL_PBL),y)
ALL-$(CONFIG_RAMBOOT_PBL) += u-boot-with-spl-pbl.bin
else
ifneq ($(CONFIG_SECURE_BOOT), y)
# For Secure Boot The Image needs to be signed and Header must also
# be included. So The image has to be built explicitly
ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl
endif
endif
ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin
ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb
ifeq ($(CONFIG_SPL_FRAMEWORK),y)
ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
endif
ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
ifneq ($(CONFIG_SPL_TARGET),)
ALL-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
endif
ALL-$(CONFIG_REMAKE_ELF) += u-boot.elf
ALL-$(CONFIG_EFI_APP) += u-boot-app.efi
ALL-$(CONFIG_EFI_STUB) += u-boot-payload.efi

ifneq ($(BUILD_ROM),)
ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
endif

# enable combined SPL/u-boot/dtb rules for tegra
ifeq ($(CONFIG_TEGRA)$(CONFIG_SPL),yy)
ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
endif

# Add optional build target if defined in board/cpu/soc headers
ifneq ($(CONFIG_BUILD_TARGET),)
ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
endif

以上的$(ALL-y)目标中看起来很复杂，但是除了第一行的通用目标外，其余的目标都只有在特殊条件下才生成，这里略去不提，只分析通用目标依赖：

ALL-y += u-boot.srec u-boot.bin u-boot.sym System.map binary_size_check

3.4 目标u-boot.bin

(1) 在$(ALL-y)的通用目标中，先分析u-boot.bin，826行

ifeq ($(CONFIG_OF_SEPARATE),y)
u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
    $(call if_changed,cat)

u-boot.bin: u-boot-dtb.bin FORCE
    $(call if_changed,copy)
else
u-boot.bin: u-boot-nodtb.bin FORCE
    $(call if_changed,copy)
endif

由于没有定义CONFIG_OF_SEPARATE选项,所以我们关心else中定义的依赖关系。

if_changed函数检测依赖文件是否有更新或目标文件是否不存在, 然后echo打印传入的参数,最后执行传入的命令copy。面贴出 scripts/Kbuild.include文件中的部分内容,大家可以自行分析

u-boot.bin: u-boot-nodtb.bin FORCE
    echo COPY    $@; cp $<  $@      #输出 COPY   u-boot.bin, 然后执行cp u-boot-nodtb.bin u-boot.bin

(2) 目标u-boot-nodtb.bin

分析867行，u-boot-nodtb.bin依赖u-boot：

u-boot-nodtb.bin: u-boot FORCE
    $(call if_changed,objcopy)
    $(call DO_STATIC_RELA,$<,$@,$(CONFIG_SYS_TEXT_BASE))
    $(BOARD_SIZE_CHECK)

(3) 目标u-boot

分析1191行：

u-boot:    $(u-boot-init) $(u-boot-main) u-boot.lds FORCE
    $(call if_changed,u-boot__)
ifeq ($(CONFIG_KALLSYMS),y)
    $(call cmd,smap)
    $(call cmd,u-boot__) common/system_map.o
endif

(4) u-boot-init,u-boot-main

u-boot-init := $(head-y)
u-boot-main := $(libs-y)

在linux上搜索head-y这个目标： grep \'head-y\' * -nR 得到下面这个结果： arch/arm/Makefile:74:head-y := arch/arm/cpu/$(CPU)/start.o 所以head-y指的是start.S.

在顶层目录Makefile中搜索libs-y可以发现其包含许多目录 比如：

libs-y += drivers/mtd/ 

另：

libs-y := $(patsubst %/, %/built-in.o, $(libs-y))

这条规则使libs-y中每个条目的最后一个斜杠替换成 /built-in.o,比如 drivers/mtd/ 会变为 drivers/mtd/built-in.o

可见libs-y最后指向各个文件夹的built-in.o，而这些built-in.o则由 Kbuild Makefile 将obj-y所包含的各个文件编译而成,

具体可研究 scripts/Kbuild.include 和 scripts/Makefile.build。

3.5 %config

一般我们在执行make之前都需要配置一下开发板参数,比如make smdk2410_config,在顶层目录Makefile有：

# Basic helpers built in scripts/
PHONY += scripts_basic
scripts_basic:
    $(Q)$(MAKE) $(build)=scripts/basic
    $(Q)rm -f .tmp_quiet_recordmcount

# To avoid any implicit rule to kick in, define an empty command.
scripts/basic/%: scripts_basic ;

build 在 scripts/Kbuild.include定义：

build := -f $(srctree)/scripts/Makefile.build obj

展开就是：

@make -f scripts/Makefile.build obj=scripts/basic

第476行：

config: scripts_basic outputmakefile FORCE
    $(Q)$(MAKE) $(build)=scripts/kconfig $@

%config: scripts_basic outputmakefile FORCE
    $(Q)$(MAKE) $(build)=scripts/kconfig $@

展开就是：

@make -f scripts/Makefile.build obj=scripts/kconfig %config

scripts/Makefile.build中:

scripts/Makefile.build中:

12: prefix := spl
13: src := $(patsubst $(prefix)/%,%,$(obj))         #obj=scripts/kconfig, src := scripts/kconfig

57: kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))                    
  #kbuild-dir := $(srctree)/scripts/kconfig

58: kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)   
#由于没有scripts/kconfig/Kbuild这个文件,所以 kbuild-file := $(srctree)/scripts/kconfig/Makefile

59: include $(kbuild-file)  #在这里将scripts/kconfig/Makefile 添加进来了

%config这个目标的生成规则在scripts/kconfig/Makefile中：

15: SRCARCH := ..    
113：%_defconfig: $(obj)/conf
114：    $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)         
      #执行：@scripts/kconfig/conf --defconfig=arch/../configs/%_defconfig Kconfig      (没有进入arch目录)
      #即：  @scripts/kconfig/conf --defconfig=configs/%_defconfig Kconfig 
115：
116：# Added for U-Boot (backward compatibility)
117：%_config: %_defconfig
118：    @:

分析到这里,我们可以看出配置单板相关的参数是在 scripts/kconfig/conf 中进行的, 传入的参数是 --defconfig=configs/%_defconfig Kconfig 可以推测conf会从configs目录下读取对应的defconfig文件进行解析然后保存参数,但我看了一下scripts/kconfig/conf.c 的代码,发现实在是过于复杂,恕博主不继续深入分析,如果以后有时间会再继续研究。

3.6 分析if_changed规则

   scripts/Kbuild.include:
     7：squote  := \'

    30：escsq = $(subst $(squote),\'$(squote)\',$1)

   217：echo-cmd = $(if $($(quiet)cmd_$(1)),
   218：echo \'  $(call escsq,$($(quiet)cmd_$(1)))$(echo-why)\';)

   234：ifneq ($(KBUILD_NOCMDDEP),1)
   235：# Check if both arguments has same arguments. Result is empty string if equal.
   236：# User may override this check using make KBUILD_NOCMDDEP=1
   237：arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) 
   238：                    $(filter-out $(cmd_$@),   $(cmd_$(1))) )
   239：else
   240：arg-check = $(if $(strip $(cmd_$@)),,1)
   241：endif

   249：make-cmd = $(call escsq,$(subst #,\\#,$(subst $$,$$$$,$(cmd_$(1)))))

   253：any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^)

   257：if_changed = $(if $(strip $(any-prereq) $(arg-check)),              
   258：    @set -e;                                                            
   259：    $(echo-cmd) $(cmd_$(1));                                            
   260：    printf \'%s
\' \'cmd_$@ := $(make-cmd)\' > $(dot-target).cmd)

   314：echo-why = $(call escsq, $(strip $(why)))

这里简单分析一下if_changed规则：

• 首先any-prereq, arg-check目标是检测目标和依赖是否存在或有更新;
• set -e 发生错误后立即停止,此处是为了不让错误像滚雪球一样越来越多;
• echo-cmd 由于是”安静模式”下进行编译的,所以这个参数会被展开成： echo \' quiet_cmd_cmd(1) \';此处忽略why, 编译的时候也没出现why信息, 估计是被屏蔽了(KBUILD_VERBOSE不等于2);
• 所以259行可以展开成： echo \' quiet_cmd_cmd(1) \'; $(cmd_$(1)); 即先打印信息,然后执行命令;

大家分析命令的时候可以搜索 quiet_cmd_xxx, 还有cmd_xxx, “xxx”是调用call函数时传入的命令参数.

3.7 总结

依赖关系如下：

all -> u-boot.bin -> u-boot-nodtb.bin -> u-boot |-> u-boot-init -> head-y (start.o)    -> start.S
                                                |-> u-boot-main -> libs-y (built-in.o) -> obj-y ...

参考文章：

[1] bootloader 详细介绍

[2] 新版u-boot移植到s3c2440开发板（一）--建立单板

[3] UBOOT2016.07移植(第一篇)初步分析（部分转载）

[4] 【u-boot-2018.11】make编译过程目标依赖分析

[5]U-Boot工程目录介绍