记一次uboot升级过程的两个坑
背景
之前做过一次uboot
的升级,当时留下了一些记录,本文摘录其中比较有意思的两个问题。
启动失败问题
问题简述
uboot
代码中用到了一个库,考虑到库本身跟uboot
版本没什么关系,就直接把旧的库文件拷贝过来使用。结果编译链接是没问题,启动却会卡住。
消失的打印
为了明确卡住的位置,就去修改了库的源码,添加一些打印(此时还是在旧版本uboot
下编译的),结果发现卡住的位置或随着添加打印的变化而变化,且有些打印语句,添加后未打印出来。
我决定先从这些神秘消失的打印入手。
分析下uboot
中的printf
实现,最底层就是写寄存器,是一个同步的函数,也没什么可疑的地方。
为了确认打印不出来的时候,到底有没有调用到printf
,我决定给printf
增加一个计数器,在gd
结构体中,增加一个printf_count
字段,初始化为0
,每次打印时执行printf_count++
并打印出值。
设计这个试验,本意是确认未打印出来时是否确实也调用到了printf
,但却有了别的发现,实验结果中printf_count
值会异常变化,不是按打印顺序递增,而是会突变成很大的异常值。
printf_count
是gd
结构体的成员,那就是gd
的问题了。进一步将uboot
全局结构体gd
的地址打印出来。确认了原因是gd
结构体的指针变化了。
这也可以解释部分打印消失的现象,原因是我们在gd
中有另一个字段,用于控制打印等级。当gd
被改动了,printf
就可能解析出错,误以为打印等级为0
而提前返回。
gd的实现
那么好端端的,gd
为什么会被改了呢?这就要先看看gd
到底是怎么实现的了。
uboot
中维护了一个全局的结构体gd
。在代码中加入
DECLARE_GLOBAL_DATA_PTR;
即可使用gd
指针访问这个全局结构体,许多地方都会借助gd
来保存传递信息。
进一步看看这个宏的定义
旧版本uboot:
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
新版本uboot:
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
居然不一样,一个是将gd
的值放到r8
寄存器,一个是放在r9
寄存器。
那么就可以猜测到,库是在旧版本uboot
中编译出来的,可能使用了r9
,那么放到新版本uboot
中去,就会破坏r9
寄存器中保存的gd
值,导致一系列依赖gd
的代码不能正常工作。
验证改动
为了求证,将库反汇编出来,发现确实避开了r8
寄存器,但使用了r9
寄存器。
说明uboot
在指定gd
寄存器的同时,还有某种方法让其他代码不使用这个寄存器。
那是不是把旧uboot
中的这个r8
改成r9
,重新编译库就可以了呢?试一下,还是不行。
那么禁止其他代码使用r8寄存器肯定就是通过别的方式实现的了。简单粗暴地在旧版本uboot
下搜索r8
,去掉.c .h
等类型后,很容易发现了
./arch/arm/cpu/armv7/config.mk:24:PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-floa
将-ffixed-r8
修改为-ffixed-r9
,重新编译出库,这回就可以正常工作了,打印正常,启动正常。反汇编出来也可以看到,新编译出来的库用了r8
没有用r9
。
当然更好的改法,是直接在新版本的uboot
中编译,这是最可靠的。
追本溯源
话说回来,为什么两个版本的uboot
,会使用不同的寄存器呢?难道有什么坑?
这就得去翻一下git
记录了。
commit fe1378a961e508b31b1f29a2bb08ba1dac063155
Author: Jeroen Hofstee <jeroen@myspectrum.nl>
Date: Sat Sep 21 14:04:41 2013 +0200
ARM: use r9 for gd
To be more EABI compliant and as a preparation for building
with clang, use the platform-specific r9 register for gd
instead of r8.
note: The FIQ is not updated since it is not used in u-boot,
and under discussion for the time being.
The following checkpatch warning is ignored:
WARNING: Use of volatile is usually wrong: see
Documentation/volatile-considered-harmful.txt
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
从git
记录中,也可以确认完整地将r8
切换到r9
,都需要做哪些修改
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 16c2e3d1e0..d0cf43ff41 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -17,7 +17,7 @@ endif
LDFLAGS_FINAL += --gc-sections
PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
- -fno-common -ffixed-r8 -msoft-float
+ -fno-common -ffixed-r9 -msoft-float
# Support generic board on ARM
__HAVE_ARCH_GENERIC_BOARD := y
diff --git a/arch/arm/cpu/armv7/lowlevel_init.S b/arch/arm/cpu/armv7/lowlevel_init.S
index 82b2b86520..69e3053a42 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -22,11 +22,11 @@ ENTRY(lowlevel_init)
ldr sp, =CONFIG_SYS_INIT_SP_ADDR
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
#ifdef CONFIG_SPL_BUILD
- ldr r8, =gdata
+ ldr r9, =gdata
#else
sub sp, #GD_SIZE
bic sp, sp, #7
- mov r8, sp
+ mov r9, sp
#endif
/*
* Save the old lr(passed in ip) and the current lr to stack
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
index 79a9597419..e126436093 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -47,6 +47,6 @@ struct arch_global_data {
#include <asm-generic/global_data.h>
-#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
+#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
#endif /* __ASM_GBL_DATA_H */
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 960d12e732..ac54b9359a 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -69,7 +69,7 @@ ENTRY(_main)
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
sub sp, #GD_SIZE /* allocate one GD above SP */
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
- mov r8, sp /* GD is above SP */
+ mov r9, sp /* GD is above SP */
mov r0, #0
bl board_init_f
@@ -81,15 +81,15 @@ ENTRY(_main)
* 'here' but relocated.
*/
- ldr sp, [r8, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */
+ ldr sp, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
- ldr r8, [r8, #GD_BD] /* r8 = gd->bd */
- sub r8, r8, #GD_SIZE /* new GD is below bd */
+ ldr r9, [r9, #GD_BD] /* r9 = gd->bd */
+ sub r9, r9, #GD_SIZE /* new GD is below bd */
adr lr, here
- ldr r0, [r8, #GD_RELOC_OFF] /* r0 = gd->reloc_off */
+ ldr r0, [r9, #GD_RELOC_OFF] /* r0 = gd->reloc_off */
add lr, lr, r0
- ldr r0, [r8, #GD_RELOCADDR] /* r0 = gd->relocaddr */
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */
b relocate_code
here:
@@ -111,8 +111,8 @@ clbss_l:cmp r0, r1 /* while not at end of BSS */
bl red_led_on
/* call board_init_r(gd_t *id, ulong dest_addr) */
- mov r0, r8 /* gd_t */
- ldr r1, [r8, #GD_RELOCADDR] /* dest_addr */
+ mov r0, r9 /* gd_t */
+ ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
/* call board_init_r */
ldr pc, =board_init_r /* this is auto-relocated! */
启动慢问题
问题简述
填了几个坑之后,新的uboot
可以启动到内核了,但发现启动速度非常慢,内核启动速度慢了接近10
倍!明明是同一个内核,为什么差异这么大。
排查寄存器
初步排查了下设备树配置,以及uboot
跳转内核前的一些关键寄存器,确实在两个版本的uboot中
有所不同,但具体去看这些不同,发现都不会影响速度,将一些驱动对齐之后寄存器差异基本就消失了。
差异的分界
那再细看,kernel
的速度有差异,uboot
呢?在哪个时间点之后,速度开始产生差异?
尝试在两个版本的uboot
中插入一些操作,对比时间戳,发现两个uboot
在某个节点之后的速度确实有区别。
进一步排查,原来是在打开cache
操作之后,旧uboot
的速度就会比新uboot
快。尝试将旧uboot
的cache
关掉,则二者基本一致。尝试将旧uboot
操作cache
的代码,移植到新uboot
,未发生改变。
此时可确认新uboot
的开cache
有问题。但觉得这个跟kernel
启动慢没关系。因为uboot
进入kernel
之前都会关cache
,由kernel
自己去重新打开。
也就是不管是用哪份uboot
,也不管uboot
中是否开了cache
,对kernel
阶段都应该没有影响才对。
于是记录下来uboot
的这个问题,待后续修复。先继续找kernel
启动慢的原因。(注:现在看来当时的做法是有问题的,这里的异常这么明显,应该设法追踪下去找出原因才对)
锁定uboot
uboot
的嫌疑非常大,但还不能完全确认,因为uboot
之前还有一级spl
。是否会是spl
的问题呢?
尝试改用新spl+旧uboot
,启动速度正常。而新spl+新uboot
的启动速度则很慢,其他因素都不变,说明问题确实出在uboot
阶段。
多做or少做
当时到这一步就卡住了,直接比较两份uboot
的代码不太现实,差异太大了。
后来我就给自己提了个问题,到底新uboot
是多做了某件事情,还是少做了某件事情?
换个说法,目前已知
spl --> 旧uboot --> kernel(速度快)
spl --> 新uboot --> kernel(速度快)
但到底是以下的情况A
还是情况B
呢?
A: spl(速度慢) --> 旧uboot(做了某个会提升速度的操作) --> kernel(速度快)
spl(速度慢) --> 新uboot(少做了某个会提升速度的操作) --> kernel(速度慢)
B: spl(速度快) --> 旧uboot(没做特殊操作) --> kernel(速度快)
spl(速度快) --> 新uboot(多做了某个会限制速度的操作) --> kernel(速度慢)
为了验证,我决定让spl
直接启动内核,看看内核到底是快是慢。
支持过程碰到了一些小问题
1.spl
没有能力加载这么大的kernel
解决:此时不需要kernel
能完全启动,只需要能加载启动一段,足以体现出启动速度是否正常即可,于是裁剪出一个非常小kernel
来辅助实验。
2.kernel
需要dtb
解决:内核有一个CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE
选项。选上重新编译。编译后再用dd
将kernel
和dtb
拼接到一起,作为新的kernel
。这样,spl
就只需要加载一个文件并跳转过去即可。
试验结果,spl
启动的kernel
和使用新uboot
启动的kernel
速度一致,均比旧uboot
启动的kernel
慢。
说明,旧uboot
中做了某个关键操作,而新uboot
没做。
找出关键操作
那接下来的任务就是,找出旧uboot
中的这个关键操作了。
怎么找呢?有了上一步的成果,我们可以使用以下方法来排查
-
spl
加载kernel
和旧uboot
-
spl
跳转到旧uboot
,此时kernel
其实已经在dram
中准备好了,随时可以启动 -
在旧
uboot
的启动流程各个阶段,尝试直接跳转到kernel
,观察启动速度 -
如果在旧
uboot
的A
点跳转kernel
启动慢,B
点跳转启动快,则说明关键操作位于AB
点之间。
方法有了,很快就锁定到start.S
,进一步在start.S
中揪出了这段代码
#if defined(CONFIG_ARM_A7)
@set SMP bit
mrc p15, 0, r0, c1, c0, 1
orr r0, r0, #(1<<6)
mcr p15, 0, r0, c1, c0, 1
#endif
新uboot
的start.S
中没有这段代码,尝试在新uboot
的start.S
中添加此操作,速度立马恢复正常了。
再全局搜索下,原来这个新版本uboot
中,套路是在board_init
中进行此项设置的,而这个平台从旧版本移植过来,就没有设置 SMP bit
, 补上即可。
SMP bit是什么
SMP
是指对称多处理器,看起来这个 bit
会影响多核的 cache
一致性,此处没有再深入研究。
但可以知道,对于单处理器的情况,也需要设置这个bit
才能正常使用cache
。
贴下arm
的图和描述:
[6] SMP
Signals if the Cortex-A9 processor is taking part in coherency or not.
In uniprocessor configurations, if this bit is set, then Inner Cacheable Shared is treated as Cacheable. The reset value is zero.
搜下kernel
的代码,发现也是有地方调用了的。不过这个芯片是单核的,根本就没配置CONFIG_SMP
。
#ifdef CONFIG_SMP
ALT_SMP(mrc p15, 0, r0, c1, c0, 1)
ALT_UP(mov r0, #(1 << 6)) @ fake it for UP
tst r0, #(1 << 6) @ SMP/nAMP mode enabled?
orreq r0, r0, #(1 << 6) @ Enable SMP/nAMP mode
orreq r0, r0, r10 @ Enable CPU-specific SMP bits
mcreq p15, 0, r0, c1, c0, 1
#endif
总结
整理出来一方面是记录这两个bug
,另一方面也是想记录下当时的一些操作。
毕竟同样的bug
可能以后都不会碰到了,但解bug
的方法和思路却是可以积累复用的。
blog: https://www.cnblogs.com/zqb-all/p/13172546.html
公众号:https://sourl.cn/shT3kz