Jump to content

Recommended Posts

Posted
1 hour ago, tkaiser said:

Gigabit Ethernet

provided by RTL8211E like on the NanoPi A64 or the Banana Pi M64 ;)

Posted
10 minutes ago, guidol said:

RTL8211E like on the NanoPi A64 or the Banana Pi M64

 

RTL8211 is used as PHY on all GbE capable SBC I know. The majority of boards uses RTL8211E, some RTL8211F and Olimex used also RTL8211CL a while ago. Pretty much irrelevant since always the GbE MAC implementation lives inside the SoC and the RTL8211 PHY is just attached via RGMII (so the MAC and PCIe parts of these RealTek chips are not used on SBC anyway. Might change soon since more and more SoCs are PCIe equipped).

 

But even on the soon to be released Orange Pi R2 the two RTL8211E are only used as PHY and attached via RGMII (RTD1296 has 3 GbE MACs but only one internal GbE PHY so for the two additional GbE interfaces external PHYs are needed):

orange-pi-R2-top-bottom.jpg

Posted
4 hours ago, TonyMac32 said:

They dropped the 5V barrel jack though

I was also wondering, TK promotes Micro USB with H5??

Posted
6 hours ago, TonyMac32 said:

They dropped the 5V barrel jack though I see

 

Not really. A barrel jack was only on the K2, all other FriendlyELEC boards only have

  • Micro USB for DC-IN (they sell a very good Micro USB cable for as less than 2 bucks)
  • a 4 pin connector suitable to be combined with their PSU-ONECOM module (allowing to attach a 4.0/1.7mm barrel PSU)

Just check http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=176, scroll to the bottom and check Shipping List. The more expensive boards ready to attach a lot of USB consumers are always sold with their great Micro USB cable (20 AWG rated or something like that. Pretty safe wrt voltage drops)

Posted

I should have one early next week, I'm a sucker for new toys, and have been an on and off customer of FriendlyARM for a long time.  :-)

Posted
1 hour ago, TonyMac32 said:

I should have one early next week, I'm a sucker for new toys, and have been an on and off customer of FriendlyARM for a long time.  :-)


:) Mine is also on the way and I will have one spare.

Posted (edited)
On 4/19/2018 at 12:05 PM, tkaiser said:

Wi-Fi with onboard aerial provided by RTL8189ETV

I don't see a driver for it on the mainline kernel, any ideas?

 

ahh, ok, seems to be RTL8189ES...

Edited by @lex
Posted

I tried the Friendlyelec Nanopi Neo 2 Armbian image and booting initiated, a few messages were printed on the screen, but after the 'now loading kernel' message, the board froze. Based on this, I assume adapting Armbian to the K1 Plus should not be too difficult. Is there a good tutorial on how to do this? I am comfortable with configuring and compiling / installing Linux kernels on Ubuntu and Arch Linux, but have limited experience with preparing images for arm based SoC boards. 

Posted
3 hours ago, cycologist said:

how to do this

 

I experimentally booted an orange pi PC 2 image on mine.  Starting from there and correcting the device tree to match the actual hardware should be sufficient

Posted
6 hours ago, TonyMac32 said:

I experimentally booted an orange pi PC 2 image on mine.  Starting from there and correcting the device tree to match the actual hardware should be sufficient

 I think that was the FE approach. I took a step further, i pulled linus 4.17.rc5, applied the 8189es patch and sy8189a patch, adjusted DT and it's working smooth.  Just a small note, i could not get SPI to work, i suspect there is something with rtl8189etv. I wired the 2.8" LCD and wlan stopped working but could be some of my mistakes.

 

the rtl wifi keeps spitting ==> rtl8188e_iol_efuse_patch , removing the LCD wlan worked again.

[    6.767828] RTL8211E Gigabit Ethernet 0.2:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=0.2:00, irq=POLL)
[    6.769361] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available
[    6.769375] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW
[    6.769932] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    6.899748] random: crng init done
[    6.899755] random: 7 urandom warning(s) missed due to ratelimiting
[    7.193944] ==> rtl8188e_iol_efuse_patch 
[    7.481112] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    7.965815] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[    7.972452] rtc-ds1307: probe of 0-0068 failed with error -110
[   34.781921] ==> rtl8188e_iol_efuse_patch 
[   39.737899] ==> rtl8188e_iol_efuse_patch 
[   52.573897] ==> rtl8188e_iol_efuse_patch 
[   62.545893] ==> rtl8188e_iol_efuse_patch 
[   76.741896] ==> rtl8188e_iol_efuse_patch 
[   81.502589] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   81.502625] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   96.705898] ==> rtl8188e_iol_efuse_patch 
[  111.133896] ==> rtl8188e_iol_efuse_patch 

