Skip to content

ROCKPro WLan Modul

Verschoben ROCKPro64
  • Hardware

    Das Modul was Pine64 verkauft. Dieses Modul wird auf den entsprechenden Steckplatz montiert.
    0_1532760059199_DSC_0034_ergebnis.JPG

    Vorteil, wer kein WLan benötigt braucht das nicht mitbezahlen.

    Das Modul wird über sdio angesteuert, das hat Kamil mit Version 0.7.8 abgeschaltet um die PCIe Funktionalität zu erhalten, weil dort ein Bug drin ist, den er vor seinem Urlaub nicht mehr gefunden hat.

    Das heißt, um das WLan Modul überhaupt zum Leben zu erwecken muss man ein Image vor 0.7.8 nutzen. Ich habe es mal mit 0.7.7 probiert.

    Software

    Hätten wir das Problem, die Software ist nicht drin. Aber JeffD aus dem Forum hatte da eine Idee 🙂 Man klaue sich den Treiber aus der Android Version, da soll es funktionieren (nicht selber getestet).

    Also die 50 GB große Android Datei runter geladen, ausgepackt und durchsucht. Dort findet man dann die Datei

    BCM4359C0.hcd
    

    Diese kopiert man nach /etc/firmware

    root@rockpro64:/home/rock64# ls -la /etc/firmware
    total 184
    drwxr-xr-x  2 root root  4096 Jul 27 21:11  .
    drwxr-xr-x 82 root root  4096 Jul 28 05:29  ..
    -rw-r--r--  1 root root 38644 Jul 15 15:52  4343A0.hcd
    -rw-r--r--  1 root root 57291 Jul 15 15:52  BCM4335C0.hcd
    -rw-r--r--  1 root root 38644 Jul 15 15:52 'BCM4343A0 26M.hcd'
    -rwxr--r--  1 root root 37286 Jul 27 21:11  BCM4359C0.hcd
    

    Danach hat man irgendwelche Ausgaben, die gar nicht so schlecht aussehen. Aber, da meine treuen Leser ja wissen, das ich kein Freund von Bluetooth und WLan auf der Konsole bin (ich hasse das 😉 ) , habe ich jetzt nach einer langen Nacht aufgegeben. Dieses Netplan auf Ubuntu regt mich auch nur noch auf!

    Also wird dem Nerd mit unterdurchschnittlichem Linuxwissen, nicht anderes übrig bleiben, als auf Kamil's nächstes Image zu warten, das dann hoffentlich PCIe & WLan unterstützt!

    Die Befürchtung, das es auf v2.0 nicht richtig läuft, kann ich vorsichtig verneinen. Die Ausgaben auf v2.0 sind gleich, ob es dann auch richtig funktioniert wird man später sehen. https://forum.frank-mankel.org/topic/176/rockpro64-kein-wlan-modul-möglich

    Hier ein paar Ausgaben, ob die sinnvoll sind kann ich nicht beurteilen.

    rfkill list all

    root@rockpro64:/home/rock64# rfkill list all
    0: bt_default: Bluetooth
    	Soft blocked: no
    	Hard blocked: no
    1: phy0: Wireless LAN
    	Soft blocked: no
    	Hard blocked: no
    2: brcmfmac-wifi: Wireless LAN
    	Soft blocked: no
    	Hard blocked: no
    

    lshw -class network

    root@rockpro64:/home/rock64# sudo lshw -class network
      *-network:0 DISABLED      
           description: Wireless interface
           physical id: 7
           logical name: wlan0
           serial: ac:83:f3:e6:1f:b2
           capabilities: ethernet physical wireless
           configuration: broadcast=yes driver=wl driverversion=0 multicast=yes wireless=IEEE 802.11
      *-network:1
           description: Ethernet interface
           physical id: 8
           logical name: eth0
           serial: 1e:0e:99:52:8e:40
           size: 1Gbit/s
           capacity: 1Gbit/s
           capabilities: ethernet physical tp aui bnc mii fibre 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
           configuration: autonegotiation=on broadcast=yes driver=st_gmac driverversion=March_2013 duplex=full ip=192.168.3.17 link=yes multicast=yes port=MII speed=1Gbit/s
    

    iw dev

    root@rockpro64:/etc# iw dev
    phy#0
    	Interface wlan0
    		ifindex 3
    		wdev 0x1
    		addr ac:83:f3:e6:1f:b2
    		type managed
    

    ip a

    root@rockpro64:/home/rock64# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
        link/ether 1e:0e:99:52:8e:40 brd ff:ff:ff:ff:ff:ff
        inet 192.168.3.18/24 brd 192.168.3.255 scope global eth0
           valid_lft forever preferred_lft forever
        inet 192.168.3.205/24 brd 192.168.3.255 scope global secondary eth0
           valid_lft forever preferred_lft forever
        inet6 fe80::1c0e:99ff:fe52:8e40/64 scope link 
           valid_lft forever preferred_lft forever
    3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether ac:83:f3:e6:1f:b2 brd ff:ff:ff:ff:ff:ff
    

    iwlist

    rock64@rockpro64:~$ iw list 
    Wiphy phy0
    	max # scan SSIDs: 10
    	max scan IEs length: 2048 bytes
    	max # sched scan SSIDs: 0
    	max # match sets: 0
    	max # scan plans: 1
    	max scan plan interval: -1
    	max scan plan iterations: 0
    	Retry short limit: 7
    	Retry long limit: 4
    	Coverage class: 0 (up to 0m)
    	Device supports T-DLS.
    	Supported Ciphers:
    		* WEP40 (00-0f-ac:1)
    		* WEP104 (00-0f-ac:5)
    		* TKIP (00-0f-ac:2)
    		* CCMP-128 (00-0f-ac:4)
    		* CMAC (00-0f-ac:6)
    	Available Antennas: TX 0 RX 0
    	Supported interface modes:
    		 * IBSS
    		 * managed
    		 * AP
    		 * P2P-client
    		 * P2P-GO
    		 * P2P-device
    	Band 1:
    		Bitrates (non-HT):
    			* 1.0 Mbps
    			* 2.0 Mbps (short preamble supported)
    			* 5.5 Mbps (short preamble supported)
    			* 11.0 Mbps (short preamble supported)
    			* 6.0 Mbps
    			* 9.0 Mbps
    			* 12.0 Mbps
    			* 18.0 Mbps
    			* 24.0 Mbps
    			* 36.0 Mbps
    			* 48.0 Mbps
    			* 54.0 Mbps
    		Frequencies:
    			* 2412 MHz [1] (20.0 dBm)
    			* 2417 MHz [2] (20.0 dBm)
    			* 2422 MHz [3] (20.0 dBm)
    			* 2427 MHz [4] (20.0 dBm)
    			* 2432 MHz [5] (20.0 dBm)
    			* 2437 MHz [6] (20.0 dBm)
    			* 2442 MHz [7] (20.0 dBm)
    			* 2447 MHz [8] (20.0 dBm)
    			* 2452 MHz [9] (20.0 dBm)
    			* 2457 MHz [10] (20.0 dBm)
    			* 2462 MHz [11] (20.0 dBm)
    			* 2467 MHz [12] (20.0 dBm)
    			* 2472 MHz [13] (20.0 dBm)
    			* 2484 MHz [14] (20.0 dBm)
    Supported commands:
    		 * new_interface
    		 * set_interface
    		 * new_key
    		 * start_ap
    		 * set_bss
    		 * join_ibss
    		 * set_pmksa
    		 * del_pmksa
    		 * flush_pmksa
    		 * remain_on_channel
    		 * frame
    		 * frame_wait_cancel
    		 * set_wiphy_netns
    		 * set_channel
    		 * tdls_mgmt
    		 * tdls_oper
    		 * start_p2p_device
    		 * connect
    		 * disconnect
    	Supported TX frame types:
    		 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    	Supported RX frame types:
    		 * IBSS: 0xd0
    		 * managed: 0x40 0xd0
    		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
    		 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
    		 * P2P-client: 0x40 0xd0
    		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
    		 * P2P-device: 0x40 0xd0
    	WoWLAN support:
    		 * wake up on anything (device continues operating normally)
    		 * wake up on pattern match, up to 8 patterns of 1-255 bytes,
    		   maximum packet offset 255 bytes
    	software interface modes (can always be added):
    	valid interface combinations:
    		 * #{ AP } <= 2, #{ managed } <= 2, #{ P2P-client, P2P-GO } <= 2, #{ P2P-device } <= 1, #{ IBSS } <= 1,
    		   total <= 4, #channels <= 2
    	Device supports scan flush.
    
  • ROCKPro64 - Samsung Portable SSD T5 500GB

    Hardware rockpro64
    1
    0 Stimmen
    1 Beiträge
    315 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - USB-C -> HDMi

    ROCKPro64 rockpro64
    3
    1
    0 Stimmen
    3 Beiträge
    501 Aufrufe
    FrankMF
    @hannescam Hallo! Das ist ja schon ein paar Tage her, gut das wir den Screenshot haben. Du könntest genau diese Kernel-Version vom Kamil suchen und benutzen. Da musste man kein Linux Held sein, Kable einstecken - Bild da. Ob das mit was Aktuellerem geht, weiß ich nicht. Debian kann man ja so installieren, wie findest Du hier im Forum. Ob Debian die USB-C Schnittstelle nutzt weiß ich nicht. muss man ausprobieren. Da für mich die Platinen immer nur ohne Desktop Sinn gemacht haben, habe ich so was immer nur ganz kurz angetestet. Nutze die SOCs eigentlich ausschließlich Headless.
  • ROCKPro64 (4GB) - Probleme mit der PCIe SATA-Karte??

    ROCKPro64 rockpro64
    8
    1
    0 Stimmen
    8 Beiträge
    1k Aufrufe
    FrankMF
    Die Verlinkung hatte ich überlesen, sorry. Es gibt nur eine Handvoll Karten, die im PCIe Port funktionieren. Warum, kann ich dir leider nicht beantworten. Es liegt aber mit Sicherheit an falschen Einstellungen im Kernel und an fehlenden Treibern. Ich habe hier auch eine andere Karte rumliegen, die erzeugt immer nur eine Kernel Panic In diesem Thread steht einiges was geht und was nicht. https://forum.pine64.org/showthread.php?tid=6459
  • Mainline 4.20.0-rc6

    ROCKPro64 rockpro64
    1
    0 Stimmen
    1 Beiträge
    435 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Armbian nand-sata-install

    Verschoben Armbian armbian rockpro64
    14
    6
    0 Stimmen
    14 Beiträge
    2k Aufrufe
    FrankMF
    Ich habe heute, nachdem es einige Updates von Armbian gab, mal nachgeschaut ob ein spezieller Fehler verschwunden ist. Und zwar geht es um das Resizen der Partion nachdem wir Armbian auf eine USB-HDD (USB3) installiert haben. Ich setze dafür folgendes System ein. Hardware ROCKPro64v2.0 4GB RAM SanDisk 240GB 2,5 Zoll HDD (nix tolles) Software Welcome to ARMBIAN 5.67.181217 nightly Debian GNU/Linux 9 (stretch) 4.4.167-rockchip64 Was sehe ich nach dem Reboot? root@rockpro64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 388M 5.3M 383M 2% /run /dev/sda1 220G 1.3G 207G 1% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /tmp /dev/mmcblk0p1 58G 1.3G 57G 3% /media/mmcboot /dev/zram0 49M 3.0M 43M 7% /var/log tmpfs 388M 0 388M 0% /run/user/0 Korrekt die Größe angepasst! Schnell mal den USB3 testen root@rockpro64:~# 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, 38.0723 s, 113 MB/s Der Adapter root@rockpro64:~# lsusb -vvv Bus 004 Device 002: ID 2109:0715 VIA Labs, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2109 VIA Labs, Inc. idProduct 0x0715 bcdDevice 1.31 iManufacturer 1 VLI Manufacture String iProduct 2 VLI Product String iSerial 3 000000123ADA bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 121 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 224mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 MaxStreams 32 Status pipe (0x02) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 70 bNumDeviceCaps 4 FIXME: alloc bigger buffer for device capability descriptors Device Status: 0x0000 (Bus Powered) Ein lästiger Fehler weniger.
  • 0 Stimmen
    2 Beiträge
    2k Aufrufe
    FrankMF
    Ergänzung Eine andere SATA-Karte und eine Riser-Karte mit angeschlossener GPU startet nicht. rock64@rockpro64v2_1:~$ uname -a Linux rockpro64v2_1 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
  • stretch-minimal-rockpro64

    Verschoben Linux rockpro64
    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
  • 2GB Version - Out of stock

    Verschoben Archiv rockpro64
    1
    1
    0 Stimmen
    1 Beiträge
    740 Aufrufe
    Niemand hat geantwortet