Jump to content

NanoPi NEO4


mindee

Recommended Posts

On 9/26/2018 at 8:33 AM, hjc said:

the whole internal hub goes down in a few seconds (dmesg shows the internal hub is disconnected, lsusb -t only shows the root hub) and I have to do a USB reset or reboot the device to get that back again.

On the M4 at least they are showing RT9724GQW as a current limiter for the individual ports, which has about 111 mili-ohms resistance at 5V, and the FET to enable the 5V for that appears to be under 41 mili-ohms, so I'm not sure what would be knocking it out unless the RTL8153 is unbelievably power hungry.

Link to comment
Share on other sites

On 10/6/2018 at 3:24 AM, Tantalum said:

Hello

 

Any idea when the NEO4 will be available for sale?

I would also love to know when this is planned for release. I would like a NanoPi-M4 and a NanoPi Neo4 but I'd rather order them together to save on shipping and import. Also what is the planned price point for this unit?

Link to comment
Share on other sites

32 minutes ago, Igor said:

Anyone familiar how to get into maskrom mode with Neo4 ... and M4? Not exactly critical since eMMC can be removed but nice to know.

According to schematic, I don't see any jumper for blocking the eMMC, although the EMMC_CLK0 has a R194 33R serial resistor, but a package SMT0201 is difficult to access ...

Link to comment
Share on other sites

Has any one any thoughts on the NanoPi Neo4 having only 1gb ram.

 

I have a Mecool KM8 s912 TV box 1 GB running Armbian and it sort of works well.

 

But I would like something a bit more mainstream for HAM radio applications and am hoping that Friendly Elec and Armbian has a better marriage of just working instead of having little things breaking.

 

Is it worth paying more and getting the NanoPi M4 2 GB model?

Link to comment
Share on other sites

1 hour ago, Seasalt said:

Is it worth paying more and getting the NanoPi M4 2 GB model?

If you don't mind the size and pricing, sure.

BTW, M4 sometimes performs much better than NEO4, since it has got dual channel memory.

Link to comment
Share on other sites

17 minutes ago, hjc said:

If you don't mind the size and pricing, sure.

BTW, M4 sometimes performs much better than NEO4, since it has got dual channel memory.

Size is OK as it will be part of my HAM Radio KIT.

 

Price I calculate at about

NanoPi NEO4 $53.98 with Heatsink and $3 power cable.

 

NanoPi M4 $74.98 with Heatsink and $3 power cable.

 

I have a draw full of old Single board computers.

BUT I need something that can Run Software defined Radio Linux programs like GQRX etc.

 

The Rasp pi3 really does not cut it, for Software defined radio applications.

 

The USB 3 interface lets me run "FL2000 VGA" transmit hacks. Assuming the RK3399 has the horsepower. https://www.crazydanishhacker.com/usb-to-vga-adapter-transmit-radio-signals-fl2000-fl2k/

 

I see 2 GB ram as important.  NanoPi M4

 

I see Friendly Elec Support and software customization as important. Both NanoPi NEO4 and NanoPi M4

 

One USB 3 is enough . Plus the USB C should be high-speed.  NanoPi NEO4

5ghz Wifi is a bonus.   NanoPi M4

 

So basically for an extra $20 will get 5ghz Wifi and 1gb more ram.

 

 

Link to comment
Share on other sites

19 minutes ago, hjc said:

If you don't mind the size and pricing, sure.

BTW, M4 sometimes performs much better than NEO4, since it has got dual channel memory.

Is there any benchmarks of Dual channel memory improving RK3399 performance.

Link to comment
Share on other sites

15 hours ago, Igor said:

 

https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md

As you can see it is quite a diff.

Ok I see the improvement in memory speed.

 

What is Armbians Plan for the RK3399.

 

Will it be a generic version of Armbian like the s905/s912 or will each RK3399 board have there own version of Armbian? Like the Orange Pi PC2 etc.

Link to comment
Share on other sites

14 hours ago, Seasalt said:

or will each RK3399 board have there own version of Armbian

 

We can/could merge Nanopi M4/T4/Neo4 under one image, which share boot loader and kernel family rk3399. We wanted to add Rock64 and Rock64PRO to one common rockchip64 family. To maintain one kernel source ... but its sadly way too much work and this is postponed to the future. Since we have two legacy kernels for RK3399 and since boot loaders are different, we can't provide one image. 

Link to comment
Share on other sites

8 hours ago, Igor said:

or will each RK3399 board have there own version of Armbian

Based on current  or expected Armbian version should I buy the Rockchip RK3399 on Friendly Elec RK3399. ie which has the most advanced Armbian OS at this moment.

Link to comment
Share on other sites

7 hours ago, Jason Law said:

I would probably buy the board that best meets your use case

Which board would you buy and why?

 

I have a draw full of old boards and I am just really hesitant, to buy another board when maybe my s912 Mecool running armbian is all I need for now.

Link to comment
Share on other sites

5 hours ago, Seasalt said:

Which board would you buy and why?

I have 2 primary needs, Media playback and NAS. My current board is the Odroid XU4Q is unfortunately not living up to my expectations but it's been a good learning process. It has problems with thermal throttling and does not have hardware decoding for H264/H265 so I get tearing and low framerates even at 1080P. Youtube is 720P. I also had issues with UAS protocols and had to disable it on my USB3.0 attached HDD. (This has more to do with my USB to SATA cable than anything else). After a fair bit of research I've decided on the RK3399 SoC.

RockPro64:

Too big for my liking. Due to thermal issues most people run it at 1.8Ghz big and 1.4Ghz small. I also really don't like that you need a PCIe expansion board for SATA. There have been a lot of issues on the forums for this board, especially with the SATA expansion board.

NanoPC-T4

I can't find much info about using the M.2 M-Key with a SATA expansion board. Only report I found of someone trying this said due to the positioning of some components their board shorted. No board released directly by FriendlyElec for this purpose so drivers will also be an issue. RK3399 SoC on the top of board so likely thermal issues.

NanoPi-M4

Checks off all the boxes nicely. Great heatsinks, 4xUSB3.0 and there's a HAT in development with 4 SATA ports and 2 Molex ports. I love the form factor, it has great reviews, the price is reasonable. With a small fan you can even overclock it slightly.

NanoPi Neo4

Could maybe work for me if they make a SATA HAT like they have for the M4, otherwise existing connectivity ports are inadequate. Also 1GB Ram is a little lean. I would still love one of these down the road to tinker on.

ODROID N1

Cancelled, otherwise this would have been a strong contender. It has on board SATA support and a large community to back it up. Still waiting to see what Odroids going to come up with next.

Other Manufacturers of RK3399 boards.

The older RK3399 boards all seem to be more expensive, lacking in SATA options and cap at 2GB RAM.  None of them really caught my attention.

X86 boards like UDOO and LattePanda 

Too expensive for what they were offering. Less power efficient.

 

Link to comment
Share on other sites

5 hours ago, Jason Law said:

It has problems with thermal throttling and does not have hardware decoding for H264/H265 so I get tearing and low framerates even at 1080P. Youtube is 720P.

...

X86 boards like UDOO and LattePanda 

A benefit of the x86 based ones would be hardware video decoding driver support.

The XU4 does have h264 hardware decoding support. The problem is getting it working in Chrome for YouTube. Apparently it worked with the Flash plugin, but it requires effort to enable to HTML5 video.

Link to comment
Share on other sites

1 hour ago, chrisf said:

A benefit of the x86 based ones would be hardware video decoding driver support.

The XU4 does have h264 hardware decoding support. The problem is getting it working in Chrome for YouTube. Apparently it worked with the Flash plugin, but it requires effort to enable to HTML5 video.

 

I'm fairly new to SBCs in general but I was under the impression that the Odroid XU4 is using software accelerated decoding of H264 and straight up can't do H265, which is why many people go for the Odroid C2 for media playback as it has a dedicated hardware decoding chip for H264. My experience in Chrome (after installing additional plugins) is that 720P runs quite smoothly as long as running full screen with no adds or anything else popping up (like the volume control button when you hit the volume keys on your keyboard, or advertisments). Otherwise other elements on the screen can cause tearing and poor playback. Chromium Youtube at 1080P is very low framerate and absolutely unplayable. Kodi is mostly usable up to 1080P but high action scenes where a large number of pixels are replaced from frame to frame playback at a very low frame rate. My first board was not the Q model, the fan was rediculously loud and the board was defective. The RMA process through Ameridroid was terrible and ended up needlessly costing me an extra ~20USD. As this is their US distributor I would like to avoid Ameridroid and Odroid altogether. Despite these annoyances the board is getting the job done well enough, but I'm included to get an RK3399 board for my home media server for fluid playback and use my Odroid as a board to tinker with.

Link to comment
Share on other sites

The GPU's in these SoC's can usually do h264. Older ones can't do hardware acceleration for h265.

It requires kernel driver support for the GPU that's built in. This usually gets done for Android kernels, so phones and tablets have good performance. No one is paying to have this done in the mainline Linux kernel, it's left up to volunteers.

 

The Exynos 5422 in the XU4 has hardware for encoding and decoding h.264 video.

 

The C2's soc, the Amlogic S905 has hardware for h264 and h265. Hardkernel advertises that too, so you'd probably have better luck getting it working. You might need to use their kernel to get something working "out the box".

Link to comment
Share on other sites

On 10/14/2018 at 11:08 PM, Jason Law said:

 

I'm fairly new to SBCs in general but I was under the impression that the Odroid XU4 is using software accelerated decoding of H264 and straight up can't do H265, which is why many people go for the Odroid C2 for media playback as it has a dedicated hardware decoding chip for H264. My experience in Chrome (after installing additional plugins) is that 720P runs quite smoothly as long as running full screen with no adds or anything else popping up (like the volume control button when you hit the volume keys on your keyboard, or advertisments). Otherwise other elements on the screen can cause tearing and poor playback. Chromium Youtube at 1080P is very low framerate and absolutely unplayable. Kodi is mostly usable up to 1080P but high action scenes where a large number of pixels are replaced from frame to frame playback at a very low frame rate. My first board was not the Q model, the fan was rediculously loud and the board was defective. The RMA process through Ameridroid was terrible and ended up needlessly costing me an extra ~20USD. As this is their US distributor I would like to avoid Ameridroid and Odroid altogether. Despite these annoyances the board is getting the job done well enough, but I'm included to get an RK3399 board for my home media server for fluid playback and use my Odroid as a board to tinker with.

@Jason Law for which board did you opt? M4 or Neo4? I have fairly similar requirements and not inclined for Odroid either.

Link to comment
Share on other sites

4 minutes ago, gdm85 said:

@Jason Law for which board did you opt? M4 or Neo4? I have fairly similar requirements and not inclined for Odroid either.

 

I bought an Asrock Deskmini 310W, makes for a nice NAS solution, not really a SBC though.

Link to comment
Share on other sites

Hello,

 

Can someone show results of "cpufreq-info" ( both on kernel 4.4 ( stable ) and 4.20 ( dev )) just to determine how things look like, please? ...

 

My NEO2's show 1.01GHz ( kernel 4.19 ) while the "new" NEO4 should be able to get to 1.8 if I am not mistaken.

Therefore in near future might replace this NEO4 with my current NEO2 boards , mainly used for oVPN and Pi-hole.

At this time I get +/- 100Mbit speeds over my VPN tunnel - which for my streaming needs is sufficient - but I am always interested to see if things can be improved.

Also it appears the 100Mbit limit is set by my ISP (RCSRDS), lucky me, considering "  asemenea viteaza de upload international s-a marit la 100Mbps. ".

 

Yet quoting from a site " There’s a significant single-core performance boost (+73%), and lower multi-core delta (+30%) as expected since RK3399 has 2 fast Cortex A72 cores, 4 low power Cortex-A53 cores, against 4 fast Cortex-A17 cores for RK3288. If you look into the details AES is over 10 times faster on RK3399, so there must be some special instructions used here, or AES hardware acceleration. "

 

Can one show me some results using ovpn 2.4.6 please as for oVPN use this "single core" and "AES" stuff is important and maybe moving to Rockchip RK3399 will be worth it.

Perhaps forcing use of the Dual Core Cortex A72 and disable the Quad Core Cortex-A53 [ echo "0" > /sys/devices/system/cpu/cpu[2-5]/online ] would be another tweak to speed things up?

 

Oh, inerested in " grep -m1 -o aes /proc/cpuinfo " as well  " openssl speed -evp aes-128-cbc " and last but not least " iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1" #where IP is address neo4

My NEO2 reads":

 

grep -m1 -o aes /proc/cpuinfo 

aes

 

openssl speed -evp aes-128-cbc

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      53449.87k   172470.12k   364346.54k   527213.91k   606710.44k   613225.81k

 

iperf3 -4 -V -c 192.168.10.2 -t 60 -b 0 -P 1

Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   734 MBytes   103 Mbits/sec  930             sender
[  4]   0.00-60.00  sec   727 MBytes   102 Mbits/sec                  receiver
CPU Utilization: local/sender 1.6% (0.1%u/1.5%s), remote/receiver 31.5% (2.5%u/29.0%s)

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-60.11  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-60.11  sec   727 MBytes   101 Mbits/sec                  receiver

 

 

tuned kernel settings:

net.core.default_qdisc = fq

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

 

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216

 

net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_timestamps = 0

Link to comment
Share on other sites

Hi @dolphs, here are results from some of the tests that you requested, running on my NEO4 (full image build from ToT):

root@nanopineo4:~# cat /proc/version
Linux version 4.20.0-rk3399 (root@elrond) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75.190210 SMP Sat Feb 9 01:24:09 UTC 2019
root@nanopineo4:~#
root@nanopineo4:~# grep -m1 -o aes /proc/cpuinfo
aes
root@nanopineo4:~# 
root@nanopineo4:~# openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 20486565 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 14675445 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 7906405 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 2861360 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 411854 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 208079 aes-128-cbc's in 3.00s
OpenSSL 1.1.0j  20 Nov 2018
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-128-cbc     109261.68k   313076.16k   674679.89k   976677.55k  1124635.99k  1136388.78k
root@nanopineo4:~#
root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu0/online
root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu1/online
root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu2/online
root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu3/online
root@nanopineo4:~# openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 67833990 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 41104921 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 15078940 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 4187372 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 552193 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 276850 aes-128-cbc's in 3.00s
OpenSSL 1.1.0j  20 Nov 2018
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-128-cbc     361781.28k   876904.98k  1286736.21k  1429289.64k  1507855.02k  1511970.13k
root@nanopineo4:~#
root@nanopineo4:~# cpufreq-info -c 0
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  maximum transition latency: 40.0 us.
  hardware limits: 408 MHz - 1.51 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 600 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 600 MHz.
  cpufreq stats: 408 MHz:0.39%, 600 MHz:62.20%, 816 MHz:0.13%, 1.01 GHz:0.15%, 1.20 GHz:0.09%, 1.42 GHz:0.04%, 1.51 GHz:37.01%  (265)
root@nanopineo4:~# cpufreq-info -c 4
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 4:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 4 5
  CPUs which need to have their frequency coordinated by software: 4 5
  maximum transition latency: 540 us.
  hardware limits: 408 MHz - 2.02 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 600 MHz and 2.02 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 600 MHz (asserted by call to hardware).
  cpufreq stats: 408 MHz:0.40%, 600 MHz:79.51%, 816 MHz:0.72%, 1.01 GHz:0.32%, 1.20 GHz:0.02%, 1.42 GHz:0.03%, 1.61 GHz:0.04%, 1.80 GHz:0.02%, 2.02 GHz:18.94%  (209)
root@nanopineo4:~#

 

For reference, here's the openssl run on one of my NEO2s (clocked at 1.3GHz max):

root@nanopineo2:~# openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 16484521 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 13180969 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 6907016 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 2458428 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 353299 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 178478 aes-128-cbc's in 3.00s
OpenSSL 1.1.0j  20 Nov 2018
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-128-cbc      87917.45k   281194.01k   589398.70k   839143.42k   964741.80k   974727.85k
root@nanopineo2:~#
root@nanopineo2:~# cpufreq-info -c 0
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  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: 5.44 ms.
  hardware limits: 120 MHz - 1.30 GHz
  available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 120 MHz and 1.30 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 120 MHz (asserted by call to hardware).
  cpufreq stats: 120 MHz:85.04%, 240 MHz:1.79%, 480 MHz:0.27%, 648 MHz:0.00%, 816 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.10 GHz:0.00%, 1.15 GHz:0.00%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:12.90%  (162205)
root@nanopineo2:~#

I hope this helps!

 

 

 

 

Link to comment
Share on other sites

thanks a lot - it indeed shows the NEO4 ( RK3399 ) is about double ( 2Ghz ) of what I can squish out of the NEO2 currently (1).

 

Which reminds me of the cpu discussion back then. In fact I owe two NEO2 LTS boards and these should be able to handle 1.3 ( instead of 1 ), hence v1.1.

Both boards run currently as ovpn server/client on stable debian9, meaning kernel 4.19 ( armbian 5.73 ).

 

Perhaps in referred topic you can guide me thru this on a running system as updating just "/boot/armbianEnv.txt "

and MAX_SPEED=1300000 in /etc/default/cpufrequtils," is not sufficient at least I set it to:

verbosity=1
console=both
overlay_prefix=sun50i-h5
overlays=cpu-clock-1.3GHz gpio-regulator-1.3v usbhost1 usbhost2
rootdev=UUID=5455aad0-a830-48da-b4ba-18795372ece0
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u


 

thanks again! 

 

Link to comment
Share on other sites

8 hours ago, dolphs said:

thanks a lot - it indeed shows the NEO4 ( RK3399 ) is about double ( 2Ghz ) of what I can squish out of the NEO2 currently (1).

 

Which reminds me of the cpu discussion back then. In fact I owe two NEO2 LTS boards and these should be able to handle 1.3 ( instead of 1 ), hence v1.1.

Both boards run currently as ovpn server/client on stable debian9, meaning kernel 4.19 ( armbian 5.73 ).

 

Perhaps in referred topic you can guide me thru this on a running system as updating just "/boot/armbianEnv.txt "

and MAX_SPEED=1300000 in /etc/default/cpufrequtils," is not sufficient at least I set it to:

 

thanks again! 

 

 

Hi @dolphs, you are very welcome!  Good news, your boards should work great at 1.3GHz.  When we moved to the new kernel and updated the DTs I added the appropriate regulator entry for the NEO2 v1.1 board by default, and was able to simplify the instructions for the NEO2 v1.1 board.  I just posted updated instructions; please give these a try:

 

Link to comment
Share on other sites

The NanoPI NEO4 ( Rockchip 3399 ) might be an interesting upgrade after all

as I was convinced there was a 100Mbit upload cap but "overclocking" the NanoPi NEO2-LTS gave me tops 200Mbit, 160Mbit average.

Yet pity NEO4 comes with WLAN and BT, perhaps friendlyelec can release a "lite" version without these components

as there is an alternative available, called "Rock Pi 4 Model A", just the size is a bit bigger: 85*54mm instead of 60*45mm ( neo4 )

thanks all will closely follow this !

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines