Menü
Aktuelles
Von:
Filter

Neu hier - und zukünftiger Alfred-User

Es ist auch nicht neu dass Software Bugs enthält - so hat die Arduino Software für den Arduino Due und auch für den GCM4 Software-Bugs. Das konnten wir in der Vergangenheit alles lösen weil es technische Programmier-Dokumentation/Spezifikationen zu den entsprechenden MCU-Chips gibt. Diesmal ist es aber anders, es gibt keine Programmier-Dokumentation zu dem SoC Chip auf dem Banana PI (Realtek RTD1395). Damit ist die Plattform eigentlich relativ nutzlos (ohne Programmierdokumentation der Chips kein Bugfixing möglich). Nur leider derzeit die einzige Plattform welche noch in ausreichender Stückzahl zu beziehen ist...
 
Zuletzt bearbeitet:
Hi Alexander,
ich habe Sonntag etwas Zeit investieren können, war aber leider wenig erfolgreich (frei nach Edison: ich habe mehrere Wege gefunden, wie es nicht geht ...)

Es kam mir aber eine Idee, die Du evtl. kurzfristig probieren könntest: Hast Du einen (älteren) Wifi-USB Adapter der auf einem anderen Chip basiert und vom M4 supported wird ? Meine Theorie: wenn es damit nicht zu Abstürzen käme, dann wäre der Wifi-Treiber der Übeltäter und man hätte ggfs. einen Workaround.
Treten die Probleme immer noch auf denn müsste man im Bereich USB bzw. USB-Hub des RTD1395 weitersuchen.

Einen neueren Kernel zum Laufen zu bekommen, halte ich für sehr schwer. Einer meiner Versuche war, einen Diff vom Stock-Linux-Kernel 4.9.311-4.9.119 auf den linux-rtk anzuwenden. Knapp 300+ Hunks sind gefailed. Habe angefangen die manuell zu resolven, aber dann waren ARM-Assembler Teile (memory-mgmt, Interrupts usw) betroffem - das war zu viel für mich...
Nächster Ansatz war, einen diff vom 4.9.119 zum linux-rtk, um die RTD1395 spezifischen Teile zu identifizieren. Leider sind da auch Änderungen sichtbar, die IMHO nichts mit RTD1395 oder Treibern zu tun haben (siehe Attachment). Entweder wurde da wirklich tief rumgefummelt oder Teile des linux-rtk basieren noch auf älteren Teilen des Kernel (was u.U. auch manche Probleme erklären könnte).
Eine ähnliche Übung müsste man machen, wenn man einen aktuellen 5.x Kernel mit entsprechender Treiber-Unterstüzung haben wollte.

Mein aktueller Ansatz ist nun, im Bereich USB den Code aus Stock-4.9.119 in den linux-rtk zu nehmen. Und dann schauen ob man es kompiliert bekommt bzw. ob der Fehler auftritt. (Mein Test-M4 kommt erst heute ...) Ob das am Ende zielführend wird und wie lange des dauert, kann ich nicht sagen.

Den Test mit einem billig USB-Wifi-Adapter halte ich aktuell für den besten Versuch. Den könnte ich die Woche auch machen (habe noch 2 hier rumliegen, muss schauen welche Chips da drin sind) ...

VG,
-Markus
 

Anhänge

  • diff_linux-rtk_linux-4.9.119.txt
    116,9 KB · Aufrufe: 3
Hallo,
ich habe hier mehrere WiFi USB Adapter (u.a. tp-link TL-WN 722N) mit RTL8188EU und dieser wird unterstützt. Damit werde ich testen.
Gruss,
Alexander
 
Zuletzt bearbeitet:
Der USB-Host-Kernel-Fehler tritt auch mit RTL8188EU auf (mit externem WiFi USB Adapter und Kernel-Treiber für internes RTL8821CU WiFi deaktiviert).
 
Zuletzt bearbeitet:
Schade, war einen Versuch wert.
Den Lockup nach Traffic testest Du aber auch noch ? Wie sicher ist es, dass die 2 Probleme identisch sind bzw. die gleiche Ursache haben ?

Langsam gehen mir die Ideen aus. Was man dennoch probieren könnte:
  • testweise ein WiFi-Modul für den M.2 E-Key finden (wo es auch Treiber gibt) und schauen, ob es besser wird
  • in der arch/arm64/configs/rtd139x_bpi_defconfig einmal mit den USB Optionen spielen
  • Code: 
    #
# USB Physical Layer drivers
#
CONFIG_USB_PHY=y
# CONFIG_USB_OTG_WAKELOCK is not set
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_ULPI is not set
# CONFIG_DUAL_ROLE_USB_INTF is not set
CONFIG_RTK_USB_RLE0599_PHY=y
CONFIG_RTK_USB2PHY=y
CONFIG_RTK_USB3PHY=y
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2

Mein BPI-M4 ist mittlerweile da, aber ich bekomme den nicht richtig zum Laufen. Diverse BPI-Images, SD-Karten, 2 USB-Netzteile probiert: Kernel startet aber es gibt immer irgendwelche Crashes später (meist "init") und ich bekomme werder was auf dem HDMI noch login auf dem Netz, er startet oft auch noch nicht mal die Karte richtig. Auch eigener Kernel mit der BSP-M4 toolchain gebaut verhält sich gleich.

Habe den M4 auf eBay-KA besorgt - evtl. hat der irgendeinen Schlag - oder ich bin zu blöd ...
 
Den loader für 1GB drauf und schon rennt das Ding. Danke @AlexanderG , da wäre ich nie drauf gekommen und hätte mich weiterhin gewundert, warum selbst die fertigen Images nicht laufen.
Werde nun mit oben erwähnten Base-Image testen, ob ich den Fehler nachstellen und evtl. Workarounds finden kann.

Frage: tritt er nur mit einer USB-Kamera auf ? Hast Du (aka soll ich) mal versuchen, bei normalem USB-Traffic (lesen von einem Stick) bei Wifi-Betrieb diesen zu reproduzieren ?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben