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.

TDA4VE-Q1: TDA4VE-Q1 A72 cpu performance test

Part Number: TDA4VE-Q1
Other Parts Discussed in Thread: TDA4VL

Tool/software:

SDK info: v805

The motherboard tda4vmeco A72 core is configured with a clock speed of 2.0GHz and set to a clock speed of 1.2GHz. When running the same code (basic pure CPU calculations), the clock speed of 1.2GHz is actually slower than that of 2.0GHz.

Here is our test code:

#include <unistd.h>
#include <time.h>
#include <sys/time.h>
#include <stdint.h>
#include <stdio.h>

#include <utils/console_io/include/app_log.h>

static uint64_t getSysClockTimeMsec();
static uint64_t getSysTimeUsec();

int main(int argc, char **argv)
{
    appLogGlobalTimeInit();

    uint64_t i = 0, a = 0;

    uint64_t s = appLogGetGlobalTimeInUsec();

    for (i = 0; i < 100000000; i++) {
        a += i;
    }

    uint64_t e = appLogGetGlobalTimeInUsec();

    printf("======================cost:%lu===========\n", e - s);

    appLogGlobalTimeDeInit();

    return 0;
}

static uint64_t getSysClockTimeMsec()
{
    struct timespec  ts;

    clock_gettime(CLOCK_MONOTONIC, &ts);

    return ((uint64_t)ts.tv_sec * 1000 + ts.tv_nsec / 1000000);
}

static uint64_t getSysTimeUsec()
{
    struct timeval tv;

    gettimeofday(&tv, NULL);

    return (uint64_t)(tv.tv_sec * 1000 * 1000 + tv.tv_usec);
}

Except for the different clock frequency settings, everything else is in the same environment (CPU load idle). As shown in the above code: the operation time from 0 to 100000000 is about 104ms at 2.0GHZ and about 88ms at 1.2GHZ.
Using functions such as appLogGetGlobalTimeInUsec, getSysClockTimeMsec, and getSysTimeUsec to calculate time consumption results is the same, and the results of binding CPU cores to run programs are also consistent.

