Checking Out Debian and Linux SDK for VideoStrong VS-RD-RK3399 Board

35 Replies to “Checking Out Debian and Linux SDK for VideoStrong VS-RD-RK3399 Board”

1. Can you please send direct output from /proc/cpuinfo to an online pasteboard service?

   Reply

2. @tkaiser
   Output of cat /proc/cpuinfo @ https://pastebin.com/Du1P6e6Z

   Reply

3. So r0p2 A72 and r0p4 A53. Fairly fresh.

   Reply

4. @cnxsoft
   Thank you! So at least CPU ‘part’ and ‘revision’ differ between big and LITTLE cores and due to the little ones being cpu0-3 (too) primitive CPU cluster detection logic doesn’t break 🙂

   In case time permits I would be really interested in tinymembench numbers for little and big cores individually. I usually kill the unwanted CPU cores like

   for i in 4 5 ; do echo 0 > /sys/devices/system/cpu/cpu${i}/online ; done

   1	for i in 4 5 ; do echo 0 > /sys/devices/system/cpu/cpu${i}/online ; done

   Reply

5. First run of tinymembench with all cores:

   linaro@linaro-alip:~/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 : 2779.6 MB/s (8.6%) C copy backwards (32 byte blocks) : 2781.7 MB/s C copy backwards (64 byte blocks) : 2778.7 MB/s C copy : 2757.2 MB/s (0.1%) C copy prefetched (32 bytes step) : 2709.9 MB/s C copy prefetched (64 bytes step) : 2707.5 MB/s C 2-pass copy : 1709.3 MB/s C 2-pass copy prefetched (32 bytes step) : 1789.0 MB/s C 2-pass copy prefetched (64 bytes step) : 1785.2 MB/s C fill : 4888.1 MB/s (0.2%) C fill (shuffle within 16 byte blocks) : 4889.9 MB/s C fill (shuffle within 32 byte blocks) : 4888.5 MB/s C fill (shuffle within 64 byte blocks) : 4889.1 MB/s --- standard memcpy : 2031.6 MB/s standard memset : 4887.9 MB/s (0.2%) --- NEON read : 4354.8 MB/s NEON read prefetched (32 bytes step) : 4454.5 MB/s NEON read prefetched (64 bytes step) : 4456.5 MB/s NEON read 2 data streams : 4519.6 MB/s NEON read 2 data streams prefetched (32 bytes step) : 4526.7 MB/s NEON read 2 data streams prefetched (64 bytes step) : 4526.1 MB/s NEON copy : 2750.0 MB/s NEON copy prefetched (32 bytes step) : 2701.9 MB/s NEON copy prefetched (64 bytes step) : 2701.5 MB/s NEON unrolled copy : 2770.0 MB/s NEON unrolled copy prefetched (32 bytes step) : 2751.6 MB/s NEON unrolled copy prefetched (64 bytes step) : 2750.3 MB/s NEON copy backwards : 2766.4 MB/s NEON copy backwards prefetched (32 bytes step) : 2711.0 MB/s NEON copy backwards prefetched (64 bytes step) : 2710.1 MB/s (0.1%) NEON 2-pass copy : 2509.6 MB/s NEON 2-pass copy prefetched (32 bytes step) : 2524.0 MB/s NEON 2-pass copy prefetched (64 bytes step) : 2523.6 MB/s NEON unrolled 2-pass copy : 2511.1 MB/s NEON unrolled 2-pass copy prefetched (32 bytes step) : 2526.1 MB/s NEON unrolled 2-pass copy prefetched (64 bytes step) : 2525.1 MB/s NEON fill : 4887.0 MB/s (0.3%) NEON fill backwards : 4887.2 MB/s VFP copy : 2783.2 MB/s VFP 2-pass copy : 2444.6 MB/s ARM fill (STRD) : 4888.1 MB/s (0.4%) ARM fill (STM with 8 registers) : 4886.1 MB/s ARM fill (STM with 4 registers) : 4887.0 MB/s ARM copy prefetched (incr pld) : 2706.3 MB/s ARM copy prefetched (wrap pld) : 2704.0 MB/s ARM 2-pass copy prefetched (incr pld) : 2523.4 MB/s ARM 2-pass copy prefetched (wrap pld) : 2525.1 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 read (from framebuffer) : 1011.5 MB/s NEON copy (from framebuffer) : 603.6 MB/s NEON 2-pass copy (from framebuffer) : 566.5 MB/s NEON unrolled copy (from framebuffer) : 520.6 MB/s NEON 2-pass unrolled copy (from framebuffer) : 507.8 MB/s VFP copy (from framebuffer) : 581.6 MB/s VFP 2-pass copy (from framebuffer) : 555.6 MB/s ARM copy (from framebuffer) : 599.7 MB/s ARM 2-pass copy (from framebuffer) : 562.1 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.9 ns / 23.9 ns 2097152 : 114.2 ns / 173.2 ns 4194304 : 162.2 ns / 217.3 ns 8388608 : 190.7 ns / 239.9 ns 16777216 : 205.1 ns / 249.3 ns 33554432 : 213.0 ns / 255.9 ns 67108864 : 222.0 ns / 272.5 ns

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136

   linaro@linaro-alip:~/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                                     :   2779.6 MB/s (8.6%) C copy backwards (32 byte blocks)                    :   2781.7 MB/s C copy backwards (64 byte blocks)                    :   2778.7 MB/s C copy                                               :   2757.2 MB/s (0.1%) C copy prefetched (32 bytes step)                    :   2709.9 MB/s C copy prefetched (64 bytes step)                    :   2707.5 MB/s C 2-pass copy                                        :   1709.3 MB/s C 2-pass copy prefetched (32 bytes step)             :   1789.0 MB/s C 2-pass copy prefetched (64 bytes step)             :   1785.2 MB/s C fill                                               :   4888.1 MB/s (0.2%) C fill (shuffle within 16 byte blocks)               :   4889.9 MB/s C fill (shuffle within 32 byte blocks)               :   4888.5 MB/s C fill (shuffle within 64 byte blocks)               :   4889.1 MB/s --- standard memcpy                                      :   2031.6 MB/s standard memset                                      :   4887.9 MB/s (0.2%) --- NEON read                                            :   4354.8 MB/s NEON read prefetched (32 bytes step)                 :   4454.5 MB/s NEON read prefetched (64 bytes step)                 :   4456.5 MB/s NEON read 2 data streams                             :   4519.6 MB/s NEON read 2 data streams prefetched (32 bytes step)  :   4526.7 MB/s NEON read 2 data streams prefetched (64 bytes step)  :   4526.1 MB/s NEON copy                                            :   2750.0 MB/s NEON copy prefetched (32 bytes step)                 :   2701.9 MB/s NEON copy prefetched (64 bytes step)                 :   2701.5 MB/s NEON unrolled copy                                   :   2770.0 MB/s NEON unrolled copy prefetched (32 bytes step)        :   2751.6 MB/s NEON unrolled copy prefetched (64 bytes step)        :   2750.3 MB/s NEON copy backwards                                  :   2766.4 MB/s NEON copy backwards prefetched (32 bytes step)       :   2711.0 MB/s NEON copy backwards prefetched (64 bytes step)       :   2710.1 MB/s (0.1%) NEON 2-pass copy                                     :   2509.6 MB/s NEON 2-pass copy prefetched (32 bytes step)          :   2524.0 MB/s NEON 2-pass copy prefetched (64 bytes step)          :   2523.6 MB/s NEON unrolled 2-pass copy                            :   2511.1 MB/s NEON unrolled 2-pass copy prefetched (32 bytes step) :   2526.1 MB/s NEON unrolled 2-pass copy prefetched (64 bytes step) :   2525.1 MB/s NEON fill                                            :   4887.0 MB/s (0.3%) NEON fill backwards                                  :   4887.2 MB/s VFP copy                                             :   2783.2 MB/s VFP 2-pass copy                                      :   2444.6 MB/s ARM fill (STRD)                                      :   4888.1 MB/s (0.4%) ARM fill (STM with 8 registers)                      :   4886.1 MB/s ARM fill (STM with 4 registers)                      :   4887.0 MB/s ARM copy prefetched (incr pld)                       :   2706.3 MB/s ARM copy prefetched (wrap pld)                       :   2704.0 MB/s ARM 2-pass copy prefetched (incr pld)                :   2523.4 MB/s ARM 2-pass copy prefetched (wrap pld)                :   2525.1 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 read (from framebuffer)                         :   1011.5 MB/s NEON copy (from framebuffer)                         :    603.6 MB/s NEON 2-pass copy (from framebuffer)                  :    566.5 MB/s NEON unrolled copy (from framebuffer)                :    520.6 MB/s NEON 2-pass unrolled copy (from framebuffer)         :    507.8 MB/s VFP copy (from framebuffer)                          :    581.6 MB/s VFP 2-pass copy (from framebuffer)                   :    555.6 MB/s ARM copy (from framebuffer)                          :    599.7 MB/s ARM 2-pass copy (from framebuffer)                   :    562.1 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.9 ns          /    23.9 ns    2097152 :  114.2 ns          /   173.2 ns    4194304 :  162.2 ns          /   217.3 ns    8388608 :  190.7 ns          /   239.9 ns   16777216 :  205.1 ns          /   249.3 ns   33554432 :  213.0 ns          /   255.9 ns   67108864 :  222.0 ns          /   272.5 ns

   Reply

