Tido

Thank you Neil, I have them in the development branch, testing out the basic stuff.
 
I also updated the 4.14 patchset to reflect your latest changes, tested out the new video modes on a couple monitors, no problems.  @Tido will be pleased, as long as his monitors support
 
- 640x480@60Hz - 800x600@60Hz - 1024x768@60Hz - 1152x864@75Hz - 1280x1024@60Hz - 1600x1200@60Hz - 1920x1080@60Hz  

I made an updated build, with the current master branch from the Rockchip repo.  I noticed we were formerly using the 1.19 "release" version, which did not incorporate many fixes and performance improvements. I was also able to compile against the standard Xenial 1.18 X server, so no need to use the backport anymore.
 
Installation steps (provided that you already configured your system according to the first post of this thread):
Restore the regular 1.18 X server packages: sudo aptitude install xserver-xorg-core xserver-xorg xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-fbdev Aptitude will ask you if you want to remove the backported ("-hwe-") packages, so answer Yes.
Download the 7z archive: https://mega.nz/#!oywWCaDA!wDtzXQuohJeVDuePCxHej4xkqDfUmhaPj6XNU7ZXyCk
Unzip it
cd xserver-1.18-ubuntu
sudo dpkg -i *.deb
sudo apt -f install
I see a big performance improvement, and also bug fixes. Windows dragging is snappy, with or without compositing. No more icons disappearing with compositor enabled.
 
