manuti

The only real difference is that nightly images are (usually) not tested. They are just built from upstream, normally every day ... in reality building can be on hold for a week or more until things, which break the compilation, gets fixed or are removed. And most of the images don't get daily images rebuild, but only packages. This means any existing image, stable or nightly, can be upgraded to the latest nightly. (armbian-config -> switch to nightly)
 
171217 = 17. December, 2017

 
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus
 
RPi 3 form factor like their K2, maximum DRAM (2GB), Gigabit Ethernet, Wi-Fi with onboard aerial provided by RTL8189ETV, still using their own/new eMMC socket. According to schematics and their Github repo a SY8106A voltage regulator is used which is great news since then it's possible to clock the H5 well above 1.3 GHz.

Test image Debian + KODI-18.
 
https://yadi.sk/d/goZiDfto3UV8UU
 
To run KODI-18 , you need to perform additional configuration of the system.
1. you need to remove the package “pulseaudio”
2. Switch to the test repository (disable all other repositories and enable "test" in the sourceslist file). Then install a new version of libc6-2.27 from the test repository).
After these steps, you can use KODI-18 as usual.

I have completely rewritten my first post with detailed instructions on how to install Ayufan's Armbian Ubuntu without needing a separate PC.

Hi , can anyone tell me which module will be good for wifi chip sv6051p? I have s905w board (x96 mini ). I tried wifi_dummy and modprobe dhd but nothing worked .

For those interested I made some improvements in the GLES display backend of uae4arm:
 
https://github.com/Chips-fr/uae4arm-rpi
 
I tested it on Armbian on my orange Pi Pc+ (H3), was able to get 50fps for some games.
 
The only remaining issue is that vsync is not activated and tearing occurs.
Does anyone know how to solve this ?
 
Feel free to try on others boards...
 

All right, the wi-fi now works:
You need to create the file /etc/modprobe.d/ssv6051.conf
and enter the path to the driver configuration file
(type in file)
options ssv6051 stacfgpath = / lib / firmware / ssv6051 / ssv6051-wifi.cfg
You must also configure the wpa_supplicant for network access.
 
A great idea from Forum Alex @ ELEC
 
The other error messages to boot remain to be solved but it is a secondary problem!
 
Now I will install my home automation server (probably Fhem)
 
Thanks to all for collaboration!

This topic is a response to the growing number of kernels, growing number of boards with... "unique properties", and for the increased complexity of some platofrms (aarch64 and the atf, etc).  I think the coherency of the chosen organizational method is starting to fall apart.
 
So just a thought experiment on my part:
 
Currently, we have a sources directory, and the sources file has not just sources, but also executable script functions in it.  We also do our patches per SoC, mostly, but the organization is by the thing being compiled rather than by the target, making finding/adjusting a bit cumbersome in some cases. 
 
I would propose a directory tree looking something like this:
 
├── RK3288 │   ├── kernel │   │   ├── default │   │   ├── dev │   │   └── next │   ├── miqi │   ├── tinkerboard │   │   ├── kernel │   │   │   ├── default │   │   │   ├── dev │   │   │   └── next │   │   └── uboot │   │   ├── default │   │   ├── dev │   │   └── next │   └── uboot │   ├── default │   ├── dev │   └── next └── S905 In this case the organization is by SoC, then by board.  All patches safe for the entire board population get put in the SoC-level kernel and uboot patch folders, anything unsafe (hardkernel-specific patches, Tinker board specific patches) go into the board-level folders.  To reinforce that we want those folder to be "last resort", we could call them "C2_bugs, Tinker_bugs" etc.
 
For our 64-bit targets, the trusted firmware would likewise have it's directory.  I think it might also make for a lower barrier to entry on committing fixes, I still worry about patching things when I don't have all the boards to test on, this way, as a novice or as someone doing something that I can't test on other hardware, I can drop the patch into the board(s) I have, then they can be evaluated by the other devs on the remainder of the hardware.
 
My particular set of boards benefit this way:
 
Tinker board specific patches are many, integrating them safely is one of the biggest reasons we lag the vendor kernel, changes to the architecture files, changes to rk3288.dtsi instead of just to rk3288-minarm.dts, changes to various drivers for specific hardware issues, etc etc etc etc. Differences in gxbb vs gxl Meson64 devices.  Most of these coexist peacefully, but then you have vendor issues with u-boot of the C2, K2, etc (everyone has their own bootloader blobs)  
I'd say we organize bootloader scripts similarly, rather than having executable scripts in the sources file we could place an include in the appropriate board folder covering the specifics. For example, if a board ships with a SPI boot flash, we don't need to burn u-boot, only provide the proper configuration of partitions/etc. That might be the only board in the series (an unusually awesome H3 board, for example).
 
