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

[Sergey Kubushyn]

On Fri, 1 Feb 2019, Chris Spencer wrote:

> On Fri, 1 Feb 2019 at 16:10, Sergey Kubushyn <ksi at koi8.net> wrote:
>>> Turns out there's already a patch to add the driver as part of the
>>> i.MX8MM patch series. [1] Go figure.
>>
>> What the fcuk is i.MX8MM? Are they going to do anything with their i.MX8MQ
>> documentation? It is currently at Rev.0 dated January 8, 2018. In its
>> present state it is not even a joke -- it is way worse than that. It is
>> missing lots of info while including hundreds and hundreds of pages that has
>> absolutely no relevance to i.MX8MQ like e.g. 120 pages long description of
>> different interfaces to LCDIF that simply don't apply to what's in that
>> chip. On the other hand there is _ABSOLUTELY_ nothing about e.g. USB PHYs in
>> that, sorry for an expression, documentation. Nada, zero, zilch. Not a word
>> about SIP. And it is all around their documentation. Hell, just try to find
>> out what those 4 input clock sources are to their PWM that are selectable
>> from a per-PWM configuration register...
>>
>> And their only reaction for e.g. missing USB PHY information was "We told
>> design/documentation guys to include it in the future revisions" somewhen
>> around August last year. There we no revisions for a whole year since the
>> initial Rev.0 was released. Zero. Nada. Zilch. It is still that stinking
>> pile of manure, Rev.0 on NXP site.
>
> Looks like the i.MX8M Mini. The naming of the i.MX8 variants seems to
> be almost deliberatly confusing.

So they put some yet non-existing chip first in their priority list and
totally abandoned i.MX8MQ that is just year (?) old. Of course, they needed
yet another undocumented chip badly so everything else could wait. Then
there will be yet another one and so on. I bet i.MX8MM documentation will be
even worse than that of i.MX8MQ that is almost impossible task -- that pile
of manure was created by copypasting pieces from those different IPs they
somehow glued together to make that chip. Those pieces were not edited, no
glue description, many pieces are totally missing and so on. This is not
what one would expect from a company that is supposed to be a decent
semiconductor manufacturer.

It looks like the entire i.MX family is doomed. The last decent one was
i.MX6Q from Freescale. Once they got sold to NXP all that went downhill and
going to its death with constantly increasing speed.

Time to switch to Rockchip and its siblings and totally forget everything
not designed and made in China -- Chinese stuff is at least 2x better than
everything else while at least 2x cheaper. Documentation is way better and
their teams are very active here in U-Boot development unlike NXP.

> I haven't had to do much with the documentation, but yeah it's kind of
> inscrutable. Just finding anything is challenging.

If it is there at all. Like e.g. USB PHY. Or ethernet clocks. Or hundreds of
other things. Then one should somehow sort out what actually applies to this
particular chip and what just came in from copypasted IP desription and
totally bogus.

>>> I guess that everything else must just happen to be usable in the
>>> default reset state.
>>
>> It won't work. Pins come up as GPIOs on powerup and something _MUST_
>> reconfigure them for Ethernet. If there is no driver and they are not
>> reconfigured in board files there will be no Ethernet.
>>
>> Same is true with USB. DTS files reference USB PHY that doesn't have a
>> driver in U-Boot. DWC3 USB references driver that doesn't exist in U-Boot.
>> There is no wonder nothing works.
>
> Sorry, I meant stuff like the usdhc (i.e., the bare minimum that needs
> to work to boot into Linux). Something must do at least some
> initialisation here to load U-Boot in the first place. I'm guessing
> the Ethernet doesn't work for anyone using this chip at the moment on
> the upstream U-Boot.

USDHC is initialized in non-DM fashion in SPL so it is still same old
thing...

As for Ethernet not working it is far from a single defficiency. There is no
USB, no PWM, no any signs of Video (LCDIF and friends) and much more. But
hey, they are busy working on that i.MX8MM that doesn't even exist yet so
we're good :(

That means we either have to take everything in our own hands and forget
about NXP or switch to something better. That actually makes sense -- what
would be the reason for holding on NXP vaporware when there are better,
cheaper, actively developed chips like e.g. RK3328 or even RK3399? Just look
at www.pine64.org and try to give a single reason why one would even think
of using any of those NXP chips. And whatever is on pine64.org is real,
existing things. I do even have ROCKPro64 on my desk now that I paid a
whopping $79 for the whole SBC with 4GBytes of RAM.

And there is even stock Fedora for Pine64 family...

Unfortunately our higher-ups made their choice in favor of i.MX8MQ on some
SOMs so I have no other choice but working on that Frankenstein...

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