tkaiser

Just for the record: These 65°C are just a number set here: https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi#L158 Ondrej used this and the other numbers when he started to code DVFS/THS stuff last year, AFAIK no one so far has looked into H3 thermal/throttling stuff from a user perspective ('Are these settings sufficient') and the only time I looked into it it was pretty obvious that the way throttling currently works with mainline kernel on those boards with primitive voltage regulation (switching only between 1.1V and 1.3V) is worse compared to BSP/legacy kernel.

Get an Armbian **DESKTOP** image, do a 'sudo apt install hfsutils' and try again. Also try again uploading debug log (the first time it failed for whatever reasons since the online pasteboard service resetted connection -- happens sometimes so just try it again). BTW: I'm a macOS user, do a lot of storage and filesystem related stuff and would never try to access HFS+ from Linux (driver support is too limited and feature compatible to HFS+ used in maybe OS X 10.5 or something like that)

Same with me. I already knew that 'Wi-Fi benchmarking' in overcrowded 2.4 GHz band is just plain stupid but did it to verify results and being able to send new users who believe in miracles to IMO the most important lesson to learn when thinking about 'Wi-Fi performance' is to avoid 2.4GHz band if you live where other people also live and also to avoid single antenna stuff. So it starts to get interesting when switching to 5 GHz and at least 2x2 MIMO. Antennas also matter. Since yesterday on most next platforms an USB attached RTL8812AU dongle seems to be the best choice if you're thinking about wireless 'performance'. What you were talking about (reliability and availability) seems not related to performance at all to me. But I would also add 'distance' to this since related (when a BPi M2 Berry for example with its crappy onboard aerial already loses connection to the AP 10m away then both reliability and availability are directly affected)

@Igor and @zador.blood.stained: I thought about bundling mmc utility from mmc-utils package already but did not found a debian package. Building from source results in these times (Clearfog Pro): time (git clone https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git ; cd mmc-utils ; make -j$(grep -c processor /proc/cpuinfo) ) ... real 0m4.989s user 0m7.035s sys 0m0.413s Size of the binary is below 300K. Any chance to bundle this somehow with an Armbian package so I could include output from it in a future armbianmonitor -U (capital U) version?

Well, I don't know if adjusting these 3 values in the way they are set now everywhere was much by intention and not just by accident. By looking at a lot of similar values (like CPU frequency steps, DVFS OPP or DRAM clockspeeds) in the meantime I came to conclusion that whoever defines them in the first place can do almost what he wants (numbers not being questioned) while later it needs an insane amount of discussions/efforts to change such numbers again. After thinking somewhat about it given the PSU's 3A limitation and people probably attaching even a host powered USB disk to their Pinebooks having pmu_runtime_chgcur set that high seems questionable to me. These were the values we started with: pmu_runtime_chgcur = <0x1c2>; pmu_suspend_chgcur = <0x5dc>; pmu_shutdown_chgcur = <0x5dc>; And that's where we're now: pmu_runtime_chgcur = <0x708>; pmu_suspend_chgcur = <0x5dc>; pmu_shutdown_chgcur = <0x5dc>; (only change: increasing charge current on a running system from 450mA to 1800mA while not touching the other values).

I just compared the GPIO pinouts of the Core with NEO / Air and it seems you designed the Shield for Core / Core2 in a way that even NanoPi Air can be used with it (though no Ethernet of course since pins not connected but M.2, the externally available USB ports and Microphone and audio out seem to be usable):

Which is obviously wrong since removed packages might leave config files behind (purge would remove those too). Maybe relying on 'dpkg -s' is a better choice eg. by parsing output from: dpkg -s samba 2>/dev/null | awk -F": " '/^Status/ {print $2}' For an installed Samba this will result most probably in 'install ok installed' (first word the desired state, last one the current state, this relates to the first three characters spitten out by 'dpkg -l' but in different order -- see this summary for example). If Samba is not installed (but config file existing since only removed but not purged before) then the string will be empty. If Samba install is somehow broken (mismatch between first and last word and something different than 'ok' in between) an appropriate choice would be to inform the user to fix installation manually?

Sorry, but there is exactly NOTHING tailored for Tinkerboard, it's just the same thing as this RPi add-on for €5 less: https://shop.olmatic.de/de/usv-raspberry-pi/2-susv-pi-advanced-4260434190029.html -- most probably you pay €5 more since they needed to replace a Raspberry symbol with a Tinkerboard logo in their advertisements and on product packaging. Raspberries are based on a TV box SoC, have no PMIC and so you need such expensive 'UPS' add-on boards if you want to run Raspberries from battery. Tinkerboard is based on a tablet SoC combined with an appropriate PMIC (power management IC capable of charging / control a battery). If the Tinkerboard would not be such a horrible design fail all that's needed there to provide 'battery capabilities' would be a battery connector attached to the PMIC (and maybe some boost converter somewhere). The RK3288 is made for tablets and laptops (Chromebooks) designed to run mostly from battery, it's almost insane to combine a RK3288 based board with faulty power design with such an expensive battery thingie. To get the Tinkerboard powered reliably all that's needed is just either desoldering the shitty Micro USB jack to replace it with a more suitable barrel connector or to power it with suitable cables through GPIO pin header in the first place (using 2x5V and 2xGND pins). This will both prevent undervoltage situations and crappy Micro USB equipment melting once you need to feed more than 2.5A continually.

Please give it a try once you get back to your R1. BTW: this is how R1 should've done it from the beginning (since even A20 already features two Ethernet ports): https://groups.google.com/forum/#!topic/linux-sunxi/sDXfamLUodw (Stefan is an Olimex employee)

What about a TV box (or as Allwinner calls it'targeted at the OTT, DVB and IPTV markets')? If the IR receiver in the picture above would move a few mm next to the GPIO header all that's needed for a TV box would be a small enclosure around. This thing can encode/decode video with Allwinner's 'Phoenix' video engine and most probably stuff like picture in picture is possible (most probably using the HDMI input). It's said that a lot of IP blocks have been updated/exchanged (bad news for linux-sunxi community mainlining efforts) but the good news is that @jernej already checked latest Allwinner BSP drop and it's at least blob free if I understood correctly. Besides that a lot of users will happily ignore both HDMI ports and are only keen on USB3 and PCIe performance This SoC seems to be suited both for media player and NAS purposes (unsurprisingly new 4-bay Synology DS418 is also based on RTD1296 -- curious how 2 SATA ports and 4 disks match) but the most interesting question as usual is the one about software support. If BPi people repeat what they did with their latest 'non Allwinner' adventure (over half a year providing neither any useful information nor the sources/manuals they already had from MediaTek) then we might know maybe in 2018...

Did you already try to set 'console=display' in armbianEnv.txt (see bootscript for the difference please)

Yes, check DT for pmu_runtime_chgcur, pmu_suspend_chgcur and pmu_shutdown_chgcur. @Xalius (who came up with increased pmu_runtime_chgcur value in the beginning) collected some information here https://forum.pine64.org/showthread.php?tid=1430

What do we know now? Not much -- most importantly that some details will change and 'board available soon'. We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them ) So all we know is really just: H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo) One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)

These are the DT bits they use: https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts#L412-L420 And then it needs the relevant code to let the magic work (Jared from FreeBSD/NetBSD discovered this and shared his wisdom with linux-sunxi kernel folks -- of course this needs some code also and as already said: DT bits have to match kernel version and the necessary patches must also be present -- no idea whether that happened already upstream for H5 or not)

No, since they 'do their own thing'. It would be different if FriendlyELEC would try to send their work upstream but they just chose a mainline kernel version suitable for their needs, a branch from Icenowy with most patches they needed included, and then considered this being their private thing. They even patch stuff broken to be compatible to Allwinner's smelly legacy kernel (see this as an example -- I gave up immediately after). This 'we do our own thing' attitude has other downsides too (eg. their own board detection uses a different way to configure DRAM clockspeeds and the values in u-boot config are unused/wrong. Now these wrong values are submitted by open source community members upstream and in the end we as Armbians strangely being the only ones around caring about such details have to add patches for this to our build system later). In other words: trying to keep up with this is a huge waste of time and it will be done when it's done

No, DT and kernel version have to match. FriendlyELEC obviously chose to remain on 4.11.2 (at least for now -- maybe they just started with 4.11 since Icenowy's kernel branch was at this version back then and will switch over to 4.14 once released... 4.14 is said to be the next LTS -- long term support -- kernel release). Armbian currently switched to 4.13. All this stuff is a moving target and you'll (we'll) waste huge amounts of efforts and time switching between versions (updating). As already said: No one from us has the production board revision and such minor problems are low priority anyway. I fear if you can't fix it yourself (without extensive guidance) then all you can do is to wait. In the meantime there are 2 more USB ports on the GPIO header to be used.

Ah, I remember. What you refer to as the 2nd USB port is usb0/OTG exposed as a type A receptacle on the Plus 2. So most probably not only a matter of device tree but also patches to turn OTG port into real host mode (Allwinner H3 and H5 can attach usb0 to either an own OTG controller or to a 4th OHCI/EHCI controller pair)

That's the reason why anyone permanently dealing with this shit show called 'powered by Micro USB' gets annoyed sooner or later. You can attach whatever you want with an amperage rating as high as some thousand amps to a Micro USB port and it won't help since it's not about amperage but about voltage drops. In my opinion boards with a boot peak consumption above 800mA that use this shitty Micro USB connector by default should be phased out. You either had luck so far or by chosing a PSU that is advertised to power shitty devices by design you chose one that is prepared to compensate for the Micro USB voltage drops (then it's a 5.25V PSU and not a 5V PSU). But even if your PSU is prepared for those voltage drops the situation with Tinkerboard is still just a shit show since Micro USB is not specified for anything higher than 1.8A -- just grab a magnifying glass and look at those laughable tiny contacts. If you like pictures like that below just give it a try to overload these tiny contacts with a 3A load. Please take a video and upload it somewhere so we can all have a laugh.

It uses /etc/armbianmonitor/datasources/soctemp which is a symlink created at boot trying to use the correct temperature source (there's some confusion and changes wrt RK3288 kernels going on -- you might follow this and check available thermal zones yourself)

@gdm85 what about doing this? Checking device tree contents (nodes below /proc/device-tree/), checking how this stuff works (for NanoPi NEO Plus 2 we use upstream settings and none of us has the right hardware since the dev samples sent out months ago have nothing to do with production hardware now), checking out how the build system works and where patches have to be applied and then submitting the necessary patches. Only alternative: waiting. All H5 boards share the same kernel config so it's pointless looking into since the differences are DT.

I have one Orange Pi Zero which had Wi-Fi working in the beginning and after some days Wi-Fi stopped working. I'm always surprised that hardware that cheap as an Orange Pi Zero works in the first place. I remember the last thing I did before realizing that I had broken Wi-Fi on my Zero was taking a nap (you remember the last thing you did was trying out another kernel). But I don't think me taking a nap is related to hardware becoming broken.

https://irclog.whitequark.org/linux-sunxi/2017-09-12#20136223;

Thank you, then it's not just me. And there is something wrong: https://github.com/armbian/build/blob/8d211eec2c15feb1e77d8dee7bf45ee7ef645eab/packages/bsp/common/etc/profile.d/check_first_login.sh#L13-L32 With psd active your Chromium performance will increase by magnitudes.

Edit: 'Benchmarking gone wrong' warning: by accident I missed iozone's -I flag below ('Use DIRECT IO if possible for all file operations. Tells the filesystem that all operations to the file are to bypass the buffer cache and go directly to disk') so all read numbers with 100MB test size are wrong since coming from DRAM and not disk) Final update: I asked the guy with BPi M2 Ultra, JMB393 port multiplier and 'my' kernel (it's really just repeating what I did already 3 years ago with the original Banana Pi) to run also the 'usual benchmarks' (see this post for details): random random kB reclen write rewrite read reread read write 102400 4 19027 19675 221183 246677 238654 7974 102400 16 18808 20857 259049 295393 278568 11913 102400 512 18999 21123 261343 310472 312191 15584 102400 1024 18682 21194 262045 294879 294856 19896 102400 16384 19199 20180 260566 306555 309892 20345 4096000 4 20412 21239 86094 85480 1508 1664 4096000 16384 20325 21326 86195 83331 78942 20452 The last two runs were with 4GB filesize since BPi M2 Ultra has 2 GB of DRAM so to prevent kernel buffers tampering the results it's necessary to test with at least twice the DRAM size. As can be seen above all read results with just 100 MB filesize are BS since way too high. This is buffering/caching at the mdraid / block device layer due to missing '-I' iozone parameter. Realistic throughput values with a RAID5 consisting of 3 disks behind a PM connected to 'Allwinner SATA' is 20 MB/s write and 85 MB/s read. Random IO depends mostly on the used drives (so as soon as you don't test with SSDs only everything will slow down as hell) but the inability to use FIS based switching with port multipliers lowers numbers too. So with R40 it's still a horribly bad idea to use SATA port multipliers and especially RAID since it's not only slow as hell but also highly unreliable (those cheap PM are excellent at eating data when overheating under constant load). If one wants to play RAID5 with such a Banana M2 Ultra the way better idea is to throw the PM into the bin and attach one disk to SATA and two to the USB host ports. Write performance will increase from 20 up to ~75 MB/s (if mainline kernel might be ready next year maybe 80 MB/s) and read performance will climb from 85 MB/s to 110 MB/s maybe. You'll get the same numbers with every cheap NanoPi or OrangePi that feature three real USB2 ports too of course