However, I am afraid that the more recent version of the X server may have caused the problem with the DSI screen that @TonyMac32 described in another post. Can you test and see if you experience the same problem as with TinkerOS? (EDIT: Nope, the problem was a download link in the product page leading to a much older version instead of the last release: https://forum.armbian.com/topic/6870-rfc-tinker-board-uart-number/?do=findComment&comment=52161) So it seems safe to use this version.
 

it comes with Arduino Header, but not with RPi-Header (GPIO), or did I get this wrong?
 
8Gb is a lot and expensive, are different configuration planned and the first Edition is fully equiped?

ahh, 1 of April
 

The problem I noticed when enabling the compositor was desktop wallpaper and icons disappearing. Can you confirm that is not happening?

I successfully completed all step of the installation, with all tests passing.  I had massive slowdown when moving windows, and so I re-enabled the compositor.  This fixed the problem and has not affected the GPU drivers.

Great Rpi innovations are coming to boards which lacks this superb way of powering 
 
 

Since we already trashed the whole thread with all this thermal babbling... Pi 3 B+ without heatspreader: https://youtu.be/4LtL9e7JqxE?t=3m10s
 

I don't think that will push them. The s905x destroys the Pi 3. The RK3288 destroys the Pi 3. The RK3328 destroys the Pi 3. The H5 destroys it as well. I've never seen a head to head with an H3, but if anything about USB or networking were involved I'm sure it would give the Pi a trouncing as well. In most conditions it's like putting a 4-function calculator up against a PC running Excel.

Sent from my Pixel using Tapatalk

Ahhhhh, the mix of English into that about killed me, hahaha  "Ich verstehe nur Bahnhof".  Idioms are only taught to the students who have the good teachers that also teach how to swear properly.   
 
I think this falls into the same category as "Stop beating around the bush", the German version says something about cats...
 
For the change, we don't currently offer more than 1 kernel option, and that option is in the "next" category.  So I want to put 4.14 into the unused "default" kernel category (such as Rockchip 4.4), and make all new "Next" category images the current stable kernel (upcoming 4.16)

I could put this up for discussion on the Facebook group and see.  I know we don't want to interrupt the stream, but we're still getting people showing up with 4.13 kernels, so...
 
Let's wait for 4.16 to be released, see how stable the result is and go from there.

So, design-off, guys?  First one to boot Armbian on their own V3s board wins?

You must install the "default" image, not "mainline". Sound is not working in mainline. This is the right one: https://dl.armbian.com/tinkerboard/Ubuntu_xenial_default_desktop.7z.torrent

Ahem, that's how open source projects usually work (see Linux kernel or u-boot for example -- @zador.blood.stained already commented on the real issue here)
 
We have no testing branch, we have constant upgrade troubles breaking user installations and interpreting your answer this won't change anytime soon or at all. I can not use Armbian any longer for my own needs without preventing Armbian packages being updated. That's just bizarre and makes me sad.
 
It's not about this specific case with this specific board. I'm talking about how we can prevent this horrible update experience happening again and again and again. Given the patch would've not been broken but really messed up sunxi u-boot... what would've happened? Why has this to happen?
 
Why can't we agree on policies every developer is bound to? Before we add a new device a 'Board bring up' thread will be started where pros/cons and problems are discussed. I have the ugly hack they 'needed' to apply on my list since months but had waited for someone starting a Board Bring Up thread (since instructed to stop starting such threads when the device should NOT be supported by Armbian).
 
If I understand correctly @Icenowy addressed the problem with changed card detect GPIO between pre-production and production boards already back in November last year (see mmc0 definition in her v2 patch series) and then SinoVoip as usual ignored everything and came up three weeks later with their ugly hack instead of relying on her work.
 
 
Well maybe that's why policies are useful or even mandatory. IMO there's no need to suck in patches sitting in a board vendor's repo (known for having never contributed upstream anything so 'port and forget' code style has to be expected) especially if Armbian does still not provide any means of a sane testing/beta environment. It's all done in master branch which is IMO terrible.

As a dev I vote to keep the dev packages in. Sure is nice to have the build tools (even git client) installed even if things like libtool and pkg-config are missing from the base. If you are going for a minimal install I understand stripping all this stuff out, but I'm not sure how important it is to have a 700K vs 1.6 G image in today's terms. As @tkaiser points out most people have moved on beyond 4G SD cards. I've been using 32G for years and the price/performance is good for what I need it for.
 
I've have some home made security cameras that write/read/delete 100s of movies and images a day 24/7 for years without failure. I realize there may be more intensive usages scenarios (more write intensive), but at the current pricing levels I'll toss the SD out every few years if I have to. As with all things the lowest common denominator or race to the bottom isn't always the best strategy. Stability and standardization are more important to me then a little extra RAM, a little more SD life, etc. Not that these are not important, but the bigger picture I think is more important to focus on.

I'm starting to regret that we added it in the past, and we need something that works reliably regardless of the daily log size. I have some thoughts, but different ideas have different requirements and expected reliability issues, and anything requires extensive tests.

The nice dashboard screenshot above is used by @Fourdee to explain why DietPi is superiour to Armbian: 'With #DietPi, logs and DietPi scripts are mounted to RAM , this reduces SD card write operations vastly' -- while I don't understand the purpose to 'mount scripts to RAM' of course the idea to cache logs into RAM is great! That's why Armbian does it since 2014 already.
 
While the above 'proof' is somewhat questionable (watching a 5 min period in a dashboard and once there's activity in one graph taking a screenshot with numbers without meaning) let's look into what makes DietPi that superiour compared to Armbian since it's always a great idea to improve even if that means taking over other project's USPs.
 
For whatever reasons DietPi dropped support for all Orange and Banana Pis recently (seems this started with a conversation between @Igor and @Fourdee on Twitter, then continued here and ended up there) so I had to take another board to do a direct comparison. The only boards that are supported by both projects are now Pine64, Rock64, Tinkerboard, some NanoPi and the ODROIDs. I chose Rock64 mostly to ensure that we use same kernel and almost same settings (Armbian's philosophy is to fix as much as possible upstream so our usual performance fixes went into ayufan's Rock64 build scripts DietPi in this case is relying on by accident so even DietPi users can continue to benefit from our work  )
 
I took latest official DietPi image for Rock64 and the first surprise was the rootfs being pretty small and entirely full so no way to proceed:
/dev/mmcblk1p7 466M 453M 0 100% / For whatever reasons DietPi chose to overtake ayufan's partition layout (for users new to DietPi: this is always just someone else's Debian image processed manually and by some scripts until it becames 'DietPi') but their 'dietpi-drive_manager' responsible to resize the rootfs seems not to be able to cope with this (I wanted to report it to DietPi but there's already a report that gets ignored and it seems I can't comment there).
 
Edit: Ah, it seems @Fourdee blocked me from helping them entirely. I wanted to assist DietPi folks over at https://github.com/Fourdee/DietPi/issues/1550 but can't point them to fix the thermal issues they're running into again or why it's a bit weird to reintroduce the 'rootmydevice' issue again or why the new Allwinner BSP code is not such a great idea due to non-existing dvfs/thermal support  
 
Fortunately our scripts below /usr/local/sbin/ were not deleted by DietPi so I simply called /usr/local/sbin/resize_rootfs.sh which instantly resized the rootfs partition and was then able to continue. For whatever reasons it took 3 whole reboots to get DietPi upgraded to their latest version v6.2 but then I was able to do so some measurements:
 
I then downloaded our Rock64 nightly image (based on Ubuntu Xenial but that doesn't matter that much -- as we all know the userland stuff is close to irrelevant since kernel and settings matter) and did the same thing. But no reboot needed since for whatever reasons DietPi remained on pretty outdated 4.4.77 kernel so I chose to not update Armbian's kernel to our 4.4.115 but to remain at 4.4.77 too:
 
Let's look at the results leaving aside the various performance and security issues DietPi suffers from since not relevant if we want to look at stuff where DietPi outperforms Armbian. First 'idle behaviour':
DietPi Armbian DRAM used: 39 MB (2%) 44 MB (2%) processes: 120 134 cpufreq lowest: 97.5% 99.8% cpufreq highest: 2.0% 0.1% idle temp: 46°C 43.5°C %idle percent: 99.95% 99.98% So we're talking more or less about identical numbers. 'Used' memory after booting is 2% of the available 2GB (anyone thinking 'free' RAM would be desirable on Linux... please try to educate yourself: https://www.linuxatemyram.com), the count of processes reported by ps is almost the same, cpufreq behaviour, %idle percentage and temperatures are also the same (DietPi temperature readout is somewhat flawed since their 'cpu' tool affects system behaviour negatively).
 
Even if Armbian ships with almost twice as much packages installed by default the process count doesn't differ that much (and idling processes really don't hurt anyway) and used memory after booting also doesn't differ significantly. But this 'boot and sit there in idle' use case isn't that relevant anyway and in situations when RAM is really needed I would assume Armbian users are in a much better position since we ship with zram active allowed to use half of the physical DRAM (see here for a brief introduction to zram).
 
So far I don't see that much advantages (none to be honest) but most probably I missed something?
 
Anyway: let's continue focussing on storage utilization and 'use':
DietPi Armbian size img.7z: 104 MB 223 MB (x 2.1) size img: 668 MB 1.6 GB (x 2.5) rootfs size: 457 MB 1.2 GB (x 2.7) packages: 229 436 (x 1.9) commit interval: 5 s 600 s kB_wrtn: 156 KB 448 KB (x 2.9) kB_read: 1008 KB 5912 KB (x 5.9) So both compressed and uncompressed image sizes are much larger with Armbian, same goes for used space on the rootfs which is understandable given that Armbian does not try to be as minimalistic as possible (see the count of pre-installed packages). I don't think going minimalistic is something desirable though we could think about removing development related packages from default installations as @zador.blood.stained suggested already. Maybe it's worth to adjust the rootfs partition size calculation to use slightly less so the uncompressed image size can be a little bit smaller?
 
Anyway: for people being concerned about smallest image size possible even without leaving out packages from default install simply building an own image and then switching from ext4 to btrfs does the job since reducing image size to around ~60% (one of Armbian's advantages is that our images are not hand-crafted unique 'gems' but the fully automated result of our build system so everyone on this earth can simply build his own Armbian images suiting his own needs).
 
And besides that I really see no benefit in trying to get the rootfs size smaller since we surely don't want to start to encourage users to write Armbian images to old and crappy SD cards with less than 4GB size (though I already consider 4GB cards nothing anyone should use these days since almost all those cards are insanely slow). Let's better continue to educate our users about the importance to choose good and reliable SD cards!
 
Now looking at the last 3 lines above. I executed an 'iostat -y 3600' to query the kernel about the total amount of data read and written at the block device layer. within one whole hour With DietPi/Stretch 156KB/1008KB (write/read) were reported and with Armbian/Xenial 448KB/5912KB (write/read). All numbers are too low for further investigations though something is worth a look: that's the default rootfs 'commit interval.' DietPi seems to use ext4 defaults (sync every 5 seconds to SD card) while in Armbian we choose a somewhat high 10 minute value (commit=600).
 
So while with Armbian and 448 KB written in one hour almost three times as much data has been written at the block device layer it might be possible that the 156 KB written by the DietPi installation caused more wear at the flash layer below due to a phenomenon called Write Amplification (TL;DR version: writes at the flash layer happen at 'page sizes', usually 8K, and by using a high commit interval somewhat larger data chunks will be written only every few minutes which can result in significantly less page writes at the flash layer compared to writing every few seconds smaller chunks of data. Adding to the problem once a card is 'full' now we're talking about much higher Write Amplification since now not just pages are written but usually whole Erase Blocks are affected that are much larger. So please choose your SD card wisely and always use a much larger capacity than needed since there's no TRIM with SD cards in Linux!)
 
It would need a lot of more detailled analysis about this write behaviour but IMO it's not worth the efforts and Armbian's 10 min commit interval does a great job reducing further SD card wearout (anyone with too much spare time? Grab 'iostat 5' and 'iotop -o -b -d5 -q -t -k | grep -v Total' and start to analyse what's happening at the block device and application layer forgetting about the filesystem layer in between!)
 
So where's some room for improvement when comparing our defaults with DietPi's?
 
Maybe removing development related packages from default package list? Maybe tuning rootfs partition creation to use slightly less space? Mostly unrelated but an issue: improving our log2ram behaviour as already discussed?

I have to note that dietpi.com front page claims optimizations towards disk space, memory consumption and CPU usage by the OS, not overall CPU, network and I/O performance in real world scenarios which you are interested the most. While it's easy to show that counting processes or checking RAM usage produces numbers without meaning, I don't think we should focus on that (arguing related activities).

Well, it's the distro'ss decision to use this log2ram mechanism and to stay with defaults that in the meantime look somewhat problematic to me.
 
We're syncing at boot the whole /var/log contents including rotated/compressed logs back into RAM: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/log2ram#L40-L44
 
If we would exclude rotated/compressed logs they would exist afterwards only in /var/log.hdd and missing in /var/log which might be confusing for users and break log analysis software and so on. Using symlinks might work but opens up another can of worms.
 
Isn't there an other option that works somewhat like an overlayfs? @zador.blood.stained IIRC we already talked about this a year ago but I can't remember the details  
 
Edit: quick google check: https://github.com/azlux/log2ram/commit/e88f67ab23a91bb1482f0f2063b990585b27730c
 

Update. CMS backend is fully operational at this stage, tested and actual data is slowly moving there, frontend early WIP, sorting at download selection is not finished, the download page is also in making.
 

Check below if this way is better. Exceptions - like a partially broken or slow SATA can be added as one of the device issues or we only expose known working features and strictly forget about crippled ones? WIFI on Opi Zero, Sata on some Oranges, ... ?
 

Solved. This is how adding a device looks like.

This is how editing a kernel looks like:

This is copy paste from the internal manual "how to add things". It might trigger valuable questions if backend needs more changes, something important was left out or this how-to is unclear:
 
 

https://github.com/TinkerBoard/debian_kernel/pull/5#issuecomment-367930082
 
So, if anyone wishes to contribute to the official ASUS kernel, it will be much easier.  

Update:  upcoming default (4.4-rockchip)image update will include services loading bluetooth on boot automagically.

So, I did some more testing and crashed my board. I hooked up wire to what I'm calling pin 3. Honestly I'm completely confused how to number these pins now. I was referencing this page
http://wiki.loverpi.com/sbc-brand:libre-computer and the pinout link there: http://wiki.loverpi.com/pinouts
 
which has two pins labelled 2: the pin right next to 3v3, and also first 5v. Anyway I wired up the pin next to 3v3 to an LED, and also ground. I then ran a bash loop to use gpioset gpiochip1 like so:
 
chris@lepotato:~/Projects/libgpiod$ for i in {1..25}; do echo $i; sudo gpioset gpiochip1 $i'=1'; read; sudo gpioset gpiochip1 $i'=0'; done 1 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 2 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 3 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 gpioset: error setting the GPIO line values: Device or resource busy gpioset: error setting the GPIO line values: Device or resource busy 20 21 22 23 24 25  
And yeah, the LED never lit up. From that spreadsheet linked above, it should have been lighting up at 5, but it wasn't. When I tried doing the above loop all the way to 100, it eventually completely crashed my board and I had to hard reset it. 
 
Is libgpio just busted or something? 
 
I confirmed the LED works by connecting it to the ground pin and 5v, then 3v3, then the second 5v, and it lights up fine on those three. I hooked it to "pin 3" and while it gives a very slight dim light by default (not sure it's supposed to do that or what), and then never changes when I run the above loop to send it to 1 or 0.  
 
I must be doing something wrong here...
 
EDIT: Okay, so I can't get this to actually change any values anyway. 
 
l_chip=gpiochip1 chris@lepotato:~$ sudo gpioget $l_chip 5 1 chris@lepotato:~$ sudo gpioset $l_chip 5=0 chris@lepotato:~$ sudo gpioget $l_chip 5 1  
I think these tools are broken.
 

EDIT2: Okay, I think I figured this out thanks to Neil's spreadsheet up there. I noticed pin 3 is GPIOAO_5 and gpiochip0 is called AOBUS in /sys/class/gpio:
chris@lepotato:~$ ls -l /sys/class/gpio/ total 0 --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/c8100000.aobus/c8100000.aobus:pinctrl@14/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip10 -> ../../devices/platform/soc/c8834000.periphs/c8834000.periphs:pinctrl@4b0/gpio/gpiochip10 --w------- 1 root root 4096 Jan 1 1970 unexport  
So I tried switching my gpioset to use gpiochip0 and turning pin 5 off turned this off. I think I can work with this now. Thanks to Neil for providing that spreadsheet, that info seems good. 
 
Now trying to figure out how to control the pins on GPIOX on that spreadsheet. They don't map to the other chip from what I can tell.
 
EDIT3: Just going to keep updating this post for my notes in case it's helpful to anyone, and if anyone has any suggestions they can chime in.
 
I might have found my crash. I was doing a read loop on the pins of chip1, and apparently reading pin 53 triggers the filesystem to go read-only and everything goes bonkers with I/O errors after that, requiring pulling the power.
 
chris@lepotato:~$ for i in {30..60}; do printf "$i: "; sudo gpioget $l_chip2 $i; done 30: 0 31: 0 32: 0 33: 0 34: 0 35: gpioget: error reading GPIO values: Device or resource busy 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 1 43: 1 44: 0 45: 1 46: 1 47: 1 48: gpioget: error reading GPIO values: Device or resource busy 49: 1 50: 1 51: 1 52: 1 53: sudo: unable to write to /var/lib/sudo/ts/chris: Read-only file system 1 54: sudo: unable to open /var/lib/sudo/ts/chris: Read-only file system  
Eh, maybe not. I don't think the reads triggered it specifically, I tried reading those pins again after reboot and it was fine. This time, I triggered some kind of I/O issue up near pin 80? It finished the loop up to 80 and then wouldn't take any more input from my ssh session. Network completely shut off at that point, another hard reboot and I can't trigger the condition again manually. Weird.
 
EDIT: Merging the info from Tido and Neil, I think I have it now. I'll try to make a new spreadsheet (yeah I know, another?) mapping the pins to libgpiod commands.
 
Basically, I realized Tido's info was shifted by 10 from what was in gpioinfo. IE, 7J1 Pin8 is listed as gpio-101, but in gpioinfo it's 91. Thanks to both of y'all for this info. This is what I was looking for.
 
And sorry for the super long multi-edits. I don't know what this forum's etiquette for that kind of thing is.

Change is not always improvement. etcher.io v 1.2.1 burns fine.