X-003-UBOOT-基于Bubblegum-96平台的u-boot移植说明

作者:wowo 发布于:2016-5-29 18:00 分类:X Project

1. 前言

本文是X Project “【任务1】启动过程-Boot from USB”的一部分,将以“Bubblegum 96boards”为例,介绍将u-boot移植到一个新的平台上的步骤和方法,并以此为契机,分析、理解u-boot的编译过程。

2. 思路

由“u-boot启动流程分析(1)_平台相关部分”的介绍可知,u-boot平台相关的代码,是以“board—>machine—>arch—>cpu”为框架逐层抽象出来的。因此,u-boot的移植,也要遵循这个框架,逐层进行,包括:

层次1,ARCH有关的代码移植(如ARM);

层次2,CPU有关的代码移植(如armv8);

层次3,Machine有关的代码移植(如S900);

层次4,Board有关的代码移植(如Bubblegum 96boards)。

而移植的过程,需要遵守如下的基本原则:

如果目标平台所对应的ARCH,已经被u-boot upstream代码支持,则直接从层次2(CPU移植)开始;

如果目标平台所使用的CPU,已经被u-boot upstream代码支持,则直接从层次3(Machine移植)开始;

如果目标平台所使用的Machine,已经被u-boot upstream代码支持,则直接从层次4(Board移植)开始;

如果目标平台所使用的Board,已经被u-boot upstream代码支持,则移植工作已经完成了。

对“Bubblegum 96boards”来说,upstream代码已经支持了ARCH(ARM)和CPU(armv8),因此我们将从层次3 Machine移植开始。

最后,为了简单,本文的移植工作,和“【任务1】启动过程-Boot from USB”所设定的目标一致,即Board有关的代码被执行后,点亮一个LED灯即可。

注1:本文的移植工作,将以u-boot SPL功能为主,因此相关的分析过程(如编译脚本等),主要以SPL为例,而具体的u-boot部分,大家可以触类旁通。

3. 准备工作

3.1 编译环境

1)运行linux系统的PC(大家自行准备,这里以Ubuntu为例)。

2)安装必要的库:

sudo apt-get install ncurses-dev

3.2 工具和代码下载

移植开始前,我们需要下载u-boot代码、交叉编译工具等。如下:

mkdir x_project

cd x_project

git clone git@github.com:wowotechX/u-boot.git

git clone git@github.com:wowotechX/tools.git

git clone git@github.com:wowotechX/build.git

注2:tools中有32位、64位等环境下的交叉编译工具。

注3:我们将在build目录中保存一些编译有关的脚本,以方便移植及后续的开发工作。

注4:由于众所周知的原因,我们从github上clone代码的时候,速度奇慢,经过wowo的探索和研究,下面的方法可以改善很多(我只贴出步骤,不再做过多解释,你懂的)。

1)%¥#¥……××&(×&

wget https://raw.githubusercontent.com/racaljk/hosts/master/hosts -qO /tmp/hosts && sudo sh -c 'cat /tmp/hosts > /etc/hosts'

sudo /etc/init.d/dns-clean start

sudo /etc/init.d/networking restart

2)使用ssh clone

github ssh配置的方法,可参考“X-001-PRE-git介绍及操作记录”。

4. 移植过程

注5:为了减少文档的工作量,移植过程尽量以git diff等source code的方式给出,大家可以参考,不再过多语言解释。

4.1 基本符号的定义

本文的目标平台是“Bubblegum-96(http://www.96boards.org/products/)“,该平台使用炬芯公司(Actions)的S900 SOC,属于ARMv8架构,按照u-boot “board—>machine—>arch—>cpu”的架构,我们定义如下符号,以指导后续的移植工作:

Board                ->  bubblegum
Vendor              ->  actions
Machine(SoC)    ->  s900
Arch                  ->  arm
CPU                  ->  armv8

4.2 目录结构以及Kconfig的确定

本节将参考“doc/README.kconfig”文档,进行平台有关的基础框架的移植:

1)在board/目录中创建“actions/bubblegum” 目录,并提供Kconfig和Makefile文件

vim@vimpc:~/work/x_project/u-boot$ mkdir -p board/actions/bubblegum

vim@vimpc:~/work/x_project/u-boot$ touch board/actions/bubblegum/Kconfig

vim@vimpc:~/work/x_project/u-boot$ touch board/actions/bubblegum/Makefile

2)在arch/arm/Kconfig中,添加“bubblegum-96”的配置菜单

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -744,6 +744,13 @@ config TARGET_THUNDERX_88XX
        bool "Support ThunderX 88xx"
        select OF_CONTROL
  
+config TARGET_BUBBLEGUM
+       bool "Support Bubblegum 96Board"
+       select ARM64
+       select SUPPORT_SPL
+       select SPL
+         help
+         Support for Bubblegum 96boards platform based on Actions S900 Soc,
+         with 4xA53 CPU, PowerVR G6230 GPU, 2GB RAM, and USB 3.0 support.
+

endchoice
  
source "arch/arm/mach-at91/Kconfig"
@@ -881,6 +888,7 @@ source "board/vscom/baltos/Kconfig"
source "board/woodburn/Kconfig"
source "board/work-microwave/work_92105/Kconfig"
source "board/zipitz2/Kconfig"
+source "board/actions/bubblegum/Kconfig" 

source "arch/arm/Kconfig.debug"

此处会select ARM64,此时arch、board、CPU等结构已经确定。同时,我们select了SUPPORT_SPL和SPL两个配置项,表明该版型将会使用SPL功能。

3)根据4.1的符号定义,在board/actions/bubblegum/Kconfig中,添加如下配置项:

--- a/board/actions/bubblegum/Kconfig
+++ b/board/actions/bubblegum/Kconfig
@@ -0,0 +1,21 @@
+#
+# wowo wowo@wowotech.net
+#
+# SPDX-License-Identifier:     GPL-2.0+
+#
+
+if TARGET_BUBBLEGUM
+
+config SYS_BOARD
+       default "bubblegum"
+
+config SYS_VENDOR
+       default "actions"
+
+config SYS_SOC
+       default "s900"
+
+config SYS_CONFIG_NAME
+       default "bubblegum"
+
+endif

根据README的描述,定义上述配置项之后,u-boot会编译如下的目录:

Define CONFIG_SYS_CPU="cpu" to compile arch//cpu/
        arch/arm/cpu/armv8
        Q:并没有看到CONFIG_SYS_CPU的定义?
        A:在“arm/Kconfig”中定义,“default "armv8" if ARM64”,这就是为什么在上面Target定义中“select ARM64”的原因。

Define CONFIG_SYS_SOC="soc" to compile arch//cpu//
        arch/arm/cpu/armv8/s900
        Q:如果该目录不存在,是否还会编译?
        A:应该不会。

Define CONFIG_SYS_VENDOR="vendor" to compile board//common/* and board///*
        board/actions/common/*
        board/actions/bubblegum/*

Define CONFIG_SYS_CONFIG_NAME="target" to include include/configs/.h
        include/configs/bubblegum.h

4)创建该板子有关的配置头文件

u-boot的配置有两种方式:一种是autoconf的方式,通过menuconfig生成.config,然后再转换为conf.h,类似于kernel的配置文件;另一种是通过版型有关的头文件(如上面的include/configs/bubblegum.h)。

autoconf的方式,后面再介绍,这里先创建一个头文件:

vim@vimpc:~/work/x_project/u-boot$ cat include/configs/bubblegum.h

/*
* (C) Copyright 2016 wowotech
*
* wowowowo@wowotech.net
*
* Configuration for Bubblegum 96boards.
*
* SPDX-License-Identifier:    GPL-2.0+
*/
#ifndef __BUBBLEGUM_H
#define __BUBBLEGUM_H

#endif

5)使用menuconfig,生成.config,并保存为bubblegum_defconfig

cd ~/work/x_project/u-boot

make menuconfig

配置Architecture和Target:

Architecture select (ARM architecture)  --->

ARM architecture  --->
    Target select (Support Bubblegum 96Board)  --->

关闭Command line interface配置项下面所有的内容:

Command line interface  --->

