STM32MP1 von ST

Cortex schrieb:
> Für die Vivante-GPUs gibt es Opensource Treiber.

Wo steht das?

Cortex schrieb:
> 
https://www.heise.de/newsticker/meldung/STM32MP1-ARM-Kombiprozessor-von-STMicroelectronics-4313997.html

Klingt für mich erstmal interessant aber ich mag schon den Namen 
OpenSTLinux nicht. Das hört sich für mich wieder sehr nach Vendor-Lockin 
an.

Harry L. schrieb:
>> Cortex schrieb:
>> Für die Vivante-GPUs gibt es Opensource Treiber.
>
> Wo steht das?

Vivante hat einen zweigeteilten Treiber. Der Teil im Kernel-Space ist 
Open-Source und der (größere bzw. wichtigere) Teil im User-Space ist 
Closed-Source:
https://en.m.wikipedia.org/wiki/Free_and_open-source_graphics_device_driver

Es gibt auch eine reverseengineerete Variante des User-Space Treibers, 
welche quelloffen ist:
https://github.com/etnaviv/etna_viv

Hmm, mal schauen ob ST mit dieser Serie Erfolg haben wird. Es ist die 
selbe Klasse, die NXP mit den i.MX-Serien und TI mit den Sitaras 
adressiert.

Nachteil solche Dinger einzusetzen sehe ich vor allem in 
Kosten+Zeit+Risiko ein Layout in Finepitch-BGA mit DRAM-Anbindung zu 
erstellen und zu qualifizieren.

ST hat es bei den STM32 im Griff hunderte verschiedene Varianten 
herzustellen. Da könnten die doch die SoCs gleich mit integriertem DRAM 
herstellen. Also ein Prozessor-Die und ein DRAM-Die, welche dann von 
denen zusammengebonded werden. Davon gibt es dann Varianten mit 256 MB 
RAM, 512 MB RAM, 1 GB RAM etc.

Dann spart man sich den Aufwand das RAM auf der Platine anzubinden und 
das Layout wird gleich auch kompakter.

Sowas gibt es in wenigen Ausführen schon bei NXP und bei TI (von Octavo 
Systems), aber da gibt es keine Flexibilität bei den RAM-Größen.

Gerd E. schrieb:
> Nachteil solche Dinger einzusetzen sehe ich vor allem in
> Kosten+Zeit+Risiko ein Layout in Finepitch-BGA mit DRAM-Anbindung zu
> erstellen und zu qualifizieren.

Sehe ich auch so aber es gibt ja mehr als genug Produzenten wie etwa 
Phytec oder Olimex für die BGA kein Problem ist und bei denen man sich 
dann ein SoM kaufen kann. Das ist ja bei TI und NXP auch nicht anders, 
von Octavo Systems mal abgesehen.

Gerd E. schrieb:
> ST hat es bei den STM32 im Griff hunderte verschiedene Varianten
> herzustellen. Da könnten die doch die SoCs gleich mit integriertem DRAM
> herstellen. Also ein Prozessor-Die und ein DRAM-Die, welche dann von
> denen zusammengebonded werden.

Das wäre für kleinere Stückzahlen sicher interessant aber die Frage ist 
ob ST das auch wirtschaftlich interessant findet.

Dr. Sommer schrieb:
> Das ist aber bei allen Systemen dieser Art so.

Das heißt aber nicht, daß man es nicht besser machen und damit einen 
Vorteil am Markt bekommen könnte.

Vor allem wenn man wie ST neu in diesem Marktbereich ist. Ein müdes "mee 
too" mit einem zuerst mal überschaubarem Portfolio reißt da bekanntlich 
niemanden vom Hocker.

> RAM und CPU auf
> einem Chip unterzubringen ist halt nicht so einfach.

Ich muß zugeben, daß ich mich im Bereich Chipfertigung nicht so gut 
auskenne.

Wo ist da jetzt genau das Problem?

Entweder packe ich die Dies nebeneinander, so wie es jetzt z.B. AMD bei 
den neuen Epycs macht oder ich glaube Mediatek schon länger bei 
Prozessoren und Mobilfunk-ICs macht, die so zusammen in ein Gehäuse 
gepackt werden. Nachteil ist, daß ich etwas mehr Fläche brauche um 
beides nebeneinander unterzubringen. Hätte aber gleich auch den Vorteil 
von etwas gröberem BGA-Pitch, was mir hinterher das Fanout vereinfacht 
und die Produktion verbilligt. Man darf es natürlich nicht übertreiben, 
größer als vielleicht 20x20 sollte es nicht werden.

