PROCESSOR-SDK-AM64X: GTC driver issue

Hello Ethan,

In AM64x Linux Processor SDK 8.0, the ARM timer is defined at arch/arm64/boot/dts/ti/k3-am64.dtsi > a53_timer0. That timer is fed by the GTC counter. From a brief skim through the device tree files, I do not see any nodes defined for interacting directly with the GTC (e.g., if you were looking at generating push events from the GTC).

What are you looking to do with the GTC?

Regards,

Nick

Hi Nick,

We use PRU1 and PRU0 to do communication.

We send command process as A53 -> PRU1 -> PRU0 -> FPGA

Get data process as FPGA -> PRU0 -> A53

The GTC counter can be accessed from every core, so I want to read the GTC counter to determine the transmission time and the data return time of each step. Can you give any suggestions?

After the board startup, I checked that the GTC is enabled. I think it's because the timer module is driven by GTC, so it has been initialized by timer initialization. That means I can directly read the GTC counter register to get the time.

But if I want to change the GTC frequency, where should I modify? In the dts file? As you said we could not find any dts nodes directly with the GTC.

Best Regards

xixiguo

Hello xixiguo,

Understood, so you are looking for a way to have a single time reference in order to benchmark communication latency. If your design has an upper limit on the allowable communication latency between Linux A53 and other cores, please make sure you are using the RT Linux release rather than the generic Linux release.

System Design: measuring latencies

My next paragraph is pretty dense. Let me know if I need to draw some pictures to help you visualize what I am saying.

Note that it takes some amount of time for a signal to travel from one part of the processor to another. Depending on how far away the different parts of the processor are, it will take more or less time for that signal to travel. So even if we ignore the variation introduced by the Linux operating system on the A53, a read from the A53 to the GTC will take a different amount of time than a read from a PRU core to the GTC.

What does that mean? If you are benchmarking your latency with microsecond or millisecond precision, then I would expect reading the GTC counter value to work just fine (at least from the PRU side, I have not looked as closely at benchmarking RT Linux at this point). However, if you are looking for latency values in the nanoseconds, you need to take that unknown difference in read time into account. For nanosecond scale precision, it might be better to use the time sync router. I'll talk about that in the next reply.

GTC Linux driver

At this point in time, we do not provide a Linux driver that gives direct control of GTC. I have not tried it yet, but you may be able to adjust the GTC using direct register writes.

Is there a reason you want to change the GTC frequency? What were you hoping to change it to?

Regards,

Nick

I ended up writing a lot more about the time sync router (TSR)  than I planned. After taking another look at it, I don't think Linux (even RT Linux) is precise enough that you will benefit from using TSR to synchronize Linux and PRU counters rather than just reading the GTC value.

However, if anyone is curious to learn more about the TSR, you can take a look at the new FAQ here:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1061474/faq-am64x-what-is-the-time-sync-router-for-how-do-i-use-it

Regards,

Nick

Hi Nick，

Thanks for your explain. It includes so many details, thank you!

I will try the GTC first, if it does not meet the demands, I will try TSR. Now it's not must to change the GTC frequency, I want to know how to change it except directly write the register.

Best regards

xixiguo  

Hello xixiguo,

is additional discussion needed here?

Regards,

Nick

Hi Nick,

Thanks for your reply! I just want to know if you have tested the latency that reading GTC counter from RT Linux APP. And if so, what's the latency and how to get GTC counter in RT Linux APP level? We can combine these two threads, and just discuss in the latest thread, here e2e.ti.com/.../4707717

Best Regards

xixiguohx

Hello xixiguohx,

Sounds good. I will continue the conversation there.

Regards,

Nick