Broken ethernet on SolidRun cubox-i

[Christoph Mattheis]

Russell, Michael, I'm here and happy to support whatever you suggest - I have multiple cuboxes here, one impacted, two not - just tell me what I should do - BR Chris


> Michael Walle <michael at walle.cc> hat am 8. Januar 2021 um 13:14 geschrieben:
> 
> 
> Am 2021-01-08 13:01, schrieb Russell King - ARM Linux admin:
> > On Fri, Jan 08, 2021 at 12:58:17PM +0100, Michael Walle wrote:
> >> Am 2021-01-08 12:53, schrieb Russell King - ARM Linux admin:
> >> > On Sun, Dec 27, 2020 at 04:11:14PM +0000, Russell King - ARM Linux admin
> >> > wrote:
> >> > > On Sun, Dec 27, 2020 at 04:59:39PM +0100, Michael Walle wrote:
> >> > > > Am 2020-12-27 16:33, schrieb Michael Walle:
> >> > > > > Am 2020-12-26 13:34, schrieb Russell King - ARM Linux admin:
> >> > > > > > I'd forgotten that there were boards out there with this problem...
> >> > > > > > the PHY address configuration is done via the LED_ACT pin, and
> >> > > > > > SolidRun
> >> > > > > > omitted a pull resistor on it, so it "floats" with the leakage current
> >> > > > > > of the LED/pin - resulting in it sometimes appearing at address 0 and
> >> > > > > > sometimes at address 4.
> >> > > > >
> >> > > > > Mh, I've guessed that too, but there must be more to it. The datasheet
> >> > > > > says it has an internal weak pull-up. Or Atheros messed up and it
> >> > > > > doesn't
> >> > > > > reliably work if there is actually an LED attached to it. But then, why
> >> > > > > would any other stronger pull-up/down work..
> >> > > >
> >> > > > Mhh, nevermind, from the commit log [1].
> >> > > >
> >> > > >   "The LED_ACT pin on the carrier-one boards had a pull down that
> >> > > >   forces the phy address to 0x0; where on CuBox-i and the production
> >> > > >   HummingBoard that pin is connected directly to LED that depending
> >> > > >   on the pull down strength of the LED it might be sampled as '0' or '1'
> >> > > > thus
> >> > > >   the phy address might appear as either address 0x0 or 0x4."
> >> > > >
> >> > > > So it actually depends on the forward voltage of the LED and the
> >> > > > hi/low thresholds of the AT8035.. nice! Oh and btw. this pin also
> >> > > > switches between high and low-active LED output. So the missing
> >> > > > pull-down might not only switch the PHY address to 4 but also invert
> >> > > > the LED state.
> >> > >
> >> > > Indeed. And whether it appears at address 0 or 4 will depend on many
> >> > > factors, including temperature - LEDs have a decrease of 2mV/°C.
> >> > >
> >> > > I wonder if we can just delete the phy-handle property, and list a
> >> > > PHY at both address 0 and 4 with the appropriate configuration...
> >> >
> >> > Michael, can you try the attached patch please?
> >> 
> >> I don't have a cubox. But it's just a device tree patch. I could
> >> try to hack one based on Christophs dtb and he could just replace
> >> it on his sd card and test. Seems easy enough.
> > 
> > This sounds like a mess of indirection. What is "Christophs dtb"?
> > Why are there different dtbs out there for the same platform? If
> > there's changes necessary, why aren't they being submitted to the
> > mainline kernel?
> > 
> > In fact, why aren't users reporting these problems to mainline kernel
> > developers? Why do we have to have this tortuous bug reporting route
> > which makes testing fixes difficult?
> > 
> > This rather makes me not want to care about this.
> 
> Well first it was a suspected issue with 'my' change in the Atheros
> PHY driver, which turned out to be not the case. I _voluntarily_
> tried to debug the issue with a user (Christoph) just to find out
> that it is likely caused by the commit mentioned above. So for
> startes, why would I care? I just wanted to be kind and provide
> some help. If anything, this shows me, I should rather stick to
> my own problems.
> 
> So please advise Christoph, where he should report this bug.
> 
> -michael