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 <k...@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@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
