Hallo, ich habe nach der folgenden Anleitung (http://www.mikrocontroller.net/articles/Linux_auf_STM32) das uCLinux auf einem STM32F429 Discovery Board zum laufen gebracht. Das System bootet, wie in dem Artikel zu sehen und ich habe einen USB-UART Adapter angeschlossen. Nun stehe ich vor dem Problem, dass ich dem System keine Befehle übergeben kann. Ich kann über minicom zwar Eingaben machen, jedoch passiert nichts wenn ich die Eingabetaste drücke. Ich hoffe jemand kann mir sagen was ich falsch mache... Gruß
Hi foobar, HW-FLusskontrolle und SW-Flusskontrolle sind aus und die Baudrate ist auf 115200 eingestellt. Gruß
Bekommst du denn ein Login Prompt? Ansonsten würde ich mal die etc/inittab untersuchen, ob da ein login auf tty0 (oder welches device auch immer die UART darstellt) gespawnt wird und mit welcher Baudrate das passiert.
Ich bekomme einen Login Prompt. Der Bootvorgang läuft genauso weit wie in dem Artikel abgebildet. Also: "Jan 1 00:00:01 login[29]: root login on 'ttyS2' ~ #" Ich würde das ganze gerne mit der etc/initab untersuchen, jedoch scheint es diese Datei nicht mehr zu geben.
Thrillhouse schrieb: > "Jan 1 00:00:01 login[29]: root login on 'ttyS2' > ~ #" Im Artikel wird ttyS0 gezeigt, und m.E. sollte das auch der primäre login sein. Das wird auch ein paar Zeilen dadrüber angeschaltet: >starting pid 29, tty '/dev/ttyS0': '/bin/login -f root' An der Stelle, wo der Prozess gestartet wird, sollte eigentlich auch die Baudrate und das device stehen. Mögl. ist das die /etc/init/rc oder die /etc/init/rc.local > Ich würde das ganze gerne mit der etc/initab untersuchen, jedoch scheint > es diese Datei nicht mehr zu geben. Hmm, sollte es bei Kernel 2.6 eigentlich geben. Das Dings heisst inittab mit Doppel-T. 'init' ist normalerweise die Mutter aller Prozesse und startet login. Schau das mal durch: http://www.alterawiki.com/wiki/How_to_set_up_a_login_prompt_with_uClinux
Matthias S. schrieb: > Im Artikel wird ttyS0 gezeigt, und m.E. sollte das auch der primäre > login sein. > Das wird auch ein paar Zeilen dadrüber angeschaltet: >>starting pid 29, tty '/dev/ttyS0': '/bin/login -f root' Das müsste daran liegen, dass ich USART3 benutze. Wenn ich RX und TX des USB-UART Adapters mit PA9 und PA10 des STM verbinde startet der Bootvorgang nicht. Einen Login Prompt, wie in dem verlinkten Tutorial beschrieben kann ich leider nicht erstellen, da ich ja keine Möglichkeit habe in dem µCLinux Dateisystem zu navigieren bzw irgendwelche Befehle zu übergeben. Gruß
Thrillhouse schrieb: > Einen Login Prompt, wie in dem verlinkten Tutorial beschrieben kann ich > leider nicht erstellen, da ich ja keine Möglichkeit habe in dem µCLinux > Dateisystem zu navigieren bzw irgendwelche Befehle zu übergeben. Das hast du aber, bevor du das Image auf dem STM schreibst. Da steht übrigens auch noch: "Um die serielle Konsolo zu verwenden benötigt man z.B. noch einen RS232(TTL)/USB Wandler. Dieser wird mit 3 Pins an PA9, PA10 und GND für die Verwendung des USART1 angeschlossen. Ändert man noch in 3 Dateien den seriellen Port von USART3 auf USART1 erhält man nach dem Start (bootet unter 1s) folgendes Bootlog:" Also muss man da noch in 3 Dateien rumfummeln. USART3 ist auf dem DiscoF429 Board nicht frei verfügbar, mindestens ein Pin geht immer an irgendwelche andere Peripherie: http://mikrocontroller.bplaced.net/wordpress/wp-content/uploads/2015/10/Pinbelegung_f429_v101.html
Matthias S. schrieb: > Also muss man da noch in 3 Dateien rumfummeln. USART3 ist auf dem > DiscoF429 Board nicht frei verfügbar, mindestens ein Pin geht immer an > irgendwelche andere Peripherie: > http://mikrocontroller.bplaced.net/wordpress/wp-content/uploads/2015/10/Pinbelegung_f429_v101.html Danke, ich versuche nun mal herauszufinden um welche drei Dateien es sich dabei handelt.
(1) stm32f429-linux-builder/configs/kernel_config' ... # # STM32 I/O interfaces # CONFIG_STM32_DMA=y CONFIG_STM32_USART1=y # CONFIG_STM32_USART2 is not set # CONFIG_STM32_USART3 is not set # CONFIG_STM32_USART4 is not set # CONFIG_STM32_USART5 is not set # CONFIG_STM32_USART6 is not set # CONFIG_STM32_I2C1 is not set # CONFIG_STM32_I2C2 is not set CONFIG_STM32_I2C3=y ... (2) stm32f429-linux-builder/rootfs/etc/inittab # inittab for uClinux # Format: # id:runlevels:action:process # /etc/start must be executable script null::sysinit:/etc/start ttyS0::respawn:/bin/login -f root null::wait:/bin/cat /proc/cpuinfo > /dev/tty1 (3) stm32f429-linux-builder/uclinux/arch/arm/configs/stm32f429-discovery_def config .... # # STM32 I/O interfaces # CONFIG_STM32_DMA=y CONFIG_STM32_USART1=y # CONFIG_STM32_USART1 is not set # CONFIG_STM32_USART2 is not set # CONFIG_STM32_USART3 is not set # CONFIG_STM32_USART4 is not set # CONFIG_STM32_USART5 is not set # CONFIG_STM32_USART6 is not set ...
Ich weiss nicht, wie die Developer Maschine des TE aussieht, aber wenn da auch Linux läuft und ncurses installiert ist, finde ich 'make menuconfig' am übersichtlichsten. 'make config' ist mir zu unübersichtlich und 'make xconfig' habe ich nie angefasst.
Wenn ich die drei Dateien so abändere wie von "xxx" beschrieben kann ich noch immer nicht booten indem ich den USB-UART Adapter an PA9 und PA10 anschließe. In dem Fall erscheinen in der Shell nur irgendwelche kryptischen Zeichen und Buchstaben. Das sieht aus als würde etwas mit der Baud Rate nicht stimmen... Die "inittab" Datei habe ich inzwischen gefunden, jedoch kann ich da nirgendwo etwas zur Baudrate der UART Verbindungen finden. Gruß
Thrillhouse schrieb: > Wenn ich die drei Dateien so abändere wie von "xxx" beschrieben kann ich > noch immer nicht booten indem ich den USB-UART Adapter an PA9 und PA10 > anschließe. Du weisst aber schon, das du nach Änderungen der kernel_config einen neuen Kernel kompilieren musst?
Wenn er das nicht weiss, ist die Lernkurve gerade bei diesem System sehr steil.
Matthias S. schrieb: > Du weisst aber schon, das du nach Änderungen der kernel_config einen > neuen Kernel kompilieren musst? Das weiß ich natürlich. Bevor ich den Kernel neu kompiliert habe, war über USART1 gar keine Eingabe möglich. Jetzt passiert was, aber eben nichts brauchbares. (siehe letzer Post von mir)
Thrillhouse schrieb: > In dem Fall erscheinen in der Shell nur irgendwelche kryptischen Zeichen > und Buchstaben. Das sieht aus als würde etwas mit der Baud Rate nicht > stimmen... Dann passe sie doch an. Probiere im Terminalprogramm einfach die gängigen Baudraten durch, nämlich 9600, 19200, 38400 und 115200 Baud.
Frank M. schrieb: > Dann passe sie doch an. Probiere im Terminalprogramm einfach die > gängigen Baudraten durch, nämlich 9600, 19200, 38400 und 115200 Baud. Danke für den Tipp. Jedoch habe ich das schon versucht, leider ohne Erfolg. Gruß
Thrillhouse schrieb: > Danke für den Tipp. Jedoch habe ich das schon versucht, leider ohne > Erfolg. Hattest Du denn den Eindruck, dass bei einer bestimmten Baudrate zumindest die Hälfte der Buchstaben lesbar war? Dann könnte es noch ein Parity Bit sein, z.B. wie 7 Bit Even Parity. Welches TTY ist es denn jetzt wirklich? ttyS0 oder ttyS2? Wie lautet der inittab-Eintrag für dieses tty? Du solltest den Eintrag derart anpassen, dass dort ein getty (sofern vorhanden) und nicht /bin/login direkt gestartet wird. Bei getty lässt sich nämlich eine Baudrate angeben. getty schaltet das TTY dann auf die gewünschte Baudrate um, fragt nach dem Usernamen und startet anschließend /bin/login mit diesem Usernamen, damit dieser dann das Password abfragt.
Frank M. schrieb: > Hattest Du denn den Eindruck, dass bei einer bestimmten Baudrate > zumindest die Hälfte der Buchstaben lesbar war? Dann könnte es noch ein > Parity Bit sein, z.B. wie 7 Bit Even Parity. Ja, bei einer Baudrate von 9600 und 6 Bit Even Parity wurde mit tty0 gebootet und die Ausgaben wurden korrekt gezeigt. Allerdings war dabei dann das Problem, dass die Eingaben nur als Fragezeichen angezeigt wurden. Frank M. schrieb: > Du solltest den Eintrag derart anpassen, dass dort ein getty (sofern > vorhanden) und nicht /bin/login direkt gestartet wird. Bei getty lässt > sich nämlich eine Baudrate angeben. getty schaltet das TTY dann auf die > gewünschte Baudrate um, fragt nach dem Usernamen und startet > anschließend /bin/login mit diesem Usernamen, damit dieser dann das > Password abfragt. Das habe ich mal gemacht und das getty scheint eine endlose Reboot-Schleife zu erzeugen. Ich habe die Änderung an der inittab nun wieder rückgängig gemacht und neu kompiliert, jetzt passiert an tty0 nichts mehr...bei keiner Baudrate. Wenn ich den USB-UART Adapter jetzt an USART3 (ttys2) anschließe kommt Folgendes immer wieder: starting pid 01, tty 'dev/ttyS2': 'getty -f root' process 'getty -f root' (pid 01) exited. Scheduling for restart. starting pid 02, tty 'dev/ttyS2': 'getty -f root' process 'getty -f root' (pid 02) exited. Scheduling for restart. . . .
Thrillhouse schrieb: > starting pid 01, tty 'dev/ttyS2': 'getty -f root' Das Manual von getty solltest Du Dir schon ansehen. Es ist gewiss nicht damit getan, /bin/login durch getty zu ersetzen und den Rest so stehen zu lassen. Ich bin mir ziemlich sicher, dass getty mit "-f root" nichts anfangen kann. Und wo ist da die Angabe der Baudrate? Hier ist zum Beispiel ein Manual für agetty, was auf Linux desöfteren benutzt wird: http://linux.die.net/man/8/agetty Im Abschnitt "Examples" findest Du dann so etwas für den inittab-Eintrag: /sbin/agetty 9600 ttyS1 Ich würde persönlich auch noch -8 als Schalter verwenden, damit das TTY auch 8-Bit-clean ist. Aber lies einfach selbst, es lohnt sich. Ob das agetty auf Deiner Linux-Variante dabei ist, weiß ich nicht. Wenn nur getty, dann gib bei Google ein "man getty" statt "man agetty". Dürfte aber für so simple Parameter wie 9600 und ttyS1 die gleiche Syntax verwenden.
Thrillhouse schrieb: > starting pid 02, tty 'dev/ttyS2': 'getty -f root' getty macht genau das, wie es heisst, es holt eine Konsole. Das danach 'login' auf die Konsole geworfen wird, interessiert getty erstmal nicht, kann agetty aber per Parameter machen. in der inittab steht dann, bei welchem Run Level was auf den tty passiert, dabei ist der Prozess bei uCLinux recht viel einfacher, als bei den 'grossen'. Es reicht meistens sowas hier:
1 | inet:unknown:/bin/inetd |
2 | ttyS0:vt100:/sbin/agetty -l /bin/login ttyS0 9600 vt100 |
wobei du inet nur dann benötigst, wenn du Netzwerk Sachen machst.
Fehler gefunden! Mein USB-UART Adapter war tatsächlich kaputt. Ich habe einen anderen ausprobiert und kann nun problemlos Eingaben unter ucLinux machen. Danke trotzdem für die Tipps!
Hallo, könntest Du vielleicht mal einen brennfähigen Code hier einstellen? Mich würde das auch mal interessieren, was uCLinux so kann auf dem Disco 429 Board. Bisher habe ich da zurück gescheut, weil mir das alles kryptisch daherkam. Wenn ich das richtig verstehe kann ich über ein RS232 Kabel mit FTDI Interface und minicom o.ä. dann mit dem Board kommunizieren. Gruss, Christian
Christian J. schrieb: > könntest Du vielleicht mal einen brennfähigen Code hier einstellen? Am besten das Projekt einmal kompilieren, damit HEX und ELF auch dabei sind. Würe das auch gerne mal anschauen. Mir geht es da ähnlich wie Christian. DANKE!
Christian J. schrieb: > Bisher habe ich da zurück gescheut, weil mir das alles kryptisch > daherkam. Die Anleitung, hier auf der Seite(https://www.mikrocontroller.net/articles/Linux_auf_STM32) ist doch eigentlich unmissverständlich. Ich bin auch noch ein Anfänger auf dem Gebiet und habe es damit Problemlos hinbekommen. Christian J. schrieb: > Wenn ich das richtig verstehe kann ich über ein RS232 Kabel mit FTDI > Interface und minicom o.ä. dann mit dem Board kommunizieren. Genau so ist es. Eigentlich alles ganz einfach, wenn man einen funktionstüchtigen USB-RS 232 Adapter hat... ;) Gruß
Hallo, ist es so schwer ein Hex File hier hochzuladen? Es gibt vielleicht Leute, die nicht die ganze Toolchain installieren möchten und die nicht Linux auf dem Rechner haben sondern einfach nur ein Flash Tool? Gruss, Christian
Christian J. schrieb: > ist es so schwer ein Hex File hier hochzuladen? Es ist nicht ein Hex File, es sind drei bin Files. Hier ist die Kommandozeile, um mittels openocd die drei Dateien zu flashen (Aus dem Makefile extrahiert): openocd -f board/stm32f429discovery.cfg \ -c "init" \ -c "reset init" \ -c "flash probe 0" \ -c "flash info 0" \ -c "flash write_image erase uboot.bin 0x08000000" \ -c "flash write_image erase xipuImage.bin 0x08020000" \ -c "flash write_image erase romfs.bin 0x08120000" \ -c "reset run" -c shutdown
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.