so why?

  • Hi Weiwei,

    As mentioned in related thread:

    "The values captured do not logically follow expectations as this code should execute faster in proportion to the CPU speed.  This execution proportionality to speed is something we consistently measure in valid tests.   I suspect your tests are not being run over a long enough time and iterations to produce a statistically correct output.  The captured differences are likely just execution time jitter."

    and

    " I ran some quick 'dhrystone' tests and from run to run with periodic back ground disturbances I could see a 30% variation for small runs, this value drop to ~10% when averaged over a longer period."

    Could we get a confirmation if you are seeing the same result for longer periods of time? For example, benchmarks that take 10 seconds instead of 100 ms?

    Regards,

    Takuma

  • Based on the test code above, the result of changing the loop to 10 billion times is consistent with the result of 100 million times:

    The result of running 10 billion times at 2.0 GHz took 10.8 seconds. As shown in the figure below:

    The result of running 10 billion times at 1.2 GHz took 8.8 seconds. As shown in the figure below:

    Test code is also provided, and you can conduct verification testing on your end. Please synchronize the verification testing with us and see how to handle it.

  • Hi Weiwei,

    Test code is also provided, and you can conduct verification testing on your end. Please synchronize the verification testing with us and see how to handle it.

    Sure, is there a Makefile and/or build steps to make the build process easier?

    Regards,

    Takuma

  • apps/basic_demos/ttedate/concerto.mak, at vision_apps, make test

    ifeq ($(TARGET_CPU), $(filter $(TARGET_CPU), x86_64 A72))

    include $(PRELUDE)

    TARGET      := test
    TARGETTYPE  := exe

    CSOURCES    := ttedate.c

    ifeq ($(TARGET_OS),LINUX)
    $(_MODULE)_LOPT += -rpath-link=$(LINUX_FS_PATH)/usr/lib
    $(_MODULE)_LOPT += -rpath-link=$(LINUX_FS_PATH)/lib
    $(_MODULE)_LOPT += -rpath-link=$(LINUX_FS_PATH)/usr/lib/python3.8/site-packages/dlr
    endif

    LDIRS       += $(VISION_APPS_PATH)/out/$(TARGET_SOC)/$(TARGET_CPU)/$(TARGET_OS)/$(TARGET_BUILD)

    STATIC_LIBS += app_utils_console_io
    SYS_SHARED_LIBS += pthread


    include $(FINALE)

    endif
  • Hi Weiwei,

    I tried running the shared sample code as-is, and output fluctuates between cost:1 or cost:2 for both 2GHz and 1.2GHz. 

    root@j721s2-evm:/opt# ./test.out
    ======================cost:1===========
    root@j721s2-evm:/opt#

    How is the measurement times of 104ms and 88ms obtained with the shared sample code at that granularity?

    Regards,

    Takuma

  • How is it possible that executing 10 billion times or 100 million times would take a total of 1 us? Currently, our TI CPU cannot sit in 1 us no matter how fast it is. We seriously suspect that the gtc time obtained from your environment is abnormal. You can use the getSysTimeUsec time obtained from Linux to confirm. Additionally, during execution, you can use time./test.out to obtain the total runtime of test.out.
    Please confirm more here, otherwise communication back and forth will be too slow.

  • Add a screenshot of the 1.2HGZ runtime and include the Linux time command to track the overall runtime。

    1、100 million

    2、10 billion

  • Let's give you the binary file we have compiled, and the time is obtained using Linux

  • Hi Weiwei,

    Sure, please share the binary file.

    Regards,

    Takuma

  • Hi Weiwei,

    I seem to get similar result as you using that binary. Let me check with the broader team on this.

    Regards,

    Takuma

  • Hello Weiwei,

    Seems to be not using the PLL8_SS_CTRL Register bit[0]. Hence some of the frequencies were causing different behaviors:

    Once we set the bit to 0x1 using:


    devmem2 0x688040 w 0x80000001

    Then lower the frequency to 1.2GHz.


    Can you try 1.2GHz and check if the performance is as expected?

    BTW you can use the latest SDK. 8.5 SDK is ~3-4 years old. This behavior is already fixed in the latest SDK.

    - Keerthy

  • Our TDAVMECO test at 1.2GHZ met expectations and was consistent with the TDA4VL test at 1.2GHZ. However, TDAVMECO's 2GHz is slower than 1.2GHZ, which does not meet expectations. Our question is here (please be aware and clarify, and we will take measures to address this issue). Of course, using overclocking at 2.7GHZ for TDAVMECO also makes it faster.
    So, why is TDAVMECO's 2.0GHz slower than 1.2GHz (whether it's ECO's 1.2GHz or TDA4VL's 1.2GHz)

  • You can conduct internal testing and confirmation yourself, which is just a simple 0-10 billion operation, pure CPU operation, 1.2GHz and 2.0GHz testing. After the testing is completed, we will discuss further handling and clarify the problem first. Otherwise, there will be no progress in the process of self doubt.
    For example, the time required to test the following code:


    uint64_t i = 0, a = 0;
    for (i = 0; i < 10000000000; i++) {
    a += i;
    }

  • Hi,

    How did you set the frequency to 1.2GHz?
    On the samples where you see 2GHz is slower than 1.2GHz please check the register 0x688040. My guess is that 1.2G might actually be 2.4G & hence it shows up higher perf than 2 GHz. This is just my theory.

    - Keerthy

  • Okay. We can check the performance with 2.0 GHz and 1.2 GHz.

  • We use the k3conf command of TDA4VL to view or configure the CPU clock speed of A72 core. In addition, we found that the A72 core of TDA4ECO runs slower than the A72 core of TDA4VL, which is why we conducted these tests. Just asked the experts from TI to see where the problem lies. We also hope to address this issue on the 805 SDK version. Please be informed.

  • Hi Weiwei,

    I can confirm that with Keerthy's suggestion to set "devmem2 0x688040 w 0x80000001", the test.out binary acts as expected. That is, at default 2.0 GHz, the "cost" is 10007793, while 1.2 GHz, the cost is 16687739.

    Below are logs:

    root@j721s2-evm:/opt/1323.test# devmem2 0x688040 w 0x80000001
    /dev/mem opened.
    Memory mapped at address 0xffff8a69c000.
    Read at address  0x00688040 (0xffff8a69c040): 0x80000000
    Write at address 0x00688040 (0xffff8a69c040): 0x80000001, readback 0x80000001
    root@j721s2-evm:/opt/1323.test#
    root@j721s2-evm:/opt/1323.test# ^C
    root@j721s2-evm:/opt/1323.test# ^C
    root@j721s2-evm:/opt/1323.test# ls
    test.out
    root@j721s2-evm:/opt/1323.test# ./test.out
    ======================cost:10007793===========
    root@j721s2-evm:/opt/1323.test# k3conf dump clocks | grep -i a72
    |     4     |     0    | DEV_A72SS0_ARM_CLK_CLK                                                            | CLK_STATE_READY     | 2000000000      |
    |     4     |     1    | DEV_A72SS0_MSMC_CLK                                                               | CLK_STATE_READY     | 1000000000      |
    |     4     |     2    | DEV_A72SS0_PLL_CTRL_CLK                                                           | CLK_STATE_READY     | 500000000       |
    |     4     |     6    | DEV_A72SS0_A72_DIVH_CLK8_OBSCLK_OUT_CLK                                           | CLK_STATE_READY     | 0               |
    |   202     |     0    | DEV_A72SS0_CORE0_ARM_CLK_CLK                                                      | CLK_STATE_READY     | 2000000000      |
    |   203     |     0    | DEV_A72SS0_CORE1_ARM_CLK_CLK                                                      | CLK_STATE_READY     | 2000000000      |
    root@j721s2-evm:/opt/1323.test# k3conf set clock 4 0 1200000000
    |-------------------------------------------------------------------------------|
    | VERSION INFO                                                                  |
    |-------------------------------------------------------------------------------|
    | K3CONF | (version 0.3-nogit built Thu Jul 25 14:13:02 UTC 2024)               |
    | SoC    | J721S2 SR1.0                                                         |
    | SYSFW  | ABI: 4.0 (firmware version 0x000b '11.0.9--v11.00.09+ (Fancy Rat))') |
    |-------------------------------------------------------------------------------|
    
    |----------------------------------------------------------------------------------------------------|
    | Device ID | Clock ID | Clock Name                              | Status          | Clock Frequency |
    |----------------------------------------------------------------------------------------------------|
    |     4     |     0    | DEV_A72SS0_ARM_CLK_CLK                  | CLK_STATE_READY | 1200000000      |
    |     4     |     1    | DEV_A72SS0_MSMC_CLK                     | CLK_STATE_READY | 1000000000      |
    |     4     |     2    | DEV_A72SS0_PLL_CTRL_CLK                 | CLK_STATE_READY | 500000000       |
    |     4     |     6    | DEV_A72SS0_A72_DIVH_CLK8_OBSCLK_OUT_CLK | CLK_STATE_READY | 0               |
    |----------------------------------------------------------------------------------------------------|
    
    root@j721s2-evm:/opt/1323.test# ./test.out
    ======================cost:16687739===========
    root@j721s2-evm:/opt/1323.test# uname -a
    Linux j721s2-evm 6.6.44-ti-gd41d875bdfc8-dirty #2 SMP PREEMPT Thu Jul 24 16:10:22 CDT 2025 aarch64 GNU/Linux
    root@j721s2-evm:/opt/1323.test#
    
    

    Other CPU benchmarks like Dhrystone also show similar results where 2.0 GHz does more computation than 1.2 GHz. 

    Regards,

    Takuma

  • HI Takuma Fujiwara  
    So we didn't understand:
    1. What is the function of devmem2 0x688040 w 0x8000001 (setting the PLL8_SS-CTRL register bit [0] to 0x1), and what are the effects if it is not set to 0x1? If this register is also tested with a default value of 0, is the test result consistent with ours?
    2. What is the 1.2GHz register that doubles performance when bit0 is set to 1? And 2.0GHz doesn't work? What is the confirmed real reason?
    3. If the value of the register bit0 for the A72 clock frequency of TDA4VL at 1.2GHz is not set to 1, is it actually running according to 1.2GHz? What impact will it also have?


    Thank you!

  • Hi Weiwei,

    If this register is also tested with a default value of 0, is the test result consistent with ours?

    Yes, test result is consistent as have been observed and described by you. I would recommend you also test out the register write suggested by Keerthy.

    What is the function of devmem2 0x688040 w 0x8000001 (setting the PLL8_SS-CTRL register bit [0] to 0x1), and what are the effects if it is not set to 0x1?

    My understanding is that this affects the divisor value behavior.

    What is the 1.2GHz register that doubles performance when bit0 is set to 1? And 2.0GHz doesn't work? What is the confirmed real reason?

    Without that bit, the divisor value for clocks have a different behavior, causing the final clock to increase instead of decrease when setting to lower frequency. 

    If the value of the register bit0 for the A72 clock frequency of TDA4VL at 1.2GHz is not set to 1, is it actually running according to 1.2GHz? What impact will it also have?

    No, it is running at an overclocked speed, which would explain the higher performance. Even though sysfw/k3conf reports 1.2GHz, the actual frequency measured was 2.4GHz. Hence, some other frequencies like 1GHz, 1.5GHz could cause hang.

    Regards,

    Takuma

  • hi,

    1、As shown in the figure below, we found that after manually writing 1 to the register bit0 (devmem2 0x688040 w 0x8000001), the data will be altered. May I ask what the reason may be?

    2、Additionally, it has been reported that this behavior has been fixed in a higher version of the SDK. I would like to know where the bit0 register was set to 1 (such as sbl)? )Can you give us a patch for the V805 SDK?

  • Hi,

    This bit let's the frequency to be programmed correctly. 

    This was fixed in device manager firmware. Since this was fixed couple of years back we would recommend setting this in Linux.

    Best Regards,

    Keerthy 

  • Hi

    setting this in Linux: so Is it more reasonable to set it in the kernel or during file system startup? Or can it all be done?

    Additionally,As shown in the figure below, we found that after manually writing 1 to the register bit0 (devmem2 0x688040 w 0x8000001), the data will be altered. May I ask what the reason may be?

  • Hi,

    setting this in Linux: so Is it more reasonable to set it in the kernel or during file system startup? Or can it all be done?

    Should be good to set it before your use case starts. Can do it at the beginning of the use case.

     Can you readback and check the register?

    - Keerthy

  • Hi,

    We have confirmed the value of the register through a read back, and also performed read and write operations on 0x688040 using devmem2. After using "devmem2 0x688040 w 0x80000001", the value of the 0x688040 register was restored to 0x80000000. Please see the image we sent below:

  • Hi Keerthy and Weiwei,

    Here was what I was seeing. I was not seeing register value change back after I wrote it in Linux using devmem2.

    Regards,

    Takuma

  • Here was what I was seeing. I was not seeing register value change back after I wrote it in Linux using devmem2.

    Thanks Takuma. That is the same behavior on the other TDA4 SoCs that I have tried in the past.

    - Keerthy

  • Hi,

    I understand, but it did happen during the testing process. So I would like to ask TI experts where the problem may be and where the historical values will be rewritten?
    Our environment is based on the v805 SDK:

  • Hi Weiwei,

    The issue has been identified and fixed for the newer SDKs. Recommendation is to use the latest SDK which will have the most amount of features and bug fixes integrated.

    Other than effort to port, is there a reason for developing on the old SDK?

    Regards,

    Takuma

  • Hi Takuma,

    We understand, but our previous products were developed on V805 and many models have already been mass-produced. If we fully migrate to a higher version of the SDK, the risks and workload will be relatively high. Please be informed that if this issue has been fixed on the new SDK, can you provide us with a patch? Or could you please let us know how we need to fix this issue on V805?

  • Hi Weiwei,

    The fix is to write to the register address 0x688040 with a value of 0x80000001. 

    Proper fix would be to move SDK version. But, if choosing to stay on the old SDK, then the fix is to write to that register. How to implement this write is up to developer, whether it be a write at U-Boot, Linux, kernel driver, userspace application, commandline, etc.

    I would like to make clear that the behavior observed on your system with the devmem2 command not going through is not observed at TI. Below is a log on 5.10 kernel used with v805, and using the default image from the SDK.

    j721s2-evm login:
    j721s2-evm login: root
    root@j721s2-evm:~# uname -a
    Linux j721s2-evm 5.10.153-g90c3a58fd2 #1 SMP PREEMPT Fri Dec 16 07:50:16 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
    root@j721s2-evm:~# ls
    1323.test  1323.test.zip
    root@j721s2-evm:~# cd 1323.test/
    root@j721s2-evm:~/1323.test# ls
    test.out
    root@j721s2-evm:~/1323.test# chmod +x test.out
    root@j721s2-evm:~/1323.test# ./test.out
    ======================cost:10007115===========
    root@j721s2-evm:~/1323.test# k3conf dump clocks | grep -i a72
    |     4     |     0    | DEV_A72SS0_ARM_CLK_CLK                                                            | CLK_STATE_READY     | 2000000000      |
    |     4     |     1    | DEV_A72SS0_MSMC_CLK                                                               | CLK_STATE_READY     | 1000000000      |
    |     4     |     2    | DEV_A72SS0_PLL_CTRL_CLK                                                           | CLK_STATE_READY     | 500000000       |
    |     4     |     6    | DEV_A72SS0_A72_DIVH_CLK8_OBSCLK_OUT_CLK                                           | CLK_STATE_READY     | 0               |
    |   202     |     0    | DEV_A72SS0_CORE0_ARM_CLK_CLK                                                      | CLK_STATE_READY     | 2000000000      |
    |   203     |     0    | DEV_A72SS0_CORE1_ARM_CLK_CLK                                                      | CLK_STATE_READY     | 2000000000      |
    root@j721s2-evm:~/1323.test# k3conf set clock 4 0 1200000000
    |--------------------------------------------------------------------------------|
    | VERSION INFO                                                                   |
    |--------------------------------------------------------------------------------|
    | K3CONF | (version v0.1-64-g48cb8e8 built Fri Dec 16 08:33:21 UTC 2022)         |
    | SoC    | J721S2 SR1.0                                                          |
    | SYSFW  | ABI: 3.1 (firmware version 0x0008 '8.5.2--v08.05.02 (Chill Capybar)') |
    |--------------------------------------------------------------------------------|
    
    |----------------------------------------------------------------------------------------------------|
    | Device ID | Clock ID | Clock Name                              | Status          | Clock Frequency |
    |----------------------------------------------------------------------------------------------------|
    |     4     |     0    | DEV_A72SS0_ARM_CLK_CLK                  | CLK_STATE_READY | 1200000000      |
    |     4     |     1    | DEV_A72SS0_MSMC_CLK                     | CLK_STATE_READY | 1000000000      |
    |     4     |     2    | DEV_A72SS0_PLL_CTRL_CLK                 | CLK_STATE_READY | 500000000       |
    |     4     |     6    | DEV_A72SS0_A72_DIVH_CLK8_OBSCLK_OUT_CLK | CLK_STATE_READY | 0               |
    |----------------------------------------------------------------------------------------------------|
    
    root@j721s2-evm:~/1323.test# ./test.out
    ======================cost:8338646===========
    root@j721s2-evm:~/1323.test# devmem2 0x688040 w 0x80000001
    /dev/mem opened.
    Memory mapped at address 0xffffbbe98000.
    Read at address  0x00688040 (0xffffbbe98040): 0x80000000
    Write at address 0x00688040 (0xffffbbe98040): 0x80000001, readback 0x80000001
    root@j721s2-evm:~/1323.test#
    root@j721s2-evm:~/1323.test# devmem2 0x688040
    /dev/mem opened.
    Memory mapped at address 0xffff8b906000.
    Read at address  0x00688040 (0xffff8b906040): 0x80000001
    root@j721s2-evm:~/1323.test# ./test.out
    [  131.700441] Initializing XFRM netlink socket
    [  133.427973] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
    [  133.447160] Bridge firewalling registered
    [  134.263686] process 'docker/tmp/qemu-check408115674/check' started with executable stack
    ======================cost:16843217===========
    root@j721s2-evm:~/1323.test# k3conf set clock 4 0 2000000000
    |--------------------------------------------------------------------------------|
    | VERSION INFO                                                                   |
    |--------------------------------------------------------------------------------|
    | K3CONF | (version v0.1-64-g48cb8e8 built Fri Dec 16 08:33:21 UTC 2022)         |
    | SoC    | J721S2 SR1.0                                                          |
    | SYSFW  | ABI: 3.1 (firmware version 0x0008 '8.5.2--v08.05.02 (Chill Capybar)') |
    |--------------------------------------------------------------------------------|
    
    |----------------------------------------------------------------------------------------------------|
    | Device ID | Clock ID | Clock Name                              | Status          | Clock Frequency |
    |----------------------------------------------------------------------------------------------------|
    |     4     |     0    | DEV_A72SS0_ARM_CLK_CLK                  | CLK_STATE_READY | 2000000000      |
    |     4     |     1    | DEV_A72SS0_MSMC_CLK                     | CLK_STATE_READY | 1000000000      |
    |     4     |     2    | DEV_A72SS0_PLL_CTRL_CLK                 | CLK_STATE_READY | 500000000       |
    |     4     |     6    | DEV_A72SS0_A72_DIVH_CLK8_OBSCLK_OUT_CLK | CLK_STATE_READY | 0               |
    |----------------------------------------------------------------------------------------------------|
    
    root@j721s2-evm:~/1323.test# ./test.out
    ======================cost:10009196===========
    root@j721s2-evm:~/1323.test# devmem2 0x688040
    /dev/mem opened.
    Memory mapped at address 0xffff9b3c9000.
    Read at address  0x00688040 (0xffff9b3c9040): 0x80000001
    root@j721s2-evm:~/1323.test#
    
    

    In the logs, I run your test application in the following order:

    1. Run test.out with default SDK image, directly after logging in -> cost:10007115
    2. Set clock from 2.0->1.2GHz
    3. Run test.out -> cost:8338646
    4. devmem2 0x688040 w 0x80000001
    5. Run test.out -> cost:16843217
    6. Set clock back to original frequency, by changing from 1.2->2.0GHz
    7. Run test.out -> cost:10009196

    Address 0x688040 value is checked throughout to confirm the value is 0x80000001 after the devmem2 command. And, as you can see, the "cost" reports back as expected after the register write. That is, 1.2/2 = 0.6 = around 10009196/16843217 (0.594256786). Why the write is not sticking on your system is a mystery and not expected behavior. As some suggestion, you may try to write from U-Boot, kernel driver, userspace application, to see if any of the writes stick.

    Regards,

    Takuma

  • HI Takuma,

    We understand that our current test results are consistent with TI's results, provided that after writing 0x8000001 to the 0x688040 register and not rewriting it back to 0x8000001, there is no problem with this.
    But we have learned that if the register bit0 does not write 1, our TDA4VL's 1.2GHz is also running at overclocking 2.4GHz. Therefore, we want to set this register bit0 to 1 for testing. After writing bit0 to 1 through devmem2, we found that sometimes this register is inexplicably rewritten back to the default 0x80000000 (bit0 is automatically cleared). We are not sure where it will be rewritten, so we need to consult experts from TI to help us locate the problem? Provide directions that need to be investigated, etc.

  • Hi Weiwei,

    Two questions:

    1. How often does the register get written back to default value? Is it every time the write is done? Or is it like 1 or 2 times out of 20?
    2. Other than A72 core, what other core is running software on your system?

    My system runs just Linux on the A72 cores and DM on a R5F core to manage the device resource. If there are other cores running on your system, then you should try to disable them to get both of our systems as close as possible to narrow down where issue can be.

    Regards,

    Takuma

  • Hi,Takuma

    Yes, we run MCU1-0 core, MCU2-0/1 core, C7X1/2 core, A72 core. Does the R5F DM referred to here mean on the MCU1-0 core?
    Let's give it a try.

  • Dear Weiwei.

    Does the R5F DM referred to here mean on the MCU1-0 core?

    yes, you are  right.

    Please help follow the suggestion to narrow the issue in your system.

    thanks a lot!

    yong

  • sync on the status.   Please help correct me.

    1. Customer reports the issue on VE, performance @ 2GHz < @1.2GHz, based on SDK8.5.
    2. Customer know that PLL8_SS_CTRL Register bit[0] need be set to 1 when A72 frequency set to 1.2GHz. has fix in latest SDK.
    3. A72 frequency will be overclock to 2.4GHz if PLL8_SS_CTRL Register bit[0] is not set to 1 when A72 frequency set to 1.2GHz.
    4. Customer checked there is similar issue on VL.
    5. Customer has shipped many ECUs w/ TDA4VL to CAR OEM w/ SW based on SDK8.5. They need clear solution w/ verification.
    6. Customer found new problem, PLL8_SS_CTRL Register bit[0] written back to default value sometimes in the way that they are not aware of.

    further actions:

    1. For VE, suggest to upgrade to latest Version SDK.
    2. For VL, suggest to write the bit from U-Boot, kernel driver, userspace application. any question from Customer?
    3. For VL, need Customer try to narrow down which one write back the bit in their system.

    thanks a lot!

    yong

  • Hi Yong and Weiwei,

    3 comments:

    1.

    A72 frequency will be overclock to 2.4GHz if PLL8_SS_CTRL Register bit[0] is not set to 1 when A72 frequency set to 1.2GHz.

    At what point in boot is the frequency being changed for A72 on the customer system? Is it within tiboot3.bin, U-Boot, or Linux?

    2.

    shipped many ECUs w/ TDA4VL to CAR OEM w/ SW based on SDK8.5. They need clear solution w/ verification.

    Are the system that is shipped using a reprogrammed clock, or using the default 2.0 GHz for A72 frequency?

    3.

    How often does the register get written back to default value? Is it every time the write is done? Or is it like 1 or 2 times out of 20?

    Is it possible to get a response to above question? I experimented a couple of times, but have not seen the behavior reported by Weiwei. I would like to know if the register write bouncing is a behavior seen on a rare occasion (and if rare, how rare), or if it is a behavior seen consistently, so that I can determine whether the issue is reproducible or non-reproducible on my system.

    Regards,

    Takuma

  • Customer know that PLL8_SS_CTRL Register bit[0] need be set to 1 when A72 frequency set to 1.2GHz. has fix in latest SDK.

    We were not aware of this e2e before it was mentioned, we were only informed here.

    For VE, suggest to upgrade to latest Version SDK.

    This is quite difficult, and currently we hope to solve the problem encountered on v805.

  • y

    We will modify the v805 SDK wherever it is modified by default, and we will not change this process. In addition, the sbl startup method we use, I understand that the A72 clock frequency is configured in sbl.

  • Dear Diwakar.

    1. for fist point, it should be a problem. there should be two questions for TDA4VL and TDA4VE individually.

    1.1 please note, for the two TDA4VL variants that TTE chooses, TDA4VL21H5AALZRQ1 and TDA4VL21J5AALZRQ1, A72 supports up to 1.2GHz. 

    1.2 For TDA4VL, A72 frequency is 1.2GHz by default. There is no switch process. the questions should be that where to set PLL8_SS_CTRL Register bit[0], tiboot3.bin, U-Boot, or Linux?

    1.3 for TDA4VE, I don't think there is scenario to switch from 2GHz to 1.2GHz. but for debug purpose, the suggestion should be set the big when switching frequency, right?

    2. they used SDK8.5, it should be 2.4GHz as the bit is not set to 1, right?

    Hi Yong and Weiwei,

    3 comments:

    1.

    A72 frequency will be overclock to 2.4GHz if PLL8_SS_CTRL Register bit[0] is not set to 1 when A72 frequency set to 1.2GHz.

    At what point in boot is the frequency being changed for A72 on the customer system? Is it within tiboot3.bin, U-Boot, or Linux?

    2.

    shipped many ECUs w/ TDA4VL to CAR OEM w/ SW based on SDK8.5. They need clear solution w/ verification.

    Are the system that is shipped using a reprogrammed clock, or using the default 2.0 GHz for A72 frequency?

    3.

    How often does the register get written back to default value? Is it every time the write is done? Or is it like 1 or 2 times out of 20?

    Is it possible to get a response to above question? I experimented a couple of times, but have not seen the behavior reported by Weiwei. I would like to know if the register write bouncing is a behavior seen on a rare occasion (and if rare, how rare), or if it is a behavior seen consistently, so that I can determine whether the issue is reproducible or non-reproducible on my system.

    Regards,

    Takuma

    thanks a lot!

    yong

  • Dear Weiwei.

    please help answer this question from Takuma?

    3.

    How often does the register get written back to default value? Is it every time the write is done? Or is it like 1 or 2 times out of 20?

    Is it possible to get a response to above question? I experimented a couple of times, but have not seen the behavior reported by Weiwei. I would like to know if the register write bouncing is a behavior seen on a rare occasion (and if rare, how rare), or if it is a behavior seen consistently, so that I can determine whether the issue is reproducible or non-reproducible on my system.

    thanks a lot!

    yong

  • Dear Weiwei.

    any update? 

    thanks a lot!

    yong