Hi Eric, On Tue, 2016-03-29 at 08:35:48 -0700, Eric Wong wrote: > On Sat, Oct 24, 2015 at 1:57 PM, Eric Wong <[email protected]> wrote: > > > > On Thu, Oct 15, 2015 at 20:56:46, Edward Wingate wrote: > > >> On Thu, Oct 15, 2015 at 6:25 AM, Mike Looijmans <mike.looijmans at > > topic.nl> wrote: > > >> As the datasheet should have explained, "0" is not a valid PHY address. > > So > > >> that does not leave many options. "0" is actually the "broadcast" > > address on > > >> the MDIO bus, so all phys will respond to it. Which makes it work with > > just > > >> one PHY, but with multiple PHYs on the MDIO bus this will not work. > > > > > >The datasheet itself never mentions 0 as being the broadcast address. > > >I wonder if the GMII-to_RGMII IP responds to 0, or only its assigned > > >PHY address. > > > > We have an almost identical configuration to yours as you've been > > describing it and were able to get the 2nd ethernet port working by > > adding this to the sclr-clkc device tree: > > clocks = <&clkc 17>; > > clock-names = "gem1_emio_clk"; > > > > A few months back, I mentioned the above, that adding those 2 lines to > sclr/clkc device tree made the 2nd ethernet port work. Can anyone tell me > exactly what they're doing? If I weren't using Linux and its device tree, > what would be the bare-metal Xilinx SDK equivalent way to configure > whatever those two lines are doing? Appreciate any help!
The DT must describe the HW. And those two lines do just that, they describe your board/bitstream-specific clocking for the Ethernet core. As long as you don't use any SOC-external clocking resources, the abstraction in Linux is essentially containing the whole model of Zynq's clock tree in this 'clkc' object. Based on internal registers and the one parameter in DT specifying the oscillator frequency, SW can then detect how the clocks are muxed and what frequencies they are running on. If you use the EMIO option for clocking though, Linux will read the clock mux for the Ethernet clock, but it has no knowledge about what clock might feed into that EMIO input. Hence, in such cases, you have to provide that information in DT. In this particular case, you tell Linux that you have connected output 17 of the clkc (fclk2 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/zynq-7000.txt#n58)) to the EMIO input for gem1 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/zynq-7000.txt#n31). That enables Linux to correctly complete the SW representation of the clock tree and calculate the clock frequencies. With that the GEM driver can enable all relevant clocks and read/generate the correct frequencies. Bare-metal has nothing like that. Assuming that you have clock frequencies, muxes etc. configured correctly in Vivado, the FSBL should correctly set these things up and nothing more should be needed. Adding that description to the DT does not change any HW state, it just ensures that Linux can create its SW state that is consistent with reality, which may be required for the GEM driver to work correctly (I suspect it would not like an input frequency of 0). Sören -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
