tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
32 minutes ago, Igor said:
Thank you! This seems right
Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp 06:52:52: 1992/1512MHz 0.23 5% 2% 2% 0% 0% 0% 29.4°C -
4 hours ago, hjc said:
On NanoPC T4, overclocking makes it exceed the max allowed current of the board, which triggers some sort of protection, and the board powered down immediately.
That's what I observed, the lights simply went out.
52 minutes ago, Igor said:OC is enabled but limited with cpufreq-tools
Nope since cpufrequtils can't deal with big.LITTLE. The little cores will always be overclocked unless we set maximum cpufreq to 1.4GHz or less. IMO we should enable 2.0/1.5GHz (tested successfully on ODROID-N1), test this on a bunch of boards and encourage users to join the testing and leave everything above to the overclocker camp.
-
On 8/16/2018 at 7:55 AM, hjc said:
Firefly RK3399 (with official active cooling fan) sbc-bench test results: http://ix.io/1kk9
It shows impressive CPU performance numbers when overclocked to 2.2/1.8 GHz, but that definitely requires a fan.
Well, tried the same with your overclocked settings on NanoPC-T4 but this definitely kills the board.
I tried it several times without a fan and just the passive heatsink and the board powered down always when running the multi-threaded 7-zip test.
Then added a large fan blowing directly over the heatsink and now cpu-miner kills the board:
root@nanopct4:/home/tk# cd /tmp/sbc-bench.sh.bpjAvD/ root@nanopct4:/tmp/sbc-bench.sh.bpjAvD# cat results.log sbc-bench v0.5.4 FriendlyElec NanoPC-T4 (Sun, 26 Aug 2018 17:00:27 +0000) Distributor ID: Debian Description: Debian GNU/Linux 9.5 (stretch) Release: 9.5 Codename: stretch Armbian release info: BOARD=nanopct4 BOARD_NAME="NanoPC T4" BOARDFAMILY=rk3399 VERSION=5.59 LINUXFAMILY=rk3399 BRANCH=default ARCH=arm64 IMAGE_TYPE=user-built BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image /usr/bin/gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 Uptime: 17:00:27 up 27 min, 1 user, load average: 0.09, 0.28, 0.22 Linux 4.4.152-rk3399 (nanopct4) 08/26/2018 _aarch64_ (6 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 2.99 0.01 0.51 0.09 0.00 96.40 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 0.15 4.42 0.00 7340 0 mmcblk1rpmb 0.00 0.01 0.00 24 0 mmcblk1boot1 0.08 0.33 0.00 540 0 mmcblk1boot0 0.08 0.33 0.00 540 0 mmcblk0 1.99 102.00 72.31 169413 120114 zram0 0.36 0.44 0.99 736 1640 zram1 0.18 0.70 0.00 1168 4 zram2 0.18 0.70 0.00 1168 4 zram3 0.18 0.70 0.00 1168 4 zram4 0.18 0.70 0.00 1168 4 total used free shared buff/cache available Mem: 3.7G 72M 3.2G 13M 449M 3.6G Swap: 1.0G 0B 1.0G Filename Type Size Used Priority /dev/zram1 partition 262140 0 5 /dev/zram2 partition 262140 0 5 /dev/zram3 partition 262140 0 5 /dev/zram4 partition 262140 0 5 ########################################################################## Checking cpufreq OPP for cpu0-cpu3: Cpufreq OPP: 1800 Measured: 1788.107/1788.741/1787.948 Cpufreq OPP: 1512 Measured: 1499.856/1499.995/1500.292 Cpufreq OPP: 1416 Measured: 1402.779/1403.328/1403.831 Cpufreq OPP: 1200 Measured: 1188.661/1187.664/1188.169 Cpufreq OPP: 1008 Measured: 995.824/995.800/996.016 Cpufreq OPP: 816 Measured: 803.730/804.091/803.730 Cpufreq OPP: 600 Measured: 588.137/587.386/587.830 Cpufreq OPP: 408 Measured: 395.342/395.967/395.809 Checking cpufreq OPP for cpu4-cpu5: Cpufreq OPP: 2208 Measured: 2200.013/2200.253/2200.277 Cpufreq OPP: 1992 Measured: 1983.248/1983.930/1984.126 Cpufreq OPP: 1800 Measured: 1792.873/1792.495/1792.475 Cpufreq OPP: 1608 Measured: 1600.285/1600.166/1599.472 Cpufreq OPP: 1416 Measured: 1408.240/1408.363/1408.256 Cpufreq OPP: 1200 Measured: 1153.708/1187.759/1187.978 Cpufreq OPP: 1008 Measured: 999.497/1000.198/1000.186 Cpufreq OPP: 816 Measured: 808.052/808.141/808.131 Cpufreq OPP: 600 Measured: 590.930/591.280/591.280 Cpufreq OPP: 408 Measured: 399.518/399.698/399.929 root@nanopct4:/tmp/sbc-bench.sh.bpjAvD# tail -f monitor.log System health while running tinymembench: Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp 17:00:41: 2208/1800MHz 0.23 3% 0% 3% 0% 0% 0% 36.2°C 17:01:41: 2208/1800MHz 0.72 16% 0% 16% 0% 0% 0% 33.9°C 17:02:41: 2208/1800MHz 0.90 16% 0% 16% 0% 0% 0% 33.9°C 17:03:41: 2208/1800MHz 0.96 16% 0% 16% 0% 0% 0% 32.2°C 17:04:41: 2208/1800MHz 0.99 16% 0% 16% 0% 0% 0% 31.1°C 17:05:41: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:06:41: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:07:41: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:08:41: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 31.1°C 17:09:41: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:10:41: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:11:41: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:12:42: 2208/1800MHz 1.06 16% 0% 16% 0% 0% 0% 30.6°C 17:13:42: 2208/1800MHz 1.02 16% 0% 16% 0% 0% 0% 30.6°C 17:14:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:15:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:16:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 31.1°C 17:17:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:18:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:19:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 30.6°C 17:20:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 40.0°C 17:21:42: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 42.2°C 17:22:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 38.8°C 17:23:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 36.2°C 17:24:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 35.6°C 17:25:43: 2208/1800MHz 1.05 16% 0% 16% 0% 0% 0% 34.4°C 17:26:43: 2208/1800MHz 1.02 16% 0% 16% 0% 0% 0% 34.4°C 17:27:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 34.4°C 17:28:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 34.4°C 17:29:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 35.0°C 17:30:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 35.0°C 17:31:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 34.4°C 17:32:43: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 35.0°C 17:33:44: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 35.0°C System health while running OpenSSL benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp 17:34:38: 2208/1800MHz 1.00 10% 0% 10% 0% 0% 0% 36.2°C 17:34:48: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 32.8°C 17:34:58: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 38.1°C 17:35:08: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 39.4°C 17:35:18: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 34.4°C 17:35:28: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 33.9°C 17:35:38: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 40.6°C 17:35:48: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 41.1°C 17:35:58: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 35.0°C 17:36:09: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 38.8°C 17:36:19: 2208/1800MHz 1.00 16% 0% 16% 0% 0% 0% 41.1°C System health while running 7-zip single core benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp 17:36:26: 2208/1800MHz 1.00 11% 0% 10% 0% 0% 0% 40.6°C 17:36:56: 2208/1800MHz 1.81 16% 0% 16% 0% 0% 0% 33.3°C 17:37:26: 2208/1800MHz 3.06 16% 0% 16% 0% 0% 0% 32.2°C 17:37:56: 2208/1800MHz 3.24 16% 0% 16% 0% 0% 0% 31.7°C 17:38:26: 2208/1800MHz 4.04 16% 0% 16% 0% 0% 0% 31.7°C 17:38:57: 2208/1800MHz 4.29 16% 0% 16% 0% 0% 0% 31.1°C 17:39:27: 2208/1800MHz 4.14 16% 0% 16% 0% 0% 0% 31.1°C 17:39:57: 2208/1800MHz 4.24 16% 0% 16% 0% 0% 0% 30.0°C 17:40:27: 2208/1800MHz 4.57 16% 0% 16% 0% 0% 0% 31.1°C 17:40:57: 2208/1800MHz 5.15 16% 0% 16% 0% 0% 0% 31.1°C 17:41:27: 2208/1800MHz 4.31 16% 0% 16% 0% 0% 0% 30.6°C 17:41:57: 2208/1800MHz 4.17 16% 0% 16% 0% 0% 0% 31.1°C 17:42:27: 2208/1800MHz 3.89 16% 0% 16% 0% 0% 0% 31.1°C 17:42:57: 2208/1800MHz 3.94 16% 0% 16% 0% 0% 0% 30.6°C 17:43:28: 2208/1800MHz 3.93 16% 0% 16% 0% 0% 0% 31.1°C 17:43:58: 2208/1800MHz 4.69 16% 0% 16% 0% 0% 0% 30.6°C 17:44:28: 2208/1800MHz 4.57 16% 0% 16% 0% 0% 0% 31.1°C 17:44:58: 2208/1800MHz 4.80 16% 0% 16% 0% 0% 0% 31.1°C 17:45:28: 2208/1800MHz 5.02 16% 0% 16% 0% 0% 0% 37.5°C 17:45:58: 2208/1800MHz 4.90 16% 0% 16% 0% 0% 0% 37.5°C 17:46:28: 2208/1800MHz 5.23 16% 0% 16% 0% 0% 0% 39.4°C 17:46:58: 2208/1800MHz 4.89 16% 0% 16% 0% 0% 0% 38.1°C 17:47:28: 2208/1800MHz 4.85 16% 0% 16% 0% 0% 0% 38.1°C 17:47:58: 2208/1800MHz 5.08 16% 0% 16% 0% 0% 0% 40.0°C 17:48:29: 2208/1800MHz 4.89 16% 0% 16% 0% 0% 0% 38.8°C 17:48:59: 2208/1800MHz 4.35 16% 0% 16% 0% 0% 0% 38.8°C 17:49:29: 2208/1800MHz 4.61 16% 0% 16% 0% 0% 0% 38.1°C 17:49:59: 2208/1800MHz 4.18 16% 0% 16% 0% 0% 0% 38.1°C 17:50:29: 2208/1800MHz 4.63 16% 0% 16% 0% 0% 0% 40.0°C System health while running 7-zip multi core benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp 17:50:38: 2208/1800MHz 4.84 12% 0% 11% 0% 0% 0% 41.1°C 17:51:09: 2208/1800MHz 4.90 79% 1% 78% 0% 0% 0% 51.7°C 17:51:39: 2208/1800MHz 5.25 86% 1% 85% 0% 0% 0% 52.8°C 17:52:09: 2208/1800MHz 5.52 82% 1% 81% 0% 0% 0% 55.0°C 17:52:40: 2208/1800MHz 5.15 80% 1% 79% 0% 0% 0% 56.7°C 17:53:10: 2208/1800MHz 5.49 89% 1% 87% 0% 0% 0% 60.6°C 17:53:40: 2208/1800MHz 5.05 77% 1% 76% 0% 0% 0% 58.9°C 17:54:10: 2208/1800MHz 5.50 89% 1% 87% 0% 0% 0% 56.7°C System health while running cpuminer: Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp 17:54:27: 2208/1800MHz 5.53 15% 0% 15% 0% 0% 0% 55.6°C Write failed: Broken pipe -
Just to have some sort of comparison to x86 based SBC I benchmarked my UP Board (lying in the drawer for years) right now:
As can be seen the Intel Atom x5-Z8300 CPU will be outperformed by an RK3399 or even an el cheapo NanoPi Fire3 pretty easily: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
Onboard eMMC performance (16GB on my model) also not that impressive (random IO ok, but sequential write performance below SD card level at just ~20 MB/s):
Internal 32 GB eMMC random random kB reclen write rewrite read reread read write 102400 4 2959 3431 16319 16706 11944 3400 102400 16 6710 6162 23026 23813 21143 6775 102400 512 15525 20512 100141 97841 98877 20622 102400 1024 20925 21024 102145 105088 100305 17150 102400 16384 20425 20749 106923 107996 108337 20844 1024000 16384 18512 19994 106359 106060 103988 20007I backed this board in the beginning to check it with NAS usage in mind but never managed to attach fast storage since UP Board (just like LeMaker's Guitar back then) uses the crappy Micro-B USB3 receptacle (designed for OTG/device and not host mode -- you need an UEFI update and a special cable to be able to attach USB3 SuperSpeed peripherals to this board).
BTW: kernel situation as crappy as with a lot of ARM boards (or maybe the board now fully works also with mainline kernel -- I don't know). At least the official kernel enabling majority of board features is a 4.9.45 that received zero fixes for over a year now: https://github.com/emutex/ubilinux-kernel
-
1 hour ago, malaga said:
the only way is to use a sata to usb adaptor or a usb enclosure for the drive
Exactly. So take care that you choose an appropriate chipset (JMS578 for example). Something like this: https://aliexpress.com/item/Black-JMS578-Chip-3569S3-EU-BK-HDD-SSD-case-with-EU-plug-support-Hot-swap-drive/32814026176.html
Performance on an USB2 Hi-Speed port is low as expected: http://linux-sunxi.org/Sunxi_devices_as_NAS
Given the high prices for an appropriate enclosure I would buy an ODROID-HC2 anyway...
-
On 8/15/2018 at 12:36 PM, malaga said:
fit to these above mentioned boards too
You would need an USB-A-to-USB-A cable.
-
1 hour ago, TonyMac32 said:
Ask Amlogic
LOL! Yeah, asking the SoC vendor constantly cheating on users... haha, no, my simple approach is to stay away from everything where's Amlogic printed on!
-
8 hours ago, PhracturedBlue said:
So I it looks like the top-left USB port is not hooked up to the usb hub on the le-potato?
Yep, this should be the 'fast' port where you connect a disk to for example since not having to share bandwidth with the other ports. But it's still USB2/Hi-Speed so no idea where xhci messages originate from.
-
3 hours ago, TonyMac32 said:
do the HC1 or 2 have a copper plane for this that you know of?
No idea. But IIRC I had to gently massage one of my 2 HC2 to get better heat transfer into the massive heatsink/enclosure thing.
3 hours ago, TonyMac32 said:I was able to get it to 49 with new thermal paste and biasing the pressure between the springs of the fansink (the SoC is nowhere near the center, so the thought that the fansink sits flush is a bit silly).
Well, this is also an important information: 'new' thermal paste (they can age and perform lower after some time, same wrt contact area between heatsink and SoC)
3 hours ago, TonyMac32 said:Interesting tidbit, I can see throttling occurring but I'm still showing cooling state = 0 on armbianmonitor.
Sure, throttling can happen without the fan becoming active and vice versa. My understanding is that it all depends on DT contents and cooling maps there. They can define to lower clockspeeds and/or activate additional measures like a fan.
BTW: the similar looking fansink on my N1 dev sample was almost silent compared to the XU4 fansink. The only annoyance was a strange chirping sound when the fan started to spin. Simple countermeasure on the N1: define entering lowest fan speed to be entered at a very low temperature already. But this isn't an option with the XU4 since then fan is too loud.
AFAIK all these thermal tresholds are available through sysfs. You can even get an immediate emergency shutdown by echoing a low temperature value to the critical treshold sysfs node.
-
35 minutes ago, emk2203 said:
dl.armbian.com has no nightlies
I tested myself and now it looks like this:
root@nanopct4:~# cat /etc/systemd/resolved.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See resolved.conf(5) for details [Resolve] #DNS= #FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844 #Domains= #LLMNR=yes #DNSSEC=no #Cache=yes #DNSStubListener=udp root@nanopct4:~# cat /etc/resolvconf/resolv.conf.d/head # In case of DNS problems, try uncommenting this and reboot for debugging # nameserver 1.1.1.1Problem solved I would say...
-
On 8/22/2018 at 8:31 AM, Igor said:
If you build an image with build tools now, DVFS is partially broken on two cores since sources were switched to Ayufan's repo and they need further adjustments (WIP). Perhaps this is the problem?
He mentioned it would be the other way around (little cores missing and only big cores present). I looked into it right now:
[ 1.562675] rk_tsadcv2_temp_to_code: Invalid conversion table: code=1023, temperature=2147483647 [ 1.562900] rockchip-thermal ff260000.tsadc: tsadc is probed successfully! [ 1.564982] cpu cpu0: Failed to get leakage [ 1.565017] cpu cpu0: Looking up cpu-supply from device tree [ 1.565099] cpu cpu0: Failed to get pvtm [ 1.565480] cpu cpu4: Failed to get leakage [ 1.565508] cpu cpu4: Looking up cpu-supply from device tree [ 1.565571] cpu cpu4: Failed to get pvtm [ 1.565872] cpu cpu0: Looking up cpu-supply from device tree [ 1.566208] cpu cpu0: Looking up cpu-supply from device tree [ 1.569178] cpu cpu4: Looking up cpu-supply from device tree [ 1.569716] cpu cpu4: _opp_add: duplicate OPPs detected. Existing: freq: 1800000000, volt: 1200000, enabled: 1. New: freq: 1800000000, volt: 1350000, enabled: 1 [ 1.569760] cpu cpu4: _of_add_opp_table_v2: Failed to add OPP, -17 [ 1.570410] cpu cpu4: couldn't find opp table for cpu:4, -17 [ 1.570638] cpu cpu5: Looking up cpu-supply from device tree [ 1.571138] cpu cpu5: _opp_add: duplicate OPPs detected. Existing: freq: 1800000000, volt: 1200000, enabled: 1. New: freq: 1800000000, volt: 1350000, enabled: 1 [ 1.571172] cpu cpu5: _of_add_opp_table_v2: Failed to add OPP, -17 [ 1.571798] cpu cpu5: couldn't find opp table for cpu:5, -17Hmm... that's bad. Due to different ways @ayufan deals with DT includes and 'the others' (RK kernel consumers) do I wonder how to proceed.
-
2 hours ago, botfap said:
¥275 / €35 RK3399 boards with GBe, 32GB eMMC, 4GB Ram, USB2 / 3, USB C
Looks like a H96 Max? According to @Slack booting via SD card is directly supported but he also reports few posts below that there is not an AP6255 but an LTM8830 inside.
-
4 hours ago, emk2203 said:
maybe with a commented line with Google's nameserver and the additional comment `# In case of DNS problems, try uncommenting this for debugging` or similar.
Tried a fix with https://github.com/armbian/build/commit/f10acc0080825faf711eb6e6b7425910d75d840c
Would be great if you could try next nightly version and report back.
-
28 minutes ago, emk2203 said:
Maybe this is in there as an artifact from whatever, but it takes precedence over the `systemd-resolved` nameserver 127.0.0.53. If this a bug of the standard Armbian image?
Please see
It seems writing something to /etc/resolvconf/resolv.conf.d/head at image creation time creates this issue and removing the file should solve it. @Igor wanted to look into but no idea what happened.
IMO neither using Google's DNS nor Cloudflare's is a brilliant idea and we should really change this so user's local config always wins. Details: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
-
On 7/20/2018 at 12:11 PM, mindee said:
Update(8/24/2018): It's time to deal with NEO4, this picture is not the final version. NEO4 will have PCIe x2 and eMMC connector too, and a MIPI-CSI. But the dual-layer USB connector will share USB 3.0 & USB 2.0, Type-C take another USB 3.0.
Thank you for the update. Simply quoting since editing posts from weeks ago might not get noticed by interested readers
Ok, so now we know:
- RK3399 with appropriate cooling if users buy the heatsink or simply use a thermal pad and attach the board to any large metal surface
- USB3 SuperSpeed available as USB3-A and USB-C (OTG)
- USB2 Hi-Speed on the other type A receptacle and on the pin header next to USB receptacles
- Gigabit Ethernet using the usual RTL8211 PHY
- PCIe x2 on connector
- MIPI-CSI for camera
- HDMI 2.0 as only display output
- eMMC connector
-
RTL8189EVB Wi-Fi(final version will use AP6212 Wi-Fi/BT) - 1 GB DDR3 with 32-bit bus width
- Powering through USB-C or 4-pin header next to USB ports.
OMG, this thing combined with a 'M.2 key M HAT' and one of the few 2242 NMVe SSDs would make up for the perfect pocket server. @wtarreau do you agree?
@guidol: https://forum.armbian.com/topic/7511-nanopi-m4/?do=findComment&comment=58021
-
56 minutes ago, emk2203 said:
;; SERVER: 127.0.0.53#53(127.0.0.53)
This query has been answered by a DNS resolver running on your laptop.
56 minutes ago, emk2203 said:;; SERVER: 8.8.8.8#53(8.8.8.8)
This query has been answered by Google's DNS server. Results as expected.
I would assume on your laptop systemd-resolved is resolving queries but uses the upstream DNS config obtained by DHCP and your Armbian installation does not but has been told to use 8.8.8.8
As usual the best idea is to always provide 'armbianmonitor -u' output since it's such a waste of time digging for information in a dialog.
-
6 minutes ago, guidol said:
there is also another log on the bpi-forum page where the cpu-identification says R40:
Are you referring to this?
CPU: Allwinner R40 (SUN8I 1701) Model: Banana Pi BPI-M2-UltraThat's just what has been defined in u-boot that will be printed. Will say R40 on a V40 or in this case A40i.
-
1 hour ago, guidol said:
I also doubled the request in their forum
And they delivered. So given this was on the A40i board it's the same as R40/V40/T3 but just different temperature range, different markings and different BU. CPU info is the same with R40 and A40i:
model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 48.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5Ok, doesn't change anything since putting an A40i on a BPi M2U or M2 Berry PCB doesn't make them 'industrial grade' boards (at least different eMMC and GbE PHY needed to to withstand extended temperature requirements). But we know that OS images for R40 and V40 also work with A40i (and of course with T3 too since they're all simply the same)
-
6 minutes ago, hjc said:
I've ordered one just now
I hope you added the heatsink?
My take on 'enclosure' is all those boards landing in a drawer. Since most recent boards generate more and more heat I'm thinking about adding 2 large and silent fans + dust filters in a similar way as shown here: https://forum.openmediavault.org/index.php/Thread/18962
-
44 minutes ago, Simonmicro said:
It seems that the fan spins up at 58°C
These are the relevant log lines:
Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 11:26:57: 200/ 200MHz 0.25 1% 0% 0% 0% 0% 0% 57.0°C 0/3 11:27:02: 200/ 200MHz 0.31 30% 4% 25% 0% 0% 0% 59.0°C 1/3C.St. means cooling state. There are 4 defined in device-tree (and you can change them if you want by adjusting .dts or via sysfs) and if 1 is reached (most probably 60°C defined) then the fan starts to spin. 57°C on a totally idle system are insanely high (comparison with passively cooled HC1) so I would suggest removing the heatsink, checking situation with thermal paste and maybe cleaning both SoC and heatsink and reapplying thermal paste. You'll find several occurences in ODROID forum about bad jobs at the factory ruining thermal efficiency of the fansink.
And if you're already at it maybe replacing the annoying fansink with the much better passive heatsink from the XU4Q.
-
56 minutes ago, Icenowy said:
Of course this makes no difference as mainline U-Boot doesn't try to recognize the print on the chip
Judging by specs A40i could be an R40/V40 with just 1 more USB2 host port. But then I don't understand the pin to pin compatibility (1 more USB host port that is not exposed?). Or maybe it's a simple typo on cnxsoft and A40i is really just a rebranded R40/V30/T3 with different temperature range and another BU in charge?
-
By comparing https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts and https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h2-plus-nanopi-duo.dts the only real difference is replacing the crappy XR819 Wi-Fi with RTL8189 (the other change being H2+ being replaced by H3)
NanoPi Hero also features RTL8189 Wi-Fi, is limited to Fast Ethernet and has an I2C accessible voltage regulator allowing the board to clock at up to 1368 MHz (at 1.4V VDD_CPUX): https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h3-nanopi-hero.dts
Maybe @mindee is so kind to provide an early picture of the latter?
-
2 hours ago, balbes150 said:
Passive cooling system has a number of serious drawbacks
This just works (on RockPro64 -- I did the testing already of course):
-
4 minutes ago, guidol said:
I only asked Lion Wang from BPi at Facebook and he answered
LOL! If that's the case why don't they show a full boot log? That's the only real information and all we need to get a clue about compatibility. Unless a boot log is provided I don't believe anything (especially not when originating from SinoVoip CEO on marketing mission
)
orange pi one general performance? Browser performance?
in Allwinner sunxi
Posted
At least on Raspberries with Chromium, 256 GB 'GPU memory' allocation and h264ify plugin it works HW accelerated (video decoding done on the VideoCore IV).