Forum: Mikrocontroller und Digitale Elektronik STM32MP1 von ST


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Cortex (Gast)


Lesenswert?

Cortex-M4 + 2 * Cortex-A7 + Vivante GPU.

Für die Vivante-GPUs gibt es Opensource Treiber.

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

von Harry L. (mysth)


Lesenswert?

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

Wo steht das?

von Christopher J. (christopher_j23)


Lesenswert?

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

von Cortex (Gast)


Lesenswert?

Harry L. schrieb:
> Wo steht das?

Das Librem 5 verwendet genau aus diesem Grund einen i.MX 8 als SOC weil 
dieser eine opensource fähige Vivante-GPU verbaut hat.

von Cortex (Gast)


Lesenswert?

Christopher J. schrieb:
> 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.

ST sagt mainline: "STM32CubeMP1 and full mainline open-source Linux® 
STM32 MPU OpenSTLinux Distribution (such as STM32MP1Starter) software 
and examples" -> 
https://www.st.com/en/evaluation-tools/stm32mp157a-dk1.html

von Gerd E. (robberknight)


Lesenswert?

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.

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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.

Das ist aber bei allen Systemen dieser Art so. Wenn man die Leistung 
braucht, muss man da eben den Speicher unterbringen. Ob jetzt in Form 
eines Moduls wie bei Octavo oder auf einem Custom PCB. RAM und CPU auf 
einem Chip unterzubringen ist halt nicht so einfach.

von Gerd E. (robberknight)


Lesenswert?

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.

von Masser (Gast)


Lesenswert?

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.

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

Mir ist da nichts bekannt.

von Christopher J. (christopher_j23)


Lesenswert?

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 ;)

: Bearbeitet durch User
von Cortex (Gast)


Lesenswert?

Christopher J. schrieb:
> 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/

PowerVR hat nur Treiber Blobs.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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!

von No Y. (noy)


Lesenswert?

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...

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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

von No Y. (noy)


Lesenswert?

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...

: Bearbeitet durch User
von pegel (Gast)


Lesenswert?

STM32CubeMX Version 5.1.0 unterstützt teilweise schon die Konfiguration 
des "Neuen".
SW4STM32 compiliert das Ergebnis erfolgreich.

Theoretisch blinkt schon eine imaginäre LED auf meinem imaginären $99 
STM32MP157C-DK2 Board.

von Dirk (Gast)


Lesenswert?

Auch sehr charmant:

 it is possible to map, at boot, almost all peripherals in the 
connectivity
 and analog units in the block diagram above to either the Cortex-M4 or 
the
 Cortex-A7

https://blog.st.com/stm32mp1-mpu-stm32mp157a-ev1-stm32mp157c-dk2/

Bleibt noch die Frage offen wie die verschiedenen Cortexe miteinander 
reden können.

von Johnny B. (johnnyb)


Angehängte Dateien:

Lesenswert?

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.

von Björn Kalkbrenner (Gast)


Lesenswert?

Bevor auf Yocto und OpenSTLinux rumgehackt wird:

Yocto ist ein "Distributionsbuilder" und eine Zusammenstellung aus 
OpenEmbedded, Bitbake und ein paar zusätzlichen Layern (Sammlungen von 
Programmrezepten).

OpenEmbedded ist schon recht erwachsen, sehr gut dokumentiert (siehe 
Yocto Mega Manual), extrem aktiv (kommt aus der Richtung OpenZaurus, 
Dreambox, ...) und wird viel komerziell sowie auch im OpenSource bereich 
genutzt - bzw viel wichtiger, ist offiziell unter der Schirmherrschaft 
von der Linux Foundation. Es setzt sich langsam als Quasi-Standard für 
derartiges Gefrickel durch. Wir nutzen bei uns in der Firma Yocto mit 
Layern von Freescale/NXP MCUs.

Distributionen bei Yocto sind eigentlich nur Konfigurationen, was aus 
Yocto (Versionen, ...) wie genutzt wird.

Es ist relativ leicht, sich mit Yocto saubere, funktionierende Pakete 
und "Distributionen" für Hardware zu erstellen, für die es BSPs gibt. 
Das ist mir tatsächlich allemal lieber als der Distributionsbuilder von 
Debian oder Ubuntu. Yocto unterstützt ebenfalls Paketformate (RPM, opkg, 
...), je nachdem, was man verwenden möchte. Und CrossCompiling möchte 
ich persönlich tatsächlich lieber in einem Yocto-Umfeld pflegen als mit 
Debian (ich maße mir mal an, das anzumerken, ich nutze Beides).

Ich habe mir das OpenSTLinux am Freitag mal angeschaut und 
durchkompiliert. Auf den ersten Blick ist das sehr saubere Arbeit, was 
STM da veröffentlicht hat. Die genutzte Version von Yocto ist "thud", 
das ist die Aktuellste stable vom November (ca Halbjahres-Zyklus).

Bis auf ein paar Custom-Scripte (um die Arbeit mit Yocto zu 
vereinfachen) ist das aber Alles nah am Yocto-Konzept. Die Integration 
des M4-Kerns über OpenAMP scheint auch recht sauber zu sein.

Ich bastel mal eine Runde damit. Ich kenne natürlich nicht Alles auf dem 
Markt aber - bisher ist STM der erste Hersteller den ich kenne, der eine 
"Linux-MCU" auf den Markt bringt, wo die komplette Toolchain offen ist 
und ohne wildes Mainline-Vendor-Kernel forking auskommt. Und für mich 
als Frickler fühlt sich das STM32MP1 Kram sehr sehr gut an.

von No Y. (noy)


Lesenswert?

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

von Björn Kalkbrenner (Gast)


Lesenswert?

Mw E. schrieb:

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

Wenn ich nicht ganz irre, sind die ersten STM32MP157 Patches schon im 
März 2018 beim Linux Mainline sowie bei u-boot eingereicht worden und 
seitdem folgen stetig neue Patches.
Laut Infos am Stand auf der EW2019 sind wohl bisher ca. 80% der Patches 
aufgenommen worden - ob das stimmt weiss ich nicht, da müsste ich mal 
schauen. Dass aber auf der LKML Patches dafür zu finden sind ist Fakt. 
Die Patches sind auch im Yocto-Layer zu finden.

Es könnte also durchaus sein, dass der Mainline Kernel jetzt schon out 
of the Box laufen könnte. Die Frage ist - will man das, ergibt das Sinn? 
Womit vergleicht man das? Mit einem Raspberry? Äpfel und Birnen.

Das ist die erste Generation von der Chipfamilie und auch kein 
Raspberry-PI Ersatz. Das Ding hat nen A7 + M4 in einem Gehäuse und 
bietet das, was der Raspberry z.B. nicht kann und was mir bisher gefehlt 
hat - echte uC-Fähigkeiten auf den GPIO's (wie z.B. Hardware-PWM etc).

Spannend wird, was es neben dem offiziellen STM32MP157A-DK1 und 
STM32MP157C-DK2 längerfristig noch für Boards (für private 
Frickler/Maker) geben wird, die diese MCU nutzen. Das DK1 und DK2 wird 
vom Preis her schon für Maker eher uninteressant sein, da muss schon was 
von anderen Herstellern kommen.

Beruflich finde ich das MP1-Konzept mit der Toolchain auf jeden Fall 
sehr spannend.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

@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.

von Borders (Gast)


Lesenswert?

Johnny B. schrieb:
> Siehe Anhang; AHB-Bus und AXI-Interconnect sind asynchron miteinander
> verbunden.

Bleibt die Frage wo sitzt die MMU die die Adressspaces der verschiedenen 
Cortexe voreinander schützt?

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Borders (Gast)


Lesenswert?

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.

von STM32User (Gast)


Lesenswert?

Weiß jemand ab wann das STM32MP157C-DK2   vorraussichtlich bei den 
einschlägigen verdächtigen (RS, Farnell,...) verfügbar sein wird? Haben 
sie das auf der embedded World verraten?

von Björn K. (terminar)


Lesenswert?

STM32User schrieb:

> 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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

Mw E. schrieb:
> So sehr hab ich mich mit Trustzone noch nicht auseinander gesetzt.
> Aber da es eh hackbar ist:

TrustZone ist eh böse - das Absurde an diesen ganzen 
"Trust"-Technologien ist ja, dass es keineswegs um das Vertrauen des 
Nutzers in die Technik geht, sondern um das Misstrauen der Hersteller 
den Nutzern gegenüber. Dem Nutzer werden Zugriffe und Rechte entzogen 
unter dem Vorwand des Urheberrechts-Schutzes (DRM & Co). Praktisch jeder 
ARM-Anwendungsprozessor kommt ab Werk mit einer proprietären 
undurchsichtigen "Trusted"-Software, welche die eigene Anwendung 
beliebig überwachen, manipulieren und Daten abgreifen kann. Die Backdoor 
wird hier als Feature angepriesen. Von daher kann man TrustZone-Hacks 
nur begrüßen.

von STM32MP1 liebäugler (Gast)


Lesenswert?

Mw E. schrieb:
> 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.

Diese Hoffnung hatte ich auch. Das Refman RM0436 Rev.2 (Seite 1040) 
interpretiere ich so, dass nur die A7-Kerne mit den HW-Semaphoren 
funktionieren. Das ist dann irgendwie ein Witz. Für die Synchronisation 
zwischen den A7 gibt es von ARM-Standards (SWP, LDREX/STREX), da brauche 
ich keine proprietäre ST-Peripherieeinheit. Ich habe noch keine 
Mögichkeit gefunden, wie die A7-Domäne mit dem M4 synchroniert werden 
kann.
Vielleicht habe ich in den 4017 Seiten Doku noch etwas übersehen ;-)

von LinuxMan (Gast)


Lesenswert?

STM32MP1 liebäugler schrieb:
> Mw E. schrieb:
>> 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.

Das ist doch nicht Sinn und Zweck der Trustzone.
Das Linux soll im nicht sicheren Kontext auf dem A7 ausgeführt werden. 
Die (kritischen) Echtzeit-Prozesse dagegen auf dem M4. Daher die 
Trennung.
Insbesondere, da ja da Linux üblicherweise über z.B. Ethernet vernetzt 
ist und somit Angriffsfläche bietet. Im Falle der Kompromittieruung ist 
dann das Kernsystem nicht betroffen und kann Schutzmassnahmen einleiten.

>> Zum Datenaustausch über Shared Memory gibts Hardware Semaphoren.
>
> Diese Hoffnung hatte ich auch. Das Refman RM0436 Rev.2 (Seite 1040)
> interpretiere ich so, dass nur die A7-Kerne mit den HW-Semaphoren
> funktionieren. Das ist dann irgendwie ein Witz. Für die Synchronisation
> zwischen den A7 gibt es von ARM-Standards (SWP, LDREX/STREX), da brauche
> ich keine proprietäre ST-Peripherieeinheit. Ich habe noch keine
> Mögichkeit gefunden, wie die A7-Domäne mit dem M4 synchroniert werden
> kann.
> Vielleicht habe ich in den 4017 Seiten Doku noch etwas übersehen ;-)

Zur Kommunikation zwischen dem A7 und M4 Kontext ist der IPCC (inter 
process communication controller) da.

von wumpe (Gast)


Lesenswert?

Bin ja mal gespannt, ob Sie damit einen Platz zwischen NXP i.MX, TI 
Sitara, und Renesas RZ finden.


Ich glaube in den Bereichen wo ich hier den STM32MP1 sehe, würde ich 
eher zum RZ/A oder einem Sitara greifen.

Naja, wenn ich an meinen früheren Chef denke … da war sehr strikt der 
gleiche Hersteller gesetzt -> STM32F irgendwas im Einsatz, … es soll 
irgendwas mit Linux gemacht werden -> es steht nur der STM32MP1 zur 
Auswahl :D. Allerdings war es bei ihm ATMEL ;), der wird dann wohl auch 
kein Kunde.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

@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.

von Maier (Gast)


Angehängte Dateien:

Lesenswert?

Recht kleines (25.4 x 25.4mm) Modul damit: 
http://linuxgizmos.com/linux-driven-stm32mp1-module-measures-less-than-one-square-inch/

Da könnte sich ST glatt erbarmen einen STM32MP1 auf ein Nucleoboard zu 
setzen.

von Christopher J. (christopher_j23)


Lesenswert?

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

von Cghgf (Gast)


Lesenswert?


von Christopher J. (christopher_j23)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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.

von 123 (Gast)


Lesenswert?

Malzeit,
Es war schon erstaunlich was für einem Aufgebot an Partnern ST auf der 
EW2019 rund um den MP1 auf ihrem Stand versamellt hat. Von einer Firma 
aus Leipzig mit einem eigenen Board, Octova mit der angkündigung von 
System on chip, Software Firmen wie Tara, Ubuntu, ...

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.

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

von R. M. (rmax)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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.

von 123 (Gast)


Lesenswert?

Hallo,

Frag nach, die sind da offen was so was angeht, ... hängt natürlich auch 
immer von der Stückzahl ab. Wir hätten eher am kleinsten MP1 mit 
geringerem Speicherausbau interesse. Es war kein generelles nein, 
sondern eher wenn genug Stückzahl/nachfrage können Sie sich das durchaus 
vorstellen ... wobei 25k pro Jahr sich nach untere Mindestmenge angehört 
hat.

Und ja natürlich meinte ich die EW2019 in Nürnberg.

von Blume (Gast)


Lesenswert?

Hallo,

Ich war heute auf dem Hands On Workshop zum Stm32mp1 in Stuttgart. Sehr 
interessant!

Dort lagen auch ein System on Module (SOM) von emtrion und eines von 
kontron aus. Es gibt wohl noch etlich weitere Anbieter solcher Module. 
Leider findet man nirgends eine Preisliste.

Hat jemand schon Preise für solche Module?

Mit freundlichen Grüßen
Blume

von Simon G. (dosenkohl)


Lesenswert?

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

von Daniel B. (dbuergin)


Lesenswert?

@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

von Frank K. (fchk)


Lesenswert?

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

: Bearbeitet durch User
von Noy (Gast)


Lesenswert?

AM335 mit PRU (älter)
Oder AM5 und bald AM6 ist das was deine Firma sucht...

von Daniel B. (dbuergin)


Lesenswert?

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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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.

: Bearbeitet durch User
von Daniel B. (dbuergin)


Lesenswert?

@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.

: Bearbeitet durch User
von MP1 Tester (Gast)


Lesenswert?

Ich möchte kein yocto basiertes Bildsystem für den STM32MP1 verwenden, 
sondern ein System mit Debian auf Packetbasis.

Wie kommt man am einfachsten dorthin ?

Beispiel: i.mx8 Debian 10

hier sehr schön und einfach gemacht:

http://variwiki.com/index.php?title=DART-MX8M

von Frank K. (fchk)


Lesenswert?

Daniel B. schrieb:

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

Warum nicht? Kein Geld? Kein Know-How?

fchk

von Daniel B. (dbuergin)


Lesenswert?

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.

von Tester (Gast)


Lesenswert?

Hat jemand schon mal ein makefile für den M4 des STM32MP1 für 
STM32CubeMX-Apps gesehen?

Die fette AC6 IDE lädt nicht zum entwickeln ein.

von pegel (Gast)


Lesenswert?

Tester schrieb:
> Die fette AC6 IDE lädt nicht zum entwickeln ein.

Aber die erzeugt dir dein Makefile.

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Tester (Gast)


Lesenswert?

Christopher J. schrieb:
> Man kann doch auch aus CubeMX ein Makefile erzeugen oder geht das etwa
> für den CM4 des MP1 nicht?

nein kann man nicht, nur für Toolchain/IDE SW4STM32 (ac6).

makefile ist ausgegraut.

von Christopher J. (christopher_j23)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.