IMX8QM: Linux: Ethernet TXC (125Mhz) from SOC beyond allowed error (PPM)

[mahesh_hns]

Hi,

We are debugging an issue with the RGMII TXC clock generated by the ENET MAC where the TXC is off by a very tiny amount on a board with IMX8QM processor. We are feeding output of a 24MHz clock crystal to the SoC  whose error is within 30ppm.  The ENET1 MAC is connected to a PHY through RGMII. As per the requirement by the PHY Chip manufacturer, this clock should be between 124.99375 and 125.00625 (+/- 50ppm). What we observed was 124.98620 MHz ( equivalent of -110 ppm). This, according to the PHY manufacturer can cause errors, especially during high temperature operations (which we are observing).

Can you guide me how the 24Mhz input clock to the SoC (XTAL) gets translated to the RGMII TXC (125Mhz for RGMII operation) coming out of the MAC ?

I saw this in the IMX8QMRM

I am trying to understand what path the clock takes to get the ENET1_TXC (125Mhz). Specifically,

1. Which PLL ( 24Mhz or AV_PLL16 or DIG_PLL0) does get used to generate TXC ?
2. Which one is the root clock for TXC ? For example CONN_SLSLICE1 or CONN_SLSLICE3_CLK_ROOT for ENET1.
3. How do I read the values of DIV and SLSlice<>_sel mentioned above?.  I believe all these are done in the SCFW ? If so, can you help me pin point where it is done?

Interestingly, I saw this table too

Does this mean that none of the DIG_PLL0, AV_PLL16 can be changed at all?  That would mean that everything depends  on the 24Mhz clock (its quality and precision) ONLY and the DIV values are hard-coded and cannot be changed?

We believe the input 24Mhz clock fed is error/jitter free. Any chance the SOC might introduce any errors? If so, is there any workaround ? lets say, adjusting any divider/multiplier along the clock tree to make the TXC error within the acceptable levels (50ppm)

Can you help us find answers to the above?

Thanks

Regards

Mahesh

[mahesh_hns]

HI,
  Is there a way to see the the DIV/MULT values for the for the AV_PLL16 and repgram it if needed?  Is it done in the SCU?

Regards,

Mahesh

[Zhiming_Liu]

Hi @mahesh_hns 

The DIV/MULT values is setting in below .o file, the functions should be called by scfw api.

dts==>linux clock driver==>scfw api==>scfw dsc driver.

imx-scfw-porting-kit-1.18.0/src/scfw_export_mx8qm_b0$ grep -r "DSC_MSliceGetDiv"
platform/drivers/dsc/fsl_dsc.h:void DSC_MSliceGetDiv(sc_dsc_t dsc, dsc_mslice_div_t *p_mslice_div);
grep: build_mx8qm_b0/drivers/dsc/fsl_dsc.o: binary file matches

If you want to change the clock rate, i think the fastest way is to modify ethernet dts property.

assigned-clock-rates = <250000000>, <125000000>;

Best Regards,
Zhiming

[dhuynh]

Is there a clock buffer output pin for the Xtal 24 MHz?
How can I program and bring this Xtal 24 MHz out to measure it, since measuring the clock frequency at the Xtal pin is not possible?

[Zhiming_Liu]

Hi @dhuynh

I would like to confirm from which end of the original description the -110 ppm measurement was taken? Closest to the SOC TXC output, or the ethernet PHY side?

Best Regards,
Zhiming

[dhuynh]

The 110 ppm measurement was taken closest to the SoC TXC output. The PHY is about an inch away from the SoC.

Dung Huynh

[Zhiming_Liu]

Hi @dhuynh 

Thanks for update, now we can be sure it has nothing to do with the layout of the TXC outputs, can you provide  24MHz circuit design? 

Best Regards,
Zhiming

[Zhiming_Liu]

Hi @mahesh_hns 

1. The 125MHz is from AV_PLL16. For 24Mhz bypass, it's not used after Ethernet PLL is stable. It's just a transition clock.

2. I don't think modifying the crossover value will solve the problem.

3. Since the hardware design manual's clock jitter requirement for the enet is 50ppm, I don't think there's any need to worry about internal PLL jitter causing this value to be larger.

4. For the 24MHz input design, the following points need to be noted in Hardwarre Developer's Guide. The default setting for internal capactior is BRD_OSC_CAP_TRM_VALUE_24M[3..0]=1010-->20pf. The default values were selected specifically for the MEK reference designs and should prove good enough for other designs in general. 

It may have something to do with the setting of this value, after making sure that there is nothing need to adjust with the design of your 24Mhz peripheral circuits. Careful burning thes bits of fuse is required. 

Have you measured the 24MHz crystal jitter above the chip's input pins? If it is confirmed that the 24Mhz jitter received by the chip meets the requirements, then the only thing left to adjust are these bits in the fuse.

Best Regards,
Zhiming

[mahesh_hns]

Thank you Zhiming for the clarification.

I'll be measuring the 24Mhz crystal on the cpu pins today and get back to you.

In the meanwhile, a few follow up questions:

How do I read/write the BRD_OSC_CAP_TRM_VALUE_24M ? Is it done through SCFW ? or any utility run from uboot/linux kernel space?

Also, isn't there any chance of any jitter/error (ppm) introduced by the SoC in converting the 24Mhz to 1000Mhz (AV_PLL16).? Is there a way I can read the DIV value for that?

Also, is there a point on the board where we can measure the AV_PLL16 directly?

Thanks
Regards

Mahesh

[dhuynh]

Measuring the clock frequency at the Xtal is not possible. The probe capacitance caused the Xtal frequency to change or stop oscillating. The only way to measure this 24 MHz Xtal clock is to set the processor to output this clock through a buffer. The question is how to program the processor and which pin it is using to output this 24 MHz buffered clock.

[Zhiming_Liu]

Hi @mahesh_hns 

1. Don't try to write fuse for now, you can use the fuse command in uboot to see the usage.

2. PLLs is internal, can't be measured. Did you measure the TXC output on SOC before? not the PHY side. 

Best Regards,
Zhiming