Neu hier - und zukünftiger Alfred-User

markus68

Member
Hallo in die Runde,
ich bin neu hier und wollte mich kurz vorstellen.

Über die Suche nach einem Rasenboter bin ich auf den Ardumower bzw. Alfred gestossen. Mit IoT/Smarthome beschäftige ich mich schon länger und habe 2011 - um meinen Sohn "an die IT zu bringen" mit ihm einen NicoBee gebaut und ein wenig damit herum gespielt.
Löten/Hardware kann ich zwar, aber ist nicht so mein Ding. Bin als IT-ler eher auf der Software-Seite unterwegs.

Daher kam die Ankündigung mit dem Alfred gerade richtig für mich, da eben vom Chassis "fertig". Auch die Tatsache dass er auf einem BananaPi basiert, kommt mit sehr gelegen. Ich habe zwar auch schon ESPs und Arduinos (und auch PICs) programmiert, aber mir ist etwas lieber, wo ich per SSH in einer CLI bin ...

Wenn der Alfred kommt, werde ich über meine Erfahrungen berichten. Plan ist auch, ihn zügig in meine Smarthome-Umgebung zu integrieren. So Zeit ist will ich auch das Projekt/die Community unterstützen. Zumindest mit Feedback, aber auch mit Code/Ergänzungen soweit möglich.

VG
-Markus
 
Hallo Markus, willkommen im Ardumower Forum.

Bin gespannt auf deinen Erfahrungsbericht.

Grüße
Willi
 
Hallo Markus,
willkommen im Forum - vielleicht bist Du zufälligerweise (oder jemand anders) ja Fit in Linux Kernel Programmierung bzw. in Linux-Kernel Kompilieren? :) Wir haben aktuell das Problem, dass der Kernel beim Anschliessen einer USB-Kamera den USB-Host Treiber nach einer zufälligen Zeit (wenige Minuten bis Stunden) deaktiviert ( https://forum.banana-pi.org/t/bpi-m4-usb-host-dying-uvcvideo-and-usb-rtl8821cu ). Grundsätzlich scheint es kein Hardware-Problem zu sein sondern evtl. ein Bug im (alten) Kernel. Hier ist die Stelle im Kernel.
Uns fehlt aber (aktuell) das Know-How wie man z.B. eine neuere Kernel-Version für den Banana PI kompiliert... Evtl. kann uns da jemand unterstützen? :)
Das Kompilieren des von Banana PI bereitgestellten Kernel 4.9.119 haben wir nach der Banana PI-Anleitung (https://github.com/BPI-SINOVOIP/BPI-M4-bsp ) geschafft - dies funktioniert am Besten auf einem x86/64 Linux System (z.B. Ubuntu 18.04). Jetzt wäre interessant herauszufinden wie man dies für eine neuere Kernel-Version macht...
Gruss,
Alexander
 
Zuletzt bearbeitet:
Hi Alexander,
ich schaue am Sonntag mal, was sich machen lässt. Eine schnelle Recherche zeigt, dass der Support für den M4 leider nicht gerade berauschend ist.
Eine Chance sehe ich, es für Kernel 4.19.x (letzter aus der 4.x Reihe) hinzubekommen. Ob da aber schon Änderungen im XHCI-Bereich stattgefunden haben, also es Hoffnung für Beseitigung des Fehlers gibt, müsste ich schauen.
Für Kernel 5.x scheint es zwar rudimentären Support für den RTL-Chip selber direkt im Kernel zu geben, aber keine Treiber ...
Ich melde mich mit meinen Erkenntnissen.

VG
-Markus
 
Also einmal könnte man versuchen den Endpoint-Watchdog (
https://github.com/BPI-SINOVOIP/BPI...d/linux-rtk/drivers/usb/host/xhci-ring.c#L891 ) zu deaktivieren, so dass der URB Watchdog nicht mehr auslösen kann. Ob das sinnvoll ist kann ich derzeit nicht beurteilen. Der Watchdog erscheint mir mit 5 Sek. eigentl. ausreichend bemessen (https://github.com/BPI-SINOVOIP/BPI...acf3d/linux-rtk/drivers/usb/host/xhci.h#L1469).

Desweiteren könnte man dann versuchen einen neuen Kernel zu kompilieren (in welchem BPI-Forumsthread hast Du denn etwas interessantes gefunden? :) )

Eine schnellere Reproduktion des Fehlers suche ich auch noch - derzeit muss ich 1-8 Stunden warten damit der Kernel-Fehler auftritt... (sehr lange Iterationszeiten für Versuche)

Eine weitere Idee wäre den Kernel-Fehler zu akzeptieren, zu monitoren und dann ggf. den USB-Host-Treiber neu zu laden (falls das bei USB Host Treibern geht). Mit allen Nachteilen die so etwas nach sich zieht (sich ändernde Gerätepfade/Dateihandles etc.)...
 
Zuletzt bearbeitet:
Das war Dein Post im BPI Forum wo Du auch die Distribution angegeben hattest.
Den Thread bzw. das Repo von Martin habe ich auch gefunden, aber da ging es dann irgendwann nicht weiter: https://forum.banana-pi.org/t/kernel-5-0-and-above/11903 . Der so gebaute Kernel scheint nicht zu booten.

Meine Befürchtung ist, dass ein neuer Kernel nix bringt sondern das Problem beim Treiber der Hardware liegt. Ein Post auf Stackoverflow suggeriert das : https://stackoverflow.com/questions...-host-not-responding-to-stop-endpoint-command

Ich bleibe dran (sobald ich Sonntag mehr Zeit habe)
 
Ja, ich gehe davon aus dass Kerneltreiber neu hineinladen funktionieren wird (ich werde das ausprobieren) - keine schöne Lösung aber besser als gar nichts :)
 
Zuletzt bearbeitet:
Auf die Schnelle den USB Host-Treiber "xHCI HCD (USB 3.0) support" als "Modul" kompilieren (und damit neu hineinladbar machen) funktioniert schon mal nicht :) ...
Code:
ERROR: "RTK_dwc3_usb2_phy_toggle" [drivers/usb/host/xhci-hcd.ko] undefined!
ERROR: "RTK_dwc3_usb3_phy_toggle" [drivers/usb/host/xhci-hcd.ko] undefined!
scripts/Makefile.modpost:107: recipe for target '__modpost' failed
make[2]: *** [__modpost] Error 1
Makefile:1312: recipe for target 'modules' failed
make[1]: *** [modules] Error 2
make[1]: Leaving directory '/home/alex/images/4.9.119/BPI-M4-bsp/linux-rtk'
Makefile:41: recipe for target 'kernel' failed
make: *** [kernel] Error 2

Der Treiber "RTK DW3 DRD (dynamical host/device mode switch)" hängt vom USB Host Treiber ab und kann scheinbar nicht als "Modul" kompiliert werden...
 
Zuletzt bearbeitet:
Hmm, Du hast ja geschrieben dass das Problem nur auftritt, wenn Wifi aktiv. Hast Du mal den Powersave explizit über "iw" für das Wlan-Device abgeschaltet (nicht nur implizit über USB-Autosuspend wie Du im BPI-Forum geschrieben hast ?)
Das Problem könnte auch eben am Wifi-Treiber liegen. Da scheint es aktuellere Linux-Treiber für 4.x bis 5.x Kernel mit aktueller Weiterentwicklung zu geben : https://github.com/brektrou/rtl8821CU bzw. https://github.com/axiomware/RTL8821CU_driver_v5.8.1 .
Diese sollten sich einfacher kompilieren lassen für den M4-Kernel
 
Super, das wäre ein Ansatz :) Und ja, das WiFi Powersave haben wir direkt am ersten Tag abgestellt :)

Code:
# stop wifi power saving
until iw wlan0 set power_save off  > /dev/null 2>&1
 
Ich habe den RTL8821CU-Treiber (https://github.com/brektrou/rtl8821CU
) in die 4.9.119 Kernel-Sourcen kopiert (den alten vorher gelöscht) und den Kernel neu kompiliert. Der Absturz des USB Hosts tritt immer noch auf :-/ Ich glaube Markus wäre bereit einen Alfred zu sponsern für die Lösung des Problems... ;-)
 
Ich fürchte, so tief im Kernel Debugging/Development bin ich nicht drin.
Willst Du evtl. mal den Frank-W aus dem BPI-Forum https://forum.banana-pi.org/t/kernel-5-0-and-above/11903 ansprechen ? Der wohnt in Bamberg und hat sich zumindest in den BPI-R2 und den ganzen Build-Prozess tief reingegraben.
Lt. dem Thread hat das Erstellen eines 5.x Kernels ja funktioniert, er bootet aber wohl nicht. Frank konnte mangels HW aber nicht testen.

Eine Frage am Rande: warum habt Ihr Euch denn für den BPI-M4 entschieden ? Der Support und die Community darum sind nicht gerade rosig. Beim klassischen RaspberryPi 4 z.B. läuft ganz normal (incl. Updates und Kernel Updates) ein Ubuntu 20.04.4 LTS bei mir mit sogar mit Boot von USB-Stick anstatt SD.

Einen 4.19.x Kernel zu integrieren ist auch nicht so trivial wie ich dachte, da es Änderugen im Kernel für die DMA-Api gab.
Ich werde probieren, die Treiber (xhci) aus dem 4.9.311 zu integrieren. Die sollten kompatibel sein und es gab in jedem Fall Änderungen in den .h und .c files zu 4.9.119.
 
Die Firma hinter "Banana PI" war die einzigen welche uns 3-stellige Mengen liefern konnte. Den RaspberryPi wird es voraussichtl. Ende diesen/Anfang nächsten Jahres in 2 bis 3-stelligen Bestellmengen geben - Bei der Evaluierung gab es ja auch keine Probleme, erst als wir die USB-Kamera anschliessen wollten und die Single Board Computer geliefert waren fingen die Probleme nach einiger Zeit an...
 
Frank hat leider sehr wenig Zeit, er hat folgenden Ratschlag gegeben:

grundsätzlich sind die bpi-repos sehr alt und man kann nie erkennen, welchen code sie nachträglich reingebracht haben. das macht es schwer, zu erkennen, ob alle nötigen Treiber im mainline-Kernel vorhanden sind, oder nicht.

grundlegend solltet ihr euch die defconfig und den Befehl zum bauen aus dem bpi-repo holen und das in einen neueren Kernel einbauen

das müsste die defconfig sein:

die kernel-parameter sind hier (make kernel in dem script mit Makefile-position)


beim bauen auf einer anderen Architektur braucht müsst ihr vorher die Ziel-Architektur und den crosscompiler definieren

z.b.

ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make ...

statt der 3 punkte übergibt man im ersten step die defconfig, kann danach mit menuconfig anschauen/ändern und zum schluss dann make allein bzw. mit dtbs/modules/… + der entsprechenden load-parameter aus dem bpi-makefile

welche dateien dann kopiert werden, steht in der build.sh…ich nehme mal an, dass zumindest die dts(i) noch rüberkopiert werden müssen und ggf. bestimmte treiber

das wäre die dtb (dts heist genauso und in dieser mal nach den includes schauen, welche da ggf. fehlen): arch/arm64/boot/dts/realtek/rtd139x/rtd-1395-bananapi-m4-*.dtb
 
Und ein ganz anderer Aspekt ist: muss man überhaupt den "xhci-Treiber" verwenden (für den USB2.0 Host) oder reicht nicht auch ein "ehci-Treiber"?
Ich habe es testweise probiert aber es wurden keine USB-Geräte mehr erkannt...
 
Zuletzt bearbeitet:
Ich habe mal Kernel 5.17.4 und 4.9.119 BPI verglichen - ganz so trivial ist das wirklich nicht, im 5.x Kernel fehlen etliche Dinge aus dem BPI-Kernel für den RTD1395 SoC (SDMMC, UIO, SERIAL, I2C, MMIO, DWC3, ....) :

CONFIG_RTK_PLATFORM=y
CONFIG_MMC_RTK_EMMC=y
CONFIG_MMC_RTK_SDMMC=y
CONFIG_LEDS_RTK=y
CONFIG_UIO_RTK=y
CONFIG_UIO_RTK_SE=y
CONFIG_UIO_RTK_MD=y
CONFIG_SERIAL_8250_RTK=y
CONFIG_RTK_WATCHDOG=y
CONFIG_I2C_RTK=y
CONFIG_ION_RTK=y
CONFIG_RTK_TIMER=y
CONFIG_RTK_THERMAL=y
CONFIG_RTK_CODEC=y
CONFIG_RTK_RESERVE_MEMORY=y
CONFIG_RTK_SB2_SECURITY_DEBG=y
CONFIG_RTK_RBUS_BARRIER=y
CONFIG_RTK_MEM_REMAP=y
CONFIG_RTK_REGMAP_I2C=y
CONFIG_RTK_MMIO=y
CONFIG_RTK_MCP=y
CONFIG_RTK_CPU_SUPPLY_ENHANCER=y
CONFIG_RTK_WORKAROUND_ARM_PMUV3=y
CONFIG_RTK_RPC=y
CONFIG_RTK_HSE=y
CONFIG_RTK_REGISTER_TRACKER=y
CONFIG_RTK_FAN=y
CONFIG_RTD139x=y
CONFIG_PWM_RTK=y
CONFIG_RTK_PWM_DEBUG=y
CONFIG_PHY_RTK_SATA=y
CONFIG_RTK_EFUSE=y
CONFIG_RTK_TRACER=y
CONFIG_USB_RTK_CTRL_MANAGER=y
CONFIG_USB_DWC3_RTK=y
CONFIG_USB_RTK_DWC3_DRD_MODE=y
CONFIG_USB_PATCH_ON_RTK=y
CONFIG_USB_EHCI_RTK=y
CONFIG_USB_OHCI_RTK=y
CONFIG_RTK_USB_RLE0599_PHY=y
CONFIG_RTK_USB2PHY=y
CONFIG_RTK_USB3PHY=y
CONFIG_BT_RTKBTRFKILL=y
CONFIG_BT_HCIUSB_RTK=m
CONFIG_RTK_HDMITX=y
CONFIG_RTK_HDCP_1x=y
CONFIG_RTK_CVBS_SWITCH=m
CONFIG_RTK_CEC=y
CONFIG_DRM_RTK=m
CONFIG_FB_RTK=y

Einen aktuellen Kernel wird man m.E. nicht nehmen können weil einfach zuviel fehlt. Den BPI-Kernel patchen sieht machbar aus...
 
Zuletzt bearbeitet:
Mal eine ganz andere Frage: Seid Ihr Euch sicher, dass es an der SW liegt und kein HW-Problem ist? Habt Ihr mal testweise einen USB-HUB mit externer Spannungsversorgung angeschlossen und die Kamera dahinter? Nicht dass die Kamera einen grenzwertigen Stromverbrauch hat und es gelegentlich zur Überlast kommt.
Mit Banana habe ich 0 Erfahrung, aber mit einem Raspberry hatte ich da schon mal Probleme, dass ich die USB-Versorgung überlastet hatte.
 
Ja, USB-Hub haben wir 3 verschiedene ausprobiert (mit gesplitteter externer Stromversorgung), wir haben sogar extra Versorgungsleitungen mit höherem Querschnitt gelegt etc., wir haben so ziemlich alles probiert. Die Probleme sind ja vom Raspberry bekannt und leider haben die üblichen Lösungen beim Banana Pi nicht geholfen.
 
Oben