Tido

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.

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

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 :-(
 

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/rk3288.dtsi?id=4e943a890cef42e90f43ce6be64728a290b97c55
 
We are talking about mainline (next branch), right?

Well, it's not just the script, it is also all the debs that are packaged with it, so I don't want to upload files unnecessarily,  if I am going to upload a new version in a few hours. I have some free time now, so I'll try to get it ready, and if not, then I'll upload it as it is now.

Follow-Up on https://www.cnx-software.com/2018/05/13/how-to-get-started-with-opencl-on-odroid-xu4-board-with-arm-mali-t628mp6-gpu/ 
 
It's about a compile job requiring up to 3 GB memory. Jean-Luc tested on an ODROID-XU4 with 2 GB RAM so he had to add 1 GB swap since otherwise compilation failed.
 
It's 2018 and we all should know that swap on HDD is anachronistic or even stupid. But Linux users still do it since they did it already one or even two decades ago.
 
Time for a 'quick' benchmark: I test on a board that is even more limited with regard to physical RAM:  It's a freshly arrived NanoPi Fire3 with eight A53 cores but just 1 GB RAM so very likely to run in out of memory situations with compile jobs running on all 8 cores in parallel.
 
I used an Armbian Stretch image running with kernel 4.14.40 and configured 2.5 GB swap (either as /var/swap or zram). Also vm.swappiness is set to the default (60). 

When compiling the job I've seen over 2.3 GB swap being used while building with zram with an average 3.5:1 compression ratio:
 
root@nanopim3:/home/tk# zramctl  NAME       ALGORITHM DISKSIZE   DATA COMPR  TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4         495.3M 370.1M 99.3M 104.5M       8 [SWAP] /dev/zram1 lz4         495.3M 370.2M 99.4M 104.5M       8 [SWAP] /dev/zram2 lz4         495.3M 371.3M 99.8M   105M       8 [SWAP] /dev/zram3 lz4         495.3M 368.8M 99.1M 104.2M       8 [SWAP] /dev/zram4 lz4         495.3M 370.2M 99.4M 104.5M       8 [SWAP] First tests were with zram (trying to compare lzo with lz4), then I used a swap file on ext4 formatted SD card (a fast A1 rated one and not 'the average SD card' showing magnitudes lower random IO performance). Afterwards I tested with an older 7200rpm notebook HDD and then a Samsung EVO 840 both attached via USB2 without UAS support (so both random and sequential IO are bottlenecked by USB2 -- 'typical SBC conditions'). Filesystem used was a freshly created ext4 so no performance difference between swap file and partition.
 
Benchmark execution as follows: I deleted the working directory, then untared the archive (see above) and then let the following run:
time scons Werror=1 -j8 debug=0 neon=1 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a build=native Results:
zram lzo                  46m57.427s zram lz4                  47m18.022s SSD                      144m40.780s SanDisk Ultra A1 16 GB   247m56.744s HDD                      570m14.406s  
Using zram is a no-brainer. The job finished within 47 minutes with both lzo and lz4 compression scheme. When testing with swap on real storage for obvious reasons the SSD won (best random IO performance), then the A1 rated SD card could finish the job in 4 hours and of course swap on HDD failed miserably since spinning rust simply sucks when it's about random I/O performance. Swap on HDD is BS.
 
A device with 1 GB physical DRAM is able to perform a build job requiring 3 GB memory within 47 minutes when using modern approaches (zram), when doing it like we did it last century (swapping to storage) then it's all about random I/O performance. A great performing SSD even if bottlenecked by USB2 is able to finish the job in less than two and a half hours. An el cheapo SanDisk Ultra A1 SD card with 16 GB scores 4 hours while as expected a 7.2k notebook HDD takes almost 10 hours to do the same job. HDDs suck at random IO. Period.
 
What can we learn from this? Nothing since Armbian is only focused on adding more and more irrelevant boards to the build system instead of improving situation for all boards.
 
As a reference iozone numbers for the 3 storage scenarios:
SanDisk Ultra A1 random random kB reclen write rewrite read reread read write 102400 4 3677 3856 9344 9320 8070 2787 102400 16 3890 7780 16398 16216 14832 6716 102400 512 9925 13902 22494 22501 22411 13178 102400 1024 13826 13750 22651 22649 22640 13792 102400 16384 14031 13936 23141 23137 23163 15395 Hitachi 2.5" 7200 rpm random random kB reclen write rewrite read reread read write 102400 4 7537 9837 8016 7763 671 1119 102400 16 17452 20618 20852 20997 2522 4250 102400 512 33123 33403 34165 34756 25589 32262 102400 1024 33580 33310 34331 35056 29620 33148 102400 16384 32592 33804 34921 35591 35277 33838 Samsung EVO 840 SSD random random kB reclen write rewrite read reread read write 102400 4 7322 9481 9636 9682 7433 9496 102400 16 16654 19453 18576 18639 18301 19370 102400 512 31296 31489 32778 32876 32977 31337 102400 1024 31016 31986 33334 34283 33991 31273 102400 16384 30600 31336 33318 33678 33236 31913  

We dealt with this problem for quite a long time.  It started out on tinkeros which prompted us to try armbian... which didn't work any better.  I worked with an asus engineer who determined that the disconnects were because of network-manager scanning for a better connection.  While the problem is likely not network-manager itself and rather how the drivers handle it, there are a few work arounds.  Asus suggested setting the bssid which we tried and it did not help.  There is also a patched version of network-manager called network-manager-noscan which supposedly fixed this problem.  I never tried it.  We switched to wpa_supplicant and have 100% success staying connected.  We don't want the end users messing with the network-manager settings anyway which show up in the task manager by default.   Read the section in the link below titled "Regular network disconnects, latency and lost packets (WiFi)"
 
https://wiki.archlinux.org/index.php/NetworkManager

@balbes150, hello !
 
What build is the most suitable for daily use, just install, setup and forget about it for months :) ?
 
 