i have chosen ubuntu 18.04 but i found it bloated, systemd has a lot of useless or unnecessary services , ubuntu 16.04 still better tuned.  Without hdmi (enabled) Temp is way low in idle node. Unfortunately, i could not grab any info from this kernel...

I think NEO2 with sy8189 will really shine.

Posted (edited)

I would like to throw some numbers here gathered with kernel 4.17.rc6 though i don't know if it is good or bad.  Seems to be very conservative. I did not find any suitable cpuburn on ubuntu 18.04.

 

sudo sysbench --test=cpu --cpu-max-prime=20000 --threads=4 run && cat /sys/devices/virtual/thermal/thermal_zone0/temp
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Initializing random number generator from current time


Prime numbers limit: 20000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  1081.94

General statistics:
    total time:                          10.0031s
    total number of events:              10829

Latency (ms):
         min:                                  3.67
         avg:                                  3.69
         max:                                 23.10
         95th percentile:                      3.68
         sum:                              39997.95

Threads fairness:
    events (avg/stddev):           2707.2500/10.85
    execution time (avg/stddev):   9.9995/0.00

44700
cpufreq-info -c 1
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.54 ms.
  hardware limits: 120 MHz - 1.37 GHz
  available frequency steps: 120 MHz, 240 MHz, 480 MHz, 528 MHz, 648 MHz, 672 MHz, 720 MHz, 768 MHz, 792 MHz, 816 MHz, 864 MHz, 912 MHz, 936 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.08 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 120 MHz and 1.37 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 648 MHz.
  cpufreq stats: 120 MHz:41.54%, 240 MHz:20.22%, 480 MHz:9.63%, 528 MHz:5.36%, 648 MHz:2.36%, 672 MHz:1.31%, 720 MHz:1.67%, 768 MHz:0.65%, 792 MHz:0.57%, 816 MHz:1.10%, 864 MHz:1.34%, 912 MHz:0.60%, 936 MHz:0.36%, 960 MHz:0.43%, 1.01 GHz:0.58%, 1.06 GHz:0.30%, 1.08 GHz:0.26%, 1.10 GHz:0.32%, 1.15 GHz:0.52%, 1.20 GHz:0.57%, 1.22 GHz:0.32%, 1.25 GHz:0.69%, 1.30 GHz:0.34%, 1.34 GHz:0.00%, 1.37 GHz:8.98%  (12516)

running 12 x sysbench

sudo sysbench --test=cpu --cpu-max-prime=20000 --threads=4 run && cat /sys/devices/virtual/thermal/thermal_zone0/temp
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Initializing random number generator from current time


Prime numbers limit: 20000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  1078.11

General statistics:
    total time:                          10.0034s
    total number of events:              10791

Latency (ms):
         min:                                  3.67
         avg:                                  3.71
         max:                                 23.34
         95th percentile:                      3.68
         sum:                              39996.37

Threads fairness:
    events (avg/stddev):           2697.7500/23.50
    execution time (avg/stddev):   9.9991/0.00

58513
cpufreq-info -c 1
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.54 ms.
  hardware limits: 120 MHz - 1.37 GHz
  available frequency steps: 120 MHz, 240 MHz, 480 MHz, 528 MHz, 648 MHz, 672 MHz, 720 MHz, 768 MHz, 792 MHz, 816 MHz, 864 MHz, 912 MHz, 936 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.08 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 120 MHz and 1.37 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.37 GHz.
  cpufreq stats: 120 MHz:45.29%, 240 MHz:20.85%, 480 MHz:8.56%, 528 MHz:4.79%, 648 MHz:2.15%, 672 MHz:1.32%, 720 MHz:1.37%, 768 MHz:0.72%, 792 MHz:0.51%, 816 MHz:0.94%, 864 MHz:1.01%, 912 MHz:0.42%, 936 MHz:0.25%, 960 MHz:0.34%, 1.01 GHz:0.40%, 1.06 GHz:0.19%, 1.08 GHz:0.18%, 1.10 GHz:0.16%, 1.15 GHz:0.27%, 1.20 GHz:0.35%, 1.22 GHz:0.31%, 1.25 GHz:0.63%, 1.30 GHz:0.21%, 1.34 GHz:0.00%, 1.37 GHz:8.78%  (37950)

 