6. Second run with only Cortex A53 cores:

   linaro@linaro-alip:~/tinymembench$ sudo su root@linaro-alip:/home/linaro/tinymembench# for i in 4 5 ; do echo 0 > /sys/devices/system/cpu/cpu${i}/online ; done root@linaro-alip:/home/linaro/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 : 1320.2 MB/s (0.6%) C copy backwards (32 byte blocks) : 1331.4 MB/s (0.6%) C copy backwards (64 byte blocks) : 1338.1 MB/s (0.6%) C copy : 1359.2 MB/s (0.5%) C copy prefetched (32 bytes step) : 1545.3 MB/s C copy prefetched (64 bytes step) : 1551.2 MB/s C 2-pass copy : 1151.2 MB/s (0.2%) C 2-pass copy prefetched (32 bytes step) : 1250.8 MB/s C 2-pass copy prefetched (64 bytes step) : 1248.7 MB/s C fill : 4771.1 MB/s C fill (shuffle within 16 byte blocks) : 4771.8 MB/s (0.3%) C fill (shuffle within 32 byte blocks) : 4773.4 MB/s C fill (shuffle within 64 byte blocks) : 4770.7 MB/s --- standard memcpy : 1402.3 MB/s (0.2%) standard memset : 3692.1 MB/s --- NEON read : 1604.2 MB/s NEON read prefetched (32 bytes step) : 2528.4 MB/s NEON read prefetched (64 bytes step) : 2528.5 MB/s NEON read 2 data streams : 1479.9 MB/s NEON read 2 data streams prefetched (32 bytes step) : 2504.0 MB/s NEON read 2 data streams prefetched (64 bytes step) : 2501.8 MB/s NEON copy : 1439.7 MB/s NEON copy prefetched (32 bytes step) : 1563.7 MB/s NEON copy prefetched (64 bytes step) : 1561.6 MB/s NEON unrolled copy : 1417.8 MB/s NEON unrolled copy prefetched (32 bytes step) : 1684.7 MB/s NEON unrolled copy prefetched (64 bytes step) : 1686.6 MB/s NEON copy backwards : 1388.6 MB/s (0.2%) NEON copy backwards prefetched (32 bytes step) : 1512.2 MB/s (0.2%) NEON copy backwards prefetched (64 bytes step) : 1510.9 MB/s NEON 2-pass copy : 1218.5 MB/s (0.2%) NEON 2-pass copy prefetched (32 bytes step) : 1319.5 MB/s NEON 2-pass copy prefetched (64 bytes step) : 1320.2 MB/s NEON unrolled 2-pass copy : 1198.6 MB/s NEON unrolled 2-pass copy prefetched (32 bytes step) : 1392.3 MB/s NEON unrolled 2-pass copy prefetched (64 bytes step) : 1453.8 MB/s NEON fill : 4770.7 MB/s NEON fill backwards : 4772.8 MB/s VFP copy : 1411.4 MB/s (0.2%) VFP 2-pass copy : 1206.4 MB/s ARM fill (STRD) : 3692.2 MB/s ARM fill (STM with 8 registers) : 4767.9 MB/s ARM fill (STM with 4 registers) : 4751.0 MB/s ARM copy prefetched (incr pld) : 1560.8 MB/s ARM copy prefetched (wrap pld) : 1529.5 MB/s ARM 2-pass copy prefetched (incr pld) : 1240.4 MB/s (0.2%) ARM 2-pass copy prefetched (wrap pld) : 1224.3 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 read (from framebuffer) : 46.5 MB/s NEON copy (from framebuffer) : 46.3 MB/s NEON 2-pass copy (from framebuffer) : 46.0 MB/s NEON unrolled copy (from framebuffer) : 46.4 MB/s NEON 2-pass unrolled copy (from framebuffer) : 45.9 MB/s VFP copy (from framebuffer) : 358.0 MB/s VFP 2-pass copy (from framebuffer) : 326.1 MB/s ARM copy (from framebuffer) : 187.0 MB/s ARM 2-pass copy (from framebuffer) : 177.3 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.1 ns / 0.1 ns 65536 : 4.9 ns / 8.2 ns 131072 : 7.5 ns / 11.5 ns 262144 : 8.8 ns / 12.8 ns 524288 : 14.6 ns / 21.0 ns 1048576 : 106.0 ns / 161.4 ns 2097152 : 154.0 ns / 202.0 ns 4194304 : 181.1 ns / 220.2 ns 8388608 : 195.3 ns / 230.3 ns 16777216 : 202.9 ns / 234.6 ns 33554432 : 206.7 ns / 239.3 ns 67108864 : 209.9 ns / 245.5 ns

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138

   linaro@linaro-alip:~/tinymembench$ sudo su root@linaro-alip:/home/linaro/tinymembench#  for i in 4 5 ; do echo 0 > /sys/devices/system/cpu/cpu${i}/online ; done root@linaro-alip:/home/linaro/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                                     :   1320.2 MB/s (0.6%) C copy backwards (32 byte blocks)                    :   1331.4 MB/s (0.6%) C copy backwards (64 byte blocks)                    :   1338.1 MB/s (0.6%) C copy                                               :   1359.2 MB/s (0.5%) C copy prefetched (32 bytes step)                    :   1545.3 MB/s C copy prefetched (64 bytes step)                    :   1551.2 MB/s C 2-pass copy                                        :   1151.2 MB/s (0.2%) C 2-pass copy prefetched (32 bytes step)             :   1250.8 MB/s C 2-pass copy prefetched (64 bytes step)             :   1248.7 MB/s C fill                                               :   4771.1 MB/s C fill (shuffle within 16 byte blocks)               :   4771.8 MB/s (0.3%) C fill (shuffle within 32 byte blocks)               :   4773.4 MB/s C fill (shuffle within 64 byte blocks)               :   4770.7 MB/s --- standard memcpy                                      :   1402.3 MB/s (0.2%) standard memset                                      :   3692.1 MB/s --- NEON read                                            :   1604.2 MB/s NEON read prefetched (32 bytes step)                 :   2528.4 MB/s NEON read prefetched (64 bytes step)                 :   2528.5 MB/s NEON read 2 data streams                             :   1479.9 MB/s NEON read 2 data streams prefetched (32 bytes step)  :   2504.0 MB/s NEON read 2 data streams prefetched (64 bytes step)  :   2501.8 MB/s NEON copy                                            :   1439.7 MB/s NEON copy prefetched (32 bytes step)                 :   1563.7 MB/s NEON copy prefetched (64 bytes step)                 :   1561.6 MB/s NEON unrolled copy                                   :   1417.8 MB/s NEON unrolled copy prefetched (32 bytes step)        :   1684.7 MB/s NEON unrolled copy prefetched (64 bytes step)        :   1686.6 MB/s NEON copy backwards                                  :   1388.6 MB/s (0.2%) NEON copy backwards prefetched (32 bytes step)       :   1512.2 MB/s (0.2%) NEON copy backwards prefetched (64 bytes step)       :   1510.9 MB/s NEON 2-pass copy                                     :   1218.5 MB/s (0.2%) NEON 2-pass copy prefetched (32 bytes step)          :   1319.5 MB/s NEON 2-pass copy prefetched (64 bytes step)          :   1320.2 MB/s NEON unrolled 2-pass copy                            :   1198.6 MB/s NEON unrolled 2-pass copy prefetched (32 bytes step) :   1392.3 MB/s NEON unrolled 2-pass copy prefetched (64 bytes step) :   1453.8 MB/s NEON fill                                            :   4770.7 MB/s NEON fill backwards                                  :   4772.8 MB/s VFP copy                                             :   1411.4 MB/s (0.2%) VFP 2-pass copy                                      :   1206.4 MB/s ARM fill (STRD)                                      :   3692.2 MB/s ARM fill (STM with 8 registers)                      :   4767.9 MB/s ARM fill (STM with 4 registers)                      :   4751.0 MB/s ARM copy prefetched (incr pld)                       :   1560.8 MB/s ARM copy prefetched (wrap pld)                       :   1529.5 MB/s ARM 2-pass copy prefetched (incr pld)                :   1240.4 MB/s (0.2%) ARM 2-pass copy prefetched (wrap pld)                :   1224.3 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 read (from framebuffer)                         :     46.5 MB/s NEON copy (from framebuffer)                         :     46.3 MB/s NEON 2-pass copy (from framebuffer)                  :     46.0 MB/s NEON unrolled copy (from framebuffer)                :     46.4 MB/s NEON 2-pass unrolled copy (from framebuffer)         :     45.9 MB/s VFP copy (from framebuffer)                          :    358.0 MB/s VFP 2-pass copy (from framebuffer)                   :    326.1 MB/s ARM copy (from framebuffer)                          :    187.0 MB/s ARM 2-pass copy (from framebuffer)                   :    177.3 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.1 ns          /     0.1 ns      65536 :    4.9 ns          /     8.2 ns     131072 :    7.5 ns          /    11.5 ns     262144 :    8.8 ns          /    12.8 ns     524288 :   14.6 ns          /    21.0 ns    1048576 :  106.0 ns          /   161.4 ns    2097152 :  154.0 ns          /   202.0 ns    4194304 :  181.1 ns          /   220.2 ns    8388608 :  195.3 ns          /   230.3 ns   16777216 :  202.9 ns          /   234.6 ns   33554432 :  206.7 ns          /   239.3 ns   67108864 :  209.9 ns          /   245.5 ns

   Reply

