On Fri, 1 Feb 2019, Chris Spencer wrote:
On Fri, 1 Feb 2019 at 16:10, Sergey Kubushyn <k...@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@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
