Ok, es gab wohl ein paar kleinere Probleme die Platinen upzugraden. Kamil hat noch schnell die Probleme gefixt und das 0.7.9 Image veröffentlicht.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 nsImages 0.7.x
-
Kamil ist wieder am schrauben.
Commits · 0.7.1 · ayufan-repos / rock64 / linux-build · GitLab
Rock64 Linux build scripts, tools and instructions
GitLab (gitlab.com)
0.7.x
- 0.7.0: Introduces heavy refactor splitting all components into separate repos, and separate independent releases (u-boot, kernel, kernel-mainline, compatibility package),
- 0.7.0: Dry run everything,
Bin gespannt auf das Ergebnis, im Moment hat das Script mit Fehlern abgebrochen, aber Kamil kennt das bestens
-
Es gibt noch nicht Neues, aber hier kann man schon ein wenig sehen was er macht.
- 0.7.3: Speed-up build process,
- 0.7.2: Pin packages,
- 0.7.1: Use GitLab CI for releasing all images,
- 0.7.0: Introduces heavy refactor splitting all components into separate repos, and separate independent releases (u-boot, kernel, kernel-mainline, compatibility package),
LATEST_UBOOT_VERSION=2017.09-rockchip-ayufan-1009-g501b20dc14
LATEST_KERNEL_VERSION=4.4.132-1042-rockchip-ayufan-g521c26bc8ee0
LATEST_PACKAGE_VERSION=0.7-5Quelle: https://gitlab.com/ayufan-repos/rock64/linux-build/commit/b557556d38760cfd1f7e9a818e7a51c873520161
-
Wenn ich das jetzt richtig beobachtet habe, hat Kamil ganze zwei Tage damit zugebracht, den Build Prozeß umzubauen. Da läuft jetzt wohl alles auf gitlab ab, die Releases findet man aber immer noch hier. Was da wie, womit zusammen arbeitet, kann ich Euch nicht sagen. Bin auf dem Gebiet mit Sicherheit kein Experte.
Das Gute, es gibt einen neuen Release. 0.7.2
Das Schlechte, bootet nicht, da scheint was mit dem u-boot nicht zu passen.
Kamil schrieb
(23:24:08) ayufan1: I will fix it later
(23:24:15) ayufan1: I basically changed 80% of the build process
(23:24:21) ayufan1: so I expect something not to work
Dann warten wir mal..
und DANKE für die Arbeit - Kamil!!
-
Gestern Nacht kam noch 0.7.3
- 0.7.3: Fix generation of extlinux.conf (linux booting),
Das Problem des nicht Bootens wurde damit behoben, aber das Image ist unstabil. Kamil weiß das , ich bin sicher das er heute weiter dran rumschraubt.
Dann mal dran erinnern was im Moment gut funktioniert.
- 0.6.58: jenkins-linux-build-rock-64-271 installieren
- und dann auf 4.18.0-rc3-1035-ayufan upgraden
Die Releases werden übrigens weiterhin auf github veröffentlicht!
-
0.7.3 released
- 0.7.3: Fix generation of extlinux.conf (linux booting),
- 0.7.2: Pin packages,
- 0.7.2: Improve performance of build process,
- 0.7.1: Use GitLab CI for releasing all images,
- 0.7.0: Introduces heavy refactor splitting all components into separate repos, and separate independent releases (u-boot, kernel, kernel-mainline, compatibility package),
- 0.7.0: Dry run everything,
Kamil hat seinen kompletten Build-Prozeß umgebaut. Diese 0.7.3 Version bootet (nur ohne PCIe NVMe-Karte). Außerdem habe ich Unstabilitäten über die LAN-Schnittstelle bemerkt (Freeze). Nicht empfehlenswert, im Moment.
-
0.7.4 released
- 0.7.4: Fix resize_rootfs.sh script to respect boot flags (fixes second boot problem introduced by 0.7.0),
- 0.7.4: Add rock(pro)64_erase_spi_flash.sh,
- 0.7.4: Fix cursor on desktop for rockpro64,
Bootet nur ohne PCIe NVMe Karte! Kamil will das Fixen.
-
0.7.6 released
- 0.7.6: Change OPP's for Rock64 and RockPro64: ayufan-rock64/linux-kernel@4.4.132-1059-rockchip-ayufan...ayufan-rock64:4.4.132-1062-rockchip-ayufan,
Soll mehr Stabilität bringen, macht es leider nicht. So langsam wird es ärgerlich, das mit jedem Release nichts nach vorne geht.
-
0.7.7 released
- 0.7.7: Fix memory corruptions caused by Mali/Display subsystem (4.4),
- 0.7.7: Enable SDR104 mode for SD cards (this requires u-boot upgrade if booting from SD),
Langsam wird es, kann man jetzt zig mal booten ohne Probleme. Einziges Problem was ich im Moment nach einem kurzen Test festgestellt habe, das Erkennen der NVMe Karte ist Zufall und gelingt nur selten. Seltsamerweise im Mainline kein Problem!?
Kamil hat das für 4.4 gefixt -> https://github.com/ayufan-rock64/linux-kernel/commit/bfb0d6c371d14b0d1fc60326b9bc84985a26f848?diff=unified
Hier gibt es den Kernel zum herunter laden -> https://github.com/ayufan-rock64/linux-kernel/releases/tag/4.4.132-1070-rockchip-ayufan
-
0.7.8 released
- 0.7.8: Improve eMMC compatibility on RockPro64,
- 0.7.8: Disable sdio (no wifi/bt) to fix pcie/nvme support on 4.4 for RockPro64,
- 0.7.8: Fix OMV builds (missing initrd.img),
- 0.7.8: Make all packages virtual, conflicting and replacing making possible to do linux-rock64/rockpro64 to replace basesystem,
(22:32:51) ayufan1: pushed one final release before vacations
(22:32:59) ayufan1: consider this one to be the future release
(22:33:15) ayufan1: if people do confirm that they do work on rockpro64 and rock64 I will make it finally stable
(22:33:21) ayufan1: it is probably the best support so far
(22:33:48) ayufan1: not yet the most performant (for rockpro64), I had to limit in bunch of places freqs, disable stuff, but it should be stable and support base ops
(22:34:01) ayufan1: but, first stability, then we gonna add extra stuffKamil macht Urlaub, da haben wir ja ein wenig Freizeit
-
0.7.10 released
- 0.7.10: Rebased rockchip and mainline kernels,
- 0.7.10: Support USB gadgets for rock/pro64,
- 0.7.10: Disable TX checksumming for RockPro64,
- 0.7.10: Improve FAN for RockPro64,
- 0.7.10: Improve sdmmc0 stability for Rock64,
- 0.7.10: Enable binfmt-misc,
- 0.7.10: Improve stability of PCIE for RockPro64,
- 0.7.10: Fix eMMC stability on RockPro64 mainline kernel,
Die Container Images fehlen, Kamil hatte da ein Problem mit. Deshalb auch die Kennzeichnung als Pre-Release.
-
Die Container-Images für 0.7.10 sind jetzt auch fertig!
Releases · ayufan-rock64/linux-build
Rock64 Linux build scripts, tools and instructions - Releases · ayufan-rock64/linux-build
GitHub (github.com)
-
0.7.11 released
- 0.7.11: Rebased mainline kernel,
- 0.7.11: Run rockchip kernel at 250Hz to increase performance,
- 0.7.11: Add support for usb gadgets for rockchip,
- 0.7.11: Introduce
change-default-kernel.shscript to easily switch between kernels,
-
Ich kann 0.7.12 nicht empfehlen. Bei der Installation eines Systems mit PCIe NVMe SSD auf einem ROCKPro64 v2.0 4GB RAM habe ich folgenden Fehler gehabt.
0.7.12_with_pcie_nvme_ssd - Pastebin.com
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
Pastebin (pastebin.com)
Danach war die Partition auf der SSD weg.
Ich bin jetzt wieder auf 0.7.11 mit dem letzten Kernel der funktioniert 4.4.154-1128-rockchip-ayufan
Dran denken, was ich mit diesem Zeichen
kennzeichne, funktioniert. -
0.7.13 released
- 0.7.13: Enable support for RockPro64 WiFi/BT module,
- 0.7.13: Fix LXDE build: updated libdrm,
PCIe NVMe SSD & WiFi = Crash!
WiFi alleine habe ich bei einem kurzen Test auf stretch minimal zum Laufen bekommen - aber unstabil!Alles in allem, noch viel Arbeit. Nur für Leute mit Spaß am Testen geeignet
Morgen, geht's weiter -
0.7.14 ist nicht empfehlenswert. (Bei mir zumindestens!!)
Was geht?
- WiFi
Was nicht geht?
- WiFi & PCIe NVMe SSD zusammen - crash!
- PCIe NVMe SSD alleine - crash!
Für mich ist der angebliche Fix, der irgendwie was drumherum bastelt, damit PCIe & WiFi zusammen funktioniert keine Lösung. Das macht jetzt aktuell mehr Probleme als vorher.
Meine Idee wäre, zwei dts Files, einmal ist WiFi an, für Leute die es brauchen und einmal ist es aus. Hoffentlich findet jemand eine vernünftige Lösung!!
Ich bleibe weiterhin bei 0.7.11 - absolut stabil, PCIe stabil, SATA läuft (mit der richtigen Karte), auf WiFi kann ich persönlich verzichten!
Ich möchte hier aber erwähnen, das es wohl Leute gibt, bei denen das funktioniert.
-
-
Serielle Konsole UART2 (2)
Angeheftet Hardware -
-
-
-
-
stretch-openmediavault-rockpro64
Verschoben Linux -
stretch-minimal-rockpro64
Verschoben Linux