Hey, ich wollte mir ein Linux für STM32F446 Development Board bauen. Dazu gibts es für Buildroot schon zwei Portierungen für das stm32f429_disco_defconfig und das stm32f469_disco_defconfig. Die beiden Boards haben jeweis ein externes SDRAM das auch von bootloader konfiguriert wird (https://github.com/mcoquelin-stm32/afboot-stm32). Mein STM32F446 hat aber leider kein SDRAM. Benötige ich zwingend ein externes SDRAM um Linux zum laufen zu bekommen? oder was muss ich umkonfigurieren damit es nur mit dem internen SRAM geht? Viele Grüße Micha
micha schrieb: > Benötige ich zwingend ein externes SDRAM um Linux zum laufen zu > bekommen? oder was muss ich umkonfigurieren damit es nur mit dem > internen SRAM geht? Linux mit 128kB RAM? Kaum. Linux mit der Lahmarschigen Gurke STM32F4? Noch weniger. Ganz Allgemein würde ich dir ans Herz legen, einen echten Prozessor zu verwenden, nicht ein Spielzeug wie den STM32F4. Willst du damit etwas anfangen, wist du mindestens bei SAMA5 oder i.MX6 UL einsteigen müssen. Darunter ist es im Höchstfall proof of concept, aber nichs brauchbares. Selbst mit einem 500MHz SAMA5 würde ich mir kein brauchbares Desktop-System erwarten. Denn das ist noch unter einem Raspberry-PI angesiedelt. Weit darunter.
micha schrieb: > Benötige ich zwingend ein externes SDRAM um Linux zum laufen zu > bekommen? Ja. Linux kommt mit dem internen RAM nicht zurecht - das ist deutlich zu klein. Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man normalerweise Betriebssysteme mit kleinerem Footprint.
Jim M. schrieb: > Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man > normalerweise Betriebssysteme mit kleinerem Footprint. Durchaus. Aber ich denke er will kein Problem lösen, sondern nur spielen. Ein Linux bekommst du mit sehr viel Mühe auf 3 bis 4 MB RAM runter. Weniger geht nicht. Oder zumindest nicht, ohne massive Codeänderungen. Aber außer als witziges Projekt sehe ich Linux auf STM32F4 nicht als sinnvoll an. Zumal der STM32 keine MMU hat und dardurch das Speichermanagement schon sehr viel overhead hat.
M. H. schrieb: > Zumal der STM32 keine MMU hat und dardurch das > Speichermanagement schon sehr viel overhead hat. Wird der Overhead nicht eher geringer, weil das Umschalten (inkl. TLB leeren, ggf. Cache leeren bei VIVT/VIPT-Cache) beim Kontextwechsel entfällt? Da dann alle Anwendungen im selben Adressraum laufen, hat man halt keine Trennung und die damit einhergehende Sicherheit und Stabilität mehr. Die Frage ist natürlich, was eigentlich erreicht werden soll.
Niklas G. schrieb: > Wird der Overhead nicht eher geringer, weil das Umschalten (inkl. TLB > leeren, ggf. Cache leeren bei VIVT/VIPT-Cache) beim Kontextwechsel > entfällt? Das Problem daran ist, dass der Kontextwechsel nicht entfällt. Alle Programme sind immernoch auf den selben virtuellen Adressraum gelinkt. Nur hat das eben das Problem, dass es keinen virtuellen Adressraum gibt, im näheren Sinne. Das Linux hat ohne MMU mehr Aufwand den Speicherbereich zu organisieren. Hier gibt es eine Übersicht über die speichertechnischen Funktionalitäten: https://www.kernel.org/doc/Documentation/nommu-mmap.txt
Achso, M. H. schrieb: > Das Problem daran ist, dass der Kontextwechsel nicht entfällt. Alle > Programme sind immernoch auf den selben virtuellen Adressraum gelinkt. Ich habe es so verstanden, dass die Programme einfach an unterschiedliche Adressen gepackt werden. Der Code muss dafür Position-Independant sein.
M. H. schrieb: > Jim M. schrieb: >> Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man >> normalerweise Betriebssysteme mit kleinerem Footprint. > > Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme lösen kann. Jetzt muss ich lesen dass Linux doch Dreck ist und man den Stm32 nativ angehen muss...
Micha schrieb: > Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme > lösen kann. Man kann es auch so sehen: Wenn man Linux verwendet, kann man auch dessen Fähigkeit zur Ansteuerung komplexer Prozessoren nutzen und es auf einem Cortex-A mit genug externem RAM laufen lassen. Dadurch erledigen sich die diversen Probleme mit uClinux. Wirklich teurer wird es dadurch nicht.
Micha schrieb: > Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme > lösen kann. Jetzt muss ich lesen dass Linux doch Dreck ist und man den > Stm32 nativ angehen muss... Natürlich sollst du den STM32 nativ angehen. Der STM32 wurde genau dazu entwickelt, um ihn nativ anzugehen. Schließlich ist er ein ja ein Microcontroller. Das steckt schon im Namen. Wer das nicht will, nimmt halt ein vollerwertiges System mit SAMA5. Also mit einem echten Prozessor. Beides hat seine Daseinsberechtigung. Die Einsatzbereiche sind völlig unterschiedlich, nichts davon ist die "einzig seelig machende Wahrheit". Wer harte Echtzeit will, wird sich mit Linux hart tun, hat aber mit dem STM32 leichte Spiel. Wer Netzwerk und Datenbank macht, hat mit dem STM32 viel Code am Hal, aber mit Linux ist das ziemlich einfach. Was willst du denn jetzt genau tun?
Micha schrieb: > Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme > lösen kann. Wer ist "man"? Irgendwelche Vollspacken, die auf der YouTube-Universität ihren Unsinn verbreiten? Oder Du selbst? > Jetzt muss ich lesen dass Linux doch Dreck ist und man den > Stm32 nativ angehen muss... Linux ist keineswegs Dreck, aber eben nicht für beliebige Einsatzzwecke geeignet.
Ja es ist mir bewusst das der STM32 kein Raspi oder Atom ist aber er lag nun mal im Schrank rum. Mein Ziel ist es also es einfach mal zu versuchen. ich bin jetzt so weit das ich eine der buildroot configs angepasst habe. Dann erhalte ich einen bootloader (stm32f446.c) einen devicetree und ein xipImage. Der Bootloader wird an Addresse 0x08000000 kopiert Das xipImage Image an Adresse 0x08008000
1 | #0 0x08000346 in start_kernel () at stm32f446.c:89 |
2 | #1 0x0800045e in main () at stm32f446.c:191 |
3 | (gdb) stepi |
4 | 0x08000348 89 kernel(0, ~0UL, 0x08004000); |
5 | (gdb) where |
6 | #0 0x08000348 in start_kernel () at stm32f446.c:89 |
7 | #1 0x0800045e in main () at stm32f446.c:191 |
8 | (gdb) stepi |
9 | 0x08008000 in ?? () |
10 | (gdb) where |
11 | #0 0x08008000 in ?? () |
12 | #1 0x0800034a in start_kernel () at stm32f446.c:89 |
13 | #2 0x0800045e in main () at stm32f446.c:191 |
14 | (gdb) where |
15 | #0 0x08008000 in ?? () |
16 | #1 0x0800034a in start_kernel () at stm32f446.c:89 |
17 | #2 0x0800045e in main () at stm32f446.c:191 |
18 | (gdb) stepi |
19 | 0x08008004 in ?? () |
20 | (gdb) where |
21 | #0 0x08008004 in ?? () |
22 | #1 0x0800034a in start_kernel () at stm32f446.c:89 |
23 | #2 0x0800045e in main () at stm32f446.c:191 |
24 | (gdb) stepi |
25 | 0x08008008 in ?? () |
26 | (gdb) where |
27 | #0 0x08008008 in ?? () |
28 | #1 0x0800034a in start_kernel () at stm32f446.c:89 |
29 | #2 0x0800045e in main () at stm32f446.c:191 |
30 | (gdb) stepi |
31 | 0x08009230 in ?? () |
32 | (gdb) where |
33 | #0 0x08009230 in ?? () |
34 | #1 0x0800800c in ?? () |
35 | Backtrace stopped: previous frame identical to this frame (corrupt stack?) |
36 | (gdb) stepi |
37 | 0x08009232 in ?? () |
38 | (gdb) Quit |
Er scheint also Tatsächlich noch in den Kernel zu springen. Aber danach kommt ein HardFault Interrupt. Die Ausgabe auf der Seriellen Schnittstelle ist:
1 | stm32-bootH |
Andreas S. schrieb: > Linux ist keineswegs Dreck, aber eben nicht für beliebige Einsatzzwecke > geeignet. Beliebig verwendbar ist Windows doch auch nicht, aber jedet linuxer verspottet es
Fang doch erst einmal mit einer Turing-Maschine an. Das ist ein überschaubares Projekt. Und man kann alles damit berechnen.
micha schrieb: > Ja es ist mir bewusst das der STM32 kein Raspi oder Atom ist aber > er lag > nun mal im Schrank rum. Mein Ziel ist es also es einfach mal zu > versuchen. Nochmal: Ohne externen RAM läuft das nicht. Im Normalfall wird man unter 32 oder 64MByte nie anfangen. Aber einige Leute sollen es schon mit einstelligen MByte geschafft haben. Beispiel: https://electronics.stackexchange.com/questions/240227/minimum-requirements-of-a-microcontroller-to-run-embedded-linux Da erzählt jemand, er hätte einen Minimal-Kernel mit 8MByte hochgebracht. Aber ohne Features. Mit 0,125MBytes (128kB) wird das niemals klappen... Also: Ein (ziemlich wenig praxistaugliches) Proof of concept ist mit dem STM32 möglich, aber nur mit externem RAM. Ohne gehts nicht.
Markus F. schrieb: > Micha schrieb: > aber jedet linuxer > verspottet es > > das arme Windows. Unterschätzt und verkannt. Da ist schon einer :)
Mich würde mal interessieren, ob man auf dem F7Disco den GCC installieren und compilieren könnte: https://github.com/fdu/STM32F746G-disco_Buildroot
eher nicht schrieb: > Ein (ziemlich wenig praxistaugliches) Proof of concept ist mit dem STM32 > möglich, aber nur mit externem RAM. Ohne gehts nicht. Man könnte ja mal einen Blick auf RetroBSD werfen. Das ist zwar nur ein 2.11BSD statt Linux, aber sollte mit 128 KB RAM inklusive Userspace zufrieden sein. Zielt im Augenblick aber auf die PIC32, nicht auf STM32... aber machbar sollte es sein.
Was will man mit einem Linux ohne Netzwerk und das mangels Speicher höchstens ein Anwendungsprogramm ausführen kann? Da bliebt doch vom Betriebssystem nicht Sinnvolles mehr übrig.
Micha schrieb: > Beliebig verwendbar ist Windows doch auch nicht, aber jedet linuxer > verspottet es Nö. Jedes dieser Betriebssysteme hat Einsatzgebiete, auf denen es vorteilhaft. Pauschaler Spott eines "Lagers" beweist nur, dass es bei den jeweiligen Aktivisten nur um picklige Hinterwäldler handelt, die nicht über ihren Tellerrand hinausschauen können. Dies betrifft sowohl das Linux-Lager, Windows-Lager als auch beliebige andere Gebiete, in denen sich solche Aktivisten als besonders progressiv aufspielen können. Und wie so häufig bleibt an dieser Stelle auch nicht der obligatorische Hinweis erspart: https://de.wikipedia.org/wiki/Best%C3%A4tigungsfehler
>Was will man mit einem Linux ohne Netzwerk und das mangels Speicher >höchstens ein Anwendungsprogramm ausführen kann? https://github.com/fdu/STM32F746G-disco_Buildroot Das F7 hat einen Lan-Anschluss.
Cornelius schrieb: >>Was will man mit einem Linux ohne Netzwerk und das mangels > Speicher >>höchstens ein Anwendungsprogramm ausführen kann? > https://github.com/fdu/STM32F746G-disco_Buildroot > Das F7 hat einen Lan-Anschluss. Ich meinte das Linux, dass er in 128kB RAM quetschen wollte. Da ist für den Netzwerk-Treiber und IP Stack kein Platz.
Stefanus F. schrieb: > Was will man mit einem Linux ohne Netzwerk und das mangels Speicher > höchstens ein Anwendungsprogramm ausführen kann? Da bliebt doch vom > Betriebssystem nicht Sinnvolles mehr übrig. Man kann an einem STM32 problemlos einen Netzwerkchip betreiben, z.B. den ENC28J60 (wird von Linux unterstützt). SLIP oder PPP über eine serielle Schnittstelle geht auch problemlos. Vor einigen Jahren hatte ich ein 486er Notebook mit 4 MB RAM und CF-Karte in ein X-Terminal (mit ein paar lokalen Anwendungen) verwandelt. OpenWrt unterstützt viele Router, die auch nicht viel mehr RAM haben. Die D-Box2 mit ihrem 66 MHz-PPC und grad mal 32 MB RAM war auch erstaunlich leistungsfähig. Als Lernübung für eingebettete Systeme ist das nicht verkehrt. Es wird ziemlich sicher kein Desktop-System mit Ubuntu und Gnome, aber das ist meine alte Fritzbox auch nicht. Und die Vorteile von Linux (existierende Treiber, gehärteter Netzwerkstack, fertige Infrastruktur von Compiler über Shell und Scriptsprachen bis Webserver) bleiben auch auf einem STM32 erhalten. Die Idee grundsätzlich pauschal als Unfug abzutun greift aus meiner Sicht schlicht zu weit. Stefanus F. schrieb: > Ich meinte das Linux, dass er in 128kB RAM quetschen wollte. Da ist für > den Netzwerk-Treiber und IP Stack kein Platz. RetroBSD könnte das vielleicht. Falls nicht, wäre das eine gute Übung. :-)
:
Bearbeitet durch User
S. R. schrieb: > Die Idee grundsätzlich pauschal als Unfug abzutun greift aus meiner > Sicht schlicht zu weit. Doch, das ist Unfug. Und ztwar ziemlich dämlicher Unfug. Ohne externes RAM geht es nicht mit Linux. Ausgeschlossen - 128kB reichen nicht für Linux. Und mit externem RAM kann ein Microcontroller wie der STM32 seine Vorteile nicht mehr ausspielen. Und der Vorteil eines STM32 ist doch genau der, dass er als Chip an sich ein Stand-alone-System darstellt, mit integrierter Peripheri und so weiter. Den wirft man weg, wenn man ein RAM dranmacht, und das Teil Prozessor spielen lässt. Dann bleibt der (für Prozessoren(!!!)) schwache Cortex-M4 übrig, der nicht für richtige Betriebssysteme entwickelt wurde. Es ist ein Microcontrollerkern. Prozessor spielen können richtige Prozessoren naturgemäß besser, und so kostet der oben genannte SAMA5 mit 500MHz und passenden Prozessorkern sogar weniger als ein STM32F4. Dazu kommen weitere Dinge, wie dass es für die viele wunderschöne STM32-Peripherie vermutlich keine fertigen Linux-Treiber geben wird, und die Linux-Unterstützung für den Cortex-A5 natürlich besser ausfällt. Ein Microcontroller ist keine CPU. Linux ist ein Betriebessystem für richtige Computer, nicht für Microcontroller. Nur um es zu wiederholen: Ein STM32F4 ist teurer als ein SAMA5 mit 500MHz, dieser hat aber die dreifache Rechenleistung. Warum das wohl so ist, hmm? Man vergleiche die Datenblätter...
Micha schrieb: > M. H. schrieb: >> Jim M. schrieb: >>> Welches Problem willst Du mit Linux lösen? Auf diesen MCUs nutzt man >>> normalerweise Betriebssysteme mit kleinerem Footprint. >> >> > > Nun, man sagt ja immer das man Linux verwenden muss, da es alle Probleme > lösen kann. Jetzt muss ich lesen dass Linux doch Dreck ist und man den > Stm32 nativ angehen muss... Offensichtlich hast du die eigentliche Frage übersehen, also nochmal: >>> Welches Problem willst du mit Linux lösen?
...auch mal was in den Raum werf... ist eine MMU nicht eine Grundvorrausetzung für ein Linux OS ? Also sprich keine MMU = kein Linux ? Es gab doch mal sowas wie FreeRTOS oder so für die stm32s wenn ich mich nicht irre, das sollte doch fürs Erste reichen. Irgendwo hab ich auch noch son altes f4diso boad rumfliegen und das war damals schon nur ein etwas schnellerer mit mehr internem RAM ausgerüsteter mikrocontroller und keine ich nenns mal klassische CPU.
Grobi G schrieb: > ...auch mal was in den Raum werf... > ist eine MMU nicht eine Grundvorrausetzung für ein Linux OS ? > Also sprich keine MMU = kein Linux ? Im Prinzip schon, aber uClinux hat vor gut 15 Jahren den Linux-Kernel auf NOMMU-Architekturen portiert (z.B. den Palm Pilot mit m68k). Inzwischen ist die Unterstützung im normalen Kernel angekommen und wird auch benutzt. Natürlich gibt es ohne MMU ein paar herbe Einschränkungen, z.B. gibt es keine Unterstützung für fork(), stattdessen muss man mit vfork() leben. ELF musste ein bisschen erweitert werden (fdPIC[*]), shared libraries sind nicht ganz so einfach uswusf. [*] Der fdPIC-Loader wird den ELF-Loader wohl mittelfristig ersetzen; jedes ELF-Binary ist auch ein gültiges fdPIC-Binary. Davon abgesehen ist das ein ganz normales Linux und viele Programme laufen ganz normal. Die üblichen Embedded-Anwendungen (z.B. Busybox) laufen sowieso. eher nicht schrieb: >> Die Idee grundsätzlich pauschal als Unfug abzutun greift aus meiner >> Sicht schlicht zu weit. > Ohne externes RAM geht es nicht mit Linux. Ausgeschlossen - 128kB > reichen nicht für Linux. Einverstanden. Trotzdem ist "Linux auf STM32" oder allgemeiner "Linux mit NOMMU" kein allzu großer Unfug. Es ist eine Frage des Anwendungsfalls. Zudem ist der STM32 relativ weit verbreitet und daher eine gute Basis, um die Unterstützung für kleinere Architekturen (mit und ohne MMU) zu fördern. Gibt zum Beispiel den jCore, der auf SH2 aufsetzt. Ein kleinerer Kernel ist nicht nur für "wenig RAM"-Szenarien nützlich, sondern lässt auf dickeren CPUs auch mehr Cache für die Anwendungen übrig. eher nicht schrieb: > Und mit externem RAM kann ein Microcontroller wie der STM32 seine > Vorteile nicht mehr ausspielen. Warum nicht? Die meisten netten Features (Netzwerkstack, Hardwaretreiber, existierende Software) bekommt man trotzdem. Die Entwicklung kann ohne Emulation nativ auf dem PC erfolgen. eher nicht schrieb: > Dazu kommen weitere Dinge, wie dass es für die viele wunderschöne > STM32-Peripherie vermutlich keine fertigen Linux-Treiber geben wird, und > die Linux-Unterstützung für den Cortex-A5 natürlich besser ausfällt. Ein Board mit STM32 und bisschen externem RAM lässt sich sicherlich einfacher entwerfen als eines mit Cortex-A5. Außerdem lässt sich dank der vielen Schnittstellen vieles relativ einfach anflanschen, zumal der STM32 als Controller elektrisch gutmütiger ist als eine richtige CPU. Das fängt schon mit den Versorgungsspannungen und Taktgebern an. :-) Im menuconfig habe ich übrigens ziemlich viele STM32-Treiber gesehen. Keine Ahnung, ob damit sämtliche Peripherie abgedeckt ist, aber ein Großteil ziemlich sicher.
S. R. schrieb: > Man kann an einem STM32 problemlos einen Netzwerkchip betreiben, z.B. > den ENC28J60 (wird von Linux unterstützt). Das mag ja sein, aber in 128kB RAM (um die es hier geht) kriegst du nie und nimmer einen Linux Kern mit den Netzwerktreibern rein, die für TCP/IP notwendig sind. Das kannst du nicht mit µIP vergleichen. µIP ist kleiner, hat aber nichts mit Linux zu tun.
S. R. schrieb: > eher nicht schrieb: >> Und mit externem RAM kann ein Microcontroller wie der STM32 seine >> Vorteile nicht mehr ausspielen. > > Warum nicht? Die meisten netten Features (Netzwerkstack, > Hardwaretreiber, existierende Software) bekommt man trotzdem. Die > Entwicklung kann ohne Emulation nativ auf dem PC erfolgen. Dann führen wir das doch mal aus: Der STM32F4 ist teurer als ein richtiger Prozessor wie der SAMA5. Es gibt sogar noch billigere Prozessoren als den SAMA5. So hat man schon mal höhere Grundkosten, bei sehr, sehr, sehr viel schlechteren Leistungsdaten. Dann hat der STM32 keine "ordenltiche"*1) RAM-Schnittstelle. Oh, man kann natürlich SDAM anschließen, aber das ist teuer und langsam, und größere Chips sind schwierig zu bekommen. Ein richtiger Prozessor kann DDR3. DDR3 bekommt man in größer und kostengünstiger als SDRAM und viel schneller. Dann ist ein STM32 schon vom Pinout her nicht gut geeignet. Das RAM belegt viele Pins und blockiert damit andere Peripherie. Bei richtigen Prozessoren hat man das Problem in der Form nicht, denn die benötigen RAM immer, das wurde also berücksichtigt. Darum oft auch die BGA-Packages. d.h. ein richtiges Prozessorsystem ist nicht nur billiger, es ist auch leistungsfähiger. Um Größenordnungen. Wo du mit dem STM32 mit 200MHz und 32MB RAM herumkrebst, bekommst du für weniger Geld wahrscheinlich einen SAMA5 mit 128MB DDR3 und 500MHz. Dreifache Rechenleistung (ja, der Cortex-A5 ist schneller!) und vierfachen RAM. Warum gibts den STM32 dann, und warum ist er so beliebt? Weil er ein guter Microcontroller ist. Warum ist ein Prozessor dann so viel billiger? Beisielsweise hat er kein Flash, welches teuer ist. Er kann in einem anderen Fertigungsprozess produziert werden, was Flächeneffizienter ist. Ein Prozessor ist dafür andersherum ein mieserabler Microcontroller. Es ist das alte Spiel: Da richtige Werkzeug für die richtige Anwendung. Die Kettensäge schneidet schlecht Brot, mit dem Brotmesser sägt man ewig an einer Fichte. *1) aus Sicht eines richtigen Prozessors!
eher nicht schrieb: > Es ist das alte Spiel: Da richtige Werkzeug für die richtige Anwendung. > Die Kettensäge schneidet schlecht Brot, mit dem Brotmesser sägt man ewig > an einer Fichte. Sehr schöne Metapher. Ich kannte bisher nur die Variante mit dem LKW und Brötchen holen.
Ich hatte mal ein Debian Linux auf einem GNUBLIN am laufen, 180MHz, 32MB RAM Es hat funktioniert, war aber kein vergnügen. Man musste auch etwas Tricksen, ein Teil das RAMs wurde komprimiert, weil das dann immer noch schneller war, als eine Auslagerungsdatei auf der SD-Karte zu benutzen. Ist lange her, damals gab es noch keine RPis
C.K. schrieb: > Ich hatte mal ein Debian Linux auf einem GNUBLIN am laufen, 180MHz, 32MB > RAM > Es hat funktioniert, war aber kein vergnügen. Eben. Selbst mit 32 MB RAM machts nicht wirklich Spaß. Und < 10 MB wird sehr eklig. Und mit eineigen KB ist es einfach unmöglich. Da sollte man, wenn man unbedingt ein OS will ein RTOS o.ä. nehmen. Ich finde schon das Raspberry Pi, vorallem die alten, obwohl die 700+ MHz, GPU und mehrere hundert MB RAM haben, ziemliche Krücken. Klar das läuft. Aber ein richtig tolles Erlebnis ist es irgendwie nicht. Liegt aber auch an den SD Karten. Wenn man da eine langsame hat, macht es das zur Tortur. Durch die fehlende MMU des STM ist man auf PIE und andere Sachen angewiesen. Außerdem funktionieren gewisse Grundpfeiler von Linux ohne MMU einfach nicht. Man ist auf speziell kompilierte SW angewiesen. Schon allein aus dem Grund, dass der STM keinen arm-Befehlssatz unterstützt, sondern "nur" den Thumb2 Mode. Vorkompilierte ARM Software kann somit eh nicht genutzt werden.
Stefanus F. schrieb: > Das mag ja sein, aber in 128kB RAM (um die es hier geht) kriegst du nie > und nimmer einen Linux Kern mit den Netzwerktreibern rein, die für > TCP/IP notwendig sind. Ich hab einfach mal stillschweigend die 8 MB zusätzlichen RAM für den Kernel vorausgesetzt. In 128 KB geht es natürlich nicht, darum mein Hinweis auf RetroBSD. Antikes UNIX ginge in 128 KB natürlich auch. :-) eher nicht schrieb: > Darum oft auch die BGA-Packages. Richtig, und ein BGA-Package setze ich nicht "mal eben so" mit dem Lötkolben auf ein kleines Board. Einen STM32 schon eher. eher nicht schrieb: > Warum gibts den STM32 dann, und warum ist er so beliebt? > Weil er ein guter Microcontroller ist. Und warum gibt es dann Linux dafür? Weil er in Maximalausstattung "gerade so" dafür ausreicht. Merke: Ich widerspreche dir fachlich nicht. Siehe unten. M. H. schrieb: > Ich finde schon das Raspberry Pi, vorallem die alten, > obwohl die 700+ MHz, GPU und mehrere > hundert MB RAM haben, ziemliche Krücken. Wenn du da ein normales Desktop-Linux drauf laufen lassen willst, wundert mich das nicht. Auf einem STM32 oder den anderen kleinen Embedded-Kisten läuft das auch nicht vernünftig. Aber Linux gibt es eben auch woanders. M. H. schrieb: > Man ist auf speziell kompilierte SW angewiesen. Schon > allein aus dem Grund, dass der STM keinen arm-Befehlssatz > unterstützt, sondern "nur" den Thumb2 Mode. Naja, "speziell kompiliert" ist ein bisschen übertrieben. Debian bietet es halt nicht vorkompiliert an, ja. Ansonsten ist Thumb2 unter Linux jetzt auch nicht so exotisch. Die höhere Codedichte reduziert auf den großen Prozessoren den Druck auf den Cache, lohnt sich also auch da. ---- Um das Thema abzuschließen: Ich halte Linux auf dem STM32 für technisch äußerst interessant und für manche Anwendungen nicht komplett verkehrt. Nicht unbedingt als erste Wahl, aber der Sprung von "AVR" zu "STM32" ist aus meiner Sicht wesentlich kleiner als der von "STM32" zu "richtiges Linux", zumindest wenn man von unten schaut. Dass es möglich ist, zeigen die vielen Geräte, die Linux auch mit geringen Taktraten (unter 500 MHz) und wenig RAM (unter 64 MB) auf vergleichsweise exotischen Architekturen (MIPS, ARM9) erfolgreich einsetzen. Viele Vorteile von Linux bleiben auch auf solchen Systemen erhalten, die man mit z.B. FreeRTOS nicht so einfach bekommt. Für ein Desktop-System sind die allesamt nicht geeignet, aber das sollen sie auch nicht. Einiges, was aus der Entwicklung für solche Umgebungen entsteht, ist auch auf großen Systemen nützlich. Und sei es das Bewusstsein, was der Kernel-Entwickler bekommt, wenn er mal nicht "eben so" 800 MB RAM verschleudern kann.
S. R. schrieb: > Richtig, und ein BGA-Package setze ich nicht "mal eben so" mit dem > Lötkolben auf ein kleines Board. Einen STM32 schon eher. Dafür gibt es SOMs. Wie das: https://www.microchip.com/design-centers/32-bit-mpus/sip-som/system-on-module S. R. schrieb: > Und warum gibt es dann Linux dafür? Weil es Leute gibt, die das als proof of concept gemacht haben. Mal im Ernst, kein Mensch wird das produktiv einsetzen wollen. Ein Profi nimmt das kostengünstigere Prozessorsystem, ein Hobbyist eine SOM oder schlicht Raspberry PI, eventuell aauch als Comute-Module: https://www.raspberrypi.org/products/compute-module-3/ Ein SOM auf eine Platine löten oder einen Sockel für das Compute-Module ist sinnvoller und einfacher als diese Krücke. Die Unterstützung für dieses STM32-Linux dürfte auch eher mau sein. Ich denke mal, wenn man das ernsthaft benutzen will, darf man sich wahrscheinlich für die meiste Peripherie erst einmal Treiber schreiben. Da ist es einfacher, das mit Free-RTOs und der HAL oder gleich bare metal zu machen. Beim SOM gibte Support vom Hersteller, beim Rasberry PI Comute Module hat man die gesamte Community. Da dürfte ein Großteil fertig sein.
Nur mal so nebenbei, uCLinux lief schon vor 12 Jahren auf meinem uCSimm, ein System mit MC68EZ328, 16Mhz und 2MB Flash sowie 8MB RAM. Mit 2.4 Kernel und kompletter Ausstattung inkl. Webserver, Framebuffer und diversen selbstgebastelten Treibern für Roboter Hardware. Die ganze Nummer war überhaupt nicht langsam und als Steuerrechner durchaus brauchbar. Wenn man sich ein Devboard mit RAM, wie z.B. das F429 Disco besorgt, kann das durchaus klappen. Allerdings sollte man sich anschauen, wie man komprimierte Flash Images herstellt. In den RAM wird so gut wie alles aus dem Flash dekomprimiert, deswegen brauchts 8MB.
Moin, Matthias S. schrieb: > Mit 2.4 > Kernel Ja, daaaamals - war ja kurz nachm Krieg wirhattenjanix - da konnte man auch noch aufm PC einfach einen Kernel auf eine 1.44MByte grosse Floppy schreiben und dahinter hat noch ein kleines rootfs gepasst und das ganze war auch noch bootfaehig. Die Zeiten sind lang vorbei :-/ Gruss WK
Dergute W. schrieb: > Ja, daaaamals - war ja kurz nachm Krieg wirhattenjanix - da konnte man > auch noch aufm PC einfach einen Kernel auf eine 1.44MByte grosse Floppy > schreiben und dahinter hat noch ein kleines rootfs gepasst und das ganze > war auch noch bootfaehig. Die Zeiten sind lang vorbei :-/ Vor allem ist das aus Bastlersicht völlig unsinnig. Ein uralter Raspberry PI 1 vom Flohmarkt schlägt jede STM32 Alternative um Längen (vermutlich auch preislich), und im Gegenzu dazu ist das Linux auf dem Ding ausgereift. Wenn es natürlich um ein "proof of concept" geht, ja dann kann man das schon machen. Es ist ohne Frage eine Leistung, auf einer so kleinen CPU hinzubekommen, und sicher ein lehrreiches Hobby.
Matthias S. schrieb: > Die ganze Nummer war überhaupt nicht langsam und > als Steuerrechner durchaus brauchbar. Das wollen die nicht sehen. Matthias S. schrieb: > Allerdings sollte man sich anschauen, wie man komprimierte > Flash Images herstellt. In den RAM wird so gut wie alles > aus dem Flash dekomprimiert, deswegen brauchts 8MB. Der Kernel kann auch XIP, für sich selbst und für Userspace. Wenn man also genügend gemappten Flash zur Verfügung hat und mit der Performance-Einbuße leben kann, braucht man weniger RAM. jemand schrieb: > Es ist ohne Frage eine Leistung, auf einer so kleinen CPU > hinzubekommen, und sicher ein lehrreiches Hobby. Gleichzeitig lernt man viel über Linux, viel über STM32 und viel über Architekturen im Allgemeinen. Und man bekommt ein halbwegs nutzbares System. "Raspi kann ja jeder."
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.