stm32 uboot调试1--Apple的学习笔记-摩杜云开发者社区

一，前言

openocd+stlink的vscode远程gdb调试环境搭建完成了，那么用吧，串口也不连接了。用自带的configs/stm32f429-discovery_defconfig进行的编译，然后就直接调试了。

二，问题记录

问题1：board_init_f进入fdt初始化就进入hang。答：因为fdt是分离的但是我并没有下载到某个地址，于是先配置为嵌入到uboot来解决。

问题2：serial_init初始化一路调用直到configure_clocks函数中，最后while1卡死

/* Enable the SAI PLL */
    setbits_le32(®s->cr, RCC_CR_PLLSAION);
    while (!(readl(®s->cr) & RCC_CR_PLLSAIRDY))

路径中先是串口设备类，然后调用pintrol设备类，最后调用你了clock设备类，问题出在clock，以前用stmF429的代码移植到stmF407，也遇到过clock相关错误，因为429支持180M，407最大支持168M

static const struct stm32_clk_info stm32f4_clk_info = {
    /* 180 MHz */
    .sys_pll_psc = {
        .pll_n = 360,
        .pll_p = 2,
        .pll_q = 8,
        .ahb_psc = AHB_PSC_1,
        .apb1_psc = APB_PSC_4,
        .apb2_psc = APB_PSC_2,
    },
    .has_overdrive = false,
    .v2 = false,
};

于是把.pll_n从360改成336即可让pll设置为168M。修改后依然在此while卡住，于是查手册RCC_CR的bit28~bit31是保留位，所以根本不存在bit29的PLLSAIRDY，所以直接注释掉即可。

问题3：继续全速运行跑，自己跑飞复位，调用了如下reset_cpu。

void bad_mode(void)
{
    panic("Resetting CPU ...\n");
    reset_cpu();
}
 

void do_hard_fault(struct autosave_regs *autosave_regs)
{
    printf("Hard fault\n");
    dump_regs(autosave_regs);
    bad_mode();
}

然后单步调试，就是board_init_f中一个个函数调用，看到reserve_board没正常退出，应该是分配内存的时候挂了。于是想到sdram是否设置正常，看了lib/fdtdec.c中的fdtdec_setup_mem_size_base函数。start地址0x90000000，长度是0x800000。那么应该是用了外部8M sdram。

stm32 uboot调试1--Apple的学习笔记_stm32uboot

但是我的板子不是F429，所以没有外部sdram，怪不得分配内存跑飞了。于是想到一个问题，就是uboot文件到底有多大，我调试的u-boot是带调试信息的所以很大，内部sdram分2块共192K，最大的一块只有112K，地址从0x20000000开始的。通过看到代码，得到信息来源是设备树

memory@90000000 {
		device_type = "memory";
		reg = <0x20000000 0x800000>;
	};

那么我暂时改成

memory@20000000 {
		device_type = "memory";
		reg = <0x20000000 0x1C000>;
	};

顺便再看看哪里配置内存的，看defconfig

CONFIG_SYS_MALLOC_LEN=0x0200000

也就是动态分配空间的大小，从2M改成64K

CONFIG_SYS_MALLOC_LEN=0x10000

调试的时候发现会进入mmu reserve空间，根本不用，所以添加设置

CONFIG_SYS_ICACHE_OFF=y
CONFIG_SYS_DCACHE_OFF=y

继续运行还是这里的问题，其实是非法gd->bd赋值的地址是否非法的。原因是之前仅设置了112K，然后reserve一些size，结果

gd->mon_len = (ulong)&__bss_end - (ulong)_start;

gd->mon_len已经超过了112K。

0x000000000802ad60                __bss_end

可以看到_start不是单单bss的大小，明显uboot设计的是把flash的内容也全部搬运到外部dram中。若我要裁剪，等于要修改uboot源码了，这样会破坏其他开发板的编译，而我目前对代码也不算很熟悉，不清楚删除某些内容是否会造成某些影响。

static int setup_mon_len(void)

{
#if defined(__ARM__) || defined(__MICROBLAZE__)
    gd->mon_len = (ulong)&__bss_end - (ulong)_start;

基于不想大概源码，仅裁剪的原则，所以最后我想到的解决方案是板子有外部sdram的预留，准备买一个外部sdram焊接上，再继续玩。

1104货已经到了，但是我焊接失败，只能停止此计划了。

三，小结

用上了自己的基于openocd+stlink的vscode远程debug环境来调试，蛮好玩的，但是这块relocate地址的设计其实用打印看起来更加快。因为这块的数据流我都知道，之前有详细分析过。但是我的串口线当前连接在了am335x开发板，所以等于无串口，那么debug看变量也很方便，否则我的环境不是白搭了，需要把它用起来，用不同的debug方法来解决问题，也算增强debug技能的刻意练习。