Beaglebone Black: UART1 dauerhaft aktivieren

[Dennis S. (dspo)]

Hallo,

nun ist der neue BeagleBone Black auf dem Markt und ich habe mir als 
Linux-Neueinsteiger ein solches Teil zur Einarbeitung in ARM/Linux und 
später mal zur Verwendung als seriell anzusteuerndes HDMI-Display 
Interface für meinen AVR-Fuhrpark zugelegt. Die Prozessorpins bzw. die 
Pins, die die Buchsenleisten P8 und P9 herausführen können mit mehreren 
Funktionen belegt werden. Von der mich interessierenden seriellen 
Schnittstelle ist per default (Angstrom-Distribution 2013-06-06) keine 
der nutzbaren vom Start weg aktiv. Um das zu erreichen ist bislang eine 
ganze Orgie von Instruktionen abzuarbeiten; mit dem neuen 3.8er Kernel 
und dem "Device Tree" Konzept hat sich auch einiges in Setup / 
Ansteuerung der nutzbaren Anschlusspins geändert.
Da ich Sinn und Zweck dieser höchst umständlich und unnötig kompliziert 
erscheinenden Linux I/O Steuerung im Augenblick wenig durchschaue bleibt 
nur Googeln und das Zusammentragen vieler Informationshäppchen, um 
erstmal ein funktionierendes Prozedere zur Aktivierung zu erhalten 
(anbei in deutsch + die beiden Downloads dazu).

Dreh-und Angelpunkt ist hier offensichtlich zum einen die Erstellung 
einer neuen (mit dem "Device Tree Compiler" dtc zu kompilierenden) 
am335x-boneblack.dtb in "/boot/" die der Kernel auswertet sowie dann ein 
Schnittstellenfile ttyO1 für UART1 in "/dev/" kreiert- und zum anderen 
ein ebenso zu erstellendes und in "/lib/firmware/" abzulegendes 
Pinmux-File welches schließlich zur Aktivierung des Pinmux-Setting in 
einem via Service gestartetem Skript dem Cape-Manager und seiner 
Slot-Verwaltung zugewiesen wird... :-(

Möglicherweise und hoffentlich lässt sich dieses oder jenes noch 
verbessern, ich hoffe sehr auf kundige Rückmeldungen!

Dem BBB-Einsteiger möchte ich für die Arbeit übers Netzwerk bzw. mit 
Windows unbedingt noch die beiden Tools PuTTY (Shell) und WinSCP 
(Dateiübertragung) ans Herz legen.

Dennis

[ansel (Gast)]

> die erste (UART0=ttyO0) steht nicht frei zur Verfügung.

was tut die auf dem Beaglebonen denn standardmässig?  Falls dort ein 
login-prompt zu sehen ist, sollte man sie in /etc/inittab für andere 
Zwecke freigeben können.  Ansonsten kann man mit lsof herausfinden, 
welcher Prozess sie verwendet.

[Dennis S. (dspo)]

ansel schrieb:
>> die erste (UART0=ttyO0) steht nicht frei zur Verfügung.

Ja tatsächlich, wenn auch nicht auf den beiden Cape-Erweiterungsheadern 
P8/9 so aber doch auf einem separaten Debug-Port ist UART0 nutzbar!

ansel schrieb:
> /etc/inittab

... findet sich nicht im Dateisystem.

[Cape- make me rich (Gast)]

Dennis S. schrieb:
> ein ebenso zu erstellendes und in "/lib/firmware/" abzulegendes
> Pinmux-File welches schließlich zur Aktivierung des Pinmux-Setting in
> einem via Service gestartetem Skript dem Cape-Manager und seiner
> Slot-Verwaltung zugewiesen wird... :-(

Ich sehe diese Herangehensweise als Versuch, den Erfolg der "denkfreien" 
Arduino-Libs und den dazugehörigen Shields auf eine höhere Ebene,
 - auf  ARM/Linux(BBB) und den dazugehörigen Capes, zu portieren, ohne 
den Aufwand und somit die Kosten der Entwicklung ebendieser Lib's tragen 
zu wollen.
Die "Strickweise" hast Du ja schon gut umrissen ...
  --  und nun macht mal!

[WarumEinfachWennsAuchKompliziertGeht (Gast)]

Im Prinzip langt doch eine einfache Textdatei, die Betriebsart bzw. 
Status jedes Pins für die Initialisierung festlegt. Aber das wär wohl zu 
einfach...

[Tomy (Gast)]

Tja, für Linux-Freunde ist eben nur das eine elegante Lösung was auch 
hinreichend kompliziert ist :)

[ansel (Gast)]

War nun selbst in der Not, drei UARTs an meinem BBB verwenden zu müssen, 
und kann nun etwas qualifizierter auf die Ursprungsfrage antworten...

Folgende Zeile in meiner /boot/uEnv.txt war hier die einzige notwendige 
Konfiguration, um angelötete rs232- und rs485-Transciever zum Leben zu 
erwecken, und dauerhaft via /dev/ttyOx zugänglich zu machen:

optargs=capemgr.enable_partno=BB-UART1,BB-UART4,BB-UART5,BB-SPI0-01

(Das ganze geschah mit Debian wheezy, aber capemgr und u-boot sind ja 
auch bei Angström im Einsatz. Einziger Unterschied ist IIRC, dass die 
Partition mit der uEnv.txt bei letzterem irnkwo unter /media statt /boot 
gemountet ist.)