chwe

Another look at the 2 SATA ports provided by the JMS561.
 
The same IC is inside Hardkernel's Cloudshell 2 thingy where users face serious SMART related issues. So let's do a quick check with an SSD connected to each SATA port:
root@rock960:~# for i in a b ; do smartctl -d sat -x /dev/sd${i}; smartctl -l devstat /dev/sd${i} -d sat,12; echo -e "\n\n\n\n\n" ; done | curl -F 'f:1=<-' ix.io http://ix.io/1o0p root@rock960:~# dmesg | tail -n5 [ 10.090856] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 89.067105] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 89.067959] xhci-hcd xhci-hcd.7.auto: @000000007bc32a30 00000000 00000000 1b000000 03078001 [ 89.162393] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 89.163274] xhci-hcd xhci-hcd.7.auto: @000000007bc32ac0 00000000 00000000 1b000000 03078001 As http://ix.io/1o0p clearly shows the issue is still there. For the disk connected to the 'SATA1' port only bogus SMART data is returned. Shutting down the board, exchanging SATA cables so that now the EVO840 is connected to 'SATA1' and again: SMART readouts broken for the disk connected to this port: http://ix.io/1o0t
 
I then wanted to create a btrfs mirror to test the same with drives busy but to my surprise Vamrs' kernel has no btrfs support enabled. Then tried an mdraid-1 (which I personally consider the most stupid disk setup ever but hey, it's only about a load test) but also no mdraid support in this kernel
 
Ok, then continuing with individual ext4 filesystems on each SSD, running iozone -e -I -a -s 20000M -r 16384k -i 0 -i 1 -i 2 on each SSD and then again doing the smartctl queries.  No USB bus resets, performance also not affected but of course still bogus SMART readouts for one SSD and the above xhci error messages in the log.
 
So both SATA ports still are fine from a performance point of view when combined with HDDs (since all HDDs are that slow that they are the bottleneck and not the JMS561 provided SATA port) but unfortunately there are functional limitations wrt the disk connected to the 'SATA1' port (no SMART health queries, you can start SMART selftests but since SMART status can not be queried no way to get selftest results without exchanging disks/cables).
 
That being said Ficus with just one HDD connected to the 'SATA2' port is a great combination. I hope Vamrs looks into this, gets in touch with JMicron and checks whether this can be resolved with a firmware update.

I've adapted a set of patches from Urja Rannikko, which move the HDMI frequencies definition into the DTS file, with some preconfigured rates if none are defined in the DTS.
 
The original patches set is here : https://www.spinics.net/lists/arm-kernel/msg673156.html
The big patch I used as a basis is here : https://github.com/urjaman/arch-c201/blob/master/linux-c201/0020-RK3288-HDMI-clock-hacks-combined.patch
I included these patches by splitting them again : https://github.com/Miouyouyou/RockMyy/commit/57ff073fffb5678e75959e566704376f6f52ac17
 
These patches were suggested to me here : https://github.com/Miouyouyou/RockMyy/issues/3
 
Anyway, after some quick tests, these patches remove the dreaded bar of purple pixels at the left of my HDMI screen, when plugged to Tinkerboard systems and MiQi systems. Note that these bars only appear on my screen when using "good" (enough) USB power supply.
Still, with these patches, they are gone. However... I only tested these patches on my 60Hz 1080p screen, which is pretty much the de-facto standard screen.
I'd like to see people test these patches on other HDMI configurations which are known to have some issues with Tinkerboard, MiQi and others RK3288 systems.
 
So, yeah, if you'd like to test some kernel patches and are not afraid to see your screen go black after a reboot, have a try.
 
Note : This is completely unrelated with the CEC issue.