Edited by @lex
running > 10 times
Posted

Tweaked DTS, some other numbers:

 

cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       294543 iterations per second for 256-bit key
PBKDF2-sha256     525865 iterations per second for 256-bit key
PBKDF2-sha512     215578 iterations per second for 256-bit key
PBKDF2-ripemd160  171335 iterations per second for 256-bit key
PBKDF2-whirlpool   75328 iterations per second for 256-bit key
argon2i       4 iterations, 229155 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 231680 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm | Key |  Encryption |  Decryption
        aes-cbc   128b   328.1 MiB/s   378.3 MiB/s
    serpent-cbc   128b    29.1 MiB/s    31.2 MiB/s
    twofish-cbc   128b    43.4 MiB/s    47.1 MiB/s
        aes-cbc   256b   287.6 MiB/s   351.6 MiB/s
    serpent-cbc   256b    29.1 MiB/s    31.2 MiB/s
    twofish-cbc   256b    43.4 MiB/s    47.1 MiB/s
        aes-xts   256b   344.4 MiB/s   345.0 MiB/s
    serpent-xts   256b    31.0 MiB/s    31.9 MiB/s
    twofish-xts   256b    47.7 MiB/s    48.4 MiB/s
        aes-xts   512b   321.7 MiB/s   322.3 MiB/s
    serpent-xts   512b    31.0 MiB/s    31.9 MiB/s
    twofish-xts   512b    47.6 MiB/s    48.4 MiB/s

 

Posted
./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                                     :   1099.0 MB/s (0.9%)
 C copy backwards (32 byte blocks)                    :   1095.5 MB/s (0.9%)
 C copy backwards (64 byte blocks)                    :   1086.3 MB/s (0.4%)
 C copy                                               :   1097.6 MB/s (1.2%)
 C copy prefetched (32 bytes step)                    :    892.8 MB/s (0.3%)
 C copy prefetched (64 bytes step)                    :    993.4 MB/s
 C 2-pass copy                                        :   1096.8 MB/s
 C 2-pass copy prefetched (32 bytes step)             :    758.1 MB/s
 C 2-pass copy prefetched (64 bytes step)             :    714.6 MB/s
 C fill                                               :   3859.1 MB/s (0.1%)
 C fill (shuffle within 16 byte blocks)               :   3856.1 MB/s
 C fill (shuffle within 32 byte blocks)               :   3856.9 MB/s
 C fill (shuffle within 64 byte blocks)               :   3854.5 MB/s
 ---
 standard memcpy                                      :   1116.0 MB/s (0.3%)
 standard memset                                      :   3858.4 MB/s (0.1%)
 ---
 NEON LDP/STP copy                                    :   1124.8 MB/s (0.2%)
 NEON LDP/STP copy pldl2strm (32 bytes step)          :    799.7 MB/s (0.4%)
 NEON LDP/STP copy pldl2strm (64 bytes step)          :    963.3 MB/s
 NEON LDP/STP copy pldl1keep (32 bytes step)          :   1164.5 MB/s
 NEON LDP/STP copy pldl1keep (64 bytes step)          :   1164.5 MB/s
 NEON LD1/ST1 copy                                    :   1109.6 MB/s (0.5%)
 NEON STP fill                                        :   3860.1 MB/s (0.1%)
 NEON STNP fill                                       :   3584.2 MB/s (0.7%)
 ARM LDP/STP copy                                     :   1126.1 MB/s (0.2%)
 ARM STP fill                                         :   3858.9 MB/s
 ARM STNP fill                                        :   3584.7 MB/s (0.8%)

