Frage steht ja schon, versprochen waren sie ja zum 2ten Halbjahr 2018. Jetzt ist schon fast das erste Quartal 2019 vorbei und es gibt noch nichteinmal Samples (für die kleinen). Weiß da einer etwas genaueres, es stehen ja noch nichtmal Anleitungen bereit.
Moin, Ich schaetz' mal: Vor der Embedded World nicht mehr, und danach nicht gleich :-) Gruss WK
Also wie beim sechser wahrscheinlich ein Jahr später. Ich frag mich immer noch ob die immer besser werdenden Rockxxx aus China nicht bald den Rang ablaufen. Ich warte es dann nochmal ab,
Moin, Rang ablaufen in was? Bumms und Preise? Da hab' ich schon seit Jahren ganz stark den Eindruck, dass in fast jeder chinesischen Garage solche SoCs in schneller, besser und billiger zusammengedengelt werden. Die einzige Hoffnung bei NXP wird dann die Verfuegbarkeit von Datenblaettern und Chips in kleineren Stueckzahlen sein. Gruss WK
Was die billigen SoCs der Chinesen völlig unbrauchbar macht, ist die unvollständige Dokumentation. Gerade der Grafikkern ist da gerne mal nur über einen Binärblobtreiber für einen bestimmten Linuxkernel verwendbar. Das ist einfach Schrott, da nützt es wenig wenn man die Teile quasi geschenkt bekommt. Man munkelt ja, dass die das machen, um zu kaschieren, dass gegen Patente und Softwarelizenzen verstoßen wird. Das Problem hat der iMX8 halt eben nicht. Solange das alles so bleibt ist der iMX8 konkurrenzlos.
Christopher C. schrieb: > Gerade der Grafikkern ist da gerne mal nur über einen Binärblobtreiber > für einen bestimmten Linuxkernel verwendbar Und das ist beim i.MX nicht so? Sind da die Register vom Grafikchip oder die vom HDMI- oder MIPI-DSI-Transmitter dokumentiert?
Christopher C. schrieb: > Gerade der Grafikkern ist da gerne mal nur über einen > Binärblobtreiber für einen bestimmten Linuxkernel verwendbar. Wenn ARM die Dokumentation zu den Malis nicht rausrückt, dann können Allwinner, Rockchip oder Samsung auch nichts dafür. Und wenn Vivante die Dokumentation zu den GPUs nicht rausrückt, dann können Marvell, NXP oder Rockchip auch nichts dafür. Das hat nichts damit zu tun, was die Hersteller wollen oder nicht wollen, sondern was sie dürfen. Es gibt keine performance, gut dokumentierte GPU für schnelle SoCs - die freien Grafiktreiber zähle ich nicht. Christopher C. schrieb: > Das ist einfach Schrott, da nützt es wenig wenn man die Teile quasi > geschenkt bekommt. Man munkelt ja, dass die das machen, um zu > kaschieren, dass gegen Patente und Softwarelizenzen verstoßen wird. Man munkelt erstaunlich viel Unsinn auf der Welt. Wenn die bösen Chinesen wenigstens eigene CPUs und GPUs in den Chips verbauen würden, könnte man darüber ja spekulieren. Aber da sie die Designs von ARM benutzen und dafür nicht in Grund und Boden geklagt werden... kann man davon ausgehen, dass sie das auch dürfen. In der Zeitung sind die Russen die Bösen. Komisch.
S. R. schrieb: > Das hat nichts damit zu tun, was die Hersteller wollen oder nicht > wollen, sondern was sie dürfen. Es gibt keine performance, gut > dokumentierte GPU für schnelle SoCs - die freien Grafiktreiber zähle ich > nicht. Doch, das hat schon mit wollen zu tun. Wenn sie nämlich wirklich wollten, würden sie selbst eine brauchbare GPU entwickeln, eine Uni eine entwickeln lassen, sich mit anderen in einer Stiftung zusammentun und von denen eine entwickeln lassen oder etwas ähnliches. Daß das geht und was brauchbares bei rauskommen kann, sieht man gerade bei RISC-V. Doch auch da war es so, daß die Initiative nicht von den SoC-Herstellern ausging, sondern von einer Uni und die Hersteller dann erst später mit aufgesprungen sind. Die wollen also nicht unbedingt. Vermutlich weil es erst mal Geld kostet, sich erst in >5 Jahren auszahlt und ein Risiko ist. Aber wenn einer mal anfängt und was brauchbares zustande bringt, wird sich das ziemlich fix durchsetzen.
jun schrieb: > Frage steht ja schon, versprochen waren sie ja zum 2ten Halbjahr 2018. > Jetzt ist schon fast das erste Quartal 2019 vorbei und es gibt noch > nichteinmal Samples (für die kleinen). Ich habe hier ein LibreM 5 Smartphone Entwicklungskit da ist ein i.MX 8M Quad drauf. Der Chip hat allerdings noch einen Bug, der Stromsparmodus funktioniert noch nicht richtig. Das wird in der nächsten Revision korrigiert sein. Auf dem Entwicklungskit wird dieses Modul hier eingesetzt: https://www.emcraft.com/products/868 Dr. Sommer schrieb: > Und das ist beim i.MX nicht so? Sind da die Register vom Grafikchip oder > die vom HDMI- oder MIPI-DSI-Transmitter dokumentiert? Es gibt doch schon einen fertigen offenen Linuxtreiber für die GPU - Läuft mit Wayland. Das Datenblatt bekommt man problemlos von NXP wenn man sich auf deren Webseite registriert. (~6000 Seiten...) HDMI geht, bei MIPI-DSI hackts noch mit dem Display auf dem DevKit, ist aber wohl ein Problem mit dem Display selbst, andere Displays laufen wohl.
Gerd E. schrieb: > Doch, das hat schon mit wollen zu tun. Wenn sie nämlich wirklich > wollten, würden sie selbst eine brauchbare GPU entwickeln, eine Uni eine > entwickeln lassen, sich mit anderen in einer Stiftung zusammentun und > von denen eine entwickeln lassen oder etwas ähnliches. Du hast vergessen, einen sinnvollen Grund zu nennen, warum sie ihre GPUs selbst entwickeln wollen sollten. Es gibt für Firmen wie Allwinner, Rockchip, NXP und so weiter keinen sinnvollen Grund dafür. Das sind Chiphersteller und -verkäufer. Die kaufen fertig getestete, performante Designs mit Support ein und machen daraus ein verkaufsfähiges Produkt. Und wenn in dem Vertrag drinsteht, dass sie die Details nicht veröffentlichen dürfen, dann ist es scheißegal, ob sie das wollen oder nicht. Ein Gegenbeispiel wäre Qualcomm, die entwickeln ihre GPUs (Adreno) selbst. Ich bin mir ziemlich sicher, dass du da noch weniger freie Dokumentation findest als bei ARM. Gilt übrigens auch für deren DSP-Architektur (Hexagon) und deren CPUs (Krait, Kryo).
:
Bearbeitet durch User
S. R. schrieb: > Du hast vergessen, einen sinnvollen Grund zu nennen, warum sie ihre GPUs > selbst entwickeln wollen sollten. Es gibt für Firmen wie Allwinner, > Rockchip, NXP und so weiter keinen sinnvollen Grund dafür. Unterm Strich, auf mehrere Jahre gerechnet, denke ich daß es sich für sie rechnen würde. Entwickelt heute noch einer seinen eigenen Compiler? Nein, die nehmen alle gcc. Da hat sich das also durchgesetzt. Heute blechen sie noch an ARM für die Lizenzen, die meisten stehen aber schon in den Startlöchern auf RISC-V zu wechseln um das vermeiden zu können. > Das sind Chiphersteller und -verkäufer. Die kaufen fertig getestete, > performante Designs genau. Schnell was fast fertiges einkaufen, eintüten und abverkaufen. Fertigung nicht in eigener Fab, die Entwickler aus der Verleihbude oder Outgesourcet,... - Alles nur auf den kurzen Horizont gesehen. Deren Kunden sind aber leider genauso drauf: das neue Smartphone-Modell schnell aus dem Referenzdesign zusammenkopiert, nen paar bunte Gehäusevarianten drumgezimmert, ein Produktionslauf, abverkaufen, fertig. Keine verlässliche Modellpolitik, keine mehrjährigen Updates für die Kunden. Diese Kunden fordern natürlich auch keinen Treiber im Sourcecode, denn sie wollen das Ding ja gar nicht über mehrere Kernelgenerationen hinweg portieren. Ich hoffe daß sich da mal was dran ändert.
Gerd E. schrieb: >> Du hast vergessen, einen sinnvollen Grund zu nennen, warum sie ihre GPUs >> selbst entwickeln wollen sollten. Es gibt für Firmen wie Allwinner, >> Rockchip, NXP und so weiter keinen sinnvollen Grund dafür. > > Unterm Strich, auf mehrere Jahre gerechnet, > denke ich daß es sich für sie rechnen würde. Unter der Voraussetzung, dass: - sie die Kompetenz für sowas bekommen können; - sie die Kosten für die Entwicklung nebenbei schultern können; - das Ergebnis wesentlich besser ist als das, was sie kaufen können. Die Margen für solche Dinge sind winzig. Würden wir selbst entwickeln wollen - wie es vor 15 Jahren der Fall war - wären wir nächstes Jahr pleite und es würde sich nicht rechnen. Zumal in so einem Produkt ja nicht nur eine GPU drin steckt, sondern auch noch ein Haufen anderer IP. > Entwickelt heute noch einer seinen eigenen Compiler? Nein, die nehmen > alle gcc. Da hat sich das also durchgesetzt. Sämtliche CPU-Hersteller entwickeln ihre eigenen Compiler. Man denke an Intels ICC, AMDs PathScale oder ARMs eigenem Compiler. Qualcomm hat was auf LLVM-Basis. Dann gibt es Firmen, die Compiler bauen (wie z.B. Keil). Dass die Welt gcc nutzen würde, ist schlicht falsch. Und wenn du mal ein Auge auf Windows werfen würdest, wo Visual C++ lebt, dann wäre das auch offensichtlich. > Heute blechen sie noch an ARM für die Lizenzen, die meisten > stehen aber schon in den Startlöchern auf RISC-V zu wechseln > um das vermeiden zu können. Wenn ARM schlau ist, entwickeln sie performante RISC-V Cores und verkaufen die. Die ISA mag frei sein, die Implementation ist es definitiv nicht. Und die Chiphersteller sind in der Lage, Chips herzustellen - nicht deren Logik zu entwickeln. Das nennt man eine arbeitsteilige Gesellschaft. >> Das sind Chiphersteller und -verkäufer. Die kaufen fertig getestete, >> performante Designs > > genau. Schnell was fast fertiges einkaufen, eintüten und abverkaufen. > Fertigung nicht in eigener Fab, die Entwickler aus der Verleihbude oder > Outgesourcet,... - Alles nur auf den kurzen Horizont gesehen. Unterschätz das mal nicht. Das mag in manchen Firmen so sein, aber wenn die gesamte Industrie nur auf den kurzen Horizont blickt, dann bist du als Firma ganz schnell pleite, wenn du es nicht tust. Du kannst es ja mal selbst versuchen. > Deren Kunden sind aber leider genauso drauf: das neue > Smartphone-Modell schnell aus dem Referenzdesign zusammenkopiert, > nen paar bunte Gehäusevarianten drumgezimmert, ein Produktionslauf, > abverkaufen, fertig. Das dachte ich vor zwei Jahren auch mal. Inzwischen seh' ich das von innen. Dem ist nicht so. Leider. Wäre es so, könnte man nämlich mal was sinnvolles machen. > Keine verlässliche Modellpolitik, > keine mehrjährigen Updates für die Kunden. Bei uns gibt es drei Android-Versionen. Mehr ist nicht drin, denn die Bedingungen von Google und den Operatören plus den Randbedingungen der Chiphersteller machen es erstaunlich schwierig bis unmöglich, neuere Versionen CDD-konform zu unterstützen. Das fängt schon bei "muss mindestens XX MB/s Encryption Performance haben" an. Wenn der Chip kein HW-Crypto hat, war's das. > Diese Kunden fordern natürlich auch keinen Treiber im Sourcecode, denn > sie wollen das Ding ja gar nicht über mehrere Kernelgenerationen hinweg > portieren. Öh... wir tun das. Wenn du die Open Source-Variante auf das Gerät tust, dann hast du die jeweils aktuelle Kernel-Version für das jeweilige Android. Unabhängig davon, was da ursprünglich drauf war. Für die normalen Images gilt das nicht. Dafür funktioniert nachweislich alles und es ist konform zu den Anforderungen von Google und den Operatören. Sonst dürfte man das nämlich nicht verkaufen. > Ich hoffe daß sich da mal was dran ändert. Ich bin mir sicher, dass sich einiges ändert. Viele Entwicklungen in der Zukunft werden Open Source sein. Deswegen werden sie trotzdem nicht offen sein. Android ist zwar Open Source und unter freier Lizenz, aber kein freies System. Nichtmal im Ansatz. Bei Android Things ist das noch restriktiver. Linux stört das nicht und RISC-V wird daran auch nichts ändern.
Andreas M. schrieb: > Das Datenblatt bekommt man problemlos von NXP wenn man sich auf deren > Webseite registriert. (~6000 Seiten...) Und da stehen die jeweiligen Register drin? Bei der Konkurrenz (TI Sitara) kriegt man zwar auch die Datenblätter, aber die Abschnitte zu HDMI und MIPI und GPU sind leer. Nicht jeder will Linux verwenden - dann ist ein Linux Treiber auch nur begrenzt nützlich.
Man kann sie anscheinend beim Distributor seiner Wahl ab Lager bestellen: https://octopart.com/mimx8mq6cvahzaa-nxp+semiconductors-87220941?r=sp&s=Dl0dUW6-TamNi35iGZgcaQ Habe ich etwas übersehen?
jun schrieb: > Also wie beim sechser wahrscheinlich ein Jahr später. Ich frag > mich > immer noch ob die immer besser werdenden Rockxxx aus China nicht bald > den Rang ablaufen. > Ich warte es dann nochmal ab, Man sollte aber nicht vergessen, dass die i.MX in Richtung Industrial und Embedded zielen, anders als diese Rockchip-Geschichten, die eher Consumerweitig unterwegs sind. Das ist einfach eine komplett andere Baustelle. Die i.MX8 kommen mit industriellem Temperaturbereich, guter Dokumentation, Langzeitverfügbarkeit und Automotive Zertifizierungen. Alles das ist eine Notwendigkeit, wenn man in den Bereich Industrie oder Automotive kommen will. Mit Rockchip ist da kein Blumentopf zu gewinnen. Andreas M. schrieb: > Ich habe hier ein LibreM 5 Smartphone Entwicklungskit da ist ein i.MX 8M > Quad drauf. Der Chip hat allerdings noch einen Bug, der Stromsparmodus > funktioniert noch nicht richtig. Das wird in der nächsten Revision > korrigiert sein. Vorsicht, nicht die i.MX8.. durcheinanderbringen. Der i.MX8M ist kleiner. Da sind 4xCortex A53 drin, der i.MX8 (ohne M) hat zusätzlich 2x Cortex A72. Der i.MX8M ist ein direkter Nachfolger für den I.MX6 Quad, der i.MX8 eher eine neue Klasse. Soweit ich mitbekommen habe, ist der i.MX8M noch nicht im Mainline-Support für den Linux-Kernel, oder ist das inzwischen so? Bin leider kein Linux-Mann, daher bitte mein Unwissen verzeihen.
guest schrieb: > https://octopart.com/mimx8mq6cvahzaa-nxp+semiconductors-87220941?r=sp&s=Dl0dUW6-TamNi35iGZgcaQ > > Habe ich etwas übersehen? Ja, du verwechselst i.MX8 und i.MX8M. Das hier ist ein i.MX8M. Ich finde die Benennung auch ungünstig, aber das hat sich NXP nun mal so eingebildet ;-)
Dr. Sommer schrieb: > Andreas M. schrieb: >> Das Datenblatt bekommt man problemlos von NXP wenn man sich auf deren >> Webseite registriert. (~6000 Seiten...) > > Und da stehen die jeweiligen Register drin? Bei der Konkurrenz (TI > Sitara) kriegt man zwar auch die Datenblätter, aber die Abschnitte zu > HDMI und MIPI und GPU sind leer. Nicht jeder will Linux verwenden - dann > ist ein Linux Treiber auch nur begrenzt nützlich. Na klar. Mit ausführlicher Beschreibung und Berechnungsformeln wie man sie benutzt. Habe letztens erst bei DSI/MIPI nachgelesen um es mit dem Linux Kernel vergleichen zu können. Es gibt nur eine Ausnahme bis jetzt: Der DDR4 RAM Phy Training Code is closed Source, denn muss man einmal am Anfang ausführen damit der DDR4 Ram genutzt werden kann. Aber das kann ich auch verstehen, bei DDR4 RAM steckt ne Menge KnowHow drinnen. soso... schrieb: > Vorsicht, nicht die i.MX8.. durcheinanderbringen. Der i.MX8M ist > kleiner. Da sind 4xCortex A53 drin, der i.MX8 (ohne M) hat zusätzlich 2x > Cortex A72. Danke für die Info. Ich muss gestehen, so genau kenne ich mich mit dem Ganzen auch nicht aus. soso... schrieb: > Soweit ich mitbekommen habe, ist der i.MX8M noch nicht im > Mainline-Support für den Linux-Kernel, oder ist das inzwischen so? Bei PuriSM und Emcraft gibt es entsprechend angepasste Kernel, die sind aber dabei das Mainline zu bekommen. Linux Kernel 4.18 (Mehr oder weniger stable): https://source.puri.sm/Librem5/linux-emcraft Linux Kernel 5.x (Noch in Entwicklung): https://source.puri.sm/Librem5/linux-next
Andreas M. schrieb: > Na klar. Mit ausführlicher Beschreibung und Berechnungsformeln wie man > sie benutzt. Danke, das ist ja sehr interessant. "Klar" ist in Sachen Dokumentation bei SoC's gar nichts, man ist ja schon froh überhaupt irgendwas ohne Linux booten zu können...
jun schrieb: > Frage steht ja schon, versprochen waren sie ja zum 2ten Halbjahr 2018. > Jetzt ist schon fast das erste Quartal 2019 vorbei und es gibt noch > nichteinmal Samples (für die kleinen). Pico-ITX i.MX8M Board Enables Offline Voice Control with Snips https://www.cnx-software.com/2019/02/17/pico-itx-i-mx8m-board-snips-offline-voice-control/
Hmm, scheint so als wolle ST jetzt bei den SoCs auch mitspielen: https://www.st.com/content/st_com/en/about/media-center/press-item.html/p4140.html Ist natürlich erst mal nur ne Ankündigung vor der Messe, aber immerhin sollen die Eval-Boards schon im April lieferbar sein. Das heißt normalerweise, daß das nicht nur heiße Luft mit tatsächlicher Verfügbarkeit erst in weiter Zukunft ist. Und ist natürlich auch nicht die Liga der i.MX8 mit nur 2x Cortex-A7 + 1x Cortex-M4. Aber NXP hat im Bereich SoC ja auch nen paar Jahre Vorsprung.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.