[参考译文] DRA829V：从 U-Boot 2023.04升级到2024.04 (续)

您好 Bo、

[引述 userid="551261" url="~/support/processors-group/processors/f/processors-forum/1489151/dra829v-upgrading-from-u-boot-2023-04-to-2024-04-cont alloc space exhausted
Could not get FIT buffer of 1118628 bytes
check CONFIG_SPL_SYS_MALLOC_SIZE[/报价]

我们已经过 R5 SPL 阶段、因此上述情况不应该影响 U-Boot 引导。

您能否再次检查 UART 的 U-Boot 别名是否也像在上一个 E2E 的 R5 SPL 级中那样正确更改。

- Keerthy

尊敬的 Keerthy：

别名也存在于 A72 DTS 中、因此不应该是问题所在。 您还有其他想法吗？

关于"alloc space tilealed"、指示的数字始终大于 tispl.bin 的一个字节：

dfu-util：
下载     [==========================] 100%   1118447字节

日志：
Alloc 空间已用尽
无法获取1118448字节的时基故障缓冲区

我尝试进行调试、但不确定是否发生了重定位。 任何一种调试方式都不显示
有用的信息、似乎指向 vsprintf.c

此致、

/BO

尊敬的 Bo：

我将进入 DFU 专家以检查它是否特定于 DFU、然后在其他引导模式中是否也会出现这种情况？
任何其他运行正常的引导模式？

- Keerthy

尊敬的 Keerthy：

"已用尽的同位空间"得到解决。 我复制并使用了新的 defconfig 文件作为我们自己配置的基础。 它现在工作正常。

引导过程不会超过以下时间：

Trying to boot from DFU
############DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed

由于 DFU 过程用于对串行进行编程、因此我还无法正常尝试引导。

我可以努力将启动文件放入闪存中(首先引导2023.04)并返回给您。

此致、

/BO

尊敬的 Keerthy：

从串行 NOR 引导也不起作用：

U-Boot SPL 2024.04-ti-g9cb01dd3e3e6 (Mar 19 2025 - 15:45:43 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
Trying to boot from SPI
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE:  BL31: Built : 07:57:12, Oct 23 2024
I/TC:
I/TC: OP-TEE version: 4.2.0-dev (gcc version 13.3.0 (GCC)) #1 Tue Oct 22 10:29:57 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check optee.readthedocs.io/.../porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-ti-g9cb01dd3e3e6 (Mar 19 2025 - 15:45:51 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
Trying to boot from SPI
Authentication passed
Authentication passed

我是否需要更新 bl31.bin 文件？ 如果是、如何在 Yocto 中做到这一点？

此致、

/BO

我不知道这是否有帮助、但我还有两个观察结果：

如果我用2023.04启动、最后两个"通过身份验证"行各需要大约1秒。 2024.04年、打印速度非常快。

我可以在 security.c 中打开调试(顶部为#define debug)。 这会在 SPL 阶段给出一些调试打印、但不会在最后两行中显示：

U-Boot SPL 2024.04-ti-g9cb01dd3e3e6 (Mar 20 2025 - 12:12:37 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
TLB table from ffff0000 to ffff4000
Trying to boot from DFU
#######################################################DOWNLOAD ... OK
Ctrl+C to exit ...
board_fit_image_post_process: processing image: addr=70000000, size=54605, os=arm-trusted-firmware
board_fit_image_post_process: matched image for ID 0
board_fit_image_post_process: processing image: addr=9e800000, size=484365, os=tee
board_fit_image_post_process: matched image for ID 1
board_fit_image_post_process: processing image: addr=89000000, size=257628, os=DM
board_fit_image_post_process: matched image for ID 3
Authenticating image at address 0x0000000000000000x
Authenticating image of size 257628 bytes
Authentication passed
board_fit_image_post_process: processing image: addr=80080000, size=301764, os=U-Boot
board_fit_image_post_process: matched image for ID 2
Authenticating image at address 0x0000000000000000x
Authenticating image of size 301764 bytes
Authentication passed
board_fit_image_post_process: processing image: addr=ffffffff, size=15755, os=
Authenticating image at address 0x0000000000000000x
Authenticating image of size 15755 bytes
Authentication passed
Loading Environment from nowhere... OK
init_env from device 18 not supported!
jump_to_image_no_args: Authenticating image: addr=70000000, size=54605, os=arm-trusted-firmware
Authenticating image at address 0x0000000000000000x
Authenticating image of size 54605 bytes
Authentication passed
jump_to_image_no_args: Authenticating image: addr=9e800000, size=484365, os=tee
Authenticating image at address 0x0000000000000000x
Authenticating image of size 484365 bytes
Authentication passed
jump_to_image_no_args: jumping to address 41010000
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE:  BL31: Built : 07:57:12, Oct 23 2024
I/TC:
I/TC: OP-TEE version: 4.2.0-dev (gcc version 13.3.0 (GCC)) #1 Tue Oct 22 10:29:57 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check optee.readthedocs.io/.../porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-ti-g9cb01dd3e3e6 (Mar 20 2025 - 12:12:38 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
Trying to boot from DFU
############DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed

此致、

/BO

再次大家好、

我真的可以在这里得到一些帮助。

当我将调试器连接到挂起状态时、如果似乎卡在"UDF"指令中、则会出现这种情况
将立即导致异常。

/BO

尊敬的 Bo：

对延迟答复的道歉。 您能否检查控制权是传递给 U-Boot、还是该 UDF 发生在 A72 SPL 中？

- Keerthy

尊敬的 Keerthy：

控制权被传递给 U-Boot。 我使用了2024年的三个第一个引导文件、然后成功引导了2023年 u-boot.img

A72 U-Boot 设置中出现问题。 我不知道该怎么办。

/BO

您好 Bo、

由于在启动时很早就会发生这种情况、有一件事值得怀疑、那就是对 U-Boot 映像执行了一些过写操作。 在 U-Boot 执行之前、您是否有调试器转储并读取二进制文件？

由于我们确定 U-Boot 正在挂起、您能否在 U-Boot 的启动时添加一个无限循环并逐步检查它在哪里崩溃？ 如果您想我分享 U-Boot 开始执行的代码、请告诉我。

此致、

Keerthy  

尊敬的 Keerthy：

很好的建议。 如果可以、请告诉我要添加什么内容以及添加位置。

/BO

尊敬的 Bo：

我实际上在办公室外、无法访问我的电路板。

您能否查看下面的 diff、它在 U-Boot 开始处添加了无限大的电流：

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 6cc1d26e..40bf1dc2 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -53,6 +53,8 @@ _bss_end_ofs:
        .quad   __bss_end - _start
 
 reset:
+loop:
+       b loop
        /* Allow the board to save important registers */
        b       save_boot_params
 .globl save_boot_params_ret

您应该连接调试器并将 PC 更新为下一步并中断循环。 然后逐步检查并查看它崩溃的位置。

此外、检查 U-Boot 内容是否位于 tact 中。

- Keerthy

尊敬的 Keerthy：

我这样做是为了使它仅在 A72中停止：

#if !defined(CONFIG_SPL_BUILD)
loop:
b loop
#endif

我正在单步执行 U-Boot 代码、所有看起来都很好、它读取环境变量等 在 string.c 中的 memset 函数中输入137个命中后、我可以继续步进、但由于我不知道它挂起的位置、我可以一直步进。 继续运行会产生挂起、当我按 Ctrl-c 时、我看到的是某个地址的一堆 UDF #0。 请参阅图片：

所有的零点让我想知道这是否与重新分配有关？ 您知道重新分配流程的切入点在哪里、以便我可以尝试在那里突破？

/BO

Bo、

这不是一件好事。 您能否分享工作中的旧 SDK 二进制文件与不工作的最新 SDK 二进制文件中所有3个引导二进制文件的大小？

此致、

Keerthy  

尊敬的 Keerthy：

以下是尺寸差异：

较旧的 SDK：

tiboot3.bin： 277664
sysfw.itb: 269718
tispl.bin: 1113703.
u-boot.img： 1425955

不工作的二进制文件：

tiboot3.bin：284332
sysfw.itb: 269718
tispl.bin: 1130151.
u-boot.img：1494759

在挂起前的瞬间步进显示时钟存在问题、可能是计时器设置存在问题。 我们仅使用一个计时器、因此已在 DTS 中启用一个计时器。 我看到、在 common-proc-board 中根本没有定义计时器。

这是挂起前的调试结果。 您可以看到寄存器 x4为0x0、代码分支到 x4包含的地址：

[0] from 0x00000000808e15f0 in memset+68 at /usr/src/debug/u-boot-ti-as3/2024.04+git/lib/string.c:549
[1] from 0x000000008083d8c4 in calloc+64 at /usr/src/debug/u-boot-ti-as3/2024.04+git/common/dlmalloc.c:2183
[2] from 0x0000000080846664 in device_bind_common+100 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/core/device.c:65
[3] from 0x0000000080847880 in dm_init+52 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/core/root.c:117
─── Threads ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[1] id 0 from 0x00000000808e15f0 in memset+68 at /usr/src/debug/u-boot-ti-as3/2024.04+git/lib/string.c:549
─── Variables ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
arg s = 0x80478060, c = 0, count = 18446744073709551615
loc sl = <optimized out>, s8 = 0x80478108 "\200\201G\200": 128 '\200', cl = <optimized out>, i = <optimized out>
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
>>>

Object@*0x80479a80

serial-uclass.c:56

clk_get_by_index

─── Output/messages ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0x0000000080846020      77              ret = cops->get_freq(sci, clk->id, clk->data, &current_freq);
─── Assembly ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 0x000000008084600c  ti_sci_clk_get_rate+28 ldr x0, [x0]
 0x0000000080846010  ti_sci_clk_get_rate+32 add x3, sp, #0x38
 0x0000000080846014  ti_sci_clk_get_rate+36 ldrb        w2, [x20, #32]
 0x0000000080846018  ti_sci_clk_get_rate+40 ldr w1, [x20, #24]
 0x000000008084601c  ti_sci_clk_get_rate+44 ldr x4, [x0, #232]
 0x0000000080846020  ti_sci_clk_get_rate+48 blr x4
 0x0000000080846024  ti_sci_clk_get_rate+52 cbz w0, 0x808460ac <ti_sci_clk_get_rate+188>
 0x0000000080846028  ti_sci_clk_get_rate+56 mov w19, w0
 0x000000008084602c  ti_sci_clk_get_rate+60 adrp        x5, 0x80910000
 0x0000000080846030  ti_sci_clk_get_rate+64 ldr x0, [x20]
─── Breakpoints ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[11] break at 0x000000008087c850 in /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/serial/serial-uclass.c:56 for serial-uclass.c:56 hit 1 time
[12] break for clk_get_rate hit 2 times
[12.1] at 0x00000000808455bc in /usr/src/debug/u-boot-ti-as3/2024.04+git/include/clk.h:645
[12.2] at 0x00000000808455c8 in /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/clk/clk-uclass.c:471
─── Expressions ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
─── History ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
$$2 = {get_clock = 0x0,idle_clock = 0x0,put_clock = 0x0,is_auto = 0x0,is_on = 0x0,is_off = 0x0,set_parent …
$$1 = 0x0: {ops = {board_ops = {board_config = 0x0,board_config_rm = 0x0,board_config_security = …
$$0 = {ops = {board_ops = {board_config = 0x0,board_config_rm = 0x0,board_config_security = 0x0,board_conf…
─── Memory ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
─── Registers ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
              x0 0x0000000000000000               x1 0x0000000000000023                         x2 0x0000000000000001             x3 0x0000000080477928
              x4 0x0000000000000000               x5 0x000000000000001e                         x6 0x0000000000000c68             x7 0x00000000809508d0
              x8 0x0000000000000c58               x9 0x00000000804776ec                        x10 0x0000000000000003            x11 0x0000000000000c24
             x12 0x0000000000000000              x13 0x00000000809508d0                        x14 0x00000000809508d0            x15 0x0000000080080fa8
             x16 0x0000000080845ff0              x17 0x0000000000000000                        x18 0x0000000080477e10            x19 0x000000008047b198
             x20 0x0000000080477958              x21 0x0000000080933800                        x22 0x000000008047a920            x23 0x000000008092e850
             x24 0x0000000000000012              x25 0x0000000000000000                        x26 0x00000000800c0cea            x27 0x00000000800c0000
             x28 0x00000000800c0cd2              x29 0x0000000080477900                        x30 0x000000008084600c             sp 0x00000000804778f0
              pc 0x0000000080846020             cpsr [ SP=1 EL=2 nRW=0 F I D C Z ]            fpsr 0x00000000                   fpcr 0x00000000
         ELR_EL1 0x0000000000000000          ESR_EL1 0x0000000000000000                   SPSR_EL1 0x0000000000000000        ELR_EL2 0x000000001529ac90
         ESR_EL2 0x0000000000000000         SPSR_EL2 0x0000000000000010                    ELR_EL3 0x0000000000000000        ESR_EL3 0x0000000000000000
        SPSR_EL3 0x0000000000000000
─── Source ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 72      u64 current_freq;
 73      int ret;
 74
 75      debug("%s(clk=%p)\n", __func__, clk);
 76
 77      ret = cops->get_freq(sci, clk->id, clk->data, &current_freq);
 78      if (ret) {
 79          dev_err(clk->dev, "%s: get_freq failed (%d)\n", __func__, ret);
 80          return ret;
 81      }
─── Stack ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[0] from 0x0000000080846020 in ti_sci_clk_get_rate+48 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/clk/ti/clk-sci.c:77
[1] from 0x0000000080881800 in timer_pre_probe+60 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/timer/timer-uclass.c:68
[2] from 0x0000000080848668 in uclass_pre_probe_device+52 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/core/uclass.c:747
[3] from 0x0000000080846b50 in device_probe+140 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/core/device.c:562
[4] from 0x0000000080881958 in dm_timer_init+148 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/timer/timer-uclass.c:153
[5] from 0x00000000808e18a8 in get_ticks+20 at /usr/src/debug/u-boot-ti-as3/2024.04+git/lib/time.c:96
[6] from 0x00000000808e1944 in timer_get_us+16 at /usr/src/debug/u-boot-ti-as3/2024.04+git/lib/time.c:170
[7] from 0x0000000080881bc4 in mbox_recv+48 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/mailbox/mailbox-uclass.c:136
[8] from 0x0000000080855004 in ti_sci_get_response+32 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/firmware/ti_sci.c:178
[9] from 0x0000000080855004 in ti_sci_do_xfer+308 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/firmware/ti_sci.c:273
[+]
─── Threads ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[1] id 0 from 0x0000000080846020 in ti_sci_clk_get_rate+48 at /usr/src/debug/u-boot-ti-as3/2024.04+git/drivers/clk/ti/clk-sci.c:77
─── Variables ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
arg clk = 0x80477958: {dev = 0x80478570,rate = 2157111376,flags = 18,enable_count = 0,id = 35,data = …
loc data = <optimized out>, sci = 0x0: {ops = {board_ops = {board_config = 0x0,board_config_rm = 0x0,board_config_security = …, cops = 0x90: {get_clock = 0x0,idle_clock = 0x0,put_clock = 0x0,is_auto = 0x0,is_on = 0x0,is_off = …, current_freq = 0, ret = <optimized out>, __func__ = "ti_sci_clk_get_rate"

我已经根据 EVM 版本检查、仔细检查并三重检查了所有配置和 DTS：es。 我找不到任何奇怪的东西。 仍然似乎控制台 UART (MAIN_uart0)未正确设置、可能是由于此时钟问题。

/BO

Unknown 说：

我们只使用一个计时器、因此在 DTS 中启用了一个计时器。 我看到

现在我们可以注释掉计时器的使用吗、我们可以检查是否可以运行到 U-Boot？

此致、

Keerthy  

Unknown 说：

现在我们可以注释掉计时器的使用情况、我们能否检查我们是否可以运行到 U-Boot？

恐怕这无助于事。

/BO

Bo、

还不确定这里出了什么问题。 如果您使用最新的 tiboot3.bin、tispl.bin 和使用较旧的 U-Boot.img、它是否工作？

只需隔离可能导致故障的 U-Boot 中的更改。

此致、

Keerthy  

是的、请参阅上面的。 使用最新的 tiboot3.bin 和 tispl.bin +旧的2023.04 uboot.img 进行引导。

/BO

尊敬的 Bo：

您能否在 U-Boot 文件夹中分享您在 SDK 上所做的更改？

我想回顾一下。 您是否已将所有更改从23.04移植到当前版本？

- Keerthy

尊敬的 Keerthy：

我想我找到了这个问题。 "tick-timer"的新设置方式很棘手、而不是采用将"Timer1"声明为&MCU_timer0的旧设置方式。 恢复到旧的方式来声明它已引导 U-Boot 正常：

U-Boot 2024.04-ti-g4bc0ca249954 (2025年4月3日- 14：45：26 +0000)

SoC: J721E SR2.0 HS-FS
Model: Schneider Electric AS-P-3
DRAM: 2 GiB
/drivers/clk/clk-uclass.c:112-clk_get_by_index_tail() prop: returning err=-2

但似乎仍有问题。 以上函数是我之前调试时的结束位置。

至少现在它可以启动、这样我就可以继续前进了。 如果您有任何其他想法、请告诉我、否则我会将此主题标记为"已解决"。

/BO

Unknown 说：

drivers/clk/clk-uclass.c：112-clk_get_by_index_tail ()

一些额外的调试打印将有所帮助。 以上没有多少好处。 很高兴您正在引导至提示符。

此致、

Keerthy

您好、Keerthy、

我"几乎"完成了迁移到 U-Boot 2024.04的更改。 我真的想将我的所有 dts-file 与 ti-branch 中的 dts-file 对齐。

把"clk_get_by_index_tail ()"问题留到现在,我想把注意力集中在 tick-timer 和 mcu_timer0的设置上,这似乎对我不起作用。 当我检查 common-proc-board 的结果 dts 时,它甚至不包含"tick-timer"属性,所以我想知道我缺少什么。

您是否有关于此更改的更多信息？ 我已经看到迹象表明我可能需要确保在 binman 文件中打开防火墙。 此外, 尼哈·弗朗西斯的一份承诺:

"*使用 k3-j721e-mcu-wakeup.dtsi 中定义的 MCU_timer0并删除
timer0、我们现在在 clk-data 中设置其时钟"

您能告诉我这个时钟的设置位置吗？

我通过在 u-boot.dtsi 中添加以下内容来引导它：

&mcu_timer0 {
	status = "okay";
	/delete-property/ clocks;
	/delete-property/ power-domains;
	bootph-all;
};

也许这可以指明您的方向？

此致、

/BO

你好 Keerthy J.

您对上述内容有任何意见吗？

/BO

您好：

Keerthy 不在办公室、但将于4月21日返回、因此请预计回复会延迟。

谢谢。

尊敬的 Bo：

时间部分、如果我们可以恢复到旧 DTS、则应解决此问题。 您要查找的具体内容有哪些？

此致、

Keerthy  

[报价 userid="551261" url="~/support/processors-group/processors/f/processors-forum/1489151/dra829v-upgrading-from-u-boot-2023-04-to-2024-04-cont/5784657 #5784657"]

我不明白这句话。

[/报价]

我的意思是"计时器"而不是时间。 抱歉更正了拼写错误。

[报价 userid="551261" url="~/support/processors-group/processors/f/processors-forum/1489151/dra829v-upgrading-from-u-boot-2023-04-to-2024-04-cont/5784657 #5784657"]

我无法使用从 U-Boot 2024.04生成的文件启动电路板。 u-boot.img 文件使电路板挂起。 下面是一个日志：

[/报价]

我将在内部与 Neha 进行检查、然后回到这个问题上。

- Keerthy

尊敬的 Keerthy：

我想我找到了罪魁祸首。

我们出厂时将 U-Boot 用作测试框架、因此需要驱动时钟脉冲。 内容类型
我们添加的原因：

CONFIG_TIMER=y

从而使电路板无法引导。 删除该配置可解决问题。

如果您有很好的权变措施、因为我们确实需要使用计时器框架创建该脉冲。

此致、

/BO

尊敬的 Keerthy：

您不必为平台创建挂起的脉冲。 只需在 U-Boot 配置中声明 CONFIG_TIMER=y。 平台无法启动。

我已经尝试从 j721e-EVM 构建加载正确的 U-Boot、并打开配置选项、这样也无法引导。 它挂起
在"Authentication Passed"之后。 我想周期计时器会变乱。

是否可以尝试在设置中设置配置并查看是否可以重现它？

此致、

/BO

您好、

请共享补丁。 重写一下类似 EMI 图。 以及您对计时器所做的任何其他 DTS 更改。

- Keerthy

尊敬的 Keerthy：

只需要定义配置。 计时器无其他更改。

--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -204,3 +204,4 @@ CONFIG_UFS=y
 CONFIG_CADENCE_UFS=y
 CONFIG_TI_J721E_UFS=y
 CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_TIMER=y

此致、

Bo

尊敬的 Bo：

对延迟的回复表示歉意。 我认为这会成为问题、因为默认情况下未定义配置。 我将尝试复制,并在下周初回来。  

此致、

Keerthy  

尊敬的 Bo：

正如我们预计的那样、我们会在 R5 SPL 级之后看到挂起：

U-Boot SPL 2024.04-ti-dirty (2025年5月5日- 15：40：26 +0530)
SYSFW ABI：4.0 (固件版本0x000a '10.1.6--v10.01.06 (Fiery Fox)')

由于我们默认情况下不启用 CONFIG_TIMER、因此我们无法捕获此信息。

- Keerthy

尊敬的 Keerthy：

我知道您可以重现我的问题。

是否可以支持 CONFIG_TIMER？ 我们确实需要它来创建
外部芯片的输出脉冲。 在我看来、这是一个非常常见的配置选项
模块。

如果不是、回到定义我们自己的计时器的旧方法来使用是否是一个问题
tick-timer 属性而不是 MCU_timer0？ 能否证实是这样
是这样定义计时器了吗？

此致、

/BO

Unknown 说：

如果不是、回到定义我们自己的计时器的旧方法来使用是否是一个问题
tick-timer 属性而不是 MCU_timer0？ 能否证实是这样
确定以这种方式定义节拍计时器？

如果旧方法是可能的、那么您可以尝试这样做、现在我们的内部 U-Boot 专家已经下班了。
我需要等到下周的时间来检查 CONFIG_TIMER 是否可行。

- Keerthy

尊敬的 Keerthy：

Unknown 说：

如果旧的方法是可能的、那么您可以尝试使用、现在我们的内部 U-Boot 专家已经离职。
我需要等到下周的时间来检查 CONFIG_TIMER 是否可行。

我渴望一些好消息。 您是否有机会研究 CONFIG_TIMER 选项？

此致、

/BO

/Bo、

该团队正在忙于下一个 SDK 版本。 这方面没有进展。 我预计在接下来的几周内不会这样做。
这是一项新要求(不是 SDK 的一部分)、必须完成优先级排序。

- Keerthy

我们目前已被释放、但我不得不重写整个脉冲生成单元、以不使用 DM_TIMER。

长期解决方案非常需要计时器框架才能在 U-Boot 中正常工作。 我觉得奇怪的是,你引入了一个打破它的变化。

/BO