==========================================================================
== 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, [MADV_NOHUGEPAGE]
      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 :    5.0 ns          /     8.4 ns 
    131072 :    7.7 ns          /    11.7 ns 
    262144 :    9.0 ns          /    13.1 ns 
    524288 :   10.6 ns          /    15.0 ns 
   1048576 :   94.4 ns          /   145.3 ns 
   2097152 :  139.6 ns          /   187.6 ns 
   4194304 :  168.3 ns          /   208.4 ns 
   8388608 :  183.7 ns          /   217.9 ns 
  16777216 :  192.6 ns          /   224.3 ns 
  33554432 :  197.2 ns          /   228.1 ns 
  67108864 :  201.0 ns          /   232.2 ns 

block size : single random read / dual random read, [MADV_HUGEPAGE]
      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 :    5.0 ns          /     8.4 ns 
    131072 :    7.7 ns          /    11.7 ns 
    262144 :    9.0 ns          /    13.1 ns 
    524288 :   10.6 ns          /    14.8 ns 
   1048576 :   94.4 ns          /   145.3 ns 
   2097152 :  139.0 ns          /   186.9 ns 
   4194304 :  161.5 ns          /   200.8 ns 
   8388608 :  172.7 ns          /   205.8 ns 
  16777216 :  177.9 ns          /   208.0 ns 
  33554432 :  180.3 ns          /   209.1 ns 
  67108864 :  181.5 ns          /   209.6 n
cpufreq-info -c 1
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.54 ms.
  hardware limits: 480 MHz - 1.37 GHz
  available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.37 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.37 GHz.
  cpufreq stats: 480 MHz:7.33%, 648 MHz:2.53%, 720 MHz:0.54%, 768 MHz:0.92%, 912 MHz:0.75%, 1.08 GHz:0.68%, 1.20 GHz:0.59%, 1.37 GHz:86.66%  (3239)

 

Posted

last numbers:

openssl speed -elapsed -evp aes-256-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256-cbc for 3s on 16 size blocks: 21097762 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 13885050 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 5712407 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 1744124 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 232965 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16384 size blocks: 116966 aes-256-cbc's in 3.00s
OpenSSL 1.1.0g  2 Nov 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) 
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" 
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc     112521.40k   296214.40k   487458.73k   595327.66k   636149.76k  
cpufreq-info -c 1
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.54 ms.
  hardware limits: 480 MHz - 1.37 GHz
  available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.37 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.37 GHz.
  cpufreq stats: 480 MHz:4.74%, 648 MHz:1.64%, 720 MHz:0.35%, 768 MHz:0.59%, 912 MHz:0.48%, 1.08 GHz:0.44%, 1.20 GHz:0.38%, 1.37 GHz:91.36%  (3239)

at least, 4.17 pretty stable...

 

I think there is room for improvement, board does not get Temp over 54 ºC so lets the experts handle this... 

 

Posted
On 5/11/2018 at 9:53 AM, Igor said:

:) Mine is also on the way and I will have one spare.

I ordered my NanoPi K1 Plus today.

I like the H5 CPU (OPi Zero Plus2 H5, OPi Zero Plus H5, NanoPi Neo2, NanoPi Neo Core2)

and with the K1 Plus = 2GB of Ram.

 

That will be much better vor Headless-usage...I didnt use a Desktop at SBCs.

Also Gigabit-Ethernet :)

 

I did think the last weeks (after my OPi Zerp Plus2 H5)  which SBC to buy....
I did leave behind the NanoPi Fire3 - and the Nano K2 wouldnt have a new CPU for me (S905 = my Ordoid C2)....

 

The H5 is well known to me and new boards does run cooler for me (Opi Zero Plus2 H5 at around 30 degree here in the summer time)

 

Hoping for DVFS in 4.18 as igor said :)

 

Posted
17 minutes ago, guidol said:

Hoping for DVFS in 4.18 as igor said

How do you test it to make sure it is working as expected? 

Posted
8 minutes ago, @lex said:

How do you test it to make sure it is working as expected? 

I cant test it, because 4.18 isnt released and I do only hope that it will be tue in the "near" future of 4.18 :)

Posted (edited)

I mean what tests you would do in order to make sure DVFS is indeed working, think of the  any actual board that is supposed to have DVFS working.

Edited by @lex
* any
Posted
1 hour ago, @lex said:

I mean what tests you would do in order to make sure DVFS is indeed working, think of the  any actual board that is supposed to have DVFS working.

I would do some (stress)-tests which do need a high cpu load and see if it will switch the frequency up & down the right way and take a look at the cpu temperatures meanwhile.

 

