Setting CCM Registers from M4 core

[ed_smith_mqx_le]

In iMX7D SABRE development board.  I'm trying to setup the correct clocking to run the Ethernet from the M4 core.  After the DSTREAM debugger connects I see the ENET PLL is already configured correctly.  I assume some initial flashed boot loader as done this, however when trying to setting the CCM registers to get correct clocking I find I'm unable to write to these registers to set the root clocks.  In particularly trying to get the RGMII TX clock to run at 125MHz.  I notices that my phy clock is slight off as well so I suspect the module clock has not been switch to the Ethernet PLL at 125MHz and is running from 120MHz System clock.  However setting the ENET1 Reference clock does seem to have any effect on the registers.  Do you know what would have prevented access to these registers and what the correct solution would be to setup the ENET controller from the M4 core.

[ed_smith_mqx_le]

Hi Mark,

Thanks for looking into this, uboot has not run.  We just run a script from the debugger MX7D_DDR3_register_programming_DS5.ds which sets up clocks and DDR then a dtsl_config_script.py which seems to just config trace for the DSTREAM.   After that our code is loaded and run from DDR on the M4 core.  As far as I know the A7 is idle.  The debugger script does seem to do a lot of clock configuration however I can't see how it would prevent further clock changes.  Just to be clear enet0 is called ENET1 in the reference manual.  We are using the first ethernet device at address 0x30BE0000.  My main question is that appears the the clock going to ENET module appears to be 120MHz inplace of expected 125MHz.  I'm not certain which muxes control this.  There seems to be link between CCGR6,  CCGR112 the ENET_AXI_CLK_ROOT and ENET_TIME_CLK_ROOT but I'm not certain how all these link together to make the ENET module clock rate.

[markruthenbeck]

Ed,

There are a couple of questions i need to ask, and a couple of suggestions...

When the M4 is being run, has uboot running and has linux booted? uboot will enable and configure one of the enets, because it has the capability for a tftp boot-up. If linux is running, then the linux driver will be working against any efforts made by the M4 on the enet hardware.

I believe uboot uses enet0, so doug's experiments would be better suited for enet1. This way there are less chances of any other code getting in the way.

The original question, there should be nothing stopping the M4 from getting to the enet registers. The RDC, which would prevent access, is not setup for exclusive accesses in uboot, or in the enet drivers.

If linux is needed, then the dts/dtb file needs to be modified to turn off the enet that the M4 would like to use.

Let me known if you have additional questions,

mark