[U-Boot] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Fri, 25 Jan 2019, Chris Spencer wrote:

Thanks for a reply. The problem here is not with leftover descriptors -- it
is MDIO bus not working at all. It is either bogus speed/clock in DM mode or
something else that I haven't found yet. Reading all zeroes means there is
no communication with the PHY whatsoever, it comes from bare wire. And there
is no need for the PHY to be present at all for an MDIO transaction to
complete successfully -- PHY is a slave device with all clocks coming from
FEC MDIO so it WILL complete successfully even if it not connected to a PHY.
It is kinda like SPI that always succeeds for the master.

Unfortunately NXPs, sorry for an expression, documentation is totally
useless -- for ENET clocks their RM (see p. 4335, 11.4.4) only tells "The
table found here describes the clock sources for ENET" and that's all
information available. There is no table "here" :) And that is not an
exception -- such "information" is all over their 6,800 pages thick
Reference Manual while stuffed with hundreds of totally bogus pages
absolutely irrelevant for i.MX8MQ SoC (see e.g. their 120+ pages long
description of LCDIF interfaces and external pins.)

Damn, Freescale was pretty decent on documentation but NXP is absolute
disaster...

> On Thu, 24 Jan 2019 at 23:51, Sergey Kubushyn <ksi at koi8.net> wrote:
>> On Fri, 4 Jan 2019, Chris Spencer wrote:
>> Hi Chris,
>>
>> Did you figure out what was wrong with the PHY always reading zeroes over
>> MDIO?
>>
>> I have exactly same problem here with out i.MX8MQ-based device -- it worked
>> just fine with older U-Boot without DM_ETH but always reads zeroes over MDIO
>> with 2019.01...
>>
>> I'm still fighting and will probably find the culprit but it would've saved
>> me some time if you had found what was wrong...
>>
>> Your reply is highly appreciated.
>>
>> My best regards,
>> Sergey.
>
> Hi Sergey,
>
> I never quite got to the bottom of why it doesn't work in U-Boot, but
> I did discover that U-Boot's failure to correctly initialise the
> Ethernet controller is what was breaking the Linux driver. Basically,
> it's leaving behind an 'unspent' transfer request in the ENET_MMFR
> register (otherwise known as FEC_MII_DATA in the Linux driver) which
> gets triggered when the Linux driver starts initialising the Ethernet
> controller. This has a nasty habit of interfering with the first
> transfer request the driver tries to make.
>
> If you don't need networking in U-Boot then you can just set
> CONFIG_CMD_NET=n in your build config and that will fix the Linux
> driver. I'm afraid I can't offer any further insight if you do need
> networking in U-Boot.
>
> Thanks,
> Chris
>

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************