7. @cnxsoft
   Nice! Thank you.

   As a quick reference memory performance from another SoC that might get interesting next year: RTD1296 (Tested/provided by BPi folks on their new BPi-W2)

   Reply

8. Hi CnxSoft
   I’m trying to boot linux on a h96Max (rk3399 4g ram, gigabit , usb-c). So far i’m able to boot on a archlinux rootfs on usb -C through the sdcard. gigabit is working fine but not the console ttyFIQ00, the systemd process is eating 1 cpu

   I’ve used the stock android kernel and the u boot from the firefly rk3399, with some dd commands to modify the sdcard provided for the firefly.

   My next step is to recompile a kernel from videostrong and adapt it.

   If you have the time to test it on your side 🙂 it could be a cost effective solution for a powerful arm linux box

   Cheers
   Occip

   Reply

9. In case you want to test some stuff like network performance later most probably you’ll realize that all interrupts end up on cpu0 potentially bottlenecking some situations with eg. USB3 and GbE access at the same time.

   I’ve not seen full /proc/interrupts output for RK3399 so far (neither vendor nor mainline kernel) but something like thisshould work in any case to have at least a more sane Ethernet IRQ processing. But then it still might depend on cpufreq scaling (when clockspeed of the little cores remains at the lower limit then saturating Gigabit Ethernet might not be possible so either tweaking cpufreq settings or moving eth0 to cpu5 might be an idea).

   On the other hand since you’re testing with Debian 9 you could give irqbalanced a try (Debian/Ubuntu packages prior to Debian 9/Stretch were broken, did nothing useful but only wasting resources and freezing the machine after some time due to a memory leak). Though I would expect an optimized fixed IRQ affinity will result in better numbers (higher performance, lower system utilization)

   Reply

