坑！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直接启动内核，看看内核到底是快是慢。

支持过程碰到了一些小问题

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