tkaiser

I give up. A development branch has been created out of nowhere, master has been abandoned and all active work happened in development with nothing 'stable' merged into master any more. At the same time stuff that would need testing still landed in master as part of PRs (so splitting development from master was absolutely useless at all). Zador wasted his time to rebase development few days ago and now in huge commits changes that have been made in development are 'ported' to master? At the same time PRs that destroy the whole build system (and my settings) get merged for no reason... Smells just like a huge waste of time again and again...

Your installation is on 5.45 What Armbian displays with Igor's motd stuff is broken. That's all. The motd routine displays a meaningless version number based on one package's version that does not get updated every time Armbian's version number increases. It's only there to confuse people and generate unnecessary support efforts. Don't expect this to be fixed :-)

(placeholder for a Board Bring Up thread -- now just collecting random nonsense) Board arrived today. Running with ayufan's Debian 9 image (using 1.8/1.4GHz settings for the big.LITTLE cores for whatever reasons instead of 2.0/1.5GHz) I checked for heat dissipation with Pine Inc's huge heatsink first. Huge heatsink combined with thin thermal pad shows really nice thermal values: below 50°C when running cpuburn-a53 on two A53 and two A72 cores in parallel with a fan blowing above the heatsink's surface Board in upright positition still running same cpuburn-a53 task without fan after 20 minutes reports still below 85°C even if heatsink orientation is slightly wrong Summary: passive cooling is all you need and you should really spend the additional few bucks on Pine Inc's well designed heatsink since being inexpensive and a great performer.

Not against this proposal but I fear it won't work that way (at least not now). As you already said there will be support issues with people mounting the heatsink and later on complaining about H5 OS image not running on H2/H3 and vice versa. Same with 'what about Mali and video decoding?!1!!?!' questions (mainline only)... If unnecessary support issues are what Armbian is about... why not? I still wonder what happened... Armbian started as a project of ours to get situation with SBC fixed to fit our needs since vendor OS images were horrible/unusable. Now it's only about what board makers (or their end users) might want?

Agree. Interesting feature set (and my RockPro64 just arrived few hours ago). Also agree on Marvell Armada and hope that we do not only see more designs like ClearFog GT 8K but also some others based on less expensive Armada 7K. Wrt Allwinner... I as many others have fooled myself thinking A20 would be a great SoC in terms of storage performance and a great fit for the NAS use case. When H3 arrived at least the board prices looked interesting (OPi PC for 15 bucks) and once some H3 and later H5 boards were released with Gigabit Ethernet and all 4 USB2 ports exposed we could do some interesting things with those (25 months ago we started to deploy H3 GbE capable boards equipped with some USB attached flash modules in RAID mode to replace huge NAS devices -- based on mainline kernel with early @montjoie Ethernet patches -- still not everything landed upstream which pretty much illustrates why situation with Allwinner SoCs sucks). But in the meantime there's RK3328 with USB3 so really no reason to look at any Allwinner device exceeding $15 any more (for me). It was fun to turn something known as 'overheating and consuming way too much energy' (Allwinner H3) into those Linux SBC with minimal consumption. Learned a lot. But it's 2018 now and almost all Allwinner devices except H6 based are just boring as hell. But obviously it's all about 'use case'. I'm interested in cameras (RPi), sensors (low consumption and as cheap as possible) and servers/NAS (good performance). So more or less done with Allwinner if the board exceeds 15 bucks.

And also https://www.loverpi.com/collections/libre-computer-project/products/libre-computer-board-all-h3-cc?variant=3133794353165 do not look like a supported product. At the time of the Tritium campaign the prices were attrative (especially the little $9 H2+ loss leader) but now with each board being $11 more...

Allwinner H3 was exciting back in 2015 and early 2016. Allwinner H5 was interesting since still inexpensive but full ARMv8 feature set (especially ARMv8 Crypto Extensions). Basically all H2+, H3 and H5 boards are the same: https://forum.armbian.com/topic/1351-h3-board-buyers-guide/?do=findComment&comment=44979 For an Allwinner H device able to draw some attention it needs either to be dirt cheap or needs interesting features like great CPU performance (needs DVFS to go beyond 1.3 GHz) or great amount of DRAM (impossible since 2 GB DRAM are the max) or great graphics capabilities (impossible, only boring Mali 4x0 and limited video engine). The Tritium board (it's just one with 3 different SoCs soldered to it) was designed as an Android TV box without enclosure (closely following Allwinner's current reference design to be able to run their BSP stuff and therefore vendor's Android). No Gigabit Ethernet, no voltage regulation and more expensive than $10. No idea why I would choose this board for which use case... It's 2018 now...

The first and also all the 'better' H3/H5 boards from Xunlong and FriendlyELEC use an I2C accessible SY8106A voltage regulator allowing to adjust voltage in 20mV steps. No real difference to a real PMIC wrt DVFS. The Orange Pi One was the first board with a more primitive voltage regulation scheme only supporting 2 voltages using SY8113B/AX3833 voltage regulators. Then came SinoVoip and forgot voltage regulation on their overheating BPI M2+, later FriendlyELEC decided to drop voltage regulation on their NEO2 since Allwinner's H5 BSP didn't support it any more and that was most probably also Libre Computer's 'motivation' to drop voltage regulation at the same time. But while Allwinner themselves do not support voltage regulation any more with H2+/H3 in their BSP (it has also been removed in their 4.4 kernel code drop) and never supported it with H5 the mainline kernel code that properly implements voltage regulation with both SY8106A and SY8113B/AX3833 without using the ARISC core exists for over 2 years now. In other words: the Libre Computer Allwinner boards are designed to run with Allwinner BSP based OS images (Android / crappy Linux) and not mainline kernel This design decision allows for lower peak performance and higher idle consumption at the same time.

Nope, I won't spend time on this. But since the differences compared to Rock64 are negligible and the only potential Con (powering via Micro USB) can be addressed by adding a warning to the download page I vote for giving the board WIP and later supported status if someone wants to maintain it.

I would prefer to simply pull in the needed bits from Firefly repos but otherwise treat the Renegade just as another member of our rk3328 $BOARDFAMILY relying on ayufan's repos for everything else as we do it already with Rock64. The only differences between both boards are DRAM (initialization) and a few DT bits.

Quick look at network, powering and USB situation (using Firefly OS image / kernel). We have the same annoying xhci messages as on Rock64 (full dmesg output) and also no UAS on USB2 ports. Switching to performance cpufreq governor, mounting my usual EVO840 in a JMS567 enclosure running the usual iozone stuff: random random kB reclen write rewrite read reread read write 102400 4 15831 23674 26796 26832 16945 23613 102400 16 49364 67209 74121 74910 58977 67366 102400 512 276872 286532 297002 306256 296619 301503 102400 1024 302448 315207 318405 329250 321060 320937 102400 16384 337756 340906 347968 359887 359601 339523 1024000 16384 355290 358703 359438 360631 Performance numbers with Rock64 with preliminary kernel support back then (!!) here: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=34185 I power the board through Micro USB as designed but using one of those great Micro USB cables from FriendlyELEC. PSU is 2A rated. A 2.5" HDD in an ASM1153 enclosure is connected to an USB2 port, the EVO840 SSD in the JMS567 enclosure is connected to the USB3 port. Both disks powered by the board. On each disk our usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' call is creating load from the USB consumers (9W), then I added a cpuburn-a53 task. Board rebooted when my Powermeter showed 13.7W consumption which is way beyond Micro USB specs (9W / 1.8A max) and my PSU's (10W / 2A). As expected the board rebooted after ~20 seconds due to underpowering (my PSU being too weak and/or voltage drop -- too lazy to measure for this since it's the vendor's job). Fortunately the board can be powered through the GPIO header too (@ces did a great PSU mod allowing to use a 4A PSU with the GPIO header using pins 4/6 to power the board). Repeating the test my powermeter reported +16W with both disk benchmarks and cpuburn-a53 running in parallel but no problems occured at all. Quick look at network performance: GbE can be fully saturated as expected:

Thanks to @ces who donated his RK3328-CC out of frustration the board is lying now on my desk. Tinymembench numbers with kernel 4.4.114, Debian 9 from Firefly and 1.4 GHz: https://pastebin.com/5CJ94dk6 OpenSSL numbers confirm the 1.4 GHz (same numbers as NanoPi Fire3 and slightly faster than Rock64 clocking at 1.3 GHz) type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 94490.89k 298985.71k 628713.13k 899772.07k 1029215.57k 1038346.92k aes-192-cbc 90576.25k 270158.63k 520800.85k 699573.25k 776418.65k 781172.74k aes-256-cbc 88150.68k 251416.41k 456345.09k 588011.52k 641419.95k 645251.07k I would guess bootloader blobs (DRAM initialization) can be found here https://github.com/FireflyTeam/rkbin/tree/master/rk33? Edit: decompiled rk3328-roc-cc.dtb, seems it's based on rk3328-roc-cc.dts and includes over there.

No idea. The only 'good' SD card that died here so far is a SanDisk Extreme Pro 8 GB I used over 3 years intensively (since both great random IO performance and also sequential performance -- burning cards with up to 80 MB/s in my MacBook was always fun). All the other cards that died were cheap Noname/Intenso/Kingston crap.

But unfortunately the contents still are no technical documentation but simply random nonsense. I mean, a board vendor designs a board with a SoC capable of 3 PCIe Gen2 lanes. One lane is used to attach the usual ASM1061 PCIe SATA controller providing 2 SATA 3.0 ports. And this stuff ends up in the boardmaker's own wiki described as USB attached (wrong) SATA 2.0 (wrong) with only one SATA port populated on the PCB while the other is optional (wrong) While this board maker clearly doesn't support his own hardware with such stunts it also means we can not trust in anything written there. It's not a technical writer providing information/documentation filling that wiki but someone doing funny copy&paste jobs assembling random words and numbers to meaningless sentences describing nothing. No progress at all I hope you call the BOARDFAMILY mt7623 later. As far as I know at least ACT POWER plans to release another MT7623 device focused on NAS use case soon and maybe they're willing to support their own hardware and provide technical documentation. Edit: At least some of this nonsense has been corrected in the meantime. But that's not how it works. A board maker should not need random community members to spot the really obvious mistakes in his 'technical documentation' but provide correct information in the first place. That's just bizarre. I mean what's the purpose of telling users a device can be powered by 12V/2A and 5V/2A (even through Micro USB) on the same page? Why not simply starting to take care of correct information and providing technical documentation that we can rely on?

If I understood @zador.blood.stained correctly he would prefer splitting this up in a more granular way. Currently we have the following functions in the script (the ones that can remain in armhwinfo marked with an X): collect_information X set_io_scheduler prepare_temp_monitoring X prepare_board log_hardware_info X get_flash_information X show_motd_warning X check_sd_card_speed X add_usb_storage_quirks activate_zram So prepare_board, set_io_scheduler and add_usb_storage_quirks could go into an armbiansetuphw service and zram could be handled by armbianzram (I really would prefer to prefix all our services with armbian so users get a clue what's plain Ubuntu/Debian and what's Armbian). Yes, but please see @zador.blood.stained's objections. I'm fine with any way as long as it's configurable and able to be disabled. The log2ram functionality would then have to implement a fallback mechanism to what we use today (check for /dev/zram0 whether it contains a freshly created btrfs filesystem. If yes use it, otherwise do the fallback to tmpfs) It's worse also for another reason: Recompressing already compressed stuff usually wastes more storage space. An uncompressed 10 MB log might end up being a 1 MB .gz file or as uncompressed file using 1.5 MB DRAM on an lzo zram device. But the 1 MB gzip version might need +2 MB on the same lzo compressed zram device. So it's not just a waste of CPU cycles but also inefficient DRAM use.

A 'new' wiki? The product pictures show early board revs from over one year ago that never got sold (showing one SATA port as optional, different SATA power ports, different layout of WAN/LAN ports, battery connector that is of no use, DC-IN is labeled '12V/2A' while it reads directly below '5 volt @2A via DC Power and/or Micro USB (OTG)'). Is this technical documentation or a joke? I started reading this section http://wiki.banana-pi.org/Banana_Pi_BPI-R2#Hardware_spec but already stopped after 7 lines of which 4 are wrong (more than 50%): 'Quad-code ARM Cortex-A7' -- copy&paste as usual from their forum 'Two SATA 2.0 Port (USB-to-SATA bridge)' -- as far as I know that's not USB but PCIe based and an ASM1061 (providing SATA 3.0)? 'MTK6625L chip' -- does not exist 'resolutions up 1920x1200' -- according to SoC manual it's 1920x1080 instead So unfortunately still no technical documentation but just the careless 'copy&paste gone wrong' weirdness this SinoVoip employee is 'famous' for. Still zero progress :-(

Well, switching from tmpfs to an already existing zram block device that has been prepared before is most probably the easy part. Prerequisit to use such a zram device would be refactoring at least armhwinfo (so that armhwinfo eventually again only does what the name tells: collecting and logging information). All the stuff that configures/optimizes should end up in own services that can be configured in a sane way so that user changes do not get lost with next update. No idea how to do that though Then the whole zram idea needs a solution since in case we reinvent the wheel and create zram devices on our own (which seems like the only way to get zram for logs to me) we need to deal with the existence of other zram related services (e.g. zram-control package in Ubuntu) And I fear the part that needs most attention is logrotate and how to interfere with. Moving old/compressed logs into RAM is no good idea at all, also moving logs compressed by logrotate from RAM to 'disk' and free RAM afterwards seems like the only sane way to me. But I've no idea how this could evolve without reinventing the wheel again and implement logrotate functionality on our own now being aware of two filesystems to use instead of one. Maybe the use of symlinks helps? The initial sync from storage to RAM does not copy old/compressed contents but creates them as symlinks to the /var/log.hdd/ variant. And then a cronjob monitors /var/log and as soon as there appear rotated logs they're moved over to /var/log.hdd and are replaced with symlinks. Active logfiles are treated differently and simply rsynced on a per file basis to /var/log.hdd

OPi PC2 has just one GB DRAM so trying to use 8 GB zram won't work. The average compression ratio I've seen in all tests so far was between 3:1 and 3.5:1 and also zram needs a small amount of DRAM for itself. So zram using 3 times the available RAM can be considered maximum and might even fail already when memory contents aren't compressable at such a ratio. If you look at page 1 of this thread you'll see that using an UAS attached SSD is the way to go in such situations. And maybe switching from zram to zcache when you want to use both DRAM and storage for swapping. Configuring zram and 'disk' as swap at the same time has some caveats.

Sorry, but data retention times are something entirely different: how long remains data readable on an inactive SD card (storing data offline). This is not the use case we're talking here about. But of course you're right and small boards with heat dissipation through the ground plane have an issue with SD card temperatures.

The current use of tmpfs is just wasting resources. Logs are highly compressable so a zram based improvement is able to reduce waste of resources by 5 to 10 times.

Nope. Just testing through zram efficiency: https://forum.armbian.com/topic/5565-zram-vs-swap/?do=findComment&comment=54725 Limiting count of CPU cores to reduce idle consumption is pretty much useless. My h3consumption approach allowing to limit count of active CPU cores is only about limiting 'worst case' consumption (something went wrong and there's a task utilizing all CPU cores -- in idle there's almost no difference whether there are 1, 2, 4 or 8 cores active. ARM guys are not stupid and implemented sorts of powermanagement ages ago)

I experienced the same when playing with 4.14 on a NanoPi Fire 3. So maybe it's a problem of this kernel release? Anyway, I ended up adding extraargs="maxcpus=2" to /boot/armbianEnv.txt and rebooted to get a dual-core system.

It's stupid to combine routing/firewalling with NAS and multimedia stuff on the same device. On a router/firewall you do NOT want to increase attack surface by unnecessarily running any unneeded services (especially no graphics stuff). Also you usually do NOT want to expose your NAS to the whole world (security best practices). Have you ever seen a RealTek SDK? Yeah, me neither. The W2 is a 'closed source' thingie (running Android and a chrooted OpenWRT/Linux inside) and the R2 might maybe supported sometimes in the future if mainline kernel support evolves and someone wants to spend his spare time on a questionable device (again: you do NOT want to combine routing/firewalling with NAS and multimedia stuff on the same device)

It is totally broken: Unsafe temp file handling Incompatible to Armbian's recommended way to setup Wi-Fi (nmtui/nmcli) It stores the Wi-Fi credentials in cleartext in a world readable file It's a mystery to me why you ever accepted this code as PR, we agreed on deleting it already (now that DietPi doesn't use Armbian as 'pre-image' any more) and now you start to recommend this stuff to users? Only sane way would be to allow to create a NM profile only readable by root below /etc/NetworkManager/system-connections/ -- since this does not exist users either need to use serial console (easy on OPi Zero since available through Micro USB) or keyboard/display.

Yep, I agree (especially since Fire3 clocked down to 1.2GHz scores around 51m with zram so the 77 minutes seem just wrong). In the meantime I started over with my Fire3 and tested through different values of vm.swappiness and count of active CPU cores (adding e.g. extraargs="maxcpus=4" to /boot/armbianEnv.txt) using this script started from /etc/rc.local. I tested again with lz4 and 2 CPU cores another time since first run results looked bogus: Timestamp vm.swappiness cores algorithm execution time Sun May 20 12:45:12 UTC 2018 100 8 lzo [lz4] deflate lz4hc real 47m53.246s Sun May 20 13:34:26 UTC 2018 80 8 lzo [lz4] deflate lz4hc real 48m9.429s Sun May 20 14:23:55 UTC 2018 60 8 lzo [lz4] deflate lz4hc real 48m25.700s Sun May 20 15:13:40 UTC 2018 40 8 lzo [lz4] deflate lz4hc real 49m40.919s Sun May 20 16:05:17 UTC 2018 100 4 lzo [lz4] deflate lz4hc real 86m55.073s Sun May 20 17:33:34 UTC 2018 80 4 lzo [lz4] deflate lz4hc real 87m50.534s Sun May 20 19:02:49 UTC 2018 60 4 lzo [lz4] deflate lz4hc real 88m43.067s Sun May 20 20:32:55 UTC 2018 40 4 lzo [lz4] deflate lz4hc real 98m43.243s Sun May 20 22:15:55 UTC 2018 100 2 lzo [lz4] deflate lz4hc real 148m58.772s Mon May 21 00:46:19 UTC 2018 80 2 lzo [lz4] deflate lz4hc real 146m58.757s Mon May 21 03:14:40 UTC 2018 60 2 lzo [lz4] deflate lz4hc real 147m3.493s Mon May 21 05:43:08 UTC 2018 40 2 lzo [lz4] deflate lz4hc real 155m22.952s Mon May 21 08:20:34 UTC 2018 100 8 [lzo] lz4 deflate lz4hc real 46m56.667s Mon May 21 09:08:59 UTC 2018 80 8 [lzo] lz4 deflate lz4hc real 47m25.969s Mon May 21 09:57:58 UTC 2018 60 8 [lzo] lz4 deflate lz4hc real 47m45.961s Mon May 21 10:47:16 UTC 2018 40 8 [lzo] lz4 deflate lz4hc real 48m14.999s Mon May 21 11:41:36 UTC 2018 100 4 [lzo] lz4 deflate lz4hc real 85m24.440s Mon May 21 13:08:31 UTC 2018 80 4 [lzo] lz4 deflate lz4hc real 85m47.343s Mon May 21 14:35:44 UTC 2018 60 4 [lzo] lz4 deflate lz4hc real 85m59.063s Mon May 21 16:03:11 UTC 2018 40 4 [lzo] lz4 deflate lz4hc real 86m49.615s Mon May 21 21:53:07 UTC 2018 100 2 [lzo] lz4 deflate lz4hc real 143m1.995s Tue May 22 00:17:40 UTC 2018 80 2 [lzo] lz4 deflate lz4hc real 144m0.501s Tue May 22 02:43:08 UTC 2018 60 2 [lzo] lz4 deflate lz4hc real 144m37.204s Tue May 22 05:09:14 UTC 2018 40 2 [lzo] lz4 deflate lz4hc real 146m51.361s Tue May 22 07:56:42 UTC 2018 100 2 lzo [lz4] deflate lz4hc real 147m15.069s Tue May 22 10:25:33 UTC 2018 80 2 lzo [lz4] deflate lz4hc real 147m31.538s Tue May 22 12:54:31 UTC 2018 60 2 lzo [lz4] deflate lz4hc real 147m27.517s Tue May 22 15:23:28 UTC 2018 40 2 lzo [lz4] deflate lz4hc real 150m54.700s So as expected with zram based swap increasing vm.swappiness to the maximum helps with performance in such memory overcommitment situations like doing this huge compile job (Arm Compute Library) that needs up to 2.6GB with a 64-bit userland -- just 2 GB when doing a 32-bit build). And for whatever reasons at least with kernel 4.14 and defaults lz4 does not perform better compared to lzo, it's quite the opposite and with lzo the jobs finish even faster.