tkaiser

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).

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

That's what I observed, the lights simply went out. 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.

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:

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 20007 I 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

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...

You would need an USB-A-to-USB-A cable.

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!

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.

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. 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) 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.

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.1 Problem solved I would say...

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, -17 Hmm... that's bad. Due to different ways @ayufan deals with DT includes and 'the others' (RK kernel consumers) do I wonder how to proceed.

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.

Tried a fix with https://github.com/armbian/build/commit/f10acc0080825faf711eb6e6b7425910d75d840c Would be great if you could try next nightly version and report back.

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/

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

This query has been answered by a DNS resolver running on your laptop. 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.

Are you referring to this? CPU: Allwinner R40 (SUN8I 1701) Model: Banana Pi BPI-M2-Ultra That's just what has been defined in u-boot that will be printed. Will say R40 on a V40 or in this case A40i.

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 : 5 Ok, 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)

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

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/3 C.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.

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?

This just works (on RockPro64 -- I did the testing already of course):

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 )