10. @Occip
    I’m very very interested too. If you are able to boot fully into it and use it as a headless server, i’ll order one of such boxes. I own 2 of H96Pro+, which i use to run Ubuntu + Docker, really love it.
    Can you share you image files for others to test?
    If you need a place to upload, use https://my.owndrive.com/index.php/s/vNynzw9pk5fIYhT
    I’ll then publicly share the files to all 🙂

    Reply

11. Good info. Mine board will arrive tomorrow most probably but because of some issues I have, not really sure when will start working on it.

    Reply

12. Somebody asked about idle power consumption on G+.
    The board running Debian 9 with USB keyboard and mouse, HDMI and Ethernet consumes about 4.1W in idle mode.

    Reply

13. @Occip
    Ah you went further than I did with H96Max. All the linux images that I tried hang during the kernel boot, and I yet didn’t manage to replace only the rootfs and keep the kernel (it took me a while to figure that this board has to be flashed via the USB3 port and not the USB-C). I’ll definitely have to try that archlinux image. I’d like to at least get an u-boot with the bootdelay set to 1 so that I can interrupt it. By experience, development process becomes much faster once you have this.

    @cnxsoft, I didn’t find the URL of your debian image in the post, I’m interested in trying it on my h96max just to see if I can get something to start with and completely ditch the existing android rootfs.

    Reply