well with the amount of boards armbian supports, providing old images would probably mean that @Igor needs something like this:
 
 

 
besides that we then had to support those old images too.. Something nobody wants to do..  
so now back to topic. A way which should work:
format your SD card test it with h2testw (windows) or f3 (linux) burn it with etcher (current orange pi pc image should work https://github.com/armbian/testings/blob/master/orangepipc-next.report) stick it via ethernet cable to your router and ssh into it download headers search somewhere for a driver for your wifi usb stick try to build this driver and just once again.. It is an OrangePi PC and not an OrangePi PC+ right? Just to ensure you downloaded the right image. 
 
if your card reports no errors with f3 and h2testw you might have a look into the powering of your board.
 
there are reasons why we suggest etcher and not dd... Debug issues cause 'dd gone wrong' is a waste of time..  
 

now, also part of the 'unofficial' UART tutorial...  written for all kind of serial access (for all kind of host systems,  Windows, Linux and even linked to OS-X) except... Silly circles..  
ssh --> uart --> uart ^ | |________________|  
 

Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
 
My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
 
I hope this helps...!
 

Does dpkg-divert not work for some reason?
dpkg-divert --add /etc/default/cpufrequtils

@lanefu self-assigned this 7 days ago. I need to recharge.

one more and you can set up a punk band.. 
 
still think that putting something like this in rc6.d just asks for trouble.. 

Oldies but goodies: a made a quick demo with my smartphone (sorry for the bad quality) of Quake2 running on rk3288 using GL4ES. The game works really well, it is totally playable and there are no issues of any sort 
 
 

I started with this 'zram on SBC' journey more than 2 years ago, testing with GUI use cases on PineBook, searching for other use cases that require huge amounts of memory, testing with old as well as brand new kernel versions and ending up with huge compile jobs as an example where heavy DRAM overcommitment is possible and zram shows its strengths. Days of work, zero help/contributions by others until recently (see @botfap contribution in the other thread). Now that as an result of this work a new default is set additional time is needed to discuss about feelings and believes? Really impressive...
 
 
Care to elaborate what I did wrong when always running exactly the same set of 'monitoring' with each test (using a pretty lightweight 'iostat 1800' call which simply queries the kernel's counters and displays some numbers every 30 minutes)?
 
 
Why should opinions matter if there's no reasoning provided? I'm happy to learn how and what I could test/modify again since when starting with this zram journey and GUI apps I had no way to measure different settings since everything is just 'feeling' (with zram and massive overcommitment you can open 10 more browsers tabs without the system becoming unresponsive which is not news anyway but simply as expected). So I ended up with one huge compile job as worst case test scenario.
 
I'm happy to learn in which situations with zram only a vm.swappiness value higher than 60 results in lower performance or problems. We're talking about Armbian's new defaults: that's zram only without any other swap file mechanism on physical storage active. If users want to add additional swap space they're responsible for tuning their system on their own (and hopefully know about zswap which seems to me the way better alternative in such scenarios) so now it's really just about 'zram only'.
 
I'm not interested in 'everyone will tell you' stories or 'in theory this should happen' but real experiences. See the reason why we switched back to lzo as default also for zram even if everyone on the Internet tells you that would be stupid and lz4 always the better option.

The armbian-image-config script is pretty much done, I'm about to push it to github but thought I best check a couple of things first with people who are more knowledgeable about Armbian than me
 
Apart from sudo netdev audio video dialout plugdev input bluetooth systemd-journal and ssh, are there any other groups that you want the user adding to? What files need deleting or modifying after initial setup but before 1st reboot? (/root/.not_logged_in_yet, ~/Xauthority) For debugging 1st reboot problems, is there any interesting info outside of /var/log? (assuming log2ram is disabled) I have only added support for WPA-PSK in the wifi setup. IS WPA-Enterprise or radius auth used enough to justify adding support for them? IPv6 support is currently DHCP or auto config only. Are there many people who use IPv6 ONLY, no IPv4, with static addressing?  
 
@lrrr I understand that. I like the idea, we do something similar in our production boxes. start the rootfs at an 8mb offset and embed a 4mb hidden, compressed fat partition between uboot and rootfs containing config information. We then have a windows GUI tool to manipulate the 3 files we store in there. I just dont think its suitable for Armbian, its adds a small level of complexity that is difficult for non tech users to troubleshoot. It also requires any minor tweaks, say a change of hostname, to have to repack and reinsert data to the disk image or SD Card. I could be wrong, feedback would be appreciated
 

Maybe ... Unfortunately, I didn't kept the old private built image with old HJC branch, so I can't even look what was different in both u-boot.
At least, we now have a manual workaround ...
 

nope
 
you can go through this one
 
or to keep it short: BPI-M2-Zero is only csc supported, you've to build the images on your own. 
 

testing  testing  testing..  
You need:
a github account a bit of time a SBC armbian supports git clone https://github.com/armbian/testings cd testings ./createreport.sh you don't even need to fork the repo in the browser, we'll do it for you from command line..  Same for the PR, everything is done from console.
 
is back now even for google users... 

Im not sure that 12mA was the only safe setting, it was the only setting that helped to stop sd corruption when using very low end or fake sd cards. 8mA was rock solid stable when using any normal sd card. Its also probably a better default for Armbian. If the users sd card wont work properly with 8mA of current then it has no place for sbc use I would have thought, the sd card is almost certain to cause other problems later on

If I would have a running windows machine at the moment..  I would test it...  but thanks to @hjc I may copy it partly in the starter..
updated.. I guess there was an u too much in uniq.. But this one should be correct now.
grep "g_serial" * | awk -F. '{print $1}' | uniq  
If you think the average armbian user doesn't know the console you set the bars low  Calling it a serial console is IMO questionable,  serial drivers are loaded a way earlier in the kernel than g_serial. Whenever possible, we should force people to use a real UART-USB adapter and g_serial should only be 'promoted' if the user doen't have a adapter. 

that's not a solution, that's a workaround.. and IMO a shitty one due to wifi for the OPi zero can be.... uncool 
If it would be my board, I would prefer to have this fixed befor wifi might quit in the future.. Just as a first one 'sudo armbianmonitor -u' can be helpful
 
see comment at the download page:
 
USB gadget mode can be something to test.. And as @martinayotte mentions everytime, and I second that: spending 1-2$ for an USB to UART adapter is it worth when working with SBCs.

Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information).
 
Prerequisites:
We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:
on debian a like systems:
sudo apt-get install picocom from arch community repo:
https://www.archlinux.org/packages/community/x86_64/picocom/
 
on fedora systems:
yum install picocom on Mac OS X:
brew install picocom on Widows we use PuTTY:
 
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
 
UART USB Adapter:
There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102
Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!).  Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.  
You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:
GND --> GND RX --> TX TX --> RX You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. 
Linux:
[256597.311207] usb 3-2: Product: USB2.0-Serial [256597.402283] usbcore: registered new interface driver ch341 [256597.402341] usbserial: USB Serial support registered for ch341-uart [256597.402392] ch341 3-2:1.0: ch341-uart converter detected [256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0 --> Device will be /dev/ttyUSB0
Windows:
for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8)
Something like the picture in USB Gadget Mode part of the tutorial should show up)
 
Armbians default settings are (expect some RK devices):
For Picocom:
picocom -b 115200 -r -l /dev/ttyUSB0 and for some RK devices:
picocom -b 1500000 -r -l /dev/ttyUSB0 For PuTTY:
You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

 
OS X:
TBD
should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&amp;t=841 as an example with minicom.
 
Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. 
 
USB Gadget Mode
Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):
 
install picocom connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up:  [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters  
connect to it via picocom (in this case 'picocom /dev/ttyACM0'):  chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password:  
I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).  
For Windows:
run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8):
(even the tutorial is for arduinos, it should be similar for every 'COM device')
 
Currently boards with USB gadget mode:
bananapim2plus bananapim2zero nanopifire3 nanopim3 nanopineo2 nanopineocore2 nanopineoplus2 orangepizeroplus nanopiair nanopiduo nanopineo olimex-som204-a20 orangepilite orangepi-r1 orangepizero orangepizeroplus2-h3 orangepizeroplus2-h5 tritium-h3  
The silly approach
For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC...  SSH --> opi, ttl --> Tinkerboard
For those loving text more than videos:
SSH to your SBC sudo armbian-config --> system --> hardware  to activate an spare UART (in this case it was UART2, will give you ttyS2) reboot picocom -b 115200 -r -l /dev/ttyS2  
 

See:  https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR

 
 

nope it can be either accessed via USB-UART adapter (that's what those 3 pins near to RJ45 are for.. Or with armbian via USB gadget mode. 
 
yep
 
hmm that sounds strange.. But with your previous armbian it worked properly on the same router via DHCP? 

Yesterday was about linus don't understand that some people might felt offended by his communications style. Today Coraline Ada's blog post about her year at github. 
 
https://where.coraline.codes/blog/my-year-at-github/
It's somehow interesting... IMO they face both the same problem. Their communication style isn't  fully compatible with the community they are in..
 
Coraline Ada:
Linus Torvalds:
 
Coraline Ada:
 
Linus Torvalds:
 
For me this is somehow ironic.  Both stand hard for their position which might not be a mainstream position which brings them quite often in trouble and they have to defend them-self.  IMO, being 'inclusive' means that you accept both behaviors as long as they don't cross some lines of common sense. We've to accept that not everyone has the same opinions on several topics and what people assume as 'normal behavior' . Both, Linus and Coraline aren't fully what I would call average but in an inclusive environment both should find their place and felt somehow welcomed as long as they accept that maybe not everyone shares their opinion on a *random topic*.  Cause actually, some of the features she and her team developed for github are really useful e.g. as she describes:
 

I think it's beneficial for bigger projects to spot new contributors either to have a closer look at the patch or just to congrats for the first contribution..  
 
and the other one:
IMO I would call it a bug that the invitation is only visible via email and not reminds you friendly as soon as you login with your github account but well.. Nothing is perfect..  But I also like that I could not be randomly added to groups I don't know or I don't want to be part of..
 
And my last two cents on this one:
Well IMO those 'values' are written by HR and Lawyers (to ensure they can't be sued for them..  ) and that's why a bunch of people inside a company don't give a fuck whats written there.. They don't grow organic it's more some sort of GMO, the majority accepts them cause they're cheap... e.g. 
smells like the marketing intern together with the law intern played a round of buzzword bingo to make an HR senior happy who had to make management happy cause they pushed him to write down some sort of 'what we are'.. If this stuff doesn't come from the people who do the work.. They don't feel responsible to follow these rules/values.. That's why IMO the companies HR department should have different 'values' than the development unit and they may have different values than the production department.. 

As for the armbian-image-config
 
https://github.com/botfap/armbian-image-config

Tool to pre-configure basic system settings on Armbian images. Each module can be used independently on an image but using the same module twice will overwrite not combine any changes. This tool needs superuser permissions to mount and write to system files on disk images, you will need to run it with sudo or in a root shell
armbian-image-config armbian-image.img module [options] modules: n|hostname [mynewhostname] e|ethernet [dhcp|static] [ipaddr mask] [gw] [dns] [search] w|wifi [dhcp|static] ssid key [ipaddr mask] [gw] [dns] [search] u|user [username] [password] l|log2ram [enabled|disabled] d|debug [enabled|disabled|save] r|remote [ssh|xrdp] [enabled|disabled] t|template [package|template.tgz] x|rootshell h|help  
Image Info
Image file can be any standard Armbian image (or ubuntu 18 / debian 9). Either self built or downloaded
Replace image name with keyword "template" to generate just the config files ready to make a template package
 
Module Help and Examples
hostname or n
Sets the system hostname for the image
armbian-image-config armbian-image.img h|hostname [mynewhostname] n|hostname name armbian-image-config armbian-image.img h myserver
ethernet or e
Sets up ethernet networking for the first detected card for either DHCP or static IP addressing
armbian-image-config armbian-image.img e|ethenet [dhcp|static] [ipaddr mask] [gw] [dns] e|ethernet d|dhcp s|static ipaddr mask [gw] [dns] [search] armbian-image-config armbian-image.img e d armbian-image-config armbian-image.img e s 10.0.0.50 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan wifi or w
Sets up wifi networking for the first detected card for either DHCP or static IP addressing
armbian-image-config armbian-image.img w|wifi [dhcp|static] ssid key [ipaddr mask] [gw] [dns] [search] w|wifi d|dhcp ssid key s|static ssid key ip mask [gw] [dns] [search] s6|staticipv6 ssid crypto key ip6 mask6 [gw6] [dns6] [search] armbian-image-config armbian-image.img w d MyWifiAP MySecret armbian-image-config armbian-image.img w s MyWifiAP MySecret 10.0.0.51 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan user or u
Sets the username and password of the primary system user
armbian-image-config armbian-image.img u [username] [password] log2ram or l
Enable or disable log2ram for troubleshooting startup issues
armbian-image-config armbian-image.img l [enabled|disabled] remote or r
Enable or disable remote access via ssh and rdp
armbian-image-config armbian-image.img r [ssh|xrdp] [enabled|disabled] debug or e
Sets the boot diagnostics to enabled / disabled or save logs from image to a local archive
armbian-image-config armbian-image.img d|debug [enabled|disabled|save] d|debug enabled disabled save e.g. armbian-image-config armbian-image.img d save rootshell or x
Mount the image and start a chroot shell
armbian-image-config armbian-image.img rootshell template or t
Inject a config template into the image. Can be any files in a compressed tar archive which is extracted at root (/) on the image root file system. See also Creating templates below
armbian-image-config armbian-image.img t|template [package|template.tgz] t|template package template.tgz e.g. armbian-image-config armbian-image.img t aic-template.tgz  
Creating templates
To create a config template, consisting of the config of 1 or more modules, use the keyword "template" instead of an image file name. This will populate the "tmproot" folder with the generated config files ready for packaging. To create a package use the command "armbian-image-config template package" and a config packaged named aic-template.tgz will be created
armbian-image-config template n tvbox armbian-image-config template w d MyWiFi wpa-psk MySecret armbian-image-config template package  
Development Status
Active
#### Module Progress
- hostname - done, needs testing
- ethernet - done, needs testing
- wifi - done, needs testing
- user #TODO
- log2ram - testing in botfap branch
- debug - testing in botfap branch
- template done, needs testing
- rootshell #TODO
- help - done, needs testing

And that's exactly what Armbian is! For someone not familiar with this basics, Armbian take care about it - even if you don't know that this is an issue. It's not that you can't change this behavior and do 'stupid things' with armbian.  But a 'stock' Armbian tries to avoid it.
That's why we should have your essays collected somewhere.  For me the best way would be that they are written somewhere as a 'tutorial'/'education' part.. But links to the forum posts could also work. 
 
For me, Armbian is:
clean Debian/Ubuntu (due to debootstrap processing of rootfs) on top of an enhanced BSP/mainline kernel (due to a bunch of patches) enhanced durability (due to log2ram & longer 'commit interval') one of the few distributions providing kernel updates on 'living systems' for arm boards (which goes sometimes wrong  - but we try to fix it in case it goes wrong, and yes there is some space for improvements) an active community trying to help you when you struggle - even your issue is not Armbian related/ due to lack of (basic) linux knowledge etc.  providing a similar linux experience over different SoCs/'brands' - the reason I'll never take use an image provided by the boardmaker (e.g. friendlyArm) is not because I think all of them do a bad job, it's because I don't want to waste hours of time to figure out where their behavior is different from the images provided by another boardmaker/distribution.   a mighty buildscript which allows the user to fix things on his own (e.g. @TonyMac32 and me try to support CSI for the tinker, we still fail  but the buildscript allows me to create different kernel configs & patches for the kernel/u-boot etc without doing the annoying diff process on my own.. I can simply do my changes inside the sources and as soon as I fixed something I can send a PR to armbian and other people can benefit from my enhancement or in case Armbian doesn't accept the PR I can provide it as an userpatch so that everyone interested in the same 'enhancement' can build it on his own).  I agree that part of the people are ignorant when it comes to durability and 'proper usage' of SBCs. I also agree that user expectations are sometimes ridiculous (I want a 8$ SBC together with a 1$ PSU and a 2$ SD-card and I expect desktop performance when it's about multimedia stuff with linux! ). I'm not sure if this is the majority, I guess that there's a 'silent majority' of users which are happy with what Armbian offers to them.  Normally you don't register to a Forum just to say "Awsome! Thank you for providing an reliable Debian/Ubuntu for my *random SBC*!" It's more than you register cause you something doesn't work as expected, cause it doesn't boot anymore or cause you bought a new SBC which is not supported (yet) by Armbian. 
As a moderator here, I get all these reminders to approve new forum postings and therefore I read a bunch of them... Some of them are funny, some of them are stupid a few of them are obviously spam but even less of them are 'impressive'. The last one I can remember was when @konsgn posted his first post where he nailed down the OPi0 thermal issue with his first post. So why did he wrote this here and not in Xunlongs forum (in case you did, mea culpa for my low google-fu , I only found it here)? Maybe he's one of the 'silent' users which are (mostly) happy with what armbian offers to them, maybe cause he thought it make sense to share it in an active community - I don't know but it seems we are a good place for sharing such informations..  
 
We can provide those informations in a 'marketing manner' and I'm sure @zador.blood.stained wouldn't be happy when we do it this way.  We can do it the way we do it at the moment, explaining the same questions again and again (and again ) to our 'customers'  or we can try to collect them so that they are accessible 'as easy as possible'. 

challenge accepted
 
Todays special:
 
Schweinshaxe mit Knöpfli
Knöpfli is Switzerlands pendant to 'Spätzle'.  Schweinshaxe (Ham hock), and for those not knowing them:
 here we go..
 
user: ~$ time meal.sh real ~2h30min user ~40min sys ~2h First we start with the Haxe. We rost them of both sides for around 2-3mins in a metal bowl on the hotplate.

First on the side where the bones are smaller, then on the other side. We add 2 roughly cutted onions and carrots and let them rost for around 5mins before adding a glass of vine.

We let the vine now reduce a little bit before adding bouillon (as much as needed so that they are not completely covered). They're no cooked for around 1h30mins at 150°C and the last 30mins at 200°C in the oven (use the liquid to 'moisten' them every 15min). 
Knöpfli:
We mix 500g flour with 300mL milk (or 150 milk 150 water), 3 eggs a bit of salt (one teaspoon) and if you like a bit of nutmeg. As soon as it is well mixed we let it rest for 30mins.
 
A big pan is filled with water and heated up until it boils. The knöpfli dough is then pressed through a 'perforated sieve' (there are special ones for 'Knöpfli' but mine comes from a steam cooking set and works also well ).

as soon as they swimm (normally immediately), they can be skimmed wit a normal sieve and collected. If you want you can roast them now in butter and add some roasted onions on top but it also works well without, or as I do add cheese on top. Similar you can add some honey on top of the 'haxen' for the last 5-10minutes for a nice crust (I guess the germans adding Soda in the end for the crust, maybe the Bavarians here knowing it? ).  
In the end, it should look somehow like that:

 
Things you need (for ~4 persons):
2 onions 2 carrots 4 haxen 500g flour 3 eggs 300mL milk a glass vine, a bit of bouillon, salt, oil (butter)  

Just had a look when I did Knöpfle the last time: over 11 years ago. Delicious taste, bad 'look&feel'. Never did them again
 

 
 
 

Current proposal?
 
the FAT32 config partition is at the end of the disk image firstrun applies configuration changes config file is scrubbed via shred for security purposes fat32 part is destroyed rootfs expansion step proceeds as normal