This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM3352:u-boot.img 2024.04在 AM335x 定制电路板上没有#39;t START

Guru**** 2460850 points
Other Parts Discussed in Thread: TPS65910, AM3359, AM3352

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1478293/am3352-u-boot-img-2024-04-doesn-t-start-on-am335x-custom-board

器件型号:AM3352
主题中讨论的其他器件:AM3359TPS65217、TPS65910

工具与软件:

尊敬的各位同事:

我们的产品基于 AM335x (大多数情况下为 AM3352/AM3359) CPU。

与操作系统类似、我们使用我们自己的基于 Yocto 的 Linux 构建系统。 在我们定制电路板的当前解决方案中、我们使用 u-boot 2018.01、没有任何问题。

出于某些技术原因、我们决定升级我们的操作系统。 现在我们将使用现代 u-boot 2024.04和 Linux 内核6.6.x 与 Yocto 5.0.X 和 gcc 13

遗憾的是、在迁移过程中、我们遇到了启动 U-Boot 2024.04的问题。

引导日志:

U-Boot SPL 2024.04-ti-g29d0c23d67ee (Feb 23 2025 - 19:32:46 +0000)
Trying to boot from MMC1
VI_DEBUG: spl: mmc boot mode: fs
VI_DEBUG: spl_mmc_do_fs_boot executing spl_start_uboot
VI_DEBUG: spl_start_uboot ENTER
VI_DEBUG: spl_start_uboot
VI_DEBUG: spl_start_uboot sdram_init_done = 0
VI_DEBUG: spl_start_uboot board_init_f_state = 2
VI_DEBUG: spl_start_uboot gd->ram_size 0x20000000
VI_DEBUG: bd_info size = 92
VI_DEBUG: bd_info stack = 96
VI_DEBUG: env_load CFG_SYS_SDRAM_BASE 0x80000000 0x80000000
VI_DEBUG: spl_start_uboot env_get_yesno NO
VI_DEBUG: spl_mmc_do_fs_boot executing spl_load_image_fat
spl_load_image_fat: fat_size, file u-boot.img size - 0
VI_DEBUG: _spl_load ENTER
VI_DEBUG: _spl_load info->priv u-boot.img
VI_DEBUG: _spl_load loading hdr from 0x0 to 807fffc0
VI_DEBUG: fat_read_file reading u-boot.img at pos 0x0
VI_DEBUG: _spl_load FDT_MAGIC branch
VI_DEBUG: _spl_load activated SPL_LOAD_FIT
VI_DEBUG: spl_load_simple_fit ENTER
VI_DEBUG: fat_read_file reading u-boot.img at pos 0x0
VI_DEBUG: load_simple_fit ENTER
VI_DEBUG: fat_read_file reading u-boot.img at pos 0x0
VI_DEBUG load_simple_fit External data: dst=80800000, offset=fc8, size=3cec4
VI_DEBUG: load_simple_fit NO_COMPRESS length = 249540
VI_DEBUG: spl_load_simple_fit load_simple_fit ret 0
VI_DEBUG: load_simple_fit ENTER
VI_DEBUG: fat_read_file reading u-boot.img at pos 0x0
VI_DEBUG load_simple_fit External data: dst=8083cf00, offset=3de8c, size=15f10
VI_DEBUG: load_simple_fit NO_COMPRESS length = 89872
VI_DEBUG: _spl_load spl_image load_addr 0x80800000 entry_point 0x80800000
VI_DEBUG: _spl_load spl_image offset 0x0
VI_DEBUG: _spl_load spl_image size 249540
VI_DEBUG: _spl_load spl_image flags 2
VI_DEBUG: spl_load_image_fat spl_load done sdram_init_done = 0
VI_DEBUG spl_load_image_fat: return 0
VI_DEBUG: spl_mmc_do_fs_boot executing spl_load_image_fat ret = 0
VI_DEBUG: spl_mmc_load spl_mmc_do_fs_boot err=0
VI_DEBUG: image entry point: 0x80800000
 b8 0 0 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5

这种情况看起来 MLO 正常启动、但 u-boot.img 无法启动。 VI_debug -为日志添加了前缀(即我们的附加前缀)

MLO 已实现成像入口点:

VI_DEBUG: image entry point: 0x80800000
 b8 0 0 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5

从地址080800000开始的前32个字节为:

b8 0 0 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5

我的  JUMP_TO_IMAGE_NO_ARGS 如下所示:

void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
{
	typedef void __noreturn (*image_entry_noargs_t)(u32 *);
	int i;
	image_entry_noargs_t image_entry =
			(image_entry_noargs_t) spl_image->entry_point;

	u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);

	debug("image entry point: 0x%lX\n", spl_image->entry_point);
	printf("VI_DEBUG: image entry point: 0x%x\n", spl_image->entry_point);
	uint8_t * entry_data = (uint8_t *) spl_image->entry_point;
    for(i = 0; i < 32; i++)
	{
		printf(" %x", (int)entry_data[i]);
	}
	printf("\n");

	/* Pass the saved boot_params from rom code */
	image_entry((u32 *)boot_params);
}

来自控制台的字节与 u-boot.img 内容匹配:

在我这边、我可以得出结论:u-boot.img 已正确加载并且 DDR 可以正常运行(DDR 的设置与2018.01中的设置相同)

我的 u-boot 配置部分:

CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_TARGET_AM335X_WECAT3D=y
CONFIG_MEL_COMMON_CMD_OPTIONS=y
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4030ff00
CONFIG_SF_DEFAULT_SPEED=24000000
CONFIG_DEFAULT_DEVICE_TREE="am335x-mlsl-v11"
CONFIG_AM33XX=y
CONFIG_CLOCK_SYNTHESIZER=y
CONFIG_TIMESTAMP=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SYS_BOOTM_LEN=0x1000000
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_LOGLEVEL=7
CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
CONFIG_BOOTCOMMAND="run findfdt; run init_console; run finduuid; run distro_bootcmd"
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_ARCH_MISC_INIT=y
CONFIG_SPL_SYS_MALLOC=y
CONFIG_SPL_SYS_MALLOC_SIZE=0x800000
CONFIG_SPL_FIT_IMAGE_TINY=y
CONFIG_SPL_ETH=y
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
CONFIG_VERSION_VARIABLE=y
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
CONFIG_AUTOBOOT_DELAY_STR="d"
CONFIG_AUTOBOOT_STOP_STR=" "
#CONFIG_FASTBOOT=y
CONFIG_CMD_SPL=y
CONFIG_ISO_PARTITION=y
CONFIG_MMC_OMAP_HS=y
CONFIG_SPI_FLASH=y
CONFIG_SPI_FLASH_SST=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_PHYLIB=y
CONFIG_SYS_NS16550=y
CONFIG_DRIVER_TI_CPSW=y
CONFIG_DM_PMIC=y
CONFIG_PMIC_TPS65217=y
CONFIG_SPL_POWER_TPS65910=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_OMAP3_SPI=y
CONFIG_LZO=y
CONFIG_SHOW_ERRORS=y
CONFIG_SYS_I2C_SPEED=100000
CONFIG_SYS_I2C_SLAVE=0x1
CONFIG_DM_I2C=y
CONFIG_OF_LIBFDT=y
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_ENV_IS_IN_FAT=y
CONFIG_OF_CONTROL=y
CONFIG_OF_LIST="am335x-evm am335x-bone am335x-sancloud-bbe am335x-sancloud-bbe-lite am335x-sancloud-bbe-extended-wifi am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle am335x-mlsl-v11"
CONFIG_ENV_OVERWRITE=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_SPL_ENV_IS_NOWHERE=y
CONFIG_OF_EMBED=y
CONFIG_ENV_FAT_FILE="uEnv.txt"
CONFIG_LOG=y
CONFIG_SPL_LOG=y
CONFIG_SPL_PAYLOAD="u-boot.img"
CONFIG_CC_OPTIMIZE_FOR_DEBUG=y

附加中的完整 u-boot 配置。

请您提供任何想法和建议、以了解 u-boot_2024这种行为的原因。

提前感谢!

