TDA4VEN-Q1: Optimize the system startup time

Hello Cesar,

We can altogether remove the A72 SPL phase as it does not do much. I believe you are using SD card to boot. If you need faster boot you can try ospi boot.

Also do you need U-Boot? Or we can bypass that? 

Best Regards,

Keerthy

Hi Keerthy,

 1. need spl,because it contains wake up core;

 2. using eMMC to boot;

3. need U-boot load Other multi-core heterogeneity(MCU1_0、MCU2_0、C7x)

Regards,

Cesar

Hello Cesar,

The eMMC expert is out for a couple of days. I will loop him. We will get back in a couple of days.

- Keerthy

Hi,

cesar.xu said:

 1. need spl,because it contains wake up core;

A53 SPL is where you are observing the delay. The R5 SPL is stage 1. Then A53 SPL is stage 2.

- Keerthy

Hi Keerthy,

using SD card to boot,there is also a delay issue.

Regards,

Cesar

Hello Cesar,

[2025-09-16 11:37:35.247] U-Boot SPL 2025.01-00566-g935b381a8687-dirty (Aug 22 2025 - 17:26:21 +0530)
[2025-09-16 11:37:35.247] SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')
[2025-09-16 11:37:35.343] ECC is enabled, priming DDR which will take several seconds.
[2025-09-16 11:37:38.575] ECC: priming DDR completed in 3225 msec
[2025-09-16 11:37:38.590] SPL initial stack usage: 17064 bytes
[2025-09-16 11:37:38.591] Trying to boot from MMC1
[2025-09-16 11:37:38.655] Authentication passed
[2025-09-16 11:37:38.655] Authentication passed
[2025-09-16 11:37:38.655] Authentication passed
[2025-09-16 11:37:38.703] Authentication passed
[2025-09-16 11:37:38.703] Authentication passed
[2025-09-16 11:37:38.703] Starting ATF on ARM64 core...
[2025-09-16 11:37:38.703] 
[2025-09-16 11:37:38.703] NOTICE:  BL31: v2.12.0(release):11.00.15-8-ged89d963b
[2025-09-16 11:37:38.718] NOTICE:  BL31: Built : 11:21:32, Aug  6 2025
[2025-09-16 11:37:39.007] 
[2025-09-16 11:37:39.007] U-Boot SPL 2025.01-00566-g935b381a8687-dirty (Aug 22 2025 - 17:26:41 +0530)
[2025-09-16 11:37:39.022] SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')
[2025-09-16 11:37:39.022] DM ABI: 3.0 (firmware ver 0x000b 'MSDK.11.00.00.05+--v11.00.09' patch_ver: 9)
[2025-09-16 11:37:39.071] Trying to boot from MMC1
[2025-09-16 11:37:39.183] Authentication passed
[2025-09-16 11:37:39.198] Authentication passed
[2025-09-16 11:37:40.606] 
[2025-09-16 11:37:40.607] 
[2025-09-16 11:37:40.607] U-Boot 2025.01-00566-g935b381a8687-dirty (Aug 22 2025 - 17:26:41 +0530)
[2025-09-16 11:37:40.607] 
[2025-09-16 11:37:40.607] SoC:   J722S SR1.0 HS-FS
[2025-09-16 11:37:40.607] Model: Texas Instruments J722S EVM
[2025-09-16 11:37:40.607] DRAM:  2 GiB (total 7 GiB)
[2025-09-16 11:37:41.278] Core:  106 devices, 29 uclasses, devicetree: separate
[2025-09-16 11:37:41.278] MMC:   mmc@fa10000: 0, mmc@fa00000: 1
[2025-09-16 11:37:41.294] Loading Environment from nowhere... OK
[2025-09-16 11:37:41.310] In:    serial@2800000
[2025-09-16 11:37:41.310] Out:   serial@2800000
[2025-09-16 11:37:41.310] Err:   serial@2800000
[2025-09-16 11:37:41.310] Net:   eth0: ethernet@8000000port@1
[2025-09-16 11:37:41.342] Hit any key to stop autoboot:  0 

A72 SPL start time: 39.007
A72 U-Boot start time: 40.607

It is taking 1.6 Seconds on the EVM. This is with eMMC boot.

- Keerthy

Hi Keerthy,

[2025-09-16 11:37:39.198] Authentication passed
[2025-09-16 11:37:40.606] 
[2025-09-16 11:37:40.607] 
[2025-09-16 11:37:40.607] U-Boot 2025.01-00566-g935b381a8687-dirty (Aug 22 2025 - 17:26:41 +0530)

Whether it is eMMC boot or sdcard boot, It takes about the same amount of time.

Please shorten this time period.

Regards,

Cesar

Hi Gokul,

spl->uboot, load u-boot.img(1.2MB),Why does it take 1.6 seconds to load this 1.2M in size；

The firmware loading speed of U-Boot is very fast

Regards,

Cesar

Hi Cesar,

This is because even after U-BOOT is loaded to RAM from the boot device, there are a set of device initializations based on the device tree(through the init_sequence_f function)  like the serial console initialization for console logs after which the U-BOOT banner is printed. Hence that time is also included in case of the time you are seeing alongside the UBOOT banner print in addition to the loading time.

Regards

Gokul

Hi Gokul,

What I want to express is why it takes 1.6 seconds to load u-boot.img, while the subsequent u-boot takes less time to load the Image file, which is larger.

Regards,

Cesar

Hi  cesar,

I will look into this and get back toy you.

Regards

Gokul

Hi Gokul,

 Is there any progress?

Regards,

Cesar

Hi cesar,

My apologies for the delay. So after iterating through the code I found out that, the initf_dm function takes approx 722 ms .

This function is responsible for initializing the devices nodes present in the device tree. This is why there is more than 1 sec delay as this function takes major chunk of time. This function  is called in UBOOT before the UBOOT print comes up. Hence it is not the image loading time , but instead it is the initialization time taken based on the devices mentioned in the device tree.

Regards

Gokul

Hi Gokul,

The size of all the dtb files is approximately 100kB. Why does initialization take so long.

Regards,

Cesar

Hi Cesar,

It is not because of the size of the dtb files. But instead, the probe functions of the device nodes present in the device tree will be called thus initializing the devices.

Regards

Gokul

Hi Gokul,

How to optimize the time-consuming issue of dts initialization.

Regards,

Cesar

HI Cesar,

Sorry for the delayed response.

You can optimize that by setting the status to disabled (status = disabled;) in the device tree for the devices you do not want to use.

For eg:

If you are only using eMMC as boot media and do not want to use any other boot media, you can disable other boot medias like SD card and OSPI .

This is just an example.

Regards

Gokul

Hi Gokul,

you said: "It is not because of the size of the dtb files. But instead, the probe functions of the device nodes present in the device tree will be called thus initializing the devices."

However, initializing dts in the Kernel is very fast, while uboot is very slow. What's the difference.

Regards,

Cesar

Hi cesar,

cesar.xu said:

you said: "It is not because of the size of the dtb files. But instead, the probe functions of the device nodes present in the device tree will be called thus initializing the devices."

That is what I was trying to explain earlier.

cesar.xu said:

However, initializing dts in the Kernel is very fast, while uboot is very slow. What's the difference.

This could be due to 2 reasons:

• The nodes initialized in the kernel device tree and uboot device tree would be different.
• The probe function implementation of the driver for a node would be different for kernel and uboot.

Regards

Gokul 

Hi Gokul,

Why don't you reconfirm the essential reason for this 700ms time consumption? It would be best to provide evidence;

The startup time of U-Boot takes about 3 seconds. It has seriously affected the product startup time requirements.

Regards,

Cesar

Hi cesar,

cesar.xu said:

Why don't you reconfirm the essential reason for this 700ms time consumption? It would be best to provide evidence;

I can confirm that this is the reason for the 700ms delay as per my reply given below which I had given earlier.

Gokul Praveen said:

o after iterating through the code I found out that, the initf_dm function takes approx 722 ms .

Regards

Gokul

Hi Gokul,

serial_init is performed after initf_dm, how do you know the duration of this time-consuming process?

Regards,

Cesar

HI Cesar,

I had used a GTC clock and stored the timestamps before and after the initf_dm function in 2 variables. After that I printed the the difference between those 2 variables after the serial_init function was called.

Regards

Gokul

Hi Gokul,

Could you provide the relevant patch? I'm planning to test it myself as well.

Regards,

Cesar

Hi Cesar,

I am attaching the patch for the same below:

diff --git a/common/board_f.c b/common/board_f.c
index 442b8349..296e19ef 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -49,9 +49,13 @@
 #include <dm/root.h>
 #include <linux/errno.h>
 #include <linux/log2.h>
+#include <time.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
+u32 start_time,end_time,time_taken;
 /*
  * TODO(sjg@chromium.org): IMO this code should be
  * refactored to a single function, something like:
@@ -108,6 +112,19 @@ int init_func_watchdog_reset(void)
 }
 #endif /* CONFIG_WATCHDOG */
 
 __weak void board_add_ram_info(int use_default)
 {
        /* please define platform specific board_add_ram_info() */
@@ -201,6 +218,9 @@ static int print_cpuinfo(void)
 
 static int announce_dram_init(void)
 {
+       printf("initf_dm_scan time(in ms):%d ms\n", time_taken);
+
+
        puts("DRAM:  ");
        return 0;
 }
@@ -827,8 +847,12 @@ static int initf_dm(void)
 #if defined(CONFIG_DM) && CONFIG_IS_ENABLED(SYS_MALLOC_F)
        int ret;
 
+       start_time = get_timer(0);
        bootstage_start(BOOTSTAGE_ID_ACCUM_DM_F, "dm_f");
        ret = dm_init_and_scan(true);
+       time_taken = get_timer(start_time);
+;
+
        bootstage_accum(BOOTSTAGE_ID_ACCUM_DM_F);
        if (ret)
                return ret;

Regards

Gokul

Hi Gokul,

The total time consumed here is 1.2 seconds, among which the dm scan takes up 372 ms;

Could you also analyze which other modules consume the most time?

Regards,

Cesar

Hi cesar,

You can try doing the same on other modules and you will be able to  get the time.

Regards

Gokul

Hi Gokul,

It was confirmed that the serial_init process took more than 700 milliseconds.

Hi cesar,

Sorry for the late reply.

This is what serial_init does. It initializes the serial device which might be taking more time.

Regards

Gokul

Hi Gokul,

Could you please help check why the initialization of the serial port takes so long?

Regards,

Cesar

Hi cesar,

The serial port is taking long because of setting up the registers and enabling clocks as mentioned in the function comments.

Regards

Gokul

Hi Gokul,

1.Which function is particularly time-consuming? Can it be optimized；

2.Or, could the serial port be turned off and logs not be printed? The purpose is just to enable the system to start normally

Regards,

Cesar

Hi cesar,

cesar.xu said:

1.Which function is particularly time-consuming? Can it be optimized；

No, this cannot be optimized as it is the hardware initialization time.

Regards

Gokul

Hi Gokul,

    could the serial port be turned off, The purpose is just to enable the system to start normally;

Regards,

Cesar

Hi cesar,

You can try that, but you will not be able to see the serial console logs if you do so.

Regards

Gokul