Oder ich packe die Dies übereinander. Broadcom hat z.B. bei den SoCs für 
den RasPi ja dieses Package-on-Package. Das braucht natürlich in der 
Fertigung der Platine spezielle Maschinen, das will man daher eigentlich 
nicht. Aber statt der Fläche für die Balls oben auf dem Gehäuse, könnte 
man da sicher auch gleich das RAM draufbonden. Das dürfte vermutlich nen 
Tick teurer in der Fertigung sein.

Beide Varianten sparen mir als Gerätehersteller aber einiges bei den 
Entwicklungs- und vermutlich auch Fertigungskosten.

Gerd E. schrieb:
> Vor allem wenn man wie ST neu in diesem Marktbereich ist. Ein müdes "mee
> too" mit einem zuerst mal überschaubarem Portfolio reißt da bekanntlich
> niemanden vom Hocker.

Ich vermute mal das sie den Markt schon gut abgeklopft haben und 
potentielle Kunden schon gesagt haben was sie gerne hätten. So wie das 
Ding aussieht könnte ich mir gut vorstellen, dass das zukünftig viel in 
weißer Ware zu finden sein wird, wo die Stückzahlen aber auch hoch genug 
sind, so dass die sich um ein komplexeres PCB-Design keine sorgen machen 
und lieber den Chip für 50 Cent weniger nehmen bzw. flexibler in der 
Ausstattung mit RAM sind.

Mich würde (für persönliche Basteleien) mal interessieren in wie weit 
der Cortex-M Zugriff auf den DDR-RAM hat. Laut Busmatrix aus dem 
Datenblatt sollte es jedenfalls gehen. Gerade für messtechnische 
Anwendungen ist das genial wenn der (niedriglatente) uC Daten per DMA in 
einen großen Buffer schreiben kann und ein dickerer 
Applikationsprozessor diese dann weiterverarbeiten kann. Bei den Sitara 
von TI ist es jedenfalls möglich, was ja erst die Verwendung eines 
Beaglebone als Logic-Analyzer sinnvoll möglich macht aber ich habe mich 
mit den PRUs nicht so wirklich im Detail auseinandergesetzt, weil mir 
das alles etwas zu sehr TI-spezifisch ist. Da Begrüße ich es, dass als 
Coprozessor ein Cortex-M4 drin steckt. Von daher sehe ich das mit dem 
"me too" auch nicht so eng, weil der einzige mir bisher bekannte 
Hersteller solcher Cortex-M+Cortex-A Kombis bisher NXP ist (von Apple 
mal abgesehen).

Masser schrieb:
> Welche linuxtauglichen Chips mit einer GPU die mainline unterstützt wird
> und einem µc drin gibt es den noch?

Das sind die i.mx 7 von NXP

Edit: Sorry, die haben keine GPU. i.mx8 sollte eine haben, ist aber mWn 
auch noch nicht verfügbar.

Noch ein Nachtrag: TI hat mit den Sitara AM654 eine Combi aus Quad-Core 
Cortex-A53 und Cortex-R5F vorgestellt:
https://www.cnx-software.com/2018/10/04/texas-instruments-am654-64-bit-arm-processor/
Ist aber auch noch nicht auf dem Markt und wohl eher was für 
Atom-U-Boote als für Waschmaschinen ;)

Also Cortex-A mit RAM drauf gibts von ex Atmel:
https://www.microchip.com/wwwproducts/en/ATSAMA5D27C-D1G

Der STM klingt dank OpenSTLinux schonmal uninteressant.
Entweder da läuft der Mainline Kernel drauf mit Debian/Arch rootFS oder 
GTFO!

Fürs Basteln vielleicht Debian/Arch rootfs. Für einen Serieneinsatz 
besser ein schlankes Yocto.
Ti AM6 SOM gibt's anscheinend schon von Phytec.
Mal schauen ob da auch der STM kommt...

Yocto ist doch keine Distri, sondern eine Toolsammlung um sich sein 
gewünschtes Linux zusammenzustöpseln?