e2e.ti.com/.../u_2D00_boot_5F00_2024.04_5F00_config.txt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    别提了、我们的器件从 SD 卡启动

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    以防我们启用调试控制台

    CONFIG_DEBUG_UART=y
    CONFIG_DEBUG_UART_BASE=0x44e09000
    CONFIG_DEBUG_UART_CLOCK=48000000
    CONFIG_DEBUG_UART_OMAP=y
    CONFIG_DEBUG_UART_SHIFT=2
    CONFIG_DEBUG_UART_ANNOUNCE=y

    控制台中什么都没有。

    初始化 crt0.S 期间似乎发生了错误

    ENTRY(_main)
    
    /* Call arch_very_early_init before initializing C runtime environment. */
    #if CONFIG_IS_ENABLED(ARCH_VERY_EARLY_INIT)
    	bl	arch_very_early_init
    #endif
    
    /*
     * Set up initial C runtime environment and call board_init_f(0).
     */
    
    #if defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_NEEDS_SEPARATE_STACK)
    	ldr	r0, =(CONFIG_TPL_STACK)
    #elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
    	ldr	r0, =(CONFIG_SPL_STACK)
    #else
    	ldr	r0, =(SYS_INIT_SP_ADDR)
    #endif
    	bic	r0, r0, #7	/* 8-byte alignment for ABI compliance */
    	mov	sp, r0
    	bl	board_init_f_alloc_reserve
    	mov	sp, r0
    	/* set up gd here, outside any C code */
    	mov	r9, r0
    	bl	board_init_f_init_reserve
    
    #if defined(CONFIG_DEBUG_UART) && CONFIG_IS_ENABLED(SERIAL)
    	bl	debug_uart_init
    #endif
    
    #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_EARLY_BSS)
    	CLEAR_BSS
    #endif

    问题可能在这里:

    #if defined(CONFIG_DEBUG_UART) && CONFIG_IS_ENABLED(SERIAL)
    	bl	debug_uart_init
    #endif

    堆栈问题可能是因为这个原因吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    最新的 AM335x Linux SDK 版本是 SDK9.3 (u-boot 2023.04)
    https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX - AM335X/09.03.05.02

    我测试了来自 u-boot 2024.04树的内部预构建二进制文件、并且我要在 AM335x EVM 上附加工作的 u-boot 日志以供您参考。
    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tag/?h=10.01.10

    此致!
    -hong

    e2e.ti.com/.../am3_5F00_10.1.10.4.log

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的同事

    感谢您的回答!

    修改后、crt0.S

    #if defined(CONFIG_AM33XX)
       bl setup_clocks_for_console
    #endif

    我获得了调试输出:

    VI_DEBUG: spl_mmc_load spl_mmc_do_fs_boot err=0
    VI_DEBUG: image entry point: 0x80800000
     b8 0 0 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5
    <debug_uart>
    initcall failed at call 808011cd (err=-2)
    ### ERROR ### Please RESET the board ###
    

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    一个选项是将 AM335x EVM"AM335x_EVM_defconfig"的 u-boot defconfig 作为参考。
    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/configs/am335x_evm_defconfig?h=10.01.10&id=82e26e0d6883673bdedbcdb0ddd4bc967ce6ce70
    AM335x EVM 上正常工作的预编译 u-boot 二进制文件是使用 u-boot 2024.04树中的上述 u-boot defconfig 构建的。
    此致!
    -hong

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的同事

    在我这边、我尝试了使用 am335x_evm_defconfig

    加载 u-boot.img 的输出日志如下所示:

    <debug_uart>
    initcall: 80803eb9
    initcall: 8081d325
    VI_DEBUG: fdtdec_setup ENTER
    initcall: 80805735
    initcall: 80803eb5
    initcall: 808040c5
    initcall: 808059fd
    initcall: 80804095
    initcall: 80803ed1
    initcall: event 9/(unknown)
    initcall: 80804099
    initcall: 8080409d
    initcall: 80804031
    VI_DEBUG: initf_dm ENTER
    VI_DEBUG: initf_dm dm_init_and_scan
    VI_DEBUG: dm_init ENTER
    VI_DEBUG: dm_init INIT_LIST_HEAD(DM_UCLASS_ROOT_NON_CONST)
    VI_DEBUG: device_bind_by_name ENTER
    VI_DEBUG: device_bind_by_name info->name root_driver
    VI_DEBUG: lists_driver_lookup_name requested name root_driver n_ents 0
    VI_DEBUG: device_bind_by_name return -2
    VI_DEBUG: dm_init device_bind_by_name() failed: -2
    dm_init() failed: -2
    dm_init() failed: -2
    VI_DEBUG: initf_dm dm_init_and_scan ret -2
    VI_DEBUG: initf_dm bootstage_accum DONE
    VI_DEBUG: initf_dm ret -2
    initcall failed at call 8081eb45 (err=-2)
    ### ERROR ### Please RESET the board ###
    

    期间出现的问题

    静态 int initf_dm (void)

    我在执行函数时遇到错误:

    RET = dm_init_and_scan (true);

    此呼叫位于此处:

    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/common/board_f.c?h=ti-u-boot-2024.04#n831

    在执行期间失败的原因

    RET = dm_init (config_is_enabled (of_live));

    位置

    RET = DEVICE_BIND_BY_NAME (NULL、FALSE、&ROOT_INFO、
    &DM_ROOT_NON_CONST);

    位于:

    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/drivers/core/root.c?h=ti-u-boot-2024.04#n117

    由于缺少名为 root_driver 的元素、因此返回错误

    驱动程序列表为空。

    这种行为的原因可能是什么?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    如果我正确理解了创建根驱动程序节点、该节点负责以下部分代码:

    /* This is the root driver - all drivers are children of this */
    U_BOOT_DRIVER(root_driver) = {
    	.name	= "root_driver",
    	.id	= UCLASS_ROOT,
    	ACPI_OPS_PTR(&root_acpi_ops)
    };
    
    /* This is the root uclass */
    UCLASS_DRIVER(root) = {
    	.name	= "root",
    	.id	= UCLASS_ROOT,
    };

    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/drivers/core/root.c?h=ti-u-boot-2024.04#n441

    但在本例中是 u-boot.img、它不起作用。

    SPL 中的问题可行、我在输出中看到、如下所示:

    debug_uart>
    VI_DEBUG: spl_common_init ENTER
    VI_DEBUG: spl_common_init CONFIG_IS_ENABLED(OF_REAL) 0
    VI_DEBUG: dm_init ENTER
    VI_DEBUG: dm_init INIT_LIST_HEAD(DM_UCLASS_ROOT_NON_CONST)
    VI_DEBUG: device_bind_by_name ENTER
    VI_DEBUG: device_bind_by_name info->name root_driver
    VI_DEBUG: lists_driver_lookup_name requested name root_driver n_ents 9
    VI_DEBUG: lists_driver_lookup_name entry->name blk_partition
    VI_DEBUG: lists_driver_lookup_name entry->name gpio_omap
    VI_DEBUG: lists_driver_lookup_name entry->name i2c_generic_chip_drv
    VI_DEBUG: lists_driver_lookup_name entry->name i2c_omap
    VI_DEBUG: lists_driver_lookup_name entry->name mmc_blk
    VI_DEBUG: lists_driver_lookup_name entry->name ns16550_serial                   
    VI_DEBUG: lists_driver_lookup_name entry->name omap_hsmmc                       
    VI_DEBUG: lists_driver_lookup_name entry->name omap_serial                      
    VI_DEBUG: lists_driver_lookup_name entry->name root_driver            

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    最后我发现了问题的原因。 如前所述、我们将我们的解决方案从 u-boot 2018.01移植到 u-boot 2024.04。 在我们的电路板中、我们使用自定义链接器脚本 u-boot.lds

    在 u-boot 2024.04中

    #define ll_entry_declare(_type, _name, _list)				\
    	_type _u_boot_list_2_##_list##_2_##_name __aligned(4)		\
    			__attribute__((unused))				\
    			__section("__u_boot_list_2_"#_list"_2_"#_name)

    #define ll_entry_declare_list(_type, _name, _list)			\
    	_type _u_boot_list_2_##_list##_2_##_name[] __aligned(4)		\
    			__attribute__((unused,				\
    			section(".u_boot_list_2_"#_list"_2_"#_name)))

    我们在 u-boot 2018.01和 u-boot 2024.04中具有的主要差异 不同的名称 说明 .u_boot_list_2 _ -> 2018.01

    __u_boot_list_2_ -> 2024.04.

    我们使用2018.01中具有旧段名称的链接器脚本。 这是一个很大的错误