The guy - Christopher Barnatt - from ExplainingComputers at Youtube often check the speed and heat from many SBCs.... so I think this tests are a good idea to test the board, the DVFS switching, performance and temperature.
https://www.youtube.com/channel/UCbiGcwDWZjz05njNPrJU7jA
https://www.explainingcomputers.com/sbc.html

Posted
1 hour ago, guidol said:

I would do some (stress)-tests which do need a high cpu load and see if it will switch the frequency up & down the right way and take a look at the cpu temperatures meanwhile.

This is already working on 4.17.3. The question is what is "right way" I think is necessary to measure the CPU voltage point for each CPU at peak times.

 

Here is the 7z b after uptime for 22:30:00:

 

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE)

LE
CPU Freq:   794  1365  1363  1365  1365  1364  1365  1364  1364

RAM size:    1999 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS


22:       2113   328    626   2056  |      57763   395   1248   4928
23:       2089   331    643   2129  |      54905   392   1212   4751
24:       2056   332    667   2211  |      48069   356   1185   4220
25:       2009   331    692   2294  |      49941   390   1140   4445
----------------------------------  | ------------------------------
Avr:             331    657   2172  |              383   1196   4586
Tot:             357    927   3379

Screenshot before the test (idle.png)

Screenshot during the test (7zb.png )

Screenshot after the test (idle2.png)

 

During the test:

Every 2.0s: ../h5-monitor.sh            nanopi-k1-plus: Sat Jun 30 21:05:16 2018

CPU1 freq       : 1248 MHz
CPU2 freq       : 1248 MHz
CPU3 freq       : 1248 MHz
CPU4 freq       : 1248 MHz
CPU5 count      : 4
Governor        : ondemand
SOC Temp        : 66 C

Idle after the test:


 

Every 2.0s: ../h5-monitor.sh            nanopi-k1-plus: Sat Jun 30 21:12:23 2018

CPU1 freq       : 648 MHz
CPU2 freq       : 648 MHz
CPU3 freq       : 936 MHz
CPU4 freq       : 1008 MHz
CPU count       : 4
Governor        : ondemand
SOC Temp        : 38 C

For whatever reason reading CPU freq in straight C always get the peak freq.

 

idle.png

7zb.png

idle2.png

Posted

Today I received my K1 Plus (and also a black ICY BOX IB-RP102 Case) :)

 

I booted

Armbian_5.47_Nanopik1plus_Debian_stretch_next_4.14.51 and Armbian_5.46.180622_Nanopik1plus_Debian_stretch_dev_4.17.2

but doesnt get a DHCP-request from the K1 Plus :(

So I used a USB-Ethernet-Dongle...which did request a IP via DHCP :)

After that I configured eth0 as static and now my K1 Plus is useable with both images.

 

Armbian_5.46.180622_Nanopik1plus_Debian_stretch_dev_4.17.2 did update to

ARMBIAN 5.52.180712 nightly Debian GNU/Linux 9 (stretch) 4.18.0-rc4-sunxi64
Linux npi-k1-plus 4.18.0-rc4-sunxi64 #214 SMP Fri Jul 13 00:03:19 UTC 2018 aarch64 GNU/Linux

IB_RP102_closed.jpg

IB_RP102_open.jpg

IB_RP102_side.jpg

IB_RP102_top.jpg

Posted
1 hour ago, guidol said:

but doesnt get a DHCP-request from the K1 Plus

 

Huh, you mean none, not even non-nightly build? IIRC it was working for me when I tried ... 

armbianmonitor -u

 

Posted
2 hours ago, guidol said:

and also a black ICY BOX IB-RP102 Case

 

I see that on Amazon.de, but not amazon.com for us colonists...:P

 

top and bottom have no holes, but that certainly looks sharp.  Add it to the "Pi-factor cases" topic?

Posted
3 hours ago, Igor said:

Huh, you mean none, not even non-nightly build? IIRC it was working for me when I tried ... 

yes on both I he didnt request a IP via DHCP - so I used a USB-Ethernet-Dongle.... (also had the chance for using HDMI-console and Keyboard)

before the Dongle I checked several times with nmap - but no IP in my DHCP-Range (.150-.200)

Here the output of armbianmonitor -u:
System diagnosis information will now be uploaded to http://ix.io/1hbi

 

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines