On Fri, Sep 27, 2013 at 02:41:53PM -0500, Matt Sealey wrote: > On Fri, Sep 27, 2013 at 2:05 PM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > Well, the patch tells me: > > > > + /* Set GPR1, bit 21 to 1 */ > > + mxc_iomux_set_gpr_register(1, 21, 1, 1); > > But you're setting the MAC clock up, and the MAC clock always goes out > over RGMII_TXC and the PHY needs to use it.. so it works. > > But that means setting up SION bits and setting ENET_REF_CLK up for > input is absolutely pointless.. > > This means the clock is being generated by the ethernet PLL Interesting. Looking in the patches, there's a need to disable some modes on the phy - i wonder if this is why. As I said, I think there is some scope for experimentation here. I think that even Rabeeh only sorted this out internally within solid-run during the last week, so it could be that some of these settings are sub-optimal. When I next see Rabeeh around, I'll talk to him about it. > >> > - Set ipg/ahb ethernet clock to 50MHz > >> > >> Hmm.. this might be a touch low, but it's not the issue here. The way > >> I recall this working, the IP has a clock (IPG, AHB as above) and > >> there is a MAC clock too which you're generating from DIV_SELECT in > >> the ENET_PLL. They don't have to be the same.. > > > > Actually, this is the issue. I now have doubts that the patches which > > Rabeeh gave us early-developers correspond with the kernel binary he > > rushed to us on Wednesday (he wasn't expecting them to be delivered soo > > quickly.) > > > > Rabeeh says in the wiki that his patches should be applied on top of > > 3.0.35 BSP 4.1.0, and the patches contain this: > > > > + /* Set enet clock to 50MHz RMII */ > > Note, RMII, not RGMII !!!! > > Can you tell us what board you got: > > http://cubox-i.com/table/ > > Subtle difference which I know I just faceplanted on in my previous > mail.. Same concept though... but if you have a DualLite then you > don't HAVE gigabit ethernet... a 125MHz clock is ridiculous, and Fabio > gave you the wrong manual. > > If it's a Dual or Quad, then you do have gigabit... and the below applies.. Okay, this is where things get a ltitle complicated. The pre-release dev hardware is not the final cubox hardware - it's a development platform, which is currently fitted with a IMX6 Solo with an AR8035 phy. The IXM6 Solo is gigabit capable, as is the AR8035. There's support in Rabeeh's patches for an AR8030, which is a fast ethernet phy (no gigabit). I suspect that the production Cubox-i hardware will have an AR8030 fitted to the lower end models, but an AR8035 to the higher end, while the dev hardware is a mix of low-end and high-end. If you look at my photo of the dev hardware on google+, you'll notice its quite different from the 2x2x2 form factor of the final product: https://plus.google.com/103895730806848715870/posts/GMnPj1w8CGZ > The question is here, really, does the PHY have it's own crystal > input, ... Yes it does. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