Ideally, at that point, adding a new board would require a new board definition file, and then the proper patches folder. 
 

Have you downloaded the modules for WiFi ? Maybe your whole problem is solved with one command " modprobe ssv6051"

 
OMV is based on Debian. That's the simple reason it won't install on Ubuntu (dependency hell, different package versions). And if someone wants to run OMV I strongly recommend to check first whether there are available images at the download page or otherwise choose an Armbian Stretch next variant and then use armbian-config to install OMV.
 
Even if someone interested in NAS does not want to rely on OMV/Debian looking into the various performance tweaks we did is worth the efforts: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44097
 
 
And for any NAS usage next kernel is strongly recommended since better hardware support (especially UAS support for USB storage).

The main utility to read and write GPIO pins on Raspian is /usr/local/bin/gpio.  It was written by Gordon Henderson (http://wiringpi.com) and also comes with an api library suitable for C/C++ development.  A couple of years ago I found an excellent version ported for the Orange Pi (https://github.com/zhaolei/WiringOP.git).  The one thing that they both do is set the SUID bit on the GPIO utility, thus allowing any user to run it.

Just for the record: This (using the OMV RPi image and removing the OMV parts) will not result in an Armbian installation (I'm aware that you've written about 'Armbian a like', just want to further clarify). It's just a Debian Jessie armhf rootfs generated by Armbian's build system that has been slightly adjusted and manually combined with RPi Foundation's kernel packages and the proprietary, closed sourced RPi stuff (ThreadX on the /boot partition and some proprietary userspace binaries to interact with VideoCore/ThreadX, most importantly to report/detect under-voltage).
 
Armbian is about:
bootloader and kernel optimizations (first not possible since closed source ThreadX, latter not reasonable/needed on Raspberries) optimized settings to improve performance, consumption and thermal behaviour (not possible on RPi since done entirely on the VideoCore by ThreadX) to improve security situation building an entire OS image from scratch so no one has fiddled around so far (if you use our build system and let it debootstrap a fresh Armbian image you know no one logged in so far and planted backdoors or stuff like that) So the OMV image is just a modified piece of data that was falling out of Armbian's build system (the rootfs) manually adjusted to be combined with the proprietary and closed source stuff that still makes up the whole 'RPi experience' (for the majority of RPi users I personally know the Pi is just a KODI and retrogaming box and without the proprietary video decoding and 3D acceleration stuff on the VideoCore they would have to throw it away)
 
So all you get by using this OMV image is the illusion wrt 3) above (clean rootfs) but thinking this would enhance security or prevent you from being backdoored is just... an illusion. The main CPU of every RPi is still the outdated VideoCore from 2009 (this chip contains not only GPU, VPU and multiple QPU cores but also an ordinary dual core CPU inside running the closed source RTOS called ThreadX). The ARM cores running any secondary OS are just guests. Since Raspberries are popular for stuff like Tor end nodes or VPN gateways who knows whether GCHQ already ordered the Foundation to ship their ThreadX with an universal backdoor to allow agency access?)
 
Anyway: maybe the OMV image's only real advantage is that it's Jessie based but still gets RPi Foundation's kernel updates (we do this via apt pinning since for whatever reasons someone at the Pi Foundation decided last year to cut off all their Jessie users from future kernel updates, weakening the security of all these installations). But if you're not running OMV (where OMV releases are bound to the underlying Debian release -- OMV 3 needs Jessie and OMV 4 simply wasn't ready last year) then why not using Stretch anyway? Raspbian isn't bad, it's just somewhat bloated.
 
As usual the 2 most important things you can do to improve general RPi performance/responsiveness is
Checking whether your powering is sufficient, you need to call perl -e "printf \"%19b\n\", $(vcgencmd get_throttled | -f2 -d=)" and have a look at the left whether there is a '1' (explanation). If you see there a 1 you're running 'frequency capped' at 600 MHz when performance would be needed. You must call vcgencmd since the usual ways to query CPU clockspeed are all fake (don't tell it over at the RPi forum -- for this you will get censored and banned  ) Throwing away your old and slow SD card and start with a new, genuine and A1 rated SD card of at least 16 GB in size (I would go with an A1 Extreme and not an A1 Ultra for the simple reason that most probably RPi folks with their next 'incremental Pi update' next year will finally implement SDR104 to speed up SD card access. This and better Wi-Fi is almost all they've left to once again sell their fanboys an 'improvement') Please note that both 'performance tweaks' are hardware and not software fixes.

https://asciinema.org/a/Goj9aUPvgpGk6YCx97Lqj3XwV
 
 

@balbes150 et al... maybe this is useful?
https://github.com/trustfarm/orangepi-zero-tfarm/tree/master/OrangePi-Kernel/linux-3.4/drivers/net/wireless/ssv6xxx
 
 

Perhaps someone will be interested-a new version of Volumio 0.7_20180325  for S9xxx. It has audio output via a standard HDMI output. To use this feature, you must use one of two dtb files. For VIM1 (S 905 X) - "kvim_android.dtb" for the VIM2 (S912) - "kvim2_android.dtb". For those who use other dtb files, please write the names of the dtb files that you use. They need to make a number of changes to make them earned HDMI output.
 
https://yadi.sk/d/xbesnjYG3PETk5
 
details
 
https://volumio.org/forum/volumio-for-box-amlogic-s905-s905x-s912-s802-s812-t8028.html

 
Which 'outsourcing'? Allwinner sells hardware. Cheap hardware for special markets. Android tablets back then, $something in between, now smart speakers, dashcams, retro gaming stuff, again tablets and TV boxes. Nintendo's NES Classic sold 2.3 million units in no time. Using a boring A33 SoC with technology from 5 years ago running a smelly 3.4.39 kernel from 5 years ago. Their customers (that's not us) do not care so why should Allwinner care so far?
 