Ja, hab ja nicht behauptet daß es eine Distribution ist.
So wie du es geschrieben hattest, hatte ich gedacht du willst ein Debian 
wie beim RPi mit Paketmanager und allem auf dem Dingen haben.

Interessant ist auch der Polarfire SOC von Microsemi.
Bin mal gespannt was da so geht mit Microchip im Rücken...

Dirk schrieb:
> Bleibt noch die Frage offen wie die verschiedenen Cortexe miteinander
> reden können.

Siehe Anhang; AHB-Bus und AXI-Interconnect sind asynchron miteinander 
verbunden.

Bin eben über die EW gelaufen..
Und beim Phytec Stand hängt tatsächlich ein STM32MP1 Modul rum...
Aber noch early Alpha..

@Björn Kalkbrenner
Danke fürs stöbern, das klingt ja dann doch echt vernünftig.
Mit dem RasPI hab ich den STM jetzt aber nicht verglichen.

Die MMU sitzt zwischen Cortex-A und AXI.
Der Cortex-M hat die bekannte MPU.

Also voreinander schützen geht nur zweigeteilt in dem der Cortex-M4 per 
MPU gehindert wird in den Linuxadresspace reinzugrätschen.

Zum Datenaustausch über Shared Memory gibts Hardware Semaphoren.

STM32User schrieb im Beitrag #5753058:

> einschlägigen verdächtigen (RS, Farnell,...) verfügbar sein wird? Haben
> sie das auf der embedded World verraten?

(Ende) April, dann allerdings Alles (Devkits, Eval-Kits und die MCUs) 
soll Alles bei den Distributoren erhältlich sein.

Borders schrieb:
> Mw E. schrieb:
>> Also voreinander schützen geht nur zweigeteilt in dem der Cortex-M4 per
>> MPU gehindert wird in den Linuxadresspace reinzugrätschen.
>
> Schön ist das nicht, wenn ein Bug in der Cortex-M Software die Cortex-A
> kompromittieren kann. Dann sich ST das ganze Trustfoo eigentlich
> komplett schenken.

So sehr hab ich mich mit Trustzone noch nicht auseinander gesetzt.
Aber da es eh hackbar ist: 
https://blog.acolyer.org/2017/09/21/clkscrew-exposing-the-perils-of-security-oblivious-energy-management/
werd ichs in nächster Zeit wohl auch nicht.

@LinuxMan
lern mal zitieren im Zitat von mir gehts um Adresspaces und MMU, 
Trustzone kam erst später.

@Topic.
Der Vorteil besteht zumindest darin, dass man die Peripherie und deren 
Treiber schon kennt und jetzt gibts das auch mit "dicken" Cortex-A 
Kernen.

Ich hätte ja nicht erwartet, dass es sooo schnell geht mit den SOMs. 
Gibts da schon Infos zu den Preisen?

Hmm, auch da keine Preise. Naja, ist ja auch noch alles ganz frisch. 
Wenn ST es nicht komplett vermasselt dürfte das Teil schon gut ankommen, 
vor allem im Bereich HMI. Dank OpenGL ES ist das Teil eigentlich 
prädestiniert dafür, selbst wenn die eigentlichen Cortex-A Kerne nicht 
so üppig vom Takt sind.

Octavo Systems hat auch ein System-in-Package mit dem STM32MP1 
angekündigt:
https://octavosystems.com/octavo_products/osd32mp15x/

Aber auch da noch keine Preise oder Lieferzeiten verfügbar.

123 schrieb:
> PS. Auf der EM2019 sind laut gut informierten quellen die ersten DK2 an
> interesierte Messebesucher verteilt worden.

Falls Du statt "EM" "EW" gemeint hast, kann ich das aus erster Hand 
bestätigen. :)

Falls es hier noch andere Mitleser gibt, die ein DK2 bekommen haben: 
Funktioniert bei Euch die Bluetooth-Demo?

Ich bekomme schon beim Booten einen Timeout vom hci_uart-Treiber und 
beim Versuch, die Demo zu starten noch mal. Jetzt frage ich mich, ob es 
ein Software-Problem ist oder ob auf meinem Board der BT-Chip einen Hau 
hat.

