Skip to content

FTDI Support (ayufan Kernel 5.0)

Ungelöst Probleme?
  • 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

  • Was macht?

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

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

  • das macht uns alle zu Astrofotografen, hurra 🙂

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

  • 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

  • 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

  • 0 Stimmen
    1 Beiträge
    222 Aufrufe
    Niemand hat geantwortet
  • Images 0.10.x

    Angeheftet Images
    10
    0 Stimmen
    10 Beiträge
    415 Aufrufe
    FrankMF

    0.10.12: gitlab-ci-linux-build-184 released

    0.10.12: Be strict on any qemu failures 0.10.12: Build by default mate/lxde/gnome/xfce4 0.10.12: Add pcie scan delay from @nuumio 0.10.12: Add ubuntu-mate-lightdm-theme where possible

    Ich komme gar nicht mehr mit dem Testen hinterher 🙂

  • Lüftersteuerung Kernel 4.20

    Ungelöst Probleme?
    12
    0 Stimmen
    12 Beiträge
    683 Aufrufe
    T

    @Hercemania sagte in Lüftersteuerung Kernel 4.20:

    kann man so etwas automatisieren?

    Du kannst dir ein Script schreiben oder statt make install das Programm checkinstall nutzen um ein Paket zu generieren.
    Anschließend kann man es mit checkinstall installieren bzw. deinstallieren um eine aktuellere Version zu erhalten.

    Aber ich denke ein Script für

    git pull
    make
    checkinstall -D make install
    dpkg -i <paketname>

    wäre schon mit Kanonen auf Spatzen geschossen. 😃

  • 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
  • 0 Stimmen
    2 Beiträge
    583 Aufrufe
    FrankMF

    Der frühe Vogel.... 🙂

    IMG_20181226_072626_ergebnis.jpg

    Das oben geschriebene eben nochmal durchgeführt, funktioniert einwandfrei. Jetzt kann ich die USB3-Platte umbauen und den Job verlagern. Dann habe ich einen ROCKPro64 wieder frei zum Testen 😉

  • SPI funktioniert

    ROCKPro64
    4
    0 Stimmen
    4 Beiträge
    840 Aufrufe
    FrankMF

    Wie ich jetzt mehrmals festgestellt habe, ist das System von der USB3 Platte instabil.

    [111985.654653] EXT4-fs error (d4: inode #16354: comm systemd: r[111985.837719] EXT4-fs error

    Das killt dann das komplette System.

    Ob das an meiner Hardware liegt, weiß ich nicht. Also, wer da draußen so ein System einsetzen will, Vorsicht! Die USB3-Schnittstelle scheint noch einige Bugs zu haben!!

    Mein NVMe System dagegen ist absolut stabil!

  • USB 3.0 - SATA Adapter

    Hardware
    2
    0 Stimmen
    2 Beiträge
    728 Aufrufe
    FrankMF

    Heute das Ganze mal mit einer Samsung 860 Pro mit 256GB. Eingesetztes Filesystem ext4

    rock64@rockpro64v2_1:/mnt$ uname -a Linux rockpro64v2_1 4.4.132-1077-rockchip-ayufan-gbaf35a9343cb #1 SMP Mon Jul 30 14:06:57 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux Speedtest rock64@rockpro64v2_1:/mnt$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Tue Jul 31 14:27:17 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 17896 23350 30390 31362 21611 14611 102400 16 56756 59180 86296 93819 51778 57327 102400 512 201347 221961 220840 222338 210887 230781 102400 1024 253752 273695 263884 266256 250153 273528 102400 16384 351112 356007 366417 372264 368721 356177 iozone test complete. DD Schreiben rock64@rockpro64v2_1:/mnt$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 12.8358 s, 335 MB/s Lesen rock64@rockpro64v2_1:/mnt$ sudo dd if=sd.img of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 11.4787 s, 374 MB/s Fazit

    Damit scheint der Adapter ganz gut am USB3.0 zu funktionieren. Die Schreibgeschwindigkeit ist ca. dreimal höher als mit der anderen SSD. 😉

  • Recover Button

    Hardware
    2
    0 Stimmen
    2 Beiträge
    790 Aufrufe
    FrankMF

    Ich hab das mal ausprobiert.

    Den Recover Button so lange drücken, bis folgendes erscheint.

    In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Pine64 RockPro64 rockchip_dnl_mode = 1 mode rockchip_dnl_mode = 2 mode rockchip_dnl_mode = 3 mode rockchip_dnl_mode = 4 mode entering maskrom mode...

    RKFlashTool clonen

    root@thinkpad:/home/frank/test# git clone https://github.com/rockchip-linux/rkflashtool Klone nach 'rkflashtool' ... remote: Counting objects: 663, done. remote: Total 663 (delta 0), reused 0 (delta 0), pack-reused 663 Empfange Objekte: 100% (663/663), 114.94 KiB | 0 bytes/s, Fertig. Löse Unterschiede auf: 100% (367/367), Fertig.

    In das Verzeichnis wechseln

    root@thinkpad:/home/frank/test# cd rkflashtool/

    Inhalt

    root@thinkpad:/home/frank/test/rkflashtool# ls doc Makefile rkcrc.h rkflashtool.h rkparametersblock examples README rkflashall rkmisc rkunpack.c fixversion.sh release.sh rkflashloader rkpad rkunsign flashuboot rkcrc.c rkflashtool.c rkparameters version.h

    RKFlashtool bauen

    root@thinkpad:/home/frank/test/rkflashtool# make gcc -O2 -W -Wall -I/usr/include/libusb-1.0 rkflashtool.c -o rkflashtool -lusb-1.0 gcc -O2 -W -Wall -I/usr/include/libusb-1.0 rkcrc.c -o rkcrc -lusb-1.0 gcc -O2 -W -Wall -I/usr/include/libusb-1.0 rkunpack.c -o rkunpack -lusb-1.0

    Ich habe ein USB-A to USB-A Kabel vom USB-C Port des ROCKPro64 zu meinem Notebook hergestellt.

    root@thinkpad:/home/frank/test/rkflashtool# sudo ./rkflashtool v rkflashtool: info: rkflashtool v5.2 rkflashtool: info: Detected RK3399... rkflashtool: info: interface claimed rkflashtool: info: MASK ROM MODE rkflashtool: info: chip version: -..-

    Ok, Verbindung steht.

    Eine Übersicht der Befehle

    root@thinkpad:/home/frank/test/rkflashtool# sudo ./rkflashtool rkflashtool: info: rkflashtool v5.2 rkflashtool: fatal: usage: rkflashtool b [flag] reboot device rkflashtool l <file load DDR init (MASK ROM MODE) rkflashtool L <file load USB loader (MASK ROM MODE) rkflashtool v read chip version rkflashtool n read NAND flash info rkflashtool i offset nsectors >outfile read IDBlocks rkflashtool j offset nsectors <infile write IDBlocks rkflashtool m offset nbytes >outfile read SDRAM rkflashtool M offset nbytes <infile write SDRAM rkflashtool B krnl_addr parm_addr exec SDRAM rkflashtool r partname >outfile read flash partition rkflashtool w partname <infile write flash partition rkflashtool r offset nsectors >outfile read flash rkflashtool w offset nsectors <infile write flash rkflashtool p >file fetch parameters rkflashtool P <file write parameters rkflashtool e partname erase flash (fill with 0xff) rkflashtool e offset nsectors erase flash (fill with 0xff)