其它暂时用默认值,保存退出,得到.config文件,然后另存为bubblegum_defconfig(具体内容可参考“https://github.com/wowotechX/u-boot/blob/x_integration/configs/bubblegum_defconfig”):

cp .config configs/bubblegum_defconfig

4.3 尝试编译一次

在这之前,现将当前改动提交到本地的u-boot仓库:

vim@vimpc:~/work/x_project/u-boot$ git commit -a -m "Basic porting for bubblegum 96board"

[x_dev 2315343] Basic porting for bubblegum 96board

5 files changed, 583 insertions(+)

create mode 100644 arch/arm/bubblegum_defconfig

create mode 100644 board/actions/bubblegum/Kconfig

create mode 100644 board/actions/bubblegum/Makefile

create mode 100644 include/configs/bubblegum.h

然后在x_project/build目录下,写一个简单的Makefile文件(可参考“https://github.com/wowotechX/build”),进行编译操作:

make u-boot

肯定会出错,没关系,兵来将挡,水来土掩,根据错误提示,一一解决。

4.4 在“include/configs/bubblegum.h”添加必要的配置项

具体可参考“https://github.com/wowotechX/u-boot/blob/x_integration/include/configs/bubblegum.h”,对我们此次的任务来说,如下配置项需要如实提供:

#define CONFIG_SPL_TEXT_BASE 0xe406b200

#define CONFIG_SPL_MAX_SIZE (1024 * 20)

#define CONFIG_SPL_STACK 0xe407f000

CONFIG_SPL_TEXT_BASE是SPL在SRAM中的运行地址,可以根据“X-002-HW-S900芯片boot from USB有关的硬件描述”中问题4的答案设置。CONFIG_SPL_MAX_SIZE是SPL最大的size(由SRAM可供执行SPL的空间决定),我们这里暂时选为20K。

CONFIG_SPL_STACK是SPL的堆栈基址,同样可以根据“X-002-HW-S900芯片boot from USB有关的硬件描述”中问题4的答案设置。

其它的配置项,此时不需要明白它们的具体意义,纯粹是为了解决编译错误。

添加后,再编译,还会出错,因为board/actions/bubblegum/中还没有C文件,随后加上。

4.5 在“board/actions/bubblegum/”中添加board有关的C文件

具体可参考“https://github.com/wowotechX/u-boot/tree/x_integration/board/actions/bubblegum”中的Makefile和board.c两个文件。

board.c中有一个名称为board_init_f函数,由CONFIG_SPL_BUILD配置项包住,我们可以在其中添加点LED的代码(具体的GPIO和LED的对应关系,可参考“Bubblegum 96boards原理图[3]”),如下:

#ifdef CONFIG_SPL_BUILD
void board_init_f(ulong bootflag)
{
        writel(readl(GPIOA_OUTEN) | (1 << TEST_LED_GPIO), GPIOA_OUTEN);
        writel(readl(GPIOA_OUTDAT) | (1 << TEST_LED_GPIO), GPIOA_OUTDAT);

        while (1);
}

#endif

其它变量和函数,纯粹是为了解决编译错误,此时先不要管它们的含义(后面用到的时候再说)。

再尝试一次编译,OK,成功了:

vim@vimpc:~/work/x_project/build$ ls out/u-boot/spl/ -l

总用量 152

-rwxrwxr-x 1 vim vim 107724  5月 28 21:28 u-boot-spl
-rwxrwxr-x 1 vim vim   6939  5月 28 21:28 u-boot-spl.bin
-rw-rw-r-- 1 vim vim  12540  5月 28 21:28 u-boot-spl.cfg
-rw-rw-r-- 1 vim vim   1055  5月 28 21:28 u-boot-spl.lds
-rw-rw-r-- 1 vim vim  17416  5月 28 21:28 u-boot-spl.map
-rwxrwxr-x 1 vim vim   6939  5月 28 21:28 u-boot-spl-nodtb.bin

按理说,通过DFU工具,把u-boot-spl.bin上传到SRAM的0xe406b200处并执行,LED应该亮了。

5. 总结和思考

5.1 debug手段

本文完成的时候,相关的改动已经上传到github了,具体可参考:

https://github.com/wowotechX/u-boot/commit/2f22e86e9b1c23771d59bee19ff364e198cbda40

https://github.com/wowotechX/build/commit/f01a056c54eb74f5721e9a72291132825a38c395

不过没有实际在板子上运行。由此得出一个疑问:

如果代码不能正确work(点亮LED),我们用什么手段debug?是不是除了JTAG别无它法?

还真不好办,暂时从软件逻辑上把握吧,只要能点亮一个灯,后面的事情就好办了。

5.2 为什么没有看到machine相关的代码移植?

这是一个值得思考的问题。我们在“u-boot启动流程分析(1)_平台相关部分”中命名提到了machine的概念,为什么在移植的时候却被忽略了?

要回答这个问题,我们可以回忆一下linux kernel中device tree的目的,以及ARM64的现状:是的,在arm64中已经把machine的概念去掉了(以往那么mach-xxx的目录不存在了),所有平台相关的代码,都分布在各种的device driver中过了。虽然u-boot没有明确提出这个概念,但是我们也要努力实现这个目标。因此:

在X project开发的过程中,我们要尽力避免machine有关的的代码出现。

5.3 链接脚本

我们在“u-boot启动流程分析(1)_平台相关部分”中有过一个假设,即:

本文先不涉及u-boot和平台相关的Kconfig/Makefile部分,以ARM64为例,假定u-boot首先从“arch/arm/cpu/armv8/start.S”的_start接口开始执行。因此我们从_start开始分析。

要解释这个假设,我们需要结合上面的移植过程,从u-boot的编译过程入手,进行简单的分析。

5.3.1 链接脚本简介

为了方便大家的理解,这里先从_start接口反推,看一下u-boot编译的链接脚本(本文主要以SPL为例,u-boot类似):

/* arch/arm/cpu/armv8/u-boot-spl.lds */

MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,
                LENGTH = CONFIG_SPL_MAX_SIZE }
MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
                LENGTH = CONFIG_SPL_BSS_MAX_SIZE }

OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", "elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
ENTRY(_start)
SECTIONS
{
        .text : {
                . = ALIGN(8);
                *(.__image_copy_start)
                CPUDIR/start.o (.text*)
                *(.text*)
        } >.sram
    ...
}

由上面的链接脚本可知,u-boot(这里为SPL,后面不再特意区分)image的开始位置,存放的是“CPUDIR/start.o”,我们应该猜到了,就是“arch/arm/cpu/armv8/start.o”。而start.S第一条指令,就是_start,所以系统启动后,执行的第一条指令,就是_start。因此,接下来我们将以此为线索,通过分析u-boot的编译过程,弄清楚如下的问题:

1)armv8目录下的链接脚本,是怎么选中并参与到u-boot的编译中的?

2)“CPUDIR”到底是怎么定义的?

不过在此之前,我们要先解释一下链接脚本开始的那几个宏定义(分析u-boot的是时候,大家一定要对CONFIG_XXX高度敏感):

CONFIG_SPL_TEXT_BASE,定义了u-boot SPL代码段的基地址。换句话说,就是我们希望SPL在哪个地址被执行。再换句话说,就是SPL image被装载到的RAM地址。回忆一下“X-002-HW-S900芯片boot from USB有关的硬件描述”中的问题4,我们应该将它设定为可以被SPL使用的SRAM地址。

CONFIG_SPL_MAX_SIZE,定义SPL代码段的最大size,这是由运行SPL的SRAM的大下做决定的,我们应该根据实际情况设置。

CONFIG_SPL_BSS_START_ADDR,定义了SPL BBS段的基地址。由“.sdram”标号可知,SPL的BSS段可以放到SDRAM中。这个特性很有意思,我们后面用到的时候再分析。

CONFIG_SPL_BSS_MAX_SIZE,定义SPL BSS段的最大size。

因此,我们也就明白了上面4.2小节中bubblegum.h文件中,为什么一定要如实定义这些配置项了。

5.3.2 链接脚本的指定

u-boot所有的编译动作,都是从根目录下的Makefile文件开始的,因此,通过阅读该文件,可以获取链接脚本的指定方式。

注6:本文主要以SPL的编译为例,u-boot类似(甚至会更简单)。

1)Makefile

参考Makefile的如下代码(不再详细分析):

all:            $(ALL-y)
ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin
spl/u-boot-spl.bin: spl/u-boot-spl
        @:
spl/u-boot-spl: tools prepare $(if $(CONFIG_OF_SEPARATE),dts/dt.dtb)
        $(Q)$(MAKE) obj=spl -f $(srctree)/scripts/Makefile.spl all

因此,如果定义CONFIG_SPL,则会编译SPL,直到“$(srctree)/scripts/Makefile.spl”中。

2)Makefile.spl

/* scripts/Makefile.spl */

# Linker Script

ifdef CONFIG_SPL_LDSCRIPT
# need to strip off double quotes
LDSCRIPT := $(addprefix $(srctree)/,$(CONFIG_SPL_LDSCRIPT:"%"=%))
endif

ifeq ($(wildcard $(LDSCRIPT)),)
        LDSCRIPT := $(srctree)/board/$(BOARDDIR)/u-boot-spl.lds
endif

ifeq ($(wildcard $(LDSCRIPT)),)
        LDSCRIPT := $(srctree)/$(CPUDIR)/u-boot-spl.lds
endif

ifeq ($(wildcard $(LDSCRIPT)),)
        LDSCRIPT := $(srctree)/arch/$(ARCH)/cpu/u-boot-spl.lds
endif

ifeq ($(wildcard $(LDSCRIPT)),)
$(error could not find linker script)
endif

由此可知,SPL的链接脚本可以通过如下方式指定(越靠前的,优先级越高,也越不通用):

通过CONFIG_SPL_LDSCRIPT自定义;

以board为单位,通过”$(srctree)/board/$(BOARDDIR)/u-boot-spl.lds“指定;

通过”$(srctree)/$(CPUDIR)/u-boot-spl.lds“指定;

通过”$(srctree)/arch/$(ARCH)/cpu/u-boot-spl.lds“指定。

结合5.3.1小节ARMv8链接脚本的路径----“arch/arm/cpu/armv8/u-boot-spl.lds”,我们将目光锁定在“CPUDIR”这个变量上。看来殊途同归啊,5.3.1小节提出的第二个问题,也是“CPUDIR”,我们就接着探索吧。

3)CPUDIR

在u-boot根目录的config.mk中,我们可以看到“CPUDIR”的定义,如下:

CPUDIR=arch/$(ARCH)/cpu$(if $(CPU),/$(CPU),)

好吧,矛盾转移到了“ARCH”和“CPU”两个变量上面了。接着在config.mk中查找,发现这两个家伙的定义如下:

ARCH := $(CONFIG_SYS_ARCH:"%"=%)

CPU := $(CONFIG_SYS_CPU:"%"=%)

矛盾接着转移,此时menuconfig可以出场了。u-boot在进行menuconfig的时候,在菜单中,第一个需要确定的配置项,就是Architecture,以ARM为例,如下:

Architecture select
    (X) ARM architecture

我们不去细究auto make脚本的执行过程,但需要看一下定义“Architecture选择”的Kconfig文件----arch/Kconfig,如下:

config ARM
        bool "ARM architecture"

source "arch/arm/Kconfig"

接着看:

menu "ARM architecture"
        depends on ARM

config SYS_ARCH
        default "arm"

config ARM64
        bool

config SYS_CPU
        ...
        default "armv8" if ARM64

SYS_ARCH已经出来了,而SYS_CPU则依赖于具体的CPU(如ARM64),那么CONFIG_ARM64在哪里定义呢?参考4.2小节中的介绍即可。

5.4 编译过程

TODO,有时间再介绍吧。

6. 参考文档

[1] S900 IC Spec,https://github.com/96boards/documentation/blob/master/bubblegum-96/SoC_bubblegum96.pdf

[2] Bubblegum 96boards硬件手册,https://github.com/96boards/documentation/blob/master/bubblegum-96/HardwareManual_Bubblegum96.pdf

[3] Bubblegum 96boards原理图,https://github.com/96boards/documentation/blob/master/bubblegum-96/bubblegum-96_Schematic_V1.0.pdf

[4] linaro-adfu-tool,https://github.com/96boards-bubblegum/linaro-adfu-tool/blob/master/src/linaro-adfu-tool-bg96.c

[5] X-002-HW-S900芯片boot from USB有关的硬件描述

[6] u-boot启动流程分析(1)_平台相关部分

 

原创文章,转发请注明出处。蜗窝科技,www.wowotech.net

标签: bubblegum uboot porting

评论:

xcyhere
2018-12-24 20:57
关于uboot编译配置里面,uboot源码的build目录具体有什么作用?为什么要在build自定义Makefile?
同济大学勾越
2018-03-22 14:41
请问适用于ARMCortexA53(armv8)的jtag源码debbuger有哪些,我想买一个自己调试用。在淘宝查了好久,没有合适的!有具体的淘宝链接吗?
wowo
2018-03-22 19:10
@同济大学勾越:这种级别的Debugger,估计没多少,常用的就是trace32,不过价钱惊人,所以还是不用了吧~
jansion
2017-04-09 21:08
我按照您的教程去做,但是始终出现这个错误,两天了都没有解决这个问题,望大神指点一下,谢谢!
输出log是:



LD      net/built-in.o
  CC      examples/standalone/hello_world.o
  CC      examples/standalone/stubs.o
  LD      examples/standalone/libstubs.o
  LD      examples/standalone/hello_world
  OBJCOPY examples/standalone/hello_world.srec
  OBJCOPY examples/standalone/hello_world.bin
  LD      u-boot
arm-none-linux-gnueabi-ld: BFD (Sourcery CodeBench Lite 2014.05-29) 2.24.51.20140217 assertion fail /scratch/maciej/arm-linux-2014.05-rel/obj/binutils-src-2014.05-29-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:7781
arm-none-linux-gnueabi-ld: error: required section '.rel.plt' not found in the linker script
arm-none-linux-gnueabi-ld: final link failed: Invalid operation
make: *** [u-boot] Error 1
sugar@sugar-VirtualBox:/mnt/wowo/xproject/uboot2016/u-boot-2016.07$
jansion
2017-04-09 22:52
@jansion:我现在在u-boot.lds中添加了rel.plt的定义后出现了这样的log:
make -f ./scripts/Makefile.build obj=test
make -f ./scripts/Makefile.build obj=test/dm
make -f ./scripts/Makefile.build obj=examples
make -f ./scripts/Makefile.build obj=examples/standalone
  arm-none-linux-gnueabi-gcc -E -Wp,-MD,./.u-boot.lds.d -D__KERNEL__ -D__UBOOT__   -D__ARM__ -marm -mno-thumb-interwork  -mabi=aapcs-linux  -mword-relocations  -fno-pic  -ffunction-sections -fdata-sections -fno-common -ffixed-r9  -msoft-float   -pipe -march=armv5t   -Iinclude   -I./arch/arm/include -include ./include/linux/kconfig.h  -nostdinc -isystem /usr/local/opt/arm-2014.05/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.3/include -include ./include/u-boot/u-boot.lds.h -DCPUDIR=arch/arm/cpu/arm1176  -ansi -D__ASSEMBLY__ -x assembler-with-cpp -P -o u-boot.lds board/harman/my6410/u-boot.lds
  arm-none-linux-gnueabi-ld   -pie  --gc-sections -Bstatic -Ttext 0x0 -o u-boot -T u-boot.lds arch/arm/cpu/arm1176/start.o --start-group  arch/arm/cpu/built-in.o  arch/arm/cpu/arm1176/built-in.o  arch/arm/lib/built-in.o  board/harman/my6410/built-in.o  cmd/built-in.o  common/built-in.o  disk/built-in.o  drivers/built-in.o  drivers/dma/built-in.o  drivers/gpio/built-in.o  drivers/i2c/built-in.o  drivers/mmc/built-in.o  drivers/mtd/built-in.o  drivers/mtd/onenand/built-in.o  drivers/mtd/spi/built-in.o  drivers/net/built-in.o  drivers/net/phy/built-in.o  drivers/pci/built-in.o  drivers/power/built-in.o  drivers/power/battery/built-in.o  drivers/power/fuel_gauge/built-in.o  drivers/power/mfd/built-in.o  drivers/power/pmic/built-in.o  drivers/power/regulator/built-in.o  drivers/serial/built-in.o  drivers/spi/built-in.o  drivers/usb/common/built-in.o  drivers/usb/dwc3/built-in.o  drivers/usb/emul/built-in.o  drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o  drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o  drivers/usb/musb-new/built-in.o  drivers/usb/musb/built-in.o  drivers/usb/phy/built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o  lib/built-in.o  net/built-in.o  test/built-in.o  test/dm/built-in.o --end-group arch/arm/lib/eabi_compat.o  arch/arm/lib/lib.a -Map u-boot.map
arm-none-linux-gnueabi-ld: BFD (Sourcery CodeBench Lite 2014.05-29) 2.24.51.20140217 assertion fail /scratch/maciej/arm-linux-2014.05-rel/obj/binutils-src-2014.05-29-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:7781
make: *** [u-boot] Error 1
jansion
2017-04-10 12:57
@jansion:我反复试过了, 我有一个没有搞懂的问题,uboot可执行文件应该是静态编译链接的,为什么连接器提示我链接脚本中要添加.rel.plt这个段,我通过u-boot.map文件,发现这个段确实被链接进了8个字节,如下:
.rel.plt        0x00005520        0x8
*(.rel.plt*)
.rel.plt       0x00005520        0x8 arch/arm/cpu/arm1176/start.o
                0x00005528                . = ALIGN (0x4)

这不知道是哪些函数符号链接进来了, 我通过readelf -r 查看了重定位信息,也没有发现start.o中有.rel.plt这个段。真是奇怪。
wowo
2017-04-10 16:23
@jansion:armv7 u-boot的.text,允许符号地址和代码的运行地址不同,也就是需要,启动(start.S)的那段代码,可能需要relocation,这估计是rel.plt存在的原因。
你可以检查一下.lds文件,确认一下.text的符号地址(默认为0,arch/arm/cpu/u-boot.lds),以及编出来的uboot的运行地址(放在ram中哪个位置)。
可能是哪个配置不对,实在不行,你先用xprj tiny210版型编译一下(修改config.mk,然后哦make env_prepare; make uboot),看看能不能编过,然后对比和你的编译过程的差异。
zzwd
2019-04-15 18:46
@jansion:你好,请问你解决了吗
wowo
2017-04-10 09:10
@jansion:如果其它的配置没有问题的话,根目录clean一下试试:
$ make clean
$ make mrproper
callme_friend
2017-01-04 18:45
根据raedme的说明:
SPL(辅助程序加载器)致力于统一所有的已存在的实现,并允许简单、方便的添加新的实现。
有了这个框架,几乎所有的硬件主板源文件都可以重用。不再需要重复代码或符号链接。

可是这些东西貌似不是必须的呀?normal的uboot也可以分为两个阶段:阶段1启动并重定位跳转到阶段2执行,那SPL还有什么意义?
wowo
2017-01-04 19:09
@callme_friend:是的,你说的对,SPL能做的事情,uboot也可以(通过链接脚本、重定位等),但用uboot去做的话,需要工程师了解很多底层的技术细节。个人感觉,SPL的框架比较简洁、易懂,仅此而已。
callme_friend
2017-01-05 10:21
@wowo:哦哦。那SPL启动的目的是做什么?是为了把uboot从其他地方copy到RAM执行吗?
如果是这样,那uboot前面的第1阶段岂不又把CPU重新初始化了一遍?
wowo
2017-01-05 21:48
@callme_friend:SPL中一般就是初始化DDR、copy u-boot。至于你所说的“把CPU重新初始化了一遍”,不太懂你指的哪些。你可以去看看SPL的代码,其实什么都没有做。
callme_friend
2017-01-07 09:46
@wowo:因为spl和uboot都把start.S编译进去了,起码这部分是重复执行吧?
wowo
2017-01-07 13:39
@callme_friend:这一点重复没问题的。ROM code、bootloader、kernel等等,这么多软件,哪一个都会重复。不用太纠结哈;-)
callme_friend
2017-01-09 10:04
@wowo:根据readme,CONFIG_SPL_FRAMEWORK更是SPL的核心,为啥咱们这个SPL没有配置该项?
jinxinxin163
2017-01-23 09:03
@callme_friend:是不是有这样的原因?
硬件厂商不想公开硬件接口部分,但用户又有改动uboot的需求,怎么办?
分成两层,spl和uboot,用户压根不知道spl,只知道有uboot
wowo
2017-01-09 10:21
@callme_friend:根据readme,CONFIG_SPL_FRAMEWORK更是SPL的核心,为啥咱们这个SPL没有配置该项?
==========================================================================
SPL有两种编译方式,一种是代码独立、独立编译(就是我们现在使用的);
另一种是和uboot搅在一起(使用CONFIG_SPL_FRAMEWORK),这一种我没有细看,反正条条大路通罗马。你有兴趣可以研究一下用着一种,看看两种的优缺点。
callme_friend
2017-01-10 22:09
@wowo:方式一是独立编译,目的是啥?(后面的博文是在SPL的基础上增加了uboot的搬运吗?)
方式二的意思是直接从spl启动内核的方式?就像doc里说的“Falcon Mode”?
wowo
2017-01-12 13:42
@callme_friend:对方式一来说,我觉得比较正规的用法是:
SPL是一个独立的Image,负责初始化DDR,负责搬运后续的uboot。一般情况下,chip常可以直接发布一个SPL的bin文件,而不需要给出source code(现在很多都是这样的,只不过这个bin文件是它们自己搞的)。
至于搬运,有时候SPL自己也要搬运自己啊,就像本文的板子一样,ROM代码只会从NAND/MMC搬运2KB的数据,SPL也不可能这么小啊。

对于方式二,我没了解过哎……
无心睡眠
2017-01-04 12:48
hi,wowo,文章中讲到使用menuconfig,生成.config,并保存为bubblegum_defconfig,这个文件相对路径是在 u-boot/configs下,为什么在4.3中提交到本地仓库,显示的路径是create mode 100644 arch/arm/bubblegum_defconfig。这里有点不理解
wowo
2017-01-04 14:07
@无心睡眠:多谢提醒啊,经您这么一说,我也有点不理解了,那个4.3的那个log是怎么出来的呢?可能一开始我的位置放错了,然后log贴错了吧,稍后改正。多谢~~
ooonebook
2016-07-10 14:41
wowo,我试着在你的版本上移植tiny210的uboot,现在用你的gcc-linaro-aarch64-linux-gnu-4.8-2013.12_linux可以编译过了,但是换成arm-linux-gcc-4.5.1的编译器就会报各种错。
make[2]: Entering directory `/home/ooonebook/code/project-x/build/out/u-boot'
  GEN     ./Makefile
scripts/kconfig/conf  --silentoldconfig Kconfig
  CHK     include/config.h
  GEN     include/autoconf.mk
cc1: warning: unknown register name: x18
  GEN     include/autoconf.mk.dep
cc1: warning: unknown register name: x18
  GEN     spl/include/autoconf.mk
cc1: warning: unknown register name: x18
make[2]: Leaving directory `/home/xys0610/code/project-x/build/out/u-boot'
make[2]: Entering directory `/home/xys0610/code/project-x/build/out/u-boot'
  CHK     include/config/uboot.release
  Using /home/xys0610/code/project-x/u-boot as source for U-Boot
  GEN     ./Makefile
  CHK     include/generated/version_autogenerated.h
  CHK     include/generated/timestamp_autogenerated.h
  UPD     include/generated/timestamp_autogenerated.h
  CC      lib/asm-offsets.s
cc1: warning: unknown register name: x18
/home/ooonebook/code/project-x/u-boot/lib/asm-offsets.c:1:0: error: bad value (armv8-a) for -march= switch
make[3]: *** [lib/asm-offsets.s] Error 1

想要请教一下,是否有必要换编译器,tiny210的soc是三星s5pv210,但是CPU也是A8的。
还是说你版本里面的那个编译器也可以用了。如果可以我就不折腾另外一个编译器导致的编译问题了。

谢谢~
wowo
2016-07-10 16:37
@ooonebook:你是怎么移植的呢?ARCH、CPU等信息,没有配置对吧?
看你的错误:error: bad value (armv8-a) for -march= switch
好像现在配置的为armv8-a?你的CPU应该不是这个ARCH。
至于编译器,确实应该用这个“arm-linux-gcc-4.5.1”。
如果还无法解决,你可以在论坛x project的讨论区发一个帖子,大家可以在那里讨论:
http://www.wowotech.net/forum/viewforum.php?id=6
傀儡
2017-07-24 19:50
@ooonebook:层主,我也遇到相同的问题,你解决了吗?能否告诉我怎么解决?
wowo
2017-07-25 08:45
@傀儡:ARCH、CPU等信息没有选对,你再检查一下。
傀儡
2017-07-25 09:45
@wowo:这些信息是在哪个目录下的文件选的?能否详细点说明。
wowo
2017-07-26 08:47
@傀儡:可以参考一下这两份文章:
http://www.wowotech.net/forum/viewtopic.php?id=52
http://www.wowotech.net/forum/viewtopic.php?id=68
傀儡
2017-07-25 09:46
@ooonebook:请问你是怎么解决的?
匿名
2017-08-23 16:41
@傀儡:交叉编译工具链的原因
东边月出
2016-06-21 21:29
很好哦
wowo
2016-05-30 11:44
刚刚试了一下,看来是没问题的,LED已经点亮了,呵呵~~
顺便提示一下,这篇文章中有一个小小的“福利”,大家懂得:-)
jansion
2017-05-07 19:14
@wowo:我没有怎么没有看懂“福利”咧?嘻嘻 看了十几遍了都.....
wowo
2017-05-08 09:02
@jansion:其实就是一个怎么访问谷哥的小伎俩,相信程序猿类都已经知道啦~~
小豌豆
2016-05-30 09:03
不过没有实际在板子上运行。由此得出一个疑问:
如果代码不能正确work(点亮LED),我们用什么手段debug?是不是除了JTAG别无它法?

更早的配置好只发送单字符串口打印,
直接配置寄存器的话,没有几行代码的,

DS5.1+Eclipse for DS-5 v5.23.0
是调试利器
wowo
2016-05-30 09:06
@小豌豆:LED如果都点不亮,灯就别提了:-)
根据我的经验,这一块如果如果仔细,IC spec又没有写错的话,一般都可以正确工作。
不过还有一个变数:DFU工具。要保证先DFU工具是正确的~~~~
小豌豆
2016-05-30 19:21
@wowo:你说的是量产工具吧。

开始的调试,可以通过量产方式把uboot下载到mmc,再启动调试。

还有个方法,量产的方法只引导uboot到DDR,然后调试,

调试bootloader和uboot最好要有 JTAG,否则很容易抓瞎的。

可能的情况太多了。
1    串口无任何打印,连接USB会进入ADFU

2    串口无任何打印,连接USB不会进入ADFU

3    串口有部分打印,连接USB会进入ADFU

4    串口有部分打印,连接USB不会进入ADFU

5    时而启动成功,时而启动失败

heavenward
2016-06-05 11:35
@小豌豆:jtag调试器很多情况下个人都是没有的。这种时候也就为了避免抓瞎,利用串口在问题代码附近输出log也是唯一的手段了
macooma
2016-09-21 14:22
@wowo:请问你尝试过在该板子上使用DS5+JTAG进行调试了吗? 我手里的hikey经过手动10pin转20pin之后链接总是失败,原因不明。
wowo
2016-09-21 14:45
@macooma:我没有用过DS5和JTAG。
bruno_liu
2016-05-30 08:45
请问Little kernel和 uboot的区别在哪里呢
wowo
2016-05-30 09:04
@bruno_liu:其实“X Project”开始的时候,我研究过很多boot,u-boot、Little kernel、UFEI、coreboot、grub等等。
从本质上来说,这些东西没有区别,都是SPL,目标都是加载linux kernel。对于您的问题,有什么区别?一时半会儿还真是不好回答,不过我们可以从侧面讨论。
其实我最倾向的,是使用Little kernel,毕竟它和kernel很像(有过一段时间,我们甚至想过做一个kernel的bootloader,使用相同的source code,通过编译选项,生成两份image,一份是bootloader,一份是kernel)。
不过最后还是决定先从u-boot的开始,原因是:
    1)u-boot在当前的ARM平台中,还是占据了绝对的统治地位。
    2)u-boot比较简单,经过尝试,只有u-boot可以在段时间内,编译出一个小于2KB的bin文件(如果好奇为什么纠结2KB,可以看看S900的spec)。

发表评论:

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog