On Fri, 2015-03-20 at 16:27 +0100, Hans de Goede wrote:
> On 20-03-15 15:39, Ian Campbell wrote:
> > On Fri, 2015-03-20 at 13:42 +0000, Ian Campbell wrote:
> >> On Fri, 2015-03-20 at 13:14 +0100, Hans de Goede wrote:
> >>> On 20-03-15 12:47, Ian Campbell wrote:
> >>>> I'm not really sure where to start looking. Perhaps CONFIG_GMAC_TX_DELAY
> >>>> on the u-boot side might be relevant?
> >>> Yes that is the first thing I was thinking of, the cubietruck is the only
> >>> gbit phy using a20 design which does not need it, which is kinda fishy.
> >> Ah, I hadn't cottoned on to that little fact-let, it's certainly worth a
> >> try then!
> > Setting CONFIG_GMAC_TX_DELAY=3 (or actually, the moral equivalent on
> > v2014.10, i.e removing the ifdef BANANPI) resulted in non-functional
> > tftp from u-boot (luckily I tried it on a local board first!).
> Interesting ...
> > Using 0, 1, or 2 seems to work from u-boot at least. I've not tried
> > anything more aggressive, my local board didn't have issues to start
> > with though.
> > I'm going to triple check my remote recovery procedures and then do some
> > experiments on one of the problematic boards.
> I wonder if it could be that there are 2 production runs of the cubietruck,
> with potentially different phy revisions.
FWIW the 4 which are remote were purchased in the same batch, which may
not mean much but makes it a bit less likely they were different
If, say, tx delay == 1 was needed, then is it possible that the default
setting of 0 might work on some systems perhaps depending on other
factors (manufacturing imperfections, cable differences)?
> Tom Cubie (added to the Cc), can you tell us if it is possible that there
> are different ethernet phy revisions on some cubeitrucks? Has there been
> a second production run ?
I think Tom moved onto other things quite a long time ago.