坑！uboot升级过程遇到的两个bug
时间：2020-09-14 17:40:34
手机看文章
扫描二维码
随时随地手机看文章
[导读]之前做过一次 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
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
cc: Albert ARIBAUD
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
-#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直接启动内核，看看内核到底是快是慢。
spl没有能力加载这么大的
kernel
kernel能完全启动，只需要能加载启动一段，足以体现出启动速度是否正常即可，于是裁剪出一个非常小
kernel来辅助实验。
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的方法和思路却是可以积累复用的。
-END-
本文授权转载自qb杂货铺，作者：瞎折腾的zqb
推荐阅读
免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！
下载文档