14. willy :
    I didn’t find the URL of your debian image in the post

    It’s the mega link in previous post linked to in first paragraph.

    Reply

15. @willy
    @tkaiser
    I see both of you have completely skipped the Android part of the post… I don’t blame you :), but the link is there at “VS3399 board’s MEGA folder”.

    Reply

16. @fossxplorer
    I’ll try to put an sd image on your server. I’ve managed to boot the videostrong kernel on the h96max but only the usb 2.0 port is working.

    Reply

17. @willy
    The sdcard method is really good , faster than flashing the board. With the parameter file you can move the root fs on usb drive
    Stay tuned

    Reply

18. @cnxsoft
    No I didn’t skip it, though I read quicker I admit, but the text around the link speaks about the Android image and I didn’t correlate it with the linux one. Thanks for the link 😉

    Reply

19. @Occip
    Good to know, thanks for the indications.

    Reply

20. @Occip
    Sounds good and looking forward. Good to see @willy is also working on it 🙂
    Wondering whether to buy a H96 Max now or later since i just got 2x H96Pro+ 🙂

    Reply

21. @cnxsoft
    Hi CnxSoft
    I’ve played with the debian image on H96Max . I’ve got the same problem as you the HDMI is on the right side.
    I’ve opened a terminal (and dragged it on the right) and issued the following command:

    xrandr --output HDMI-1 --left-of DSI-1

    1	xrandr --output HDMI-1 --left-of DSI-1

    The menu is now available on HDMI 🙂

    I’ve enabled the wired network and the wifi seems to work .

    Reply

