Audio Recording mit LinkIt Smart 7688 und I2S-Mikro

Entwicklung / Development Maschinenraum / Machine room
19

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.

22

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.

24

A post was merged into an existing topic: Developing Saraswati: A robust, multi-channel audio recording, transmission and storage system

25

@weef gibt es ein image für den LinkIt, das die I2S-Schnittstelle unterstützt?

26

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…

1 Like
27

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?

28

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

29

Danke für Eure Erkenntnisse und Ausführungen und besonderen Dank an @weef für die session am letzten Donnerstag! Hier noch ein paar

Weitere Details

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

Und nun?

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

30

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?

31

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.

32

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?

33

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.

2 Likes
34

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

3 Likes
35

Hört sich gut an - hast Du trunk oder das tag ‘v18.06.1’ gebaut?

36

Branch: openwrt-18.06 commit: 4f6ad3c13a

39

@weef, hast du das erfolgreich nachbauen können?

Ich hatte bei meinem Build diesen LinkIt Feed von MediaThek inkludiert, jedoch den wifitreiber vor dem bauen raus geschmissen, denn den brauchte ich ja nicht. Ich war nur auf das pinmux binary scharf, weil mein AVRDude nicht tat und ich hoffte, dass deren /usr/bin/run-avrdude daran etwas richten könnte. Konnte es aber nicht. Letzlich bin ich auf avrdude 6.1 gegangen, welches funktioniert hat. (vgl. AVRDUDE Issues)

45

2 posts were merged into an existing topic: Whisper policy

46

Exzellent! Schön, dass es bzgl. des LinkIt vielleicht doch noch Hoffnungen gibt. Ich hatte ihn nach den Ergebnissen aus der letzten Session gemeinsam mit @weef, die aber am Ende dann wegen vermuteter FOSS Treiberprobleme dann doch enttäuschend waren, auch schon abgeschrieben. Merci, @einsiedlerkrebs!

47

2 posts were merged into an existing topic: Whisper policy

48

Ich weiß nicht, ob ich es noch korrekt reproduzieren kann - war schon eine weile her: Den AP-Mode habe ich hinbekommen, und afaik bin ich da auch auf LUCI gekommen. Dort habe ich dann den AP deaktiviert und meine WLAN credentials eingetragen, so dass sich der LinkIt lokal einloggen kann. Dann kam ich über das lokale WLAN nicht mehr ran. Das habe ich damals auf den buggy WLAN-Treiber geschoben.

Nun hat mir @einsiedlerkrebs aber noch den Tipp gegeben, dass

bei OpenWRT im default gar keine Dienste von “außen” erreichbar sind. Während du eine IP vom LinkIt beziehst bist du in dessen LAN Domäne, wo z.B. SSH und HTTP exposed sind. Dein Heimnetzwerk ist für den LinkIT jedoch sein WAN Domäne. SSH und HTTP müsstest du explizit in der Firewall erlauben:
/etc/config/firewall :

config rule
        option src              wan
        option dest_port        22
        option target           ACCEPT
        option proto            tcp
        option name       ALLOW_SSH

config rule
        option src              wan
        option dest_port        443
        option target           ACCEPT
        option proto            tcp
        option name       ALLOW_HTTP

… $ /etc/init.d/firewall restart nicht zu vergessen

1 Like