They enable device manufacturers to throw out cheap hardware with somewhat working software with ok-ish margins (their main market) or sometimes enable their customers like Nintendo to sell insanely overpriced/overhyped products where again no-one cares about kernel, software or anything else we would be interested in.
 
For Allwinner there's still no 'Linux market'. Though things might change in the future. But unless there's an incentive to mainline their own hardware and submit code upstream (good luck given the BSP code quality) I doubt anything will change soon or at all. But of course I highly appreciate that they now contribute and react in a very responsive way. As @jernej pointed out in the meantime many requests will be answered positively (and I always chuckle seeing wink, the Allwinner guy, directly contributing to linux-sunxi wiki now -- I never thought this would happen)

 
Sure, this is how it should work. Great that now even the RPi folks got it
 
Yesterday I 'unboxed' Orange Pi Lite 2 (Allwinne H6). As small as the H3 Lite but extra thick PCB. After 10 minutes of idle operation the whole PCB including all receptacles is warm so the groundplane efficiently spreads the heat away from the SoC. I put 3 low performing heatsinks on SoC, PMIC and DRAM and reported SoC temperature went down from 49°C in idle to 46°C (after waiting the same 10 minutes or until temperature is stable).
 
So still curious how efficient a 2mm thermal pad between PCB lower side and an aluminium enclosure would work (to transport heat out of an enclosure). To be clear: I'm talking about something like this (and am not willing to spend my own time on such tests any more since done with the low consumption/thermal stuff)
 
Testing such stuff with enclosures that already exist seems impossible. The FLIRC is constructed wrongly and to buy the Wicked you must be mad.

Update to latest armbian, go to armbian-config -> system and change display manager.

Image update Armbian 20180323 kernel 4.14.11 .
Works wired network, USB, monitor (you can change the screen resolution on the fly). The images are in the "test"directory.

 
Sure. Better results compared to the board lying flat on a pillow
 
Since latest RPi 3+ from last week now also started to copy what those cheap Orange Pi do since years (using the PCB ground plane as massive heatsink) I suggested this test over at RPi forum: https://archive.fo/6kzg0 ... and (not so) surprisingly the post got censored: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=207863&start=225#p1286503 -- they really don't like it over there their users could get the idea that there grows more than Raspberries on this earth 
 
BTW: really impressive how inefficient the old RPi 3 was and is from a thermal point of view:

 
vs.

Try it. I like Arch. They have also images for other boards.

Yes, I use it as headless machine. 
 
Linux odroid-u3 4.15.11-1-ARCH #1 SMP Tue Mar 20 00:23:08 UTC 2018 armv7l GNU/Linux

Yes!!! and now @balbes150 is moving to kernel 4.9.40 
 

@Tido
I've been using Linux desktops on a vast number of physical and virtual systems from enterprise to dinky toys, standardizing on plain Debian and LXDE for robust and stable systems. The LXDE-desktop uses even less ressources than XFCE and is particularly suited for small boards. The choice of desktop ( XFCE ) and Ubuntu bloat are somewhat contrary to the idea of Armbian as a lean and robust distribution. If your seriously interested in Linux desktops opt for the real thing and set up a lightning fast LXDE desktop based on Debian stable. In combination with x2go terminal server you'll experience a vastly superior and universal desktop world.
Enjoy !

No, all TV-box stuff is handled by Balbes150's excellent work.