123 schrieb:
> Zum Thema Octavo:
> Hab mich auf der EW2019 gewundert wieso die mit auf dem ST stand stehen.
> Kenne die bisher nur vom Beaglebon / Sitara. Laut deren Aussage wird es
> erstmal nur eine Variante mit den ganz grossen MP1 geben mit 1GB Ram.
> Verfügbarkeit war so gegen Ende Q3 bzw Q4 2019 geplant. Preise wurden
> nicht genau genannt, aber gehen so gegen 20 - 30$. Laut Octavo soll es
> dann auch Beaglebone Variante mit MP1 geben. Verfübarkeit auch so gegen
> ende 2019.

Danke für die Infos.

Hast Du zufällig von Octavo erfahren, ob die auch noch ein stärkeres 
System-in-Package als bisher bringen wollen? Also z.B. mit TI AM572x und 
PCIe-Bus. Die TI AM335x sind leistungsmäßig für manche Anwendungen 
einfach zu eng.

Hallo Zusammen,

ich arbeite bei Kontron und habe das MP1 SoM mit entwickelt.
Leider kann ich es von der vertrieblichen Seite nicht voll abdecken und 
deswegen zu den Preisen (noch) recht wenig sagen.
Aber zumindest für technische Fragen bin ich empfänglich ;-)

Grüße,
Simon

@dosenkohl

Danke für das Angebot, da habe ich doch gleich ein/zwei Fragen.

Wir haben eine kleine Inhouse Schaltung, die auf einem nativen Cortex-M4 
STM32F407ZGT6 Board als Herzstück basiert. Darin läuft primär ein 1us 
Interrupt, der DAC Werte ausgibt und auf ein paar GPIOs reagiert. Im 
main loop wird noch auf RS232 Eingaben reagiert. Get gerade noch so, ist 
aber langsam eng mit den CPU-Cycles. Deshalb suchen wir ein Board, bei 
dem wir die langsameren Tasks vie RS232 auf eine weitere CPU auslagern 
könnten plus noch ein paar Wünsche wie TCP/IP Zugriffe und ev. ein 
kleiner Webserver.

Fragen:

- Welche GPIO's sind auf Eurem Base-Board herausgeführt ?
- Wie schnell lässt sich so ein GPIO vom M4 aus hoch oder runternehmen ?
- Wie schnell reagiert der DAC auf Aenderungen ?

Beim DAC ist klar, dass er nicht in ein 1us von 0 auf 100% geht, wenn 
der etwas nachläuft ist kein Problem.
Die Fragen nach dem GPIO Speed kommen von Tests mit einem anderen Board 
in der Vergangenheit, welches ebenfalls ein M4 Subprocessor hat (NXP 
i.MX7Dual). Und dort waren die Tests ernüchternd, auf dem nativen M4 ist 
der GPIO in etwas ~10ns oben, auf dem NXP Board 150-200ns.

Danke und Gruss
Daniel

Daniel B. schrieb:

> Die Fragen nach dem GPIO Speed kommen von Tests mit einem anderen Board
> in der Vergangenheit, welches ebenfalls ein M4 Subprocessor hat (NXP
> i.MX7Dual). Und dort waren die Tests ernüchternd, auf dem nativen M4 ist
> der GPIO in etwas ~10ns oben, auf dem NXP Board 150-200ns.

Ja, genau dafür sind ARMs auch eher weniger geeignet. Das hhängt damit 
zusammen, dass die IO-Ports nicht wie bei AVR und PIC (bis PIC24 und 
dsPIC) quasi als Prozessorregister angebunden sind, sondern über einen 
IO-Bus müssen, und wenn das z.B. ein APB ist, ist das eben langsam. 
Speziell für solche Anwendungen sind andere Architekturen wie z.B. TI 
C28xx geeigneter. Die C28xx haben auch sehr gute Peripherieeinheiten, 
sie man so woanders nicht findet. Sind eben speziell für 
Steuerungsaufgaben designt.

fchk

PS: http://www.ti.com/tool/LAUNCHXL-F28379D

Ihr seid also auch der Meinung, dass das hier wohl auch das Problem ist 
?
Ka...e, dann muss ich wohl oder übel eines der TI Boards anschauen 
(danke für den Link), oder ein Linux Board mit einem Cortex-M4/7 Board 
verheiraten. Eigentlich wollte ich:
- den Cortex-M4 Code beibehalten
- mich in keine neue CPU einarbeiten
- Mit Linux die unkritischen (Zeit) Teile erledigen (Unix kenne ich)
- Ein Board mit allem drauf (wir können kein eigenes Board designen)

Danke erstmal für die Antworten. Werde trotzdem mal ein paar einfache 
Tests machen (das Board ist jetzt gekommen). Und ev. meldet sich der 
Simon noch mal.

Cheers.

Man könnt auch einfach mal ins Datenblatt gucken?
Im Blockdiagramm ist doch eindeutig zu sehen, dass der M4 sein eigenen 
AHB hat und an diesem hängen auch die GPIO.

Also ändert sich in diesem belang garnichts zu einem STM32F4 zum MP1.
Der AHb ist mit 209 statt 168MHz sogar noch schneller.

Frank K. schrieb:
> Daniel B. schrieb:
>
>> Die Fragen nach dem GPIO Speed kommen von Tests mit einem anderen Board
>> in der Vergangenheit, welches ebenfalls ein M4 Subprocessor hat (NXP
>> i.MX7Dual). Und dort waren die Tests ernüchternd, auf dem nativen M4 ist
>> der GPIO in etwas ~10ns oben, auf dem NXP Board 150-200ns.
>
> Ja, genau dafür sind ARMs auch eher weniger geeignet. Das hhängt damit
> zusammen, dass die IO-Ports nicht wie bei AVR und PIC (bis PIC24 und
> dsPIC) quasi als Prozessorregister angebunden sind, sondern über einen
> IO-Bus müssen, und wenn das z.B. ein APB ist, ist das eben langsam.

Das ist aber nicht generell für alle ARM-basierten Prozessoren so, 
sondern ist stark vom Design des jeweiligen Prozessors abhängig.

Die STM32MP1 sehen für diesen Zweck gar nicht so schlecht aus: die GPIOs 
hängen lt. Datenblatt an einem AHB mit 209 MHz. Der Cortex-M4 hängt 
direkt am selben AHB. Außerdem haben die GPIO-Ports die von den anderen 
STM32 bekannten BSRR-Register, mit denen man in einem Zyklus und atomar 
bitweise schreiben kann.

@Daniel: ich würd mir an Deiner Stelle also einfach mal das Demoboard 
von ST holen und es kurz ausprobieren.

@fritzler:

Man hat, aber man war sich nicht sicher, was man dort sieht, und vor 
allem ob man sich auch darauf verlassen kann. Du meinst sicher Page 19 
mit dem Block Diagram ?

Deshalb hier die Frage an den Spezialisten, der mit dem Ding schon 
gearbeitet hat.

@robberknight:
Das Board habe ich schon, bin nur noch nicht dazu gekommen, und wenn der 
Spezi gleich gesagt hätte, vergiss es, hätte ich mir die Zeit sparen 
können.

Daniel B. schrieb:

> - Ein Board mit allem drauf (wir können kein eigenes Board designen)

Warum nicht? Kein Geld? Kein Know-How?

fchk

Frank K. schrieb:
> Daniel B. schrieb:
>
>> - Ein Board mit allem drauf (wir können kein eigenes Board designen)
>
> Warum nicht? Kein Geld? Kein Know-How?
>
> fchk

Sowohl als auch und eine Richtofferte bei einem Ingenieurbüro hier in 
der Schweiz hat unser Budget leicht gesprengt. Respektive ist für eine 
Stückzahl kleiner 20 in keinem Verhältnis.

Man kann doch auch aus CubeMX ein Makefile erzeugen oder geht das etwa 
für den CM4 des MP1 nicht?

pegel schrieb:
> Tester schrieb:
>> Die fette AC6 IDE lädt nicht zum entwickeln ein.
>
> Aber die erzeugt dir dein Makefile.

Aber das ist doch totaler Käse.

Dann könntest du mal das CubeMX2Makefile-Skript ausprobieren, das frisst 
nämlich AC6-Projekte:

https://github.com/baoshi/CubeMX2Makefile

Ob es funktioniert weiß ich nicht, weil das zuletzt nur für CubeMX 4.x 
gedacht war, weil ja CubeMX seitdem eigentlich Makefiles generieren 
kann.