On Wed, Aug 10, 2016 at 7:29 AM, Edward Wingate <edwinga...@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 <edwinga...@gmail.com> wrote:
>> On Sun, Jul 31, 2016 at 6:26 AM, Nathan Rossi <nat...@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.
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
