Ich werde versuchen, heute Abend mit deinen Hinweisen weiter zu kommen. Beim Yun hatte ich das OS schon mal aktualisiert, so i’ll try my very best! … und reporte dann wie weit ich gekommen bin.
Schade, dass es nicht so geht wie gedacht. Hätte ich das schon mit “arecord -l” sehen müssen / können?
Vielen Dank für die Hilfe und Deine lange Antwort! ;-) Auch wenn “einfacher” besser wäre und der Weg steinig ist, lernt man mit deinen Antworten immer viel!
So, das firmware-update ging irgendwie schief. Der LinkIt bleit beim booten hängen (WLAN-LED geht nicht aus). Ich setzte mich morgen nochmal dran.
Woran machst Du das fest?
Die WLAN-LED ist nur ein GPIO, daher kann das ein normales Verhalten dieser LED unter diesem Treiber sein (den MT76 -wifi-Treiber benutze ich nicht mangels Notwendigkeit, sonst wüßte ich es genauer). Vorher war ja der proprietäre Treiber darin, und der wird ziemlich sicher anders geblinkt haben. - Also das allein ist noch kein Indiz.
Was sagt denn die console, schick’ doch mal den kompletten Mitschnitt des boot-Vorgangs von der seriellen Schnitte! Da meldet sich der bootloader, der das image reinzieht, entpackt und versucht, den Kernel anzustarten usw. Im besten Fall kommen irgendwann keine Protokollzeilen mehr, und Du kannst Enter drücken, um eine root shell zu erhalten. Wenn er vorher anhält, kann ich nur mit einem bootlog irgendwas dazu sagen.
Wie hast Du geupdated: über serielle, USB-Stick oder Ethernet? Hast Du das von der OpenWRT-Oberfläche aus gemacht oder aus der shell auf dem linkit mit sysupgrade? Du solltest auch immer die sha256 für das file mit der angegebenen verifizieren und neu downloaden, wenn es da eine Abweichung gibt!
BTW, Yun ist ne gute Idee, das ist der gleiche Target-core: ein mips24Kc (mips32r2-Code). Das bedeutet, daß Du für den Yun gebaute Pakete per ipkg komfortabel nachinstallieren kannst. - Ich nutze ja die Carambola2, das ist auch mips24kc. Der SoC ist ein anderer Hersteller (Atheros AR9331), aber wiederum der gleiche wie im Yun. Das heißt, ich habe dafür bereits die gebaute toolchain zum crosscompilen (und muß sie nicht erst bauen). Das beschert relativ schnell den ics43432-Treiber, - was aber noch nicht ausreicht…
Ja. Müssen nicht, können schon. ;)
Das update habe ich über die LuCI-Weboberfläche gemacht, wie unter Via Web-Oberfläche (weiter unten auf der Seite) beschrieben.
Der LinkIt war dabei im lokalen WLAN, die (bestehende) Konfiguration habe ich nicht übernommen (Option beim update). Dann habe ich damit gerechnet, dass der LinkIt in den AP-Mode wechselt und ein WLAN-Netzwerk mit “LinkIt irgendwas …” aufmacht. Ok, ist kein “original” LinkIt-Image, vielleicht macht er das gar nicht. Ich versuche mal über die Konsole ran zu kommen.
Um den boot-Prozess zu debuggen und auf den LinkIt – ohne WLAN – zuzugreifen muss man ihn über die serielle Schnittstelle ansprechen. Anleitung unter Bootloader and kernel console … hilfreich dabei auch das Pin-out Diagramm
LinkIt Smart 7688 FTDI
[board] [cable]
GND -- GND
P8 (UART TX2) -- RX
P9 (UART RX2) -- TX
, und die baud-Rate auf 57600 einstellen!
Nun kann man mit PuTTY auf den LinkIt zugreifen. Wenn man nur am output interessiert ist kann man alternativ auch den seriellen Monitor der Arduino-IDE verwenden.
Et voila! Alive!
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 18.06.0-rc1, r7090-d2aa3a1b62
-----------------------------------------------------
D.h. die dauerangeschaltetet WLAN-LED, die mit der Original Linkit-Firmware einen Fehler signalisiert scheint – wie von @weef oben geschrieben – hier keinen Fehler zu signalisieren. ;-)
Nun muss ich noch WLAN konfigurieren.
WLAN ist bei OpenWRT per default deaktiviert, man muss es erst anschalten.
Nun spannt OpenWRT auch einen AccessPoint mit der SSID OpenWrt auf, mit dem kann man sich nun verbinden. Hat man die Verbindung hergestellt kommt man über http://192.168.1.1 auf LuCI.
A post was merged into an existing topic: Developing Saraswati: A robust, multi-channel audio recording, transmission and storage system
bestimmt - ich habe es nur noch nicht gebaut! ;)
Im Moment läuft hier auf dem MT7688 zwar ein gebautes openwrt-Image mit u.a. python 2.7 und gstreamer (ca. 21MB; ist letzten Do noch nach unserer session mit @Andreas entstanden), und das rennt auch, - aber es bröselt an einer der Hauptfunktionen: der freie MT76-Wifi-Treiber ist zwar schon toll, aber nur dessen AP mode funktioniert zuverlässig, sobald man aber zusätzlich einen STA mode braucht (als wifi client zum home-Netzwerk), wackelt das ganze im einstelligen Sekundenbereich, bis hin zu kernel warnings… 8(
Diese Probleme sind immerhin bzw. leider bekannt, und aufgrund des Alters des Systems und Desinteresse seitens Mediatek an der opsen source-Weiterentwicklung des Treibers auch nicht einfach so zu lösen. Maintainer für u.a mt76 ist nbd (Felix Fietkau); es ist davon auszugehen, daß schon alles in dem MT76-Treiber ist, was er ohne Doku ermöglichen konnte. Ich kann aber gerne auch den Stand und die Aussichten noch mal von ihm bestätigen lassen. Auch dieser Treiber kommt leider nicht ohne binary blob für die Wifi-Funktionalität aus.
Man könnte ja nun den AP abschalten, nachdem das Teil auf das home-Netz provisioniert ist, man hat nur kaum Zeit dazu, bevor das Teil auf beiden Interfaces wieder aus- und angeht. - Als nächstes kommt jetzt mal ein MagJack dran, damit ich ich stabiles Ethernet habe, sonst macht das Ding keinen Spaß.
Im Moment habe ich da ‘nur’ USB-Audio mit unserem bekannten kleinen Interface, den ICS43432-Treiber habe ich noch nicht kompiliert, was aber, wie beschrieben, kein Problem darstellt. Es muß in jedem Fall der device tree angepaßt für das Mikrofon werden - und dafür muß ich mir Zuarbeit anfragen…
Danke fürs update! Dann waren es fake news von @Andreas ;-) bzw. mein Wunsch, dass I2S läuft eher Vater des Gedankens! :-)
Hmm, bei mir ist es auch so, dass der AP mode stabil läuft, aber ein eingerichtetes WLAN nicht richtig funktioniert.
In die LinkIt-Linux-Version bekommen wir den Teiber nicht, da zu alte Linux-Version, oder?
Mediatek hat proprietäre Treiber für ein paar patchlevel vom 3.18.x kernel, damit muß man sich nicht mehr ohne Not beschäftigen müssen, oder man macht die nötigen backports alle selbst! ;)
Möglich wäre noch folgendes: Im openwrt-Forum hat offenbar jemand Zugriff auf die proprietären wifi-sources von MT und baut einen aktuellen openwrt-feed (wiki, Binärtreiber) für den proprietären Treiber plus helper; 4.14.x ist was dabei, das hätte Chancen, - wenn man sich auf all das einlassen möchte…
Laß’ uns im Auge behalten und kommunizieren, wieviel yak shaving wir uns geben wollen für dieses target… ;)
Danke für Eure Erkenntnisse und Ausführungen und besonderen Dank an @weef für die session am letzten Donnerstag! Hier noch ein paar
Das jüngste Release der proprietären Firmware von LinkIt auf Basis von OpenWrt Chaos Calmer 15.04 hat bereits ein paar Monate auf dem Buckel:
$ http https://labs.mediatek.com/en/download/hpcKCI7J --follow --print Hh | grep 'Last-Modified'
Last-Modified: Wed, 30 Nov 2016 10:28:05 GMT
Die Programme dieser Firmware linken noch gegen die uClibc während aktuellere OpenWrt Distributionen gegen die modernere musl libc Bibliothek linken. Beides sind kompakte Ausgaben der von einem “großen” Linux bekannten “glibc”, der glibc - Wikipedia.
Das sind also wirklich zwei Welten. Die OpenWrt Firmware von LinkIt lebt noch in der älteren, während wir beim Einsatz von OpenWrt eher auf die neuere setzen sollten.
Nach aktuellem Stand der Dinge schaue ich bereits in Richtung BeagleBone Green. Da hier auch Mainstream Distributionen wie Debian laufen, würden wir erstmal komplett ohne yak shaving auskommen - für den Start des Testbetriebs von Saraswati vielleicht nicht ganz unschlau.
Wenn das ohne zu großen Aufwand von abenteuerlustigen unter uns noch getestet werden könnte, wäre das vielleicht wirklich noch eine Chance. Grundsätzlich wäre der LinkIt für diesen Anwendungsfall schon ein tolles Stück Hardware. Oder vielleicht doch der Carambola 2, den Du ohnehin im Einsatz hast, @weef?
P.S.: Hier bei den Forks finden sich auch noch Weiterentwicklungen, die wir uns dann ggf. ansehen sollten: Network Graph · Nossiac/mtk-openwrt-feeds · GitHub
Mal ganz doof in die Runde gefragt, @weef du sagtest, man könne den ein oder anderen code-Schnipsel, der für den Yun gebaut wurde auch für den LinkIt verwenden? Da kommen wir aber nicht weiter, oder? Haben nicht den gleichen WLAN-chip?
Nein - da hatte ich mich initial geirrt (daß ich die toolchain des AR9 auch für ramips nehmen könnte):
der AR9331 (vormals Atheros, jetzt bei Qualcomm; im Yun und Carambola2) sowie der MT7688 (core vormals von Ralink, jetzt bei Mediatek) sind zwar beide MIPS 24Kc. Sie wollen jedoch jeweils eine verschiedene endianness: der AR9 ist big endian und der ramips ist eine little endian-Maschine (siehe z.B. MIPSel – Wikipedia).
Daher sind die toolchains sowie deren Produkte nicht identisch, sondern zueinander inkompatibel - was aber in der Praxis keinerlei Einschränkung darstellt, sofern auf einem target nur die binaries der zugehörigen endianness verwendet werden.
genau - als konkurrierende Firmen verwenden sie (gemäß den ‘Kernkompetenzen’ der jeweils aufgekauften Firmen) eigene WLAN-Implementationen.
D.h. wir haben keine Chance den I2S-Treiber für den ICS43432 beim LinkIt einzuspielen, weil es nur über ein kernel-update geht und wir den aktuellen brauchen? “Nachinstallieren” auf der default firmware geht nicht, ja? D.h. der Linkit Smart ist für die I2S-Schiene gestorben, oder?
Ja; der Treiber wurde mit 4.3 released, ab da funktioniert das. Ich kann hier den Treiber bauen für die kernel 4.4, 4.9. und 4.14. Im make kernel_menuconfig vom OpenWRT kann man das Symbol SND_SOC_ICS43432 nicht direkt auswählen, es gibt keinen Menueintrag dafür, sondern es wird durch eine Kombination von anderen Sound-Optionen für dieses target automagisch ausgewählt. Leider drängelt sich da im Moment noch der WM8960-Treiber dazwischen, welcher durch den device tree für das ‘MT7620 eval kit’ (das dem LinkIt-Smart eval kit -ähnlichste Ziel, das verwendet wird) auch automatisch eingebunden wird - in Ermangelung eines besseren, passenderen device trees samt overlays…
Da kann ich gerade nicht helfen; der kernel baut natürlich für device tree overlays, aber ich muß die erst noch selbst verstehen, bevor ich da etwas sinnvoll und zielführend anfassen kann - wie schon erwähnt, ist das nämlich nicht meine Domäne. ;) Das OpenWRT macht schon alles richtig, man muß ihm halt ‘nur’ einen auf die hw zutreffenden device tree resp. overlay hinpacken, dann ginge das auch.
Wieso denn? Wenn wir das break-out board / eval kit von Seeed für das Ding hätten, würde auch der I2S mit dem WM8960 funktionieren.
Ich möchte mich mit dem proprietären WLAN-Treiber für 3.18.x nicht beschäftigen, auch nicht mit den oben erwähnten Neukompilationen von Nossiac oder deren forks. Der ‘originale’ wlan-Treiber-Stack von Mediatek ist nicht kompatibel zu den Abstraktionen mac80211 usw. von OpenWRT (letzlich linux-wireless), welche grundsätzlich unterstützenswürdig sind. Das bedingt, daß Nossiac viele helper und bindings für LuCI selbst schreiben muß - sehr schön, aber man müßte viele Kröten schlucken und wieder geschlossene unbekannte Binärbibliotheken benutzen… 8(
Mit MT76 von Felix auf dem Linkit Smart komme ich soweit gut klar, AP mode ist stabil, STA und AP gleichzeitig ist ohnehin Luxus. Ethernet mit MagJack funktioniert hier (noch ohne Bob Smith-Terminierung, ohne diese halt nicht bei beliebigen Kabellängen), finde ich allein schon zum Provisionieren allzu nützlich.
Sound an USB mit LinkIt Smart, Carambola2 oder BeagleBone klappt hier alles super auf gebautem OpenWRT, insofern ist mir I2S v.a. an den MIPS-Plattformen gerade nicht so wichtig.
Ich glaube da habe ich am Wochenende andere Erfahrungen sammeln können. Aus dem 18.06 stable release gebaut tat der LinkIt 7688. Lediglich den AVRDude musste ich downgraden, weil da ein bug drin war (vgl. How to recover a LinkIt Smart 7688 ).
Wifi läuft anstandslos auch im Dualen modus (Client und AP).
Hört sich gut an - hast Du trunk oder das tag ‘v18.06.1’ gebaut?
Branch: openwrt-18.06 commit: 4f6ad3c13a