Today's nightly or build from development branch:

- packages cleanup and reorganize: removed Libre writer and Thunderbird from the default desktop install. This brings CLI < 1G and desktop < 2G.
- many bugfixes, enhancements and new software added to armbian-config https://github.com/armbian/config/blob/development/README.md
- fixed FriendlyARM M3 kernel
- wireless for Z28PRO
- removed HDD temperature from MOTD
- many upstream changes for Espressobin kernel(s)
- Odroid DT blob switching was added to the armbian-config. This speeds up boot process and lower consumption on HC1/HC2
- docker building improved
... more changes will be found at the merge
 
Tomorrow website launch ... then:
- merging patches to the stable
- testing
- testing
- fixing
- testing
- testing
- fixing

There is a great variety of different builds of KODI and Libreelec for different platforms (x86 , ARM, etc) and different models. This is a different system, description, for some not suitable to others. To operate your remote control, you need a settings file. See the example files (remote.conf) on a recorded medium. For KODI-17 from the composition of Armbian, the file must match the format of the driver amremote. For KODI-18, this is a different format (lirc).

To be fair I think a capped blob is acceptable to everyone, as long as it is answering to the kernel and is accurately reporting it's behavior.

Or it could be pushed into a separate branch, stay there while it needs testing, and then squashed into one commit and merged to master. While master is currently set to protected so it is not possible to change existing commits,  commits in other branches may be rebased, squashed or amended if necessary.
 
We could still create temporary topic branches on demand (i.e. sunxi-next-4.17) for large change sets.

Well, it comes with a barrel power jack which is nice, but for US $56.00 / piece plus shipment. Quite expensive and I guess no Battery-Connector is in the box :-(
 
Allwinner R40 -- some already available information
https://forum.armbian.com/topic/2169-allwinner-r40-some-already-available-information/
 
The new Banana PI M2 Ultra
https://forum.armbian.com/topic/2884-the-new-banana-pi-m2-ultra/
 

First of all, I appreciate your fast answer.   And that there's clarification inside your team.
 
 
I don't think that he would have a problem that you use his code. But in his version there was a small add on top:
 
For me, there's no reason to remove this small credit part.  

Right.  There won't be much hacking involved, I could replace the "add tritium H3" patches and support all 3 fairly easily, they share the entire device tree, only difference board to board is the board/SoC compatible, and at the latest I think 4.18 will support them without patches.  Other than the unexpected appearance of unknown hardware bugs, these boards are quite literally the SoC, the PMIC, the RAM, and the various plugs.  The support question comes down to dealing with the typical micro-USB issues, and probably folks who don't know which board they have since they are all exactly the same looking... 

Good news about the new webpage.
 
I also have some good news about RK3288 media implementation: I finally got rkmpp accelerated mpv to work. It works really well, better than Gstreamer, although only in fullscreen. It's a real "Armbian premiere", no other distro implements it so far, neither ASUS' nor Rockhip's own. In the next days, I'll try to put that with some other new goodies into a script, and keep it available there until it is possible to integrate it in the main build script.

OK, development branch will reflect the change, on existing installations you will have to manually add
console=ttyS3,115200n8 to the armbianEnv.txt file in /boot.  I did a tiny bit of house cleaning as well, putting the Tinker u-boot patches into a board-specific directory so they don't impact the MiQi.

Very nice.  They dropped the 5V barrel jack though I see...

Release the libVA improvements when the kernel driver patch series is ready for submission, sometime next week. read more here: https://bootlin.com/

Tested on MiQi, Igor merged to the development branch.  A quick minerd --benchmark showed 7.1 khash/sec, I had just updated to the previous config 4.16.0 and had tested (same rootfs, only kernel differed) at 6.9 khash/second.  All things were constant other than the kernel config.
 
Thank you!

Hi Board,
 
I have submitted a PR a few minutes ago to Build repo (https://github.com/armbian/build/pull/927) removing some drivers that WILL NOT load in RK3288, because they are specific to other SoCs / Architectures.
 
I also took the opportunity to convert a batch of drivers / machines to modules, in order to alleviate the kernel size and squeeze some performance (because some of the loaded stuffs does effectively consumes CPU). Well, that's what modules are meant for, right?
 
The patch was crafted to DEV version. Need more extensive Tinkerboard tests (did not test the GUI) and MiQi (not tested at all, I lack the hardware).
 
Have a great week,
 
- RF.

Hello @freak,
 
How about try below method to get the actually current system Voltage?

 
that would more close with the true voltage. (But cannot get the current)
Also if measuring voltage between PSU and Cable, it would miss the Cable’s effect.
(if cable also cause the voltage drop…)

Hello all.
I've made a video about the Rock64. I've tried different distro's, but Armbian was the best for me.
The only problems I've found was that Synaptic Package Manager didn't work. It crashes when I press the search button. And sometimes surfing was extremely slow. Otherwise it did fix all the problems I've had with the other distro's I've tried.
Thank you for all the great work.

Now I've started my research with the Orange Pi +2, and again Armbian is the best choice.
Greetings, NicoD

Here is my video.

 

Well, if Xunlong didn't change any markings on the board (especially the revision number) then it gets pretty nasty
 
Compile the list of affected devices first (i.e. by contacting Steven), then put the notice regarding possible instability for newer boards on board download pages. After that there are different ways to limit the top CPU frequency, but there are multiple things to check and change - default in-kernel governor, OPPs in FEX and DT, /etc/default/cpufrequtils

Okay, I knew your board was missing something, but I couldn't point what it was. I think I finally got it:
 

 
That makes it perfect! Don't you think so?