Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. nodejs & NodeBB

nodejs & NodeBB

ROCKPro64
  • FrankMF

    Wollte mal schauen wie gut die 0.6.51 von Softwareseite aus läuft. Dazu habe ich mal eben nodejs und NodeBB auf dem ROCKPro64 installiert. Das klappt einwandfrei, keine besonderen Hürden 🙂

    0_1528535019700_nodebb.png

    Die Probleme die noch gelöst werden müssen sind also wohl alle noch hardwareseitig. Sieht also so aus, als wenn das .dtb File noch viel Arbeit benötigt.

    Die 0.6.51 läuft hier sehr stabil, einziges Problem was sie hat. Beim Starten klappt es ab und zu nicht. Muss man manchmal öfter probieren. aber wenn sie läuft ist sie sehr stabil.

    Linux

    rock64@rockpro64:/$ uname -a
Linux rockpro64 4.4.126-rockchip-ayufan-253 #1 SMP Mon Jun 4 08:47:16 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

    nodejs

    Installation

    Bitte nach dieser Anleitung
    Wichtig ist nur, das ihr als Plattform arm64 nehmt!

    rock64@rockpro64:/$ node -v
v8.11.3

    NodeBB

    rock64@rockpro64:~/nodebb$ ./nodebb -V  
1.9.3

    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
Anmelden zum Antworten

  • FrankMF

    WLan auf der Konsole einrichten

    Angeheftet Linux
    3
    0 Stimmen
    3 Beiträge
    645 Aufrufe
    FrankMF
    Ich kann im Manjaro keine WPA3 Sicherheit auswählen, dann bekomme ich keine Verbindung. Es geht nur WPA2 Personal. Gegenstelle ist eine FRITZ!Box 6591 Cable. [image: 1638114013848-2021-11-28_16-37.png] In der Fritzbox sieht das so aus [image: 1638114096062-50d23aa8-5f67-485e-a994-244ef4f6a270-image.png] Das kam als Fehlermeldung Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: Trying to associate with SSID 'FRITZ!Box 6591 Cable AK' Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: WPA: Failed to select authenticated key management type Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: WPA: Failed to set WPA key management and encryption suites Ich denke, der Treiber unterstützt das nicht.
  • FrankMF

    ROCKPro64 - 0.9.16 mit Kernel 5.6 auf PCIe NVMe SSD

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    384 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Zwischenfazit April 2019

    Angeheftet ROCKPro64
    1
    1
    1 Stimmen
    1 Beiträge
    571 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    960 EVO M.2 vs. 970 PRO M.2

    ROCKPro64
    2
    0 Stimmen
    2 Beiträge
    2k Aufrufe
    FrankMF
    Die 970 steckt jetzt in meinem Haupt-PC. Dort werkelt ein aktuelles Linux Mint Cinnamon 19. Zum Vergleich. 100M frank@frank-MS-7A34:~$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 [sudo] Passwort für frank: Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux-AMD64 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: Sun Aug 19 16:52:19 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 92640 121912 131074 139525 45719 116653 102400 16 254286 285267 285539 320370 108049 314486 102400 512 537947 581765 606103 598137 537701 588214 102400 1024 566892 547921 567369 597286 518014 558686 102400 16384 1407884 1642148 1941120 2115608 2006947 1668118 iozone test complete. 1000M frank@frank-MS-7A34:~$ sudo iozone -e -I -a -s 1000M -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-AMD64 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: Sun Aug 19 15:28:38 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 1024000 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 1000M -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 1024000 4 95635 121379 108328 108265 45369 123356 1024000 16 239238 314359 245937 241877 105865 297193 1024000 512 596812 620661 442100 382367 351948 613525 1024000 1024 608903 611898 434687 417192 412018 646465 1024000 16384 1898738 2004622 2143647 2188062 2099674 1983240 iozone test complete. Da scheint auf dem ROCKPro64 noch ein wenig Luft nach oben.
  • FrankMF

    ROCKPro64 - kein WLan-Modul möglich?

    ROCKPro64
    4
    2
    0 Stimmen
    4 Beiträge
    2k Aufrufe
    FrankMF
    Heute, 5 Monate später, kann ich bestätigen das WLan möglich ist Getestet auf einem ROCKPro64 v2.1 mit 2GB RAM. Eine Vorabversion von Recalbox machte es das erste Mal für mich möglich das WLan zu benutzen. Bericht Und PCIe ist abgeschaltet im dts File. pcie-phy { compatible = "rockchip,rk3399-pcie-phy"; #phy-cells = <0x0>; rockchip,grf = <0x15>; clocks = <0x8 0x8a>; clock-names = "refclk"; resets = <0x8 0x87>; reset-names = "phy"; status = "disabled"; phandle = <0x8b>; }; pcie@f8000000 { compatible = "rockchip,rk3399-pcie"; #address-cells = <0x3>; #size-cells = <0x2>; aspm-no-l0s; clocks = <0x8 0xc5 0x8 0xc4 0x8 0x147 0x8 0xa0>; clock-names = "aclk", "aclk-perf", "hclk", "pm"; bus-range = <0x0 0x1f>; max-link-speed = <0x2>; linux,pci-domain = <0x0>; msi-map = <0x0 0x89 0x0 0x1000>; interrupts = <0x0 0x31 0x4 0x0 0x0 0x32 0x4 0x0 0x0 0x33 0x4 0x0>; interrupt-names = "sys", "legacy", "client"; #interrupt-cells = <0x1>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; interrupt-map = <0x0 0x0 0x0 0x1 0x8a 0x0 0x0 0x0 0x0 0x2 0x8a 0x1 0x0 0x0 0x0 0x3 0x8a 0x2 0x0 0x0 0x0 0x4 0x8a 0x3>; phys = <0x8b>; phy-names = "pcie-phy"; ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x1e00000 0x81000000 0x0 0xfbe00000 0x0 0xfbe00000 0x0 0x100000>; reg = <0x0 0xf8000000 0x0 0x2000000 0x0 0xfd000000 0x0 0x1000000>; reg-names = "axi-base", "apb-base"; resets = <0x8 0x82 0x8 0x83 0x8 0x84 0x8 0x85 0x8 0x86 0x8 0x81 0x8 0x80>; reset-names = "core", "mgmt", "mgmt-sticky", "pipe", "pm", "pclk", "aclk"; status = "disabled"; Also bleibt weiterhin ungeklärt, ob auch beides zusammen möglich ist. Also gleichzeitig das WLan-Modul und eine PCIe Karte.
  • FrankMF

    Mainline Kernel 4.20.x

    Verschoben Images
    26
    0 Stimmen
    26 Beiträge
    4k Aufrufe
    FrankMF
    4.20.0-1090-ayufan released Änderungen -> https://gitlab.com/ayufan-repos/rock64/linux-mainline-kernel/commits/master
  • FrankMF

    stretch-openmediavault-rockpro64

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

    stretch-minimal-rockpro64

    Verschoben Linux
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF
    Mal ein Test was der Speicher so kann. rock64@rockpro64:~/tinymembench$ ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 2812.7 MB/s C copy backwards (32 byte blocks) : 2811.9 MB/s C copy backwards (64 byte blocks) : 2632.8 MB/s C copy : 2667.2 MB/s C copy prefetched (32 bytes step) : 2633.5 MB/s C copy prefetched (64 bytes step) : 2640.8 MB/s C 2-pass copy : 2509.8 MB/s C 2-pass copy prefetched (32 bytes step) : 2431.6 MB/s C 2-pass copy prefetched (64 bytes step) : 2424.1 MB/s C fill : 4887.7 MB/s (0.5%) C fill (shuffle within 16 byte blocks) : 4883.0 MB/s C fill (shuffle within 32 byte blocks) : 4889.3 MB/s C fill (shuffle within 64 byte blocks) : 4889.2 MB/s --- standard memcpy : 2807.3 MB/s standard memset : 4890.4 MB/s (0.3%) --- NEON LDP/STP copy : 2803.7 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 2802.1 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 2800.7 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 2745.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 2745.8 MB/s NEON LD1/ST1 copy : 2801.9 MB/s NEON STP fill : 4888.9 MB/s (0.3%) NEON STNP fill : 4850.1 MB/s ARM LDP/STP copy : 2803.8 MB/s ARM STP fill : 4893.0 MB/s (0.5%) ARM STNP fill : 4851.7 MB/s ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON LDP/STP copy (from framebuffer) : 602.5 MB/s NEON LDP/STP 2-pass copy (from framebuffer) : 551.6 MB/s NEON LD1/ST1 copy (from framebuffer) : 667.1 MB/s NEON LD1/ST1 2-pass copy (from framebuffer) : 605.6 MB/s ARM LDP/STP copy (from framebuffer) : 445.3 MB/s ARM LDP/STP 2-pass copy (from framebuffer) : 428.8 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 4.5 ns / 7.2 ns 131072 : 6.8 ns / 9.7 ns 262144 : 9.8 ns / 12.8 ns 524288 : 11.4 ns / 14.7 ns 1048576 : 16.0 ns / 22.6 ns 2097152 : 114.0 ns / 175.3 ns 4194304 : 161.7 ns / 219.9 ns 8388608 : 190.7 ns / 241.5 ns 16777216 : 205.3 ns / 250.5 ns 33554432 : 212.9 ns / 255.5 ns 67108864 : 222.3 ns / 271.1 ns