[meta-xilinx] Help with ethernet0 device tree node

[Edward Wingate]

So it turns out the application I'm running on CPU1 was interfering
with Linux on CPU0.  My application on CPU1 uses eth1/gem1 and Linux
on CPU0 uses eth0/gem0.

The CPU1 application performs this sequence of register writes to set
the GEM1 divisor values during initialization:

*(volatile unsigned int *)(SLCR_UNLOCK_ADDR) = SLCR_UNLOCK_KEY_VALUE;
*(volatile unsigned int *)(SLCR_GEM1_CLK_CTRL_ADDR) = SOME_VALUE;
*(volatile unsigned int *)(SLCR_LOCK_ADDR) = SLCR_LOCK_KEY_VALUE;

The third line is (re)locking the SCLR registers and it is my
conjecture that doing this somehow interferes with Linux's eth0
operation because by not performing the locking (commenting out that
line in my CPU1 application), Linux is able to successfully change the
eth0 speed.  Conjecturing further, it seems like Linux keeps the SLCR
registers unlocked and assumes they remain so.  It should probably
check the SLCR_LOCKSTA register for the lock status and unlock if
necessary.  I tried to find in the kernel where this would occur, but
got lost in the kernel driver code.



On Thu, Aug 11, 2016 at 4:41 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
> On Wed, Aug 10, 2016 at 7:29 AM, Edward Wingate <edwingate8 at gmail.com> wrote:
>> Nathan,
>>
>> May I ask where your gem0 clock is sourced from?
>> My gem0 clock is sourced from iopll and my clock tree looks like this:
>>
>> ps_clk
>>      iopll_int
>>         iopll
>>            gem0_mux
>>               gem0_div0
>>                  gem0_div1
>>                     gem0_emio_mux
>>                        gem0
>>      armpll_int
>>         armpll
>>            cpu_mux
>>               cpu_div
>>                  cpu_1x_div
>>                     cpu_1x
>>                        gem0_aper
>>
>> I'm wondering if the gem0_emio_mux before gem0 is the issue (I'm not
>> going through EMIO).
>
> The "gem0_emio_mux" refers to the fact that the gem unlike other
> peripherals can mux their clock source from EMIO, it simply represents
> the MSB of the SRCSEL section of the GEM*_CLK_CTRL register in the
> SLCR. The kernel just implements it as two muxes (just like the MIO
> muxes for e.g. the can peripherals). The important part is the tree is
> sourced from the iopll <- ps_clk.
>
> The clk tree on the zybo looks similar:
>
>    clock                         enable_cnt  prepare_cnt        rate
> accuracy   phase
>
>  ps_clk                                   3            3    50000000
>        0 0
>     iopll_int                             1            1  1000000000
>        0 0
>        iopll                              8            8  1000000000
>        0 0
>           gem1_mux                        0            0  1000000000
>        0 0
>              gem1_div0                    0            0    16666667
>        0 0
>                 gem1_div1                 0            0    16666667
>        0 0
>                    gem1_emio_mux           0            0    16666667
>         0 0
>                       gem1                0            0    16666667
>        0 0
>           gem0_mux                        1            1  1000000000
>        0 0
>              gem0_div0                    1            1  1000000000
>        0 0
>                 gem0_div1                 1            1   125000000
>        0 0
>                    gem0_emio_mux           1            1   125000000
>         0 0
>                       gem0                1            1   125000000
>        0 0
>
>     armpll_int                            1            1  1300000000
>        0 0
>        armpll                             2            2  1300000000
>        0 0
>           cpu_mux                         1            1  1300000000
>        0 0
>              cpu_div                      3            3   650000000
>        0 0
>                 cpu_1x_div                1            1   108333333
>        0 0
>                    cpu_1x                10           10   108333333
>        0 0
>                       gem1_aper           0            0   108333333
>        0 0
>                       gem0_aper           2            2   108333333
>        0 0
>
> And when linked at 100M/25MHz
>
>           gem0_mux                        1            1  1000000000
>        0 0
>              gem0_div0                    1            1  1000000000
>        0 0
>                 gem0_div1                 1            1    25000000
>        0 0
>                    gem0_emio_mux           1            1    25000000
>         0 0
>                       gem0                1            1    25000000
>        0 0
>
>>
>> Also, my ps7_ethernet0 node has this in it:
>>     clock-names = "ref_clk", "aper_clk";
>>     clocks = <&clkc 13>, <&clkc 30>;
>>
>> The "30" in clocks is referring to gem0_aper, which looks out of place
>> in the clock tree (being under armpll instead of iopll).
>
> This should be fine, the aper_clk refers to the peripheral bus clock
> which should be common to all the cores on the same bus.
>
> Regards,
> Nathan
>
>>
>>
>> On Mon, Aug 8, 2016 at 12:08 PM, Edward Wingate <edwingate8 at gmail.com> wrote:
>>> On Sun, Jul 31, 2016 at 6:26 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
>>>>
>>>> I tested this with both the emacps and the macb driver (linux-xlnx
>>>> kernel v2016.2, on a ZYBO). Both advertise and link correctly with a
>>>> 100M switch and forced advert 100M with a 1G switch, and packets are
>>>> transmitted and received correctly.
>>>
>>> Appreciate the confirmation, Nathan.
>>>
>>>> If you are having issues with this before diving into the board/hw/etc
>>>> testing double check your clock setup (and that it is propagated to
>>>> FSBL/SPL correctly), and/or EMIO setup if you are routing through PL.
>>>
>>> I'll be doing so in coming days.  But despite the initial clock setup
>>> from FSBL, won't Linux mess with the registers during boot and
>>> ethernet initialization?  I wonder, can I change the link speed while
>>> in u-boot to see if it works there?  I'm tftping in u-boot
>>> successfully, probably at 1Gbps.