Thanks Soren, So the 2nd ethernet port wasn't originally working in Linux because, without those two lines, Linux wasn't able to initialize the clock frequency for the GEM driver correctly, but the HW itself was fine? And a bare-metal app should be fine as long as I am using the same FSBL for my bare-metal application as I was using for Linux? Will give it a go and see. Thanks!
However, while debugging this before discovering the fix, I was having the Linux kernel print out debug logs for any writes to Zynq clock control registers (e.g., APER_CLK_CTRL, GEM1_CLK_CTRL) and something was manipulating/changing them during Linux boot up. Do you know what in the Linux kernel would possibly be controlling them? Unfortunately, I can't say which exact bits were being changed now, so perhaps it was unrelated to GEM1 clocking. Eric On Tue, Mar 29, 2016 at 9:59 AM, Sören Brinkmann wrote: > 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
