linux-nerds.org

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Recover Button

Hardware

2 Beiträge 1 Kommentatoren 791 Aufrufe

F Online
F Online
FrankM
schrieb am zuletzt editiert von FrankM

#1
In der Version v2.0 fehlte dieser Button noch, er war einfach nicht bestückt.

Wenn jemand den vermisst, zur Not kann man da was dran löten. Sollte machbar sein.

v2.1

Die Frage, was macht das Ding? Gehen wir mal auf die Suche.....

Kamil hat auf seiner Release Seite einen Link zu u-boot recovery selection

Kamil erklärt das so

ayufan: introduce recovery button mode selection

Press and hold recovery button to choose suitable boot mode.
When given mode is selected release the button.
Each mode exposes device over USB-OTG and can be connected via USB A-to-A cable

1 blink: share eMMC or SD as virtual disk
2 blinks: enter fastboot (Android's)
3 blinks: enter RockUSB download mode
4 blinks: enter MaskROM download mode

Ob das so funktioniert kann ich nicht sagen, da ich nicht 100% weiß wofür das ist.

Spekulation

An die USB-C Buchse kann man ein USB A-to-A Kabel anschliessen, damit kann man dann mit verschiedenen Programmen auf das Board zugreifen.
- fastboot
- RockUSB / MaskROM
Für Entwickler vermutlich total wichtig, denke ich das es für den durchschnittlichen Anwender unwichtig ist.
Im Fediverse -> @FrankM@nrw.social
1. NanoPi R5S
2. Quartz64 Model B, 4GB RAM
3. Quartz64 Model A, 4GB RAM
4. RockPro64 v2.1
1 Antwort Letzte Antwort
0

FrankM

schrieb am

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)

F FrankM hat am auf dieses Thema verwiesen

F

Quartz64 - Kühler
Geplant Angeheftet Gesperrt Verschoben Quartz64 - A quartz64 rockpro64
3

0 Stimmen

3 Beiträge

245 Aufrufe

F

@thc013 I use an thermal pad. So i think it isn't an problem.
F

Images 0.10.x
Geplant Angeheftet Gesperrt Verschoben Images rockpro64
10

0 Stimmen

10 Beiträge

415 Aufrufe

F

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 🙂
F

ROCKPro64 - Booten von USB3
Geplant Angeheftet Gesperrt Verschoben ROCKPro64 rockpro64
3

0 Stimmen

3 Beiträge

367 Aufrufe

F

Yeah, genau das worauf ich auch warte.

Wenn ich das richtig mitbekommen habe, könnte das Kamil's nächster Punkt auf seiner Liste sein.
F

ROCKPro64 - WLan-Antennen
Geplant Angeheftet Gesperrt Verschoben Hardware rockpro64
1

0 Stimmen

1 Beiträge

262 Aufrufe

Niemand hat geantwortet
F

Neues Script "change-default-kernel.sh "
Geplant Angeheftet Gesperrt Verschoben ROCKPro64 rockpro64
1

0 Stimmen

1 Beiträge

582 Aufrufe

Niemand hat geantwortet
F

Tehuti Networks Ltd. TN9710P 10GBase-T/NBASE-T Ethernet Adapter
Geplant Angeheftet Gesperrt Verschoben Hardware hardware rockpro64
2

0 Stimmen

2 Beiträge

1k Aufrufe

F

This repo contains the tn40xx Linux driver for 10Gbit NICs based on the TN4010 MAC from Tehuti Networks.

This driver enables the following 10Gb SFP+ NICs:

D-Link DXE-810S
Edimax EN-9320SFP+
StarTech PEX10000SFP
Synology E10G15-F1
... as well as the following 10GBase-T/NBASE-T NICs:

D-Link DXE-810T
Edimax EN-9320TX-E
EXSYS EX-6061-2
Intellinet 507950
StarTech ST10GSPEXNB

Quelle: https://github.com/ayufan-rock64/tn40xx-driver/tree/master
F

stretch-minimal-rockpro64
Geplant Angeheftet Gesperrt Verschoben Linux rockpro64
3

0 Stimmen

3 Beiträge

982 Aufrufe

F

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
F

ROCKPro64 - PCIe x4
Geplant Angeheftet Gesperrt Verschoben Hardware hardware rockpro64
13

0 Stimmen

13 Beiträge

5k Aufrufe

F

@Northstar Hallo, laut meinen Info's nicht, hat irgendwas mit der Speicheradressierung zu tuen. Und Grafikkarten benötigen wohl zu viel. Das ist das, was ich bei den vielen Diskussionen im IRC so aufgeschnappt habe.

Ich habe es auch schon mal genauso probiert - natürlich ohne Erfolg.

linux-nerds.org

Recover Button

Spekulation