• State TI Thinks Resolved
  • Locked Locked
  • Replies 42 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1151 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DRA829V: Boot problems going from 2023.04 to 2024.04

DRA829V: Upgrading from U-Boot 2023.04 to 2024.04 cont.

Bo Mellberg
Intellectual 571 points
Part Number: DRA829V

Tool/software:

Hi experts,

After solving the previous issue with the serial console for the early stages of booting, I am now stuck
at what I believe is the point where the A72 is about to start the main U-Boot process.

Here is the boot log:

U-Boot SPL 2024.04-ti-gea67cbeaca21 (Mar 18 2025 - 14:34:00 +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 ...
alloc space exhausted
Could not get FIT buffer of 1118628 bytes
        check CONFIG_SPL_SYS_MALLOC_SIZE
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 18 not supported!
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 https://optee.readthedocs.io/en/latest/architecture/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-gea67cbeaca21 (Mar 18 2025 - 14:34:08 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
The value of PLL8_SS_CTRL register 0x80000001
The value of PLL7_SS_CTRL register 0x80000001
Successfully set the A72 clock frequency to 1000000000
Successfully set the MSMC clock frequency to 500000000
Trying to boot from DFU
############DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed

What worries me is the warning about not enough space for the FIT buffer:

alloc space exhausted
Could not get FIT buffer of 1118628 bytes
check CONFIG_SPL_SYS_MALLOC_SIZE

Could this be that the large u-boot FIT image does not fit and therefore cannot be started?

The U-Boot fit image (u-boot-asp3-hs-fs.img) looks like this:

FIT description: FIT image with multiple configurations
Created:         Tue Mar 18 16:43:06 2025
 Image 0 (uboot)
  Description:  U-Boot for asp3 board
  Created:      Tue Mar 18 16:43:06 2025
  Type:         Firmware
  Compression:  uncompressed
  Data Size:    1358444 Bytes = 1326.61 KiB = 1.30 MiB
  Architecture: ARM
  OS:           U-Boot
  Load Address: 0x80800000
  Hash algo:    crc32
  Hash value:   91759ad8
 Image 1 (fdt-dev)
  Description:  k3-j721e-asp3
  Created:      Tue Mar 18 16:43:06 2025
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    113102 Bytes = 110.45 KiB = 0.11 MiB
  Architecture: ARM
  Hash algo:    crc32
  Hash value:   beda69a1
 Default Configuration: 'conf-0'
 Configuration 0 (conf-0)
  Description:  k3-j721e-asp3
  Kernel:       unavailable
  Firmware:     uboot
  FDT:          fdt-dev
  Loadables:    uboot

I have tried to increase the SPL_SYS_MALLOC_SIZE by enabling these configs:

# Enable SPL MALLOC SIZE
CONFIG_SPL=y
CONFIG_SPL_SYS_MALLOC=y
CONFIG_SPL_SYS_MALLOC_SIZE=0x200000
But if I do that, the board won't boot:
U-Boot SPL 2024.04-ti-gea67cbeaca21 (Mar 18 2025 - 14:27:19 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')
Trying to boot from DFU
How can I move further?
Regards,
/Bo
  • 0
    TI__Guru**** 163510 points

    Hello Bo,

    Bo Mellberg said:
    alloc space exhausted
    Could not get FIT buffer of 1118628 bytes
    check CONFIG_SPL_SYS_MALLOC_SIZE

    We are past the R5 SPL stage so the above should not be impacting the U-Boot boot.

    Can you double check if the U-Boot alias for UART is also changed correctly like you did in the previous E2E for R5 SPL stage.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    The alias is present in the A72 dts as well so that shouldn't be the issue. Do you have any other ideas?

    Regarding the "alloc space exhausted", the number indicated is always one byte larger than the tispl.bin:

    dfu-util:
    Download        [=========================] 100%      1118447 bytes

    Log:
    alloc space exhausted
    Could not get FIT buffer of 1118448 bytes

    I tried do debug but I am unsure if relocation has taken place or not. Either way debugging doesn't show any
    useful info, seemingly pointing to vsprintf.c

    Regards,

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hi Bo,

    I will loop in the DFU expert to check if that is specific to DFU before that Is this also seen on other boot modes?
    Any other boot modes that are working fine?

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    The "alloc space exhausted" is solved. I copied and used the new defconfig files as a base for our own configs. It works fine now.

    The boot will still not go further than:

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

    Since the DFU process is where we program the serial nor I have not yet been able to try booting normally.

    I can make an effort in getting the boot files into flash (by booting 2023.04 first) and get back to you.

    Best regards,

    /Bo

  • 0 in reply to Bo Mellberg
    Intellectual 571 points

    Hi Keerthy,

    Booting from serial nor doesn't work either:

    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 https://optee.readthedocs.io/en/latest/architecture/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

    Do I need to update the bl31.bin file? If so, how do I do that in yocto?

    Best regards,

    /Bo

  • 0 in reply to Bo Mellberg
    Intellectual 571 points

    I don't know if it is any help but I have two additional observations:

    If I boot with 2023.04, the last two "Authentication passed" lines takes about 1 second each. In 2024.04 the are very quickly printed out.

    I can turn debug on in security.c (#define DEBUG at the top). That gives me some debug prints in the SPL stages, but not for the last two lines:

    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 https://optee.readthedocs.io/en/latest/architecture/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

    Regards,

    /Bo

  • 0 in reply to Bo Mellberg
    Intellectual 571 points

    Hi again,

    I could really use some help here.

    As I attach my debugger in the hanged state, if seems to be stuck at an "udf" instruction, which
    would immediately lead to an exception.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hi Bo,

    Apologies for responding late. Can you check if the control is passed to U-Boot or this udf happens in A72 SPL?

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    Control is passed to U-Boot. I have used the 2024 three first boot files and then successfully booted a 2023 u-boot.img

    Something is wrong in the A72 U-Boot setup. I can't figure out what.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hello Bo,

    Since this is happening so early at the boot, one thing is suspect is some over write of U-Boot image. Do you have a debugger to dump back and read the binary just before U-Boot execution?

    Since we are sure that U-Boot is hanging can you add an infinite loop at the starting of U-Boot and step through to see where it's crashing? Let me know if you want me to share the code where U-Boot starts execution.

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    Good suggestion. If you could, please let me know what to add and where.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hi Bo,

    I am actually out of office & not having access to my boards.

    Can you take a look at the diff below that adds an infinite while right at the beginning of the 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

    You should connect debugger & update PC to next and break the loop. Then step through & see where it crashes.

    Also check if the U-Boot contents are in tact.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    I did this to make it stop only in the A72:

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

    I am stepping the U-Boot code and everything seems to be fine, it reads environmental variables etc etc. After 137 hits in the memset function in string.c, I can continue stepping but since I don't know where it hangs I could step forever. Continuing the run creates the hang, and when I ctrl-c all I see is a bunch of udf #0 at a certain address. See picture:

    All the zeros makes me wonder if this has something to do with reallocation? Do you know where the entry point for the reallocation process is so I can try to break there?

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Bo,

    Understood so this is not helping. Can you share the sizes of all the 3 boot binaries in the working older SDK vs non working latest SDK binaries?

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    Here are the size differences:

    Older SDK:

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

    Non-working binaries:

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

    Stepping at the very en before hang shows that there is a problem with clocks, perhaps with the timers setup. We only use one timer, so that one has been enabled in our dts. I see that in the common-proc-board, there are no timers defined at all.

    Here is the debug just before hang. You see that register x4 is 0x0 and the code branches to the address that x4 contains:

    [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"

    I have checked, double checked and triple checked all configs and dts:es against the evm versions. I can't find anything strange. Still it seems that the console uart (main_uart0) is not being setup properly, perhaps because of this clock issue.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points
    Bo Mellberg said:
    We only use one timer, so that one has been enabled in our dts. I see

    For now can we comment out the timer usage and can we check if we can run to U-Boot?

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Intellectual 571 points
    Keerthy J said:
    For now can we comment out the timer usage and can we check if we can run to U-Boot?

    I'm afraid that didn't help.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Bo,

    Still not sure what's going wrong here. If you use the latest tiboot3.bin, tispl.bin and use older U-Boot.img does it work?

    Just want to isolate the changes in U-Boot that can cause the failure.

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Yes, see above. Booting with latest tiboot3.bin and tispl.bin + an old 2023.04 uboot.img works.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hi Bo,

    Could you share the changes you have made on top of the SDK in the U-Boot folder?

    I want to review them. Have you ported all of the changes from 23.04 to current one?

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    I think I found the problem. There is something fishy with the new way the "tick-timer" is setup to &mcu_timer0 instead of the old way which declared a "timer1". Reverting to the old way of declaring it booted the U-Boot proper:

    U-Boot 2024.04-ti-g4bc0ca249954 (Apr 03 2025 - 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

    There still seems to be something wrong though. The above function is where I was ending up when debugging earlier.

    At least now it boots so I can go forward. If you have any more ideas please let me know, otherwise I'll mark this thread as resolved.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points
    Bo Mellberg said:
    drivers/clk/clk-uclass.c:112-clk_get_by_index_tail()

    Some additional debug prints will help. The above does not give much. Glad that you are booting to prompt.

    Best Regards,

    Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hello Keerthy,

    I am "almost" finished with my changes to move to U-Boot 2024.04. I really want to align all my dts-files to the ones in the ti-branch.

    Leaving the "clk_get_by_index_tail()" problem for now, I want to focus on the tick-timer and setup of mcu_timer0 that doesn't seem to work for me. When I inspect the resulting dts for the common-proc-board it doesn't even contain the "tick-timer" property, so I wonder what I am missing.

    Do you have any more information about this change? I have seen indications that I might need to make sure that firewalls are being opened in the binman-files. Also, a commit by :

    "* Use mcu_timer0 defined in k3-j721e-mcu-wakeup.dtsi and remove
    timer0, we have its clocks set up in clk-data now"

    Can you point me to where this clock is set up?

    I have been able to get it booting by adding this in my u-boot.dtsi:

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

    Maybe that can point you in some direction?

    Best regards,

    /Bo

  • 0 in reply to Bo Mellberg
    Intellectual 571 points

    Hello .

    Do you any any input on the above?

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Mastermind 48253 points

    Hello,

    Keerthy is out of the office but will return on April 21st, so please expect a delayed response.

    Thanks.

  • 0 in reply to Praveen Rao
    TI__Guru**** 163510 points

    Hi Bo,

    The time part if we can revert to old dts then that should take care of the issue. Anything specific that you are looking for?

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    Keerthy J said:
    The time part if we can revert to old dts then that should take care of the issue.

    I don't understand this sentence.

    I can't boot my board with the files produced from U-Boot 2024.04. The u-boot.img file makes the board hang. Here is a log:

    U-Boot SPL 2024.04-ti-g67b43ee6d423 (Apr 23 2025 - 08:16:10 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
Trying to boot from DFU
########################################################DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 18 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.0(release):11.00.05-5-g2ae655f0f-dirty
NOTICE:  BL31: Built : 12:42:48, Mar 26 2025
I/TC:
I/TC: OP-TEE version: 4.5.0-73-gef1ebdc23-dev (gcc version 13.3.0 (GCC)) #1 Wed Mar 26 12:42:53 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/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 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
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: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-ti-g67b43ee6d423 (Apr 23 2025 - 08:16:11 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
Trying to boot from DFU
############DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed

... Hanged forever

    Here is a boot log when I have enabled #define LOG_DEBUG in clk_uclass.c:

    U-Boot SPL 2024.04-ti-g67b43ee6d423 (Apr 23 2025 - 08:06:46 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
clk_set_defaults(temperature-sensor@42040000)
clk_set_default_parents: could not read assigned-clock-parents for 41c86784
clk_set_defaults(wkup-i2c0-default-pins)
clk_set_default_parents: could not read assigned-clock-parents for 41c85e2c
clk_set_defaults(i2c@42120000)
clk_set_default_parents: could not read assigned-clock-parents for 41c861a8
clk_set_defaults(tps659413a@48)
clk_set_default_parents: could not read assigned-clock-parents for 41c8631c
clk_set_defaults(buck123)
clk_set_default_parents: could not read assigned-clock-parents for 41c8637c
clk_set_defaults(memorycontroller@0298e000)
clk_set_default_parents: could not read assigned-clock-parents for 41c871b4
clk_request(dev=41c85c10, clk=41cdc2a8)
clk_request(dev=41c85c10, clk=41cdc2c8)
clk_get_rate(clk=41cdc2c8)
clk_get_rate(clk=41c88780)
clk_get_parent_rate(clk=41c88780)
clk_get_parent(clk=41c88780)
clk_set_rate(clk=41cdc2a8, rate=19200000)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8cc80)
clk_get_parent_rate(clk=41c8cc80)
clk_get_parent(clk=41c8cc80)
clk_get_rate(clk=41c8a1c0)
clk_get_parent_rate(clk=41c8a1c0)
clk_get_parent(clk=41c8a1c0)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8d400, rate=19200000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41cdc2a8, rate=533000000)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8d400, rate=533000000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8cc80, rate=1066000000)
clk_get_parent_rate(clk=41c8cc80)
clk_get_parent(clk=41c8cc80)
clk_get_parent_rate(clk=41c8cc80)
clk_get_parent(clk=41c8cc80)
clk_set_rate(clk=41c8d400, rate=533000000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8cc80)
clk_get_parent_rate(clk=41c8cc80)
clk_get_parent(clk=41c8cc80)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41cdc2a8, rate=19200000)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8d400, rate=19200000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41cdc2a8, rate=533000000)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8d400, rate=533000000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41cdc2a8, rate=533000000)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8d400, rate=533000000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41cdc2a8, rate=533000000)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8d400, rate=533000000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41cdc2a8, rate=533000000)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_rate(clk=41c8d400, rate=533000000)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_get_rate(clk=41c8d400)
clk_get_parent_rate(clk=41c8d400)
clk_get_parent(clk=41c8d400)
clk_set_defaults(esm@700000)
clk_set_default_parents: could not read assigned-clock-parents for 41c8714c
clk_set_defaults(esm@40800000)
clk_set_default_parents: could not read assigned-clock-parents for 41c867d4
clk_set_defaults(esm)
clk_set_default_parents: could not read assigned-clock-parents for 41c8641c
Trying to boot from DFU
clk_set_defaults(usb@6000000)
clk_set_default_parents: could not read assigned-clock-parents for 41c8703c
########################################################DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed
Authentication passed
clk_set_defaults(wkup-gpio-pins-default)
clk_set_default_parents: could not read assigned-clock-parents for 41c85ecc
clk_set_defaults(gpio@42110000)
clk_set_default_parents: could not read assigned-clock-parents for 41c86134
clk_set_defaults(a72@0)
clk_set_default_parents: could not read assigned-clock-parents for 41c87204
clk_get_by_indexed_prop(dev=41c87204, index=0, clk=81fffe40)
clk_request(dev=41c85c10, clk=81fffe40)
clk_set_default_get_by_id(): could not get parent clock pointer, id 95
clk_set_rate(clk=81fffe40, rate=2000000000)
clk_get_rate(clk=41c8d640)
clk_get_parent_rate(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_get_rate(clk=41c8cbc0)
clk_get_parent_rate(clk=41c8cbc0)
clk_get_parent(clk=41c8cbc0)
clk_get_rate(clk=41c8ad00)
clk_get_parent_rate(clk=41c8ad00)
clk_get_parent(clk=41c8ad00)
clk_get_rate(clk=41c8d640)
clk_get_parent_rate(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_set_rate(clk=41c8d640, rate=2000000000)
clk_get_parent_rate(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_get_rate(clk=41c8d640)
clk_get_parent_rate(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_set_rate(clk=41c8cbc0, rate=2000000000)
clk_get_parent_rate(clk=41c8cbc0)
clk_get_parent(clk=41c8cbc0)
clk_get_parent_rate(clk=41c8cbc0)
clk_get_parent(clk=41c8cbc0)
clk_set_rate(clk=41c8d640, rate=2000000000)
clk_get_parent_rate(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_get_rate(clk=41c8cbc0)
clk_get_parent_rate(clk=41c8cbc0)
clk_get_parent(clk=41c8cbc0)
clk_get_rate(clk=41c8d640)
clk_get_parent_rate(clk=41c8d640)
clk_get_parent(clk=41c8d640)
clk_get_by_indexed_prop(dev=41c87204, index=1, clk=81fffe40)
clk_request(dev=41c85c10, clk=81fffe40)
clk_set_default_get_by_id(): could not get parent clock pointer, id 155
clk_set_rate(clk=81fffe40, rate=200000000)
clk_get_rate(clk=41c8ed80)
clk_get_parent_rate(clk=41c8ed80)
clk_get_parent(clk=41c8ed80)
clk_get_rate(clk=41c8e480)
clk_get_parent_rate(clk=41c8e480)
clk_get_parent(clk=41c8e480)
clk_get_rate(clk=41c8c8c0)
clk_get_parent_rate(clk=41c8c8c0)
clk_get_parent(clk=41c8c8c0)
clk_get_rate(clk=41c8ed80)
clk_get_parent_rate(clk=41c8ed80)
clk_get_parent(clk=41c8ed80)
clk_get_parent(clk=41c8ed80)
clk_get_rate(clk=41c8e480)
clk_get_parent_rate(clk=41c8e480)
clk_get_parent(clk=41c8e480)
clk_get_rate(clk=41c8e480)
clk_get_parent_rate(clk=41c8e480)
clk_get_parent(clk=41c8e480)
clk_set_rate(clk=41c8e480, rate=200000000)
clk_get_parent_rate(clk=41c8e480)
clk_get_parent(clk=41c8e480)
clk_get_rate(clk=41c8e480)
clk_get_parent_rate(clk=41c8e480)
clk_get_parent(clk=41c8e480)
clk_request(dev=41c85c10, clk=84000410)
clk_set_defaults(reset-controller)
clk_set_default_parents: could not read assigned-clock-parents for 41c85c78
Loading Environment from nowhere... OK
init_env from device 18 not supported!
clk_get_rate(clk=84000410)
clk_get_rate(clk=41c8ed80)
clk_get_parent_rate(clk=41c8ed80)
clk_get_parent(clk=41c8ed80)
clk_get_rate(clk=41c8e480)
clk_get_parent_rate(clk=41c8e480)
clk_get_parent(clk=41c8e480)
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.0(release):11.00.05-5-g2ae655f0f-dirty
NOTICE:  BL31: Built : 12:42:48, Mar 26 2025
I/TC:
I/TC: OP-TEE version: 4.5.0-73-gef1ebdc23-dev (gcc version 13.3.0 (GCC)) #1 Wed Mar 26 12:42:53 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/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 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
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: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-ti-g67b43ee6d423 (Apr 23 2025 - 08:06:48 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
Trying to boot from DFU
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)
/drivers/clk/clk-uclass.c:387-clk_set_defaults() clk_set_defaults(main-usbss0-pins-default)

... repeats forever

    With the debug on, I don't even get to the part where it waits for the u-boot.img file. It just repeats the last line forever.

    As I said above, if I add this to my k3-j721e-u-boot.dtsi:

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

    the board boots, but there are clock errors that makes me suspect that the clocks are not setup properly. This is the boot log:

    U-Boot SPL 2024.04-ti-g67b43ee6d423 (Apr 23 2025 - 08:21:13 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
Trying to boot from DFU
########################################################DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 18 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.0(release):11.00.05-5-g2ae655f0f-dirty
NOTICE:  BL31: Built : 12:42:48, Mar 26 2025
I/TC:
I/TC: OP-TEE version: 4.5.0-73-gef1ebdc23-dev (gcc version 13.3.0 (GCC)) #1 Wed Mar 26 12:42:53 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/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 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
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: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-ti-g67b43ee6d423 (Apr 23 2025 - 08:21:15 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.4--v11.00.04+ (Fancy Rat)')
Trying to boot from DFU
############DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed


U-Boot 2024.04-ti-g67b43ee6d423 (Apr 23 2025 - 08:21:15 +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
Core:  173 devices, 39 uclasses, devicetree: separate
MMC:   mmc@4f80000: 0
Loading Environment from SPIFlash... /drivers/mtd/spi/spi-nor-core.c:4001-  spi_nor_soft_reset() jedec_spi_nor flash@0: Software reset enable failed: -524
/drivers/soc/ti/k3-navss-ringacc.c:1020- k3_nav_ringacc_init() k3-navss-ringacc ringacc@2b800000: Ring Accelerator probed rings:286, gp-rings[96,20] sci-dev-id:235
/drivers/soc/ti/k3-navss-ringacc.c:1025- k3_nav_ringacc_init() k3-navss-ringacc ringacc@2b800000: dma-ring-reset-quirk: disabled
/drivers/spi/cadence_qspi.c:1599-cadence_spi_mem_do_calibration() cadence_spi spi@47050000: Pattern not found. Skipping calibration
SF: Detected w25q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
/drivers/net/ti/am65-cpsw-nuss.c:791-am65_cpsw_probe_nuss() am65_cpsw_nuss ethernet@c000000: K3 CPSW: nuss_ver: 0x6BA01901 cpsw_ver: 0x6BA80101 ale_ver: 0x00294104 Ports:8
/drivers/clk/clk-uclass.c:112-clk_get_by_index_tail() prop: returning err=-2
/drivers/clk/clk-uclass.c:112-clk_get_by_index_tail() prop: returning err=-2
/drivers/clk/clk-uclass.c:91-clk_get_by_index_tail() get: returning err=-19
Sierra init failed:-19
Net:
Warning: ethernet@c000000port@1 (eth2) using random MAC address - 96:5f:6a:24:7e:e0
eth2: ethernet@c000000port@1
Warning: ethernet@c000000port@3 (eth0) using random MAC address - 4a:89:b3:b9:36:d0
, eth0: ethernet@c000000port@3
Warning: ethernet@c000000port@4 (eth1) using random MAC address - 6e:c5:57:8d:cb:60
, eth1: ethernet@c000000port@4
Hit any key to stop autoboot:  0
=>

    Regards,

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points
    Bo Mellberg said:

    I don't understand this sentence.

    I meant 'timer' instead of time. Sorry for the typo.

    Bo Mellberg said:

    I can't boot my board with the files produced from U-Boot 2024.04. The u-boot.img file makes the board hang. Here is a log:

    I will check internally with Neha and get back on this.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    I think I found the culprit.

    We use U-Boot as a test framework in factory and therefore need to drive a clock pulse. For that
    reason we have added:

    CONFIG_TIMER=y

    in the U-Boot config, which makes the board not boot. Removing that config resolves the problem.

    If you have a workaround that would be great, since we really need to create that pulse using the timers framework.

    Best regards,

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Bo,

    This is something best checked with U-Boot list.
    u-boot@lists.denx.de

    We do not use the U-boot timer framework to create the pulse.


    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    You don't have to create a pulse for the platform to hang. Just declare CONFIG_TIMER=y in U-Boot config. The platform won't boot.

    I have tried to load the U-Boot proper from the j721e-evm build with the config option turned on and that won't boot either. It hangs
    after "Authentication passed". My guess is that the tick-timer is messed up.

    Could you try to set the config on your setup and see if you can reproduce it?

    Best regards,

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hi,

    Please share the patch. I will try to reproduce on the EVM. Also any other dts changes that you did for timers.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    You just need to define the config. No other changes for timers.

    --- 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

    Regards,

    Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hi Bo,

    Apologies for the delayed response. I believe this will be as issue as the config is not defined by default. I will try reproducing and get back early next week. 

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    TI__Guru**** 163510 points

    Hi Bo,

    Like we anticipated we see a hang after R5 SPL stage:

    U-Boot SPL 2024.04-ti-dirty (May 05 2025 - 15:40:26 +0530)
    SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.6--v10.01.06 (Fiery Fox)')

    Since we do not enable CONFIG_TIMER by default we cannot catch this.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    I understand that you can reproduce my problem.

    Is there any chance that you can support CONFIG_TIMER? We really need it to create
    an output pulse for an external chip. In my opinion it is a config option that is quite commonly
    used.

    If not, would it be a problem to go back to the old way of defining a timer of our own to be used
    for the "tick-timer" property instead of the mcu_timer0? Could you confirm that it would be
    ok to define the tick-timer that way?

    Best regards,

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points
    Bo Mellberg said:
    If not, would it be a problem to go back to the old way of defining a timer of our own to be used
    for the "tick-timer" property instead of the mcu_timer0? Could you confirm that it would be
    ok to define the tick-timer that way?

    If the old way is possible then you could try that, Right now our internal U-Boot expert is out of office.
    I need time till next week to check if the CONFIG_TIMER is a possibility.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    Hi Keerthy,

    Keerthy J said:
    If the old way is possible then you could try that, Right now our internal U-Boot expert is out of office.
    I need time till next week to check if the CONFIG_TIMER is a possibility.

    I'm craving some good news. Have you had a chance to investigate the CONFIG_TIMER option?

    Regards,

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    /Bo,

    The team is busy with the next SDK release. No progress on this. I anticipate this will not be done in the next couple of weeks.
    This is a new requirement(Not part of the SDK) and prioritization has to be done.

    - Keerthy

  • 0 in reply to Keerthy J
    TI__Guru**** 163510 points

    Bo,

    This is still not part of SDK. I want to check if this is needed as part of SDK? Or you are unblocked?

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 571 points

    We are unblocked at the moment but I had to rewrite our whole pulse generation unit to not use DM_TIMER.

    For a long term solution we are very much in need of the TIMER framework to be functional in U-Boot. I find it strange that you introduced a change that broke it.

    /Bo

  • 0 in reply to Bo Mellberg
    TI__Guru**** 163510 points

    Hello Bo,

    I have raised an internal requirement for this. This will be implemented in one of the next SDKs.

    Closing this thread as this is not part of the SDK yet.

    - Keerthy