22. @occip
    Is there a possibility to get mainline kernel working on this box?

    Reply

23. @fossxplorer
    Hi
    I’ve uploaded a sdcard image on your owncloud server. H96maxdebian.img. Just put your sdcard in your hp96max board and wait 🙂
    Use at your own risk. The usb-c connector is not working, it may need a kernel mod.
    I will try to compile a mainline kernel after tweaking the videostrong kernel

    Reply

24. @fossxplorer
    @Occip

    I don’t see why it wouldn’t be possible. Just checked 3.14rc tree, there are evb and firefly 3399 device trees there and looks like someone already ported Armbian using mainline to 3399 EVB board.

    Reply

25. @Occip
    Whooaaa, that’s AWESOME. I’m placing an order for this box NOW! Highly appreicated! I’ve made the link “public” and not “upload only” so others can download the image as well: https://my.owndrive.com/index.php/s/vNynzw9pk5fIYhT

    @Stane1983, that sounds promising. Armbian support sounds really awesome as i run it on my H96Pro+ board 🙂

    Reply

26. Btw, i’ve already started to think about replacing the heatsink with a bigger one and possibly also a fan (USB fan) on top of it. I dunno how H96Max looks inside, but i’ll probably use a pretty big heatsink and just remove one side of the cover.

    How do you guys remove stock heatsink without breaking anything?
    :)I need to do the same on H96Pro+ as well.

    Reply

27. The boards looks like http://freaktab.com/filedata/fetch?photoid=654187

    Reply

28. @fossxplorer
    Removing the heatsink will be very easy, just pinch and push the two plastic bits on the bottom side of the board.

    Reply

29. @Stane1983
    Hi
    I’m very happy with the videostrong kernel, almost everything is working on my H96Max :
    All usb ports OK
    shutdown OK
    wifi OK
    ethernet OK
    HDMI working (lxde desktop ok)

    What i’ve done:
    extract the DTB from the original resource.img ( h96 android kernel, offset 0x800)
    convert DTB to DTS with dtc command ( I’m very impressed )
    compile the videstrong kernel as described on this page with my DTS
    put kernel.img + resource.img on sdcard .

    The system is really fast , 10 seconds to the LXDE desktop 🙂

    Next step is to compile mainline kernel (4.12)

    Reply

30. My Debian impressions…. I’m actually surprised… If there was HDMI issue on wrong side, with image that is available now for download it’s fixed. Everything I tested (except Bluetooth) worked. No lags, UI is smooth, web browsing using Chromium is smooth, youtube playback is smooth but could be smoother (maybe it’s because of WiFi, didn’t use ethernet to connect to net). Kodi 17.1 that ships with Debian stretch works just fine… This is my first experience with Rockchip SoC after long time…. and I love it 🙂

    Reply

31. @occip
    Same here, I flashed the VS image onto my H96Max and it worked out of the box. I was surprized that the rootfs is 32-bit only despite the 64-bit kernel. Not a big deal though. The first tests I’ve run show that it’s about 10% faster than the MiQi for gcc. At the moment it’s limited to 1.8/1.4 GHz. I haven’t modified the DTB yet to change this (the rockchip process is a real pain to go through with all their conversion steps and I’m not feeling brave enough to go into this again right now). The device doesn’t heat much during builds, actually less than the RK3288. I was surprized to see that I forgot to replug the power adapter after flashing it and that running all 6 cores out of just a USB3 power supply went fine (or I was very lucky).

    Reply

    1. Hi
       On h96max With the correct DTB the shutdown is working as well as the usb C.
       I’ve made test with the latest mainline kernel ( rk3399 EVM dts) . Only gigabit and usb3 are working, no hdmi and no cpufreq ( stay at 408MHz)
       We have to wait for the next kernel version …

       Reply

32. I added VS device trees to rockchip upstream kernel if someone wants to check it out:
    https://github.com/Stane1983/kernel

    there is also separate branch vs-rk3399 with 2 more commits (Makefile predefined toolchains removed and rockchip_linux_defconfig merged with VS one).

    I tested kernel only with headless Linux (Debian 9 aarch64 rootfs). What I tested worked 🙂 Comments, issues, PRs are welcome.

    Reply

33. I have maybe a bit stupid question but….

    This board lacks a bit of community support while VERY similar board Firefly Rk3399 seems to be a bit more supported ie – armbian… Will software from Firefly RK3399 work on VS RK3399?

    Reply

    1. Well… board does not boot from SD with Armbian for Firefly RK3399… which is good and bad…
       Good because according to documentation boot from SD should happen only if eMMC will be shortcuted but this board actually boots try to boot as while SD card is in with system normal eMMC is not starting and for Armbian it is changing led to red even (short the eMMC clock to GND) http://opensource.rock-chips.com/wiki_Boot_option#Boot_flow

       Bad – since board didnt booted.

       Reply