J784S4XEVM: Clock Frequency Configuration

Hi,

The clock settings for the A72 core can be viewed using the k3conf utility, which will be available as part the filesystem if following the TI SDK build process.   Please check the clock settings using this utility as below

• k3conf --help
• k3conf dump clocks
• k3conf dump clocks | grep ARM0_CLK_CLK

Output from 'k3conf dump clocks | grep ARM0_CLK_CLK', should show 2,000,000,000.

If tick count is not aligning to expectations, please contact QNX/Blackberry for how this is being set in the QNX BSP.

Regards,

kb

I can confirm that k3conf shows all arm cores are at 2GHz.  We are receiving a boot message stating: "ERROR: GTC_CNTFID0 is 0! Assuming 200000000 Hz. Fix Bootloader"

This seems to be the same issue as this forum post: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1087477/tda4vm-error-gtc_cntfid0-is-0-assuming-200000000-hz-fix-bootloader#

The solution in this post is to add these two lines into an initGTC(void) function:
static void initGTC(void)
{
    CSL_REG32_WR(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTCR, 0x1);
    CSL_REG32_WR(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTFID0, 200000000);
}

Is this still accurate?  I'm struggling to locate the correct CSL file for A72 which contains CSL_initGTC

Hi Sam,

The "ERROR: GTC_CNTFID0 is 0! Assuming 200000000 Hz. Fix Bootloader" is likely not affecting anything.   As mentioned, the boot loader code needs to be updated, such that the error is not seen.

One code location would be mcuss_demos/boot_app_mcu_rtos/boot.c, this file may or may not be, being used depending on your bootflow.

Regarding tick count, this is setup in the QNX BSP startup, search on timer_start, timer_diff, in psdkqa/qnx/bsp.

• Understanding the Microkernel's Concept of Time (qnx.com)

Another quick test is to run 'sleep 5' from QNX command prompt and ensure that when using stop-watch/phone timer, that the prompt returns in 5 seconds.

Regards,

kb

I ran another test on the J784s4 and a Raspberry Pi 4, both running QNX
This timing method is currently :

const uint64_t target_cycles = 10000000000;
uint64_t start_cycles, end_cycles;
uint64_t elapsed_cycles = 0;
start_cycles = ClockCycles();
while (elapsed_cycles < target_cycles) {
        
        end_cycles = ClockCycles();
        elapsed_cycles = end_cycles - start_cycles;
 }

uint32_t time = elapsed_cycles * 1e6 / (SYSPAGE_ENTRY(qtime)->cycles_per_sec);

cout << "Clock Cycles per second (From SysPage) : " << SYSPAGE_ENTRY(qtime)->cycles_per_sec << endl;cout << "Time Elapsed " << time << " us" <<endl;

The Raspberry pi reports:

Clock Cycles per second (From SysPage) : 54000000 (54MHz)
Time Elapsed 185185185 us

The timer on my phone is exactly 185 seconds, matching the results of the test.  There appears to be no issues with timing on the Raspberry Pi 4 running QNX.

The J784s4 reporting:
Clock Cycles per second (From SysPage) : 200000000 (200MHz)

Time Elapsed 50000000 us

The timer on my phone reports 40 seconds, approximately 20% faster than the test.

Attempting every method of timing discussed in Understanding the Microkernel's Concept of Time (qnx.com), the J784s4 is still reporting to take ~20% longer than a physical stopwatch timer. Running "sleep x" from qnx terminal is also off by ~20%.

Looking at how the ticks are setup in the psdkqa/qnx/bsp, it appears that timer_freq is getting set appropriately to the general counter register in the A72.  I have confirmed that 200MHz is the value of the register that is being set to timer_freq.

The "20% longer than stopwatch" finding does sound like the GTC not being at an expected value. 

From command prompt a read can be done as below, to see the current value:

• k3conf read 0xa90020

To update the GTC in the SBL boot flow:

The code referenced in the e2e link in your original post can be used.  The code is in place at:

• mcusw/mcuss_demos/boot_app_mcu_rtos/boot.c 

It would need to be moved to below location where it is currently not present.   

• pdk_j784s4_09_01_00_22/packages/ti/boot/sbl/example/boot_app/boot_app_main.c

For the Uboot boot flow, the below thread has some details:

• (99+) TDA4VH-Q1: Linux System Clock Related to GTC - Processors forum - Processors - TI E2E support forums

Regards,

kb

Great, thanks for the references.  I am attempting to add the initGTC function to:
pdk_j784s4_09_01_00_22/packages/ti/boot/sbl/example/boot_app/boot_app_main.c

The syntax in the boot_app_main appears different than the boot_app_mcu_rtos, so I am attempting in this manor.

Will report how it goes. 

Please also be aware of a recently created FAQ for this issue, recommendation would be to follow the patch provided there.

(+) [FAQ] TDA4VL-Q1: Change GTC Clock frequency to 200MHz for SBL boot flow - Processors forum - Processors - TI E2E support forums

Regards,

kb

I have had limited time to continue my investigation in this area.  Sorry for the delay. 

In reference to the patch you provided:
I attempted to apply this patch and build.  It was successful, but after copying the files over to my J784s4 dev board and rebooting the board will not boot, and I get no serial output.

Is this patch also applicable for the J784s4 board? or only the J21 as specified in one of the patch files?

Also, I want to confirm that the the pdk_libs, sbl image and boot app image should be built with gcc-arm.  I had to manually select my toolchain in order to get these to build.

Will loop in author of the patch. 

Regards,

kb

Hi, 

The same change is applicable on J784s4 as well.

Instead of board_pll of J721s2, it would in j784s4 folder

And all the build commands would have J784s4_evm as BOARD.

Sam Presser said:

Also, I want to confirm that the the pdk_libs, sbl image and boot app image should be built with gcc-arm.  I had to manually select my toolchain in order to get these to build.

Yes, it should automatically select the toolchain from the path provided in ${PDK_PATH}/packages/ti/build/Rules.make

Here, you should give SDK_INSTALL_PATH = /home/${USER}/ti where the toolchains are installed upon running the setup script in the SDK

Regards,

Nikhil