Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. Probleme?
  5. FTDI Support (ayufan Kernel 5.0)

FTDI Support (ayufan Kernel 5.0)

Ungelöst Probleme?
  • D

    Hallo zusammen,

    ich nutze einen RockPro64 zur Astrofotografie und hatte Probleme mit meiner Kamera am USB 3.0 Port weswegen ich vom standardmäßigen Kernel 4.4.190 auf Kernel 5.0 umgestiegen bin (aktuell 5.0.0-1092-ayufan-g58b7aac480ae), usprünglich installiert mit dem Image bionic-mate-rockpro64-0.9.14-1159-armhf.img

    Nun habe ich ein USB-Device das sich wie folgt per lsusb meldet:

    Bus 007 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

    leider bekomme ich keine Verbindung hin, denn es gibt offenbar keine passenden Treiber und auch das ftdi_sio Modul ist nicht vorhanden.
    modprobe meldet:

    modprobe: FATAL: Module ftdi_sio not found in directory /lib/modules/5.0.0-1092-ayufan-g58b7aac480ae

    und dmesgsagt meldet beim anschließen:

    usb 7-1: new full-speed USB device number 3 using xhci-hcd

    Wie kann ich es hinbekommen, dass das Gerät erkannt wird?

    Gruß und Danke,
    Dominik

    0
  • FrankMF

    Was macht?

    /sbin/modprobe ftdi_sio

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0
  • K

    hallo,
    da hilft eigenen kernel bauen. ist nicht so schwer, das netz ist voll mit infos dazu.
    gruß

    1
  • FrankMF

    Man kann Kamil auch bitten, das Modul in den Kernel einzubauen. Das hat es schon öfter mal gemacht. Fragen kostet nichts 😉

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0
  • K

    das macht uns alle zu Astrofotografen, hurra 🙂

    0
  • FrankMF

    Wenn ich mir das hier mal auf meinem NAS anschaue, dann finde ich as Modul

    root@rp64v_2_1_NAS:/lib/modules/4.4.138-1094-rockchip-ayufan-gf13a8a9a4eee/kernel/drivers/usb/serial# ls -lha f*
-rw-r--r-- 1 root root  19K Aug  9  2018 f81232.ko
-rw-r--r-- 1 root root 136K Aug  9  2018 ftdi_sio.ko

    Ist uralt der Kernel, ich fahre da normalerweise einen 5er. Das aktuelle Image mal eben lokal eingehangen.

    root@debian:/media/frank/linux-root/lib/modules/4.4.190-1233-rockchip-ayufan-gd3f1be0ed310/kernel/drivers/usb/serial# ls -lha f*
-rw-r--r-- 1 root root  19K Aug 28 11:00 f81232.ko
-rw-r--r-- 1 root root 136K Aug 28 11:00 ftdi_sio.ko

    Ich bin da jetzt vorsichtig, bin nicht der Experte für Module 🙂 Das müsste in meinen Augen funktionieren. Im 5er Kernel habe ich das Modul nicht gefunden.

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0
  • K

    Hi, ich habe Kamil mal angeschrieben, ob er das in einem Update einbauen könnte. Benötige das auch für meine Arduinos. Laufe derzeit noch auf dem 4.4., aber würde auch gerne mal den 5er Kernel ausprobieren.
    Gruss

    1
  • K

    Hi, leider habe ich bisher keine Antwort von Kamil erhalten. So habe ich selbst mal einen Kernel kompiliert. Als Vorlage habe ich den Ayufan 5.3 rc4 1118 genommen. Also gleiche config nur zusätzlich den FTDI und den CH341 (Arduino clones) Treiber hinzugefügt. Könnt ihr ja mal bei Lust und Laune testen. Für meine Zwecke funktioniert er gut.
    Gruss
    https://drive.google.com/file/d/1kJarihL7bAqN9y6tK-m1V4zHCSEiEWtf/view?usp=sharing

    1

  • R

    Schon wieder mal: Problem mit SATA Karte Marvell 88SE9230 - mainline kernel installieren?

    Gelöst Probleme?
    27
    0 Stimmen
    27 Beiträge
    2k Aufrufe
    FrankMF

    Danke für die Rückmeldung.

    Mein NAS läuft wie gesagt schon relativ lange sehr stabil. Und es macht auch was 🙂 Es sichert z.B. dieses Forum und viele andere Seiten regelmäßig. Ansonsten dient es als mein Datengrab. Nix besonderes..

    Wenn Du nicht so komplizierte Dinge fragst, darfst du gerne neue Threads eröffnen 🙂

  • FrankMF

    ROCKPro64 - Anpassen resize_rootfs.sh

    Angeheftet ROCKPro64
    3
    0 Stimmen
    3 Beiträge
    421 Aufrufe
    FrankMF

    Seit Release 0.10.10 ist das automatische Vergrößern der Root Partition mit drin 🙂

    0.10.10: Support automated resize when booting from nvme

    Einfach das Image auf die NVMe SSD schreiben, ab in den ROCKPro64 und fertig! Nach dem Booten wird die Partition dann automatisch auf die maximal mögliche Größe erweitert.

    Kamil hat das Script auch ein wenig angepasst.

    case $dev in /dev/mmcblk?p?) DISK=${dev:0:12} PART=${dev:13} NAME="sd/emmc" ;; /dev/sd??) DISK=${dev:0:8} PART=${dev:8} NAME="hdd/ssd" ;; /dev/nvme?n?p?) DISK=${dev:0:12} PART=${dev:13} NAME="pcie/nvme" ;;

    Das Resultat bei einer Samsung 979 EVO mit 500GB Speicher

    rock64@rockpro64:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 918M 0 918M 0% /dev tmpfs 192M 5.2M 187M 3% /run /dev/nvme0n1p4 459G 1.2G 439G 1% / tmpfs 957M 0 957M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 957M 0 957M 0% /sys/fs/cgroup /dev/nvme0n1p3 229M 44M 169M 21% /boot /dev/nvme0n1p2 12M 0 12M 0% /boot/efi tmpfs 192M 0 192M 0% /run/user/1000

    Perfekt. Danke Kamil!

  • K

    NVME stromverbrauch mainline kernel, APST

    Ungelöst Probleme?
    4
    2 Stimmen
    4 Beiträge
    494 Aufrufe
    K

    falls jemand das otf (on-the-fly) ausprobieren möchte und sysfs an hat (heißt so glaub ich, ist aber default vermutlich): mit

    /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us

    herum spielen. Wert auf 0 schreiben, dann den Wert der latenz. Siehe unten. Das beispiel unten von mir zeigt bei für mein system bspw auch den grenzwert (10000, aus dem p3 exlat, obwohl das angeblich nicht so sein sollte). bei 9999 geht das system 1W hoch, bei 10000 runter

    ps 0 : mp:5.00W operational enlat:0 exlat:0 rrt:0 rrl:0 rwt:0 rwl:0 idle_power:- active_power:- ps 1 : mp:3.50W operational enlat:0 exlat:0 rrt:1 rrl:1 rwt:1 rwl:1 idle_power:- active_power:- ps 2 : mp:3.00W operational enlat:0 exlat:0 rrt:2 rrl:2 rwt:2 rwl:2 idle_power:- active_power:- ps 3 : mp:0.0700W non-operational enlat:4000 exlat:10000 rrt:3 rrl:3 rwt:3 rwl:3 idle_power:- active_power:- ps 4 : mp:0.0025W non-operational enlat:4000 exlat:45000 rrt:4 rrl:4 rwt:4 rwl:4 idle_power:- active_power:- echo "0" > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us echo "9999" > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us echo "0" > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us echo "10000" > /sys/class/nvme/nvme0/power/pm_qos_latency_tolerance_us
  • FrankMF

    Kernel 4.4.x

    Angeheftet Images
    45
    0 Stimmen
    45 Beiträge
    4k Aufrufe
    FrankMF

    4.4.202-1237-rockchip-ayufan released

    PATCH: kernel 4.4.201-202
  • FrankMF

    Unterstützung Lüfter

    ROCKPro64
    5
    0 Stimmen
    5 Beiträge
    2k Aufrufe
    FrankMF

    Mit dem neuen Release hatte jemand das mal ausprobiert -> https://forum.frank-mankel.org/topic/795/fan-control-omv-auyfan-0-10-12-gitlab-ci-linux-build-184-kernel-5-6/6

    Dieser Kernel kam zur Anwendung

    Linux rockpro64 5.6.0-1137-ayufan-ge57f05e7bf8f #ayufan SMP Wed Apr 15 10:16:02 UTC 2020 aarch64 GNU/Linux

    Dort stellt man dann fest, das sich eine Kleinigkeit geändert hat. Der Pfad und der Dateiname hat sich geändert.

    Kontrollieren kann man das mit

    nano /sys/devices/platform/pwm-fan/hwmon/hwmon3/pwm1

    Der Wert geht von 0 - 255, wie gehabt.

  • FrankMF

    [HOWTO] ROCKPro64 - Boot

    Verschoben Hardware
    5
    0 Stimmen
    5 Beiträge
    4k Aufrufe
    FrankMF

    Das Problem sollte mit Kernel 4.19.0-rc4-1069-ayufan behoben sein.

  • FrankMF

    stretch-openmediavault-rockpro64

    Verschoben Linux
    1
    0 Stimmen
    1 Beiträge
    792 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Links

    Angeheftet Linux
    1
    0 Stimmen
    1 Beiträge
    763 Aufrufe
    Niemand hat geantwortet