AM6548: Time stamping in PRU

Hi TI Team any update on the above query ?

Hello Sarfaraz,  (I know that we have emailed, but wanted to directly comment on this thread to get the conversation going here)

TI AM6548 TEAM - PLEASE ALSO REPLY HERE !

As we discussed offline, could you politely comment on the applicability of your previous e2e thread and corresponding TI reply to “There is HW support available to timestamp events using IEP but I don't think there's an easy way to timestamp them using the Linux system time, that would have to be done in software.  The correct way to do this is to keep the IEP and System in sync (with or without a fixed offset) and then use IEP to timestamp events.”

This is found here:  AM6548: Read system time in PRU - Processors forum - Processors - TI E2E support forums

If this seems applicable (I believe that it does), one could then follow this App Note, particularly Section 2.3.3 beginning with the following " IEP Timestamping With 64-Bit Support The IEP timer peripheral of PRU-ICSS within the AM437x supports only a 32-bit timer. PRU firmware is used to extend the timestamping to 64 bit. The 32-bit IEP timer wrap-around occurs every 4.29 seconds. This wrap-around is used in providing 64-bit timestamping. The IEP event is generated when there is a wrap-around by setting up the IEP_CMP [0] event. Each PRU updates their IEP high count value, which is stored in shared memory. "

This is found here:  https://www.ti.com/lit/ug/tiducd4/tiducd4.pdf

Please comment.

Our AM6548 team will also monitor and comment.

Thank you kindly,

Chris

Hello Chris,

     Thanks for the update. I have read the document. Can you confirm whether the 64-bit timestamping value is absolute timestamp synced using NTP or is it a counter which is mentioned in  6.5.13.2.2.1 PRU_ICSSG IEP Timer Features of TRM.

    Also 6.5.13.2.6.1 PRU_ICSSG IEP Sync0/Sync1 Features of TRM mentions syncing of the counter value. Does this mean the synchronization with PTP or other PRU modules?

Thanks,

Nikhil.

Hello Nikhil,  [JIAN AND PROCESSORS TEAM, PLEASE COMMENT.  THANK YOU]

1) I believe this is just simply a counter mentioned in the Section 6.5.13.2.2.1 PRU_ICSSG IEP of the TRM and not an absolute timestamp sync using NTP.

2) I believe it means synchronization to other [timing] features within the PRU for instance.  For example, one could use it to generate IEP synchronized PWM timers on the PRU such as explained here:

(+) AM6548: AM6548 - Generate IEP PWM on PRU - Processors forum - Processors - TI E2E support forums

One could also use it to measure various signal intervals for instance a signal interval of IRQ which is another interrupt signal generated by EtherCAT IP such as explained here:

(+) AM6548: Measurement of signal interval at PRU_ICSSG IEP - Processors forum - Processors - TI E2E support forums

Again, I'd really like for a member of the Processors team to comment further, but hopefully this helps in the meantime.

Regards,

Chris

Hello Chris,

    I see that we have many options to synchronize systems internally on the processor level but getting the absolute timestamp still remains a challenge. Can anyone from the AM6548 team comment further on this?

Thanks,

Nikhil.

Hi Nikhil,

I speaking with the AM6548 Team last night, it is my understanding that the recommended option would be to initiate the 64-bit Timer within the context of Linux time prior to the ADC capture sequence.  This way, it falls within the necessary time domain.  I believe the AM65xx Team took the action and was planning to comment further on this specific thread, so stay tuned for more.  Thank you for your patience and understanding.

Regards,

Chris

I have some queries on timestamping using IEP. Kindly revert on the same:

Earlier you have shared IEP based timestamping example used in Real-Time Ethernet Tracer.
Can you confirm whether the assembly code in below file performs same logic as explained in section 2.3.3 of the document.

ti/drv/emac/firmware/icss_dualmac/src/iep.h

I have attached a pseudo code for IEP registers’ initialization and reading of timestamp, which I plan to run in PRU0.
Can you check whether my understanding is correct and if any step is missing or mistaken.
I have not fully understood the compensation register and increment register. Can you share some information on how I can init those so that the 64-bit counter value emulates as a system time counter.
The value I need is in count registers, so what is the significance of compare registers?
Do we need special handling to detect CMP[0] event? Or is it ok if I continuously read the count registers?

// Pseudo code IEP timestamping
struct iep iepVal;
uint32 highCount;
uint32 lowCount;

/* Initialize timer to known state (default values) */
// Disable counter (IEP_GLOBAL_CFG_REG[0])
iepVal.global_cfg_reg_bit.cnt_enable = 0;

// Reset Count Register (IEP_COUNT_REG0, IEP_COUNT_REG1)
iepVal.count_reg0 = 0xFFFFFFFF;
iepVal.count_reg1 = 0xFFFFFFFF;

// Clear overflow status register (IEP_GLOBAL_STATUS_REG[0])
iepVal.global_status_reg_bit.cnt_ovf = 1;

// Clear compare status (IEP_CMP_STATUS_REG[15-0])
iepVal.cmp_status_reg = 0xFFFFFFFF;

// Set compare values IEP_CMP0_REG0, IEP_CMP0_REG1. Init to zero
iepVal.cmp0_reg0 = 0x0h;
iepVal.cmp0_reg1 = 0x0h;

// Set increment value (IEP_GLOBAL_CFG_REG[7-4])
iepVal.global_cfg_reg_bit.default_inc = 1;

// Set compensation value (IEP_COMPEN_REG[22-0])
iepVal.global_cfg_reg_bit.cmp_inc = TBD;

/******** Enable Compare 0 Event *******/
// Enable shadow so that count registers have 32 bit high and low for 64 bit counter
iepVal.cmp_cfg_reg_bit.shadow_en = 1;

// Enable reset of counter for CMP0 event
iepVal.cmp_cfg_reg_bit.cmp0_rst_cnt_en = 0;

// Set event to CMP0 event
iepVal.cmp_cfg_reg_bit.cmp_en = 0x01;

// Enable Counter (IEP_GLOBAL_CFG_REG[0])
iepVal.global_cfg_reg_bit.cnt_enable = 1;

// Update timestamp value in existing code
while (1) {
	highCount = iepVal.count_reg0;
	lowCount = iepVal.count_reg1;
}

Hello Nikhil,

Thank you again for your patience.  I will be speaking this evening to our Jacinto team once again and will make sure to escalate this for additional feedback.  In the meantime, here are some responses:

1) Yes, the assembly code in the iep.h file does appear to perform the same logic as explained in Section 2.3.3 of the IEP document.

2) Your pseudo code and overall understanding appears sound.  Running on the PRU would be our recommendation also.  Please pay particular attention to the IEP configuration overall.

3) Regarding Compensation/Increment, there are additional notes in the TRM Technical Reference Manual Section 6.4.13.2.2. if you can review. 

4)  The value needed is indeed in count registers and I suspect the significance of compare registers is inter-related.

5) Is should be acceptable to continuously read the count registers, as you noted.

I will again follow up after speaking to our team later today.

Thank you,

Chris

Thanks Chris for your reply. I am testing my approach now and will update the forum accordingly.

Hi Nikhil,

Regarding your latest inquiries:

1. Do we need to enable shadow mode operation.
   1. I see that enabling the mode, I see the counter values but they are not incrementing.
   2. On disabling the mode, I am seeing negative values (most probably overflowed). Do I need to handle the overflow flag in such case?

I do not believe Shadow Mode is required, although it is described in the TRM section 6.4.13.2.3 32-Bit Shadow Mode.

If you intend to try using Shadow Mode, we would suggest following the TRM Section specifically 6.4.13.2.3 and including the Sequence of operation portion described.  Unfortunately, I do not believe we have sample code or an example project for this purpose.

1. Also do I need to keep checking for CMP0 event to occur or reading the count registers should be enough?

Reading the count registers as described some in the Sequence of operation section of TRM should be adequate.

1. Also I am initiating compare values to zero. I hope that is correct.

Yes, I agree and believe that is correct again per the Sequence of operation excerpt in the TRM.

We again apologize for not having a readily available sample project or example code for this feature.

Please keep us posted on your progress via this e2e thread if you can please.

Thank you,
Chris

Hello Nikhil,

I will be commenting from the Sitara team side. Please let us know if there are follow-up questions.

The question

Is this understanding of your clock synchronization system design correct?
 * Linux ARM is receiving master clock time over Ethernet PTP
 * PRU_ICSSG core needs to be able to use the local IEP timer for timestamping
 * You are looking for input on how to align the IEP timer counter with the IEEE 1588 time

The concept

From a conceptual standpoint, the IEEE 1588 / PTP time is recorded as a rate multiplier m, and a DC offset b, that are applied on top of a local monotonically incrementing hardware counter.

In ARM64 the counter used is the ARMv8 system counter that is available locally in the A53 core, we also connect it to the block we call GTC (which really is the mandatory memory mapped ARMv8 system counter). So those two counters are the same value (there is a fixed offset of some nanoseconds), and increment at exactly the same rate. So if we can keep track of the IEP counter relative to the GTC counter, and tune the IEP counter as needed, then we should be able to use m and b from the GTC counter.

Ok, so how to do that? The AM65x time sync router allows us to send regular pulses from an input (e.g., GTC counter) to an output or multiple outputs that need to be synchronized. The PRU_ICSSG can receive those pulses. For more information on the basic idea of the time sync router, take a look at this FAQ for the AM64x: 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 Note that AM65x time sync router is better documented in the TRM, and will have different inputs, outputs, and latencies.

AM65x time sync router latencies: (reference the above FAQ for explanations and diagram)
input latency is less than 8ns
router + output latency, ONLY outputs that are internal to the AM65x processor: less than 8ns. Thus, the difference in time for a single input to reach two different outputs inside the processor will also always be less than 8ns.
router + output latency, all possible outputs (including the SYNC_OUT processor pins): less than 16ns. Thus, the difference in time for a single input to reach two different outputs when at least one of the outputs is a processor pin will always be less than 16ns.

The (start of the) implementation 

We can talk more specifics later as needed.

Let's send a push event from GTC_HWPUSH (AM65x TRM Table “TIMESYNC_INTRTR0 Event Map”) to one of the ICSSG interrupt inputs (e.g., ICSSG0_PR1_EDC0_LATCH0_IN from table “TIMESYNC_INTRTR0 Hardware Requests”).

For the above example, probably want to start with direct register writes since I do not expect that the GTC Linux driver allows for setting push events (at least, it does not for AM64x). The time sync router could be set with the timesync_router devicetree node, or the register TIMESYNC_INTRTR0_MUXCNTL_y (where for the above example, y is 8).

Regards,

Nick

Hello Nick,

    Thanks for the update.

    The approach you have suggested for syncing the time based counters looks good.

    Currently we are focusing on using CMP[0] event to generated a 64 bit timestamp.

     The steps we are following are: initializing the IEP counter value to zero in PRU, increment the counter with expected values and pass to R5F. Which in turn passed data to A53. For now, just focusing on getting some counter value in A53, which we can later synchronize with GTC to get accurate values as per your suggested approach.

      Also I will look more into Time Sync Router document and get back to you with queries, if any.

Thanks,

Nikhil.

Hello Nick,

    I did some more analysis on your reply and below are my follow-up questions.

• A53 is running Linux. Do we have any APIs to configure and read the GTC in Linux?
• Where can I read the multiplier and offset values. Is it saved in some register?
• I think we have not enabled TSR in device tree. I suppose we need to enable that to try this approach.
  • I could find an example at https://www.spinics.net/lists/devicetree/msg460994.html
• Do we have any appnotes or sample codes for the Time sync between A53 and PRU based on TSR.

   I still have a concern that how my IEP counter will look. If we are doing synchronization using pulses then how can we make sure GTC counter value is same as IEP counter value. Because GTC counter will be a measure of time. So if we just start IEP at zero and use the pulses to increment it that wont work maybe. Maybe the multiplier and offset will help here.

Thanks,

Nikhil.

Hello Nikhil,

APIs to configure and read GTC in Linux? 

There are no Linux APIs to directly configure the GTC. I am double-checking with the team to see if there are APIs to read the GTC value in Linux.

IEP counter value relative to GTC counter value 

Note that you can configure the IEP counter and the GTC counter to use the same clock source (e.g., both can use CPSWHSDIV_CLKOUT2, MAINHSDIV_CLKOUT3, PCIE0_TXI0_CLK, PCIE1_TXI0_CLK), which would ensure that the rate that each counter is increasing stays fixed relative to the other.

You will not be able to start the GTC counter and the IEP counter at the exact same time. However, let's say you use a GTC push event. The GTC push event just outputs a bit of the GTC counter. So if we selected the bit at 0x0010_0000, then you would get a signal level transition every 2^20 GTC clocks, and a rising edge every 2^21 GTC clocks. From my previous reply, we know that the signal level transition will take less than 16ns to get from the GTC to the ICSSG (input latency plus router + output latency for a destination within the chip). We also know the time it takes the AM65x ICSSG to read the local IEP counter from the PRU Read Latencies app note here: https://www.ti.com/lit/sprace8 . So we can know the IEP and GTC counter values to within about 16ns of each other.

How do I enable TSR in the devicetree?

Please take a look at arch/arm64/boot/dts/ti/k3-am642-evm.dts. Search for "timesync_router".

Where can I read the rate multiplier and offset values? 

I am reassigning your thread to another team member to comment.

Regards,

Nick

Hi Nick,

To simplify to you regarding our requirements. We use Linux on A53, RTOS on R5 and custom firmware in PRU.

1. We connect to ADC from PRU pins. so whatever data comes to system we need to timestamp the single sample.

2. Timestamp should be the Linux Time upto nano sec precision. We dont want to timestamp the counter value as our requirements is to be precise at PTP level time.

Is there a simple way to pass the Linux data to PRU upto nano sec level and use it to timestamp our input data?

looking at the above methods looks bit complicated and this looks difficult to maintain the nano level sync between PRU and A53.

Hi Nick,

In addition to above queries by Sarfaraz,

We are already using PPS signal as a GPIO, so not sure whether we would be able to configure it for TSR.

The PTP packets are timestamped in PRU. Any chances we can leverage that timestamp for our implementation?

There is a TS_OFFSET mentioned in the dts file, is it same as the rate multiplier and DC offset mentioned in your answer. 

Thanks,

Nikhil

sarfaraz shaikh said:

2. Timestamp should be the Linux Time upto nano sec precision. We dont want to timestamp the counter value as our requirements is to be precise at PTP level time.

Trying make sure we understand the use case. You have Linux running ptp (ptp4l ?) and you use phc2sys to use that time as the time in Linux. Something like the steps in https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM65X/08_02_00_01/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW2g.html?highlight=linuxptp . Weather you use ICSS or CPSW based Ethernet, it should not matter (PTP packets are timestamped in PRU sound like you are using ICSSG based Ethernet). You then want to use this time in the PRU code interfacing to the ADC. So you need to establish the relationship between Linux system time and the IEP (a counter available for PRUs) running inside ICSSG you use to timestamp the ADC samples.

Before going deeper is the above accurate?

  Pekka

Hi Pekka Varis

     Yes we do have PTP running on Linux and it is synced with RTC.

     Also you are right about we needing system time on Linux synced with IEP counter in PRU (Maybe with some offset). Note that IEP is the best solution (inside ICSSG subsystem) we could find for this use case as it has in-built support for 64 timestamping. 

Thanks,

Nikhil.

Thanks Pekka Varis for the inputs. 

We have ptplinux installed as part of sdk and also use CPSW. we have ICSSG1 and ICSSG2 working as ethernet ports but how to send time to ICSSG0 which is not a ethernet port. it is normal PRU with our custom firmware.

Is there any example available how to send linux time to PRU via any protocol or available registers.

Thanks,

Sarfaraz

Hello Pekka Varis Nick Saulnier,

Below are the things we tried until now,

1. I am seeing that GTC counter is running as expected. GTC clock source is 0h - CPSWHSDIV_CLKOUT2 200 Mhz.

2. IEP counter when enabled is also running as expected. But I saw that the GTC and IEP counters are incrementing and varying rates (taking the increment value of IEP counter in consideration). I observed that the IEP counter set at PER1HSDIV_CLKOUT1 225Mhz. I changed IEP_CLK to CPSWHSDIV_CLKOUT2 200Mhz. Still I am not seeing that the two counters are incrementing at same rate though the drift between the two reduced drastically.

For the time sync router, I am using following settings

Input Event
    SYNCEVENT_INTRTR_IN_1 1 GTC_HWPUSH GTC hardware push event Pulse

    I am trying to generate GTC Push event using GTC_PUSHEVT[5-0] EXPBIT_SEL.

Output Event
    ICSSG0_PR1_EDC0_LATCH0_IN SYNCEVT_RTR_SYNC8_EVT Selectable timesync event 8 Edge

    In my understanding, if the output event is correctly configured I should see the counter value in IEP_DIGIO_DATA_IN_REG. But I am seeing its value as zero. I have also enabled the IEP DIGIO to use PR<k>_EDC_LATCH0_IN signal as input by writing 0x1h to bit4-5 of IEP_DIGIO_CTRL_REG. Or is the synchronized counter value directly available in IEP low and high count register?

Please let me know what we are missing. I have also enabled the TSR in device tree as per the example.

Thanks,

Nikhil.

I think you are headed in the right direction, run the counters from the same clock, then latch to see what is the offset. Unfortunately we don't have an example of the IEP usage and time sync router.

I've notified one of the ICSSG/PRU experts to see if he would give an additional comment on why you are not seeing the latch happen.

  Pekka

Hi Nikhil,

have you been able to debug this further on your end as to why the latch doesn't happen and the counter value is not reflected? I want to see how to help to move this forward so I'd like to understand the latest-latest status on your side.

Thanks,
Andreas

Hi Andreas Dannenberg,

I was not able to find why the latched signal is not occurring. I am dependent on the counter register to see whether its working or not. So mostly I am stuck at whatever I have written a month ago.

Any flag in PRU/ICSSG to check whether a specific latch event has occurred?

Can you confirm whether I am doing the correct configuration to IEP_DIGIO_CTRL_REG? In my understanding if the latch input is working correctly then IEP_DIGIO_DATA_IN_REG will show the input counter. The same value should appear in Low and High count registers of IEP.

Nikhil,

Thanks for your patience. I think the configuration of the time sync router and maybe input is the most likely place to look. The EXPBIT_SEL is essentially a power of 2 comparator, so the 5-bit value is the 2^value that gets compared, so the value of 10 would mean an event every 1024 ticks of GTC. What value are you trying in EXPBIT_SEL ? I think in your case the GTC is running at 200MHz/5ns , so the value 10 in EXBIT_SEL should mean a latch roughly every 5.12 microseconds.

  Pekka

Hi Pekka,

    I was also using same value (0x10). But as I mentioned, I was not getting the latched input hence the counter was not incrementing. I think whatever value I use for EXPBIT_SEL, the latch bit should always come-in and counter should increment.

Thanks,

Nikhil.

Do you have the possibility to try a different output than the IEP? For example a pin like SYNC0_OUT and then see if there is a pulse every 5.12us?

Pekka Varis Andreas Dannenberg

In the AM65xx Time Synchronization Architecture document it is mentioned that GTC provides a Gray-coded timestamps to A53. 

1. What is the level for (bit ) Gray encoding this is.

2.Also does GTC have the exact system time as seen by linux or is there any further conversion method for this?

sarfaraz shaikh said:

In the AM65xx Time Synchronization Architecture document it is mentioned that GTC provides a Gray-coded timestamps to A53. 

1. What is the level for (bit ) Gray encoding this is.

2.Also does GTC have the exact system time as seen by linux or is there any further conversion method for this?

Unfortunately we chose a little confusing naming for this. The user does not need to care about the encoding (it is used underneath in the HW), the registers in the GTC are compliant with system counter the as defined in the ARMv8 Architecture Reference Manual https://developer.arm.com/documentation/ddi0487/latest section D7.1. This is the same counter that is visible for Linux from within the A53 core. It is the monotonic counter used by Linux, but to get to system time you need the SW maintained and update the rate and offset.

  Pekka

Thanks Pekka, for your reply.

Can you let me know at what clock frequency the IEP counter in ICSSG 0 is running with default SDK. As mentioned in TRM it is mentioned that it is functioning at 200Mhz but after tracing the clock from clock tree I found that the IEP is running at 225 MHz.

Can you clarify what will be the frequency for IEP counter in default SDK running system

Thanks,

Sarfaraz

sarfaraz shaikh said:

Can you clarify what will be the frequency for IEP counter in default SDK running system

root@am65xx-evm:~# 
root@am65xx-evm:~# k3conf dump clock | grep IEP
|    62     |    10    | DEV_PRU_ICSSG0_BUS_IEP_CLK                                                                    | CLK_STATE_READY | 200000000       |
|    62     |    11    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_ADPLLM_HSDIV_WRAP_MCU_1_BUS_HSDIV_CLKOUT2_CLK               | CLK_STATE_READY | 200000000       |
|    62     |    12    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_ADPLLLJM_HSDIV_WRAP_MAIN_0_BUS_HSDIV_CLKOUT3_CLK            | CLK_STATE_READY | 250000000       |
|    62     |    13    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_BOARD_0_BUS_MCU_CPTS_RFT_CLK_OUT                            | CLK_STATE_READY | 0               |
|    62     |    14    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_BOARD_0_BUS_CPTS_RFT_CLK_OUT                                | CLK_STATE_READY | 0               |
|    62     |    15    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_BOARD_0_BUS_MCU_EXT_REFCLK0_OUT                             | CLK_STATE_READY | 0               |
|    62     |    16    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_BOARD_0_BUS_EXT_REFCLK1_OUT                                 | CLK_STATE_READY | 0               |
|    62     |    17    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_WIZ8B2M4VSB_MAIN_0_BUS_LN0_TXCLK                            | CLK_STATE_READY | 0               |
|    62     |    18    | DEV_PRU_ICSSG0_BUS_IEP_CLK_PARENT_WIZ8B2M4VSB_MAIN_1_BUS_LN0_TXCLK                            | CLK_STATE_READY | 0               |
|    63     |    10    | DEV_PRU_ICSSG1_BUS_IEP_CLK                                                                    | CLK_STATE_READY | 200000000       |
|    63     |    11    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_ADPLLM_HSDIV_WRAP_MCU_1_BUS_HSDIV_CLKOUT2_CLK               | CLK_STATE_READY | 200000000       |
|    63     |    12    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_ADPLLLJM_HSDIV_WRAP_MAIN_0_BUS_HSDIV_CLKOUT3_CLK            | CLK_STATE_READY | 250000000       |
|    63     |    13    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_BOARD_0_BUS_MCU_CPTS_RFT_CLK_OUT                            | CLK_STATE_READY | 0               |
|    63     |    14    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_BOARD_0_BUS_CPTS_RFT_CLK_OUT                                | CLK_STATE_READY | 0               |
|    63     |    15    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_BOARD_0_BUS_MCU_EXT_REFCLK0_OUT                             | CLK_STATE_READY | 0               |
|    63     |    16    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_BOARD_0_BUS_EXT_REFCLK1_OUT                                 | CLK_STATE_READY | 0               |
|    63     |    17    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_WIZ8B2M4VSB_MAIN_0_BUS_LN0_TXCLK                            | CLK_STATE_READY | 0               |
|    63     |    18    | DEV_PRU_ICSSG1_BUS_IEP_CLK_PARENT_WIZ8B2M4VSB_MAIN_1_BUS_LN0_TXCLK                            | CLK_STATE_READY | 0               |
|    64     |    10    | DEV_PRU_ICSSG2_BUS_IEP_CLK                                                                    | CLK_STATE_READY | 200000000       |
|    64     |    11    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_ADPLLM_HSDIV_WRAP_MCU_1_BUS_HSDIV_CLKOUT2_CLK               | CLK_STATE_READY | 200000000       |
|    64     |    12    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_ADPLLLJM_HSDIV_WRAP_MAIN_0_BUS_HSDIV_CLKOUT3_CLK            | CLK_STATE_READY | 250000000       |
|    64     |    13    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_BOARD_0_BUS_MCU_CPTS_RFT_CLK_OUT                            | CLK_STATE_READY | 0               |
|    64     |    14    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_BOARD_0_BUS_CPTS_RFT_CLK_OUT                                | CLK_STATE_READY | 0               |
|    64     |    15    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_BOARD_0_BUS_MCU_EXT_REFCLK0_OUT                             | CLK_STATE_READY | 0               |
|    64     |    16    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_BOARD_0_BUS_EXT_REFCLK1_OUT                                 | CLK_STATE_READY | 0               |
|    64     |    17    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_WIZ8B2M4VSB_MAIN_0_BUS_LN0_TXCLK                            | CLK_STATE_READY | 0               |
|    64     |    18    | DEV_PRU_ICSSG2_BUS_IEP_CLK_PARENT_WIZ8B2M4VSB_MAIN_1_BUS_LN0_TXCLK                            | CLK_STATE_READY | 0               |
root@am65xx-evm:~# 
root@am65xx-evm:~# uname -a
Linux am65xx-evm 5.10.65-rt53-g541ec9a699 #1 SMP PREEMPT_RT Tue Dec 21 02:58:35 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
root@am65xx-evm:~# 

Looks to me like 200MHz in the above SDK I'm running. You could check the same in your setup. k3conf is a very convenient Linux helper.

  Pekka

Hi Pekka,

Thanks for sharing the info.

Yes we are also getting the same result as above, but from the attached clock source tree . I could see that the mux IEP_OCP_CLK_EN bit is 1 means it is selecting the CORE_CLK as IEP_CLK in default system.

Thanks,

Sarfaraz

Hello Sarfaraz,

I am going through and double-checking on the Ethernet threads that I'm aware of. Is any additional action needed for this thread?

Regards,

Nick

Thanks Nick. No additional action required on this thread.