manuti

At least this is understandable on the surface - apt-update is running in the background automatically when the board starts the first time.

Wait for a new release or update to beta, then use armbian-config to enable/disable desktop.

Since almost all ARM SBC use SoCs that were made with Android or very special purposes in mind. So each SoC maker is doing his own things and we need for every chip family own software. Besides that there's optimizations needed, when you take a vendor (Android) kernel with vendor (Android) settings and combine it with a Linux userland performance will simply suck (well, today same is even true when using community's mainline stuff). That's one of the reasons Armbian exists since we did a lot of research here and ship with 'per device' optimized settings.
 
So even if some (64-bit) SBC now start to ship with an universal bootloader I doubt you get the same overall performance booting an OpenSUSE compared to an optimized Armbian build.
 
But things will improve but not with all SBC but only starting with ARMv8 and it will need a few more years until dedicated distros like ours aren't necessary any more. As a starting point: https://www.cnx-software.com/2014/01/31/arm-unveils-system-base-architecture-specification-to-standardize-arm-based-servers/

Reboot doesnt seems to work like before.... while booting up the <5 appears then the Ubuntu-login-Screen.
After u-boot the screen seems to be initialized in another way (short dissorted image)

And for new boards in the future a better solution would be adding a eMMC connector compatible with Hardkernel and Pine boards.

Thats right...they are from Sven Kayser...I asked him now on Facebook about the pictures.
 
[EDIT] He did say:
 
Please do.

Let's sum up major concerns/problems and unify/create a plan of actions.
 
We already decided to wait with mainline H3-H5-A64 ... which means old stable/legacy kernels/a10-20-xu4 (what else?) mainline should be rebuilt and what remains goes under nightly? Images can be made one board at the time, they can be made in exactly 4 days or not. Perhaps I should emphasize "approximately" more? Or remove this date since it only creates an extra pressure? Or is it ok?
 
This should be fun. For me, most of the time is even sometimes days are wasted and frustration or stress builds up to insane levels.

We know which kernels are not done and there is nothing we can do in a week(s)/month, so let's focus now only on userspace and kernels which are labeled stable ...  and what shall be removed from /download and dl. ?

Since we don't go out with mainline H3-H5-A64 major testing is not that critical, but things are rolling in that direction. With a delay.
 
I am aware we are not organized perfectly. It's also WIP

Yes - for sure - if it do help
with the Fake-6.0.1 Android...its inly a Kitkat 4.4 - so no KODI 17.5 - only KODI 16.1
Her are pictures from @tkaiser - maybe you can use them also? what did you say Thomas?

OK, I started the Sunxi wiki page ... http://linux-sunxi.org/Sunvell_R69
Is a pice of crap, yes I know.
Hi @guidol may I use your board images in the wiki?
Anyone interested in sent me info to fill the info.
Thanks!!

Yes!. It was the "&" at the end of the calls to the scripts. The 3 of them... Now i have too a "/tmp/botones.log".
 
With that and the "sleep.time(0.1)" at the end of the while, all works fine.
 
Thank you both!!!

Only on H2+/H3 boards (sun8i architecture) our RPi-Monitor installation routine will detect this and installs improved templates (should work with both legacy and mainline kernel, at least I added/tested this last year). No other platforms (PC2 --> H5 --> sun50i) are supported in this way, especially the background daemon collecting detailed CPU (and voltage) information isn't installed.
 
I do not plan to change anything here since the above 'OPi-Monitor mode' was mostly implemented to let users help us supporting new boards (especially needed for the overheating Banana Pi M2+ back then). The other reason why I will not touch this is since work on Armbian got so frustrating especially the last days.
 
My templates were uploaded to Github https://github.com/armbian/build/tree/master/packages/bsp/armbianmonitor/templates -- sun8i dev would be the best starting point.

BTW, you have an ampersand missing :
nohup python /home/orangepi/scripts/botones.py > /tmp/botones.log 2>&1 & And you don't have any /tmp/botones.log created ? Strange  ! Add some print() in the python script ...
 
Try also to change the first line from " #!/usr/bin/env python" to " #!/usr/bin/python"

My OMV installation routine was at fault (cause/fix), it only affects installations with IPv6 propagated through DHCP (that's why I did not notice since my lab is IPv4 only) and is fixed at least on the XU4/HC1 image in the meantime. Most probably only C2 image affected any more (and maybe C1 image).
 
Still waiting for C2 being usable with btrfs and next kernel in general. Then I'll regenerate the image. In the meantime affected users should take care that IPv6 is temporarely disabled when they boot their OMV image the first time.

Available for:
 
4.13.10 cubox (Cubox-i, Hummingboards)
4.13.10 mvebu64 (Espressobin)
4.9.58  odroidxu4 (Odroid XU3/XU4)
4.13.10 rockchip (Tinkerboard, MiQi)
4.13.10 sunxi (All Allwinner 32bit boards)
4.13.10 sunxi64 (All Allwinner 64bit boards)
 
https://dl.armbian.com/_misc/realtime-kernel

Requirements:

- Armbian OS. Ubuntu or Debian bases.
- root credentials

Download: *dtb and *image packages at a minimum and install them with dpkg -i *.deb ... If you want to stay on this kernel, freeze upgrades in armbian-config -> system -> freeze kernel upgrades.

Remember that those kernels are bleeding edge, made from upstream sources and may have troubles. Consider them as is/experimental, without end-user support. If you want to build them - patches are present but .disabled and might not apply cleanly with more recent sources without adjustements.
 
What is RT?

Don't lose hope.. I asked Steven Zhao on Ali in late sept.   His response:
 
steven zhao 17/09/24 20:19   Yes, we are purchasing the materials for Plus2E now, it will be on stock next month  
 

Just like on any Z28 (Pro) box. My personal opinion on 'working' on TV boxes: It's stupid from a developer's perspective for more than one reason (read here and below). That being said obviously you missed that Igor ordered the biggest Z28 Pro TV box variant (with GbE onboard) so if it's about choosing a RK3328 TV box that might maybe get supported status then it's clearly Z28 Pro and none of the other Z28 boxes that are all more or less the same hardware since following closely one of 4 Rockchip reference designs (check ROCK64 schematics there you find all 4 variants).

Yes. And not just here. We discussed this briefly here https://github.com/armbian/build/issues/798 but it was off topic and we didn't continue.
 
Shall we simply add this to armbian-config?

IMO we should consider shipping with
overlays=usbhost2 added to /boot/armbianEnv.txt by default for this board since zero disadvantages but only avoiding support efforts and 'reviews' ('With Armbian mSATA does not work'). Users don't read the fineprint, so let's fix this now and not later.
 
On a related note: I did some tests with zram and vm.swappiness=100 and this really looks promising. Could be a real improvement on those boards with low memory where we can ensure that no legacy kernels will be used.
 
Edit: Or maybe it's better to add ohci2/ehci2 nodes to the DT patch since referencing sun8i-h3-nanopi.dtsi there and activating usb3 by default can already be considered 'wrong' from a kernel dev's perspective (for reasons unknown to me these guys want to reduce 'user experience')

Yes, it's planned in about two weeks. https://www.armbian.com/

Most probably the heatsink wasn't that efficient and almost all those SBC enclosures are such an bizarre fail if it's about heat dissipation. I tested this years ago with a DHT22 sensor inside such a 'standard enclosure' and internal temperature was +20°C above ambient temperature around. Metal enclosures with direct contact to heat emitting sources like the SoC would be way more efficient than those 'traditional' approaches attaching a heatsink of any size and then cramping everything in a tiny enclosure without direct contact to the outside (for a good implementation see ODROID HC1 for example, but with all those NanoPi it also works excellent, a customer is attaching them directly to 'huge heatsinks' (screwed to the inside of rack cabinets with a thin thermal pad between SoC and the metal)
 
 
If you chose those provided within the last 2 months... they work flawlessly (personally tested over ten times each). But I should really stop to care about reports that affect crappy hardware (Micro USB for DC-IN)

Check your SD card and dmesg for 'read-only' messages. Man, this gets so booooooooring.

Well, that was what we observed one year ago on Orange Pi Zero prior to disabling wi-fi powermanagement (it reads off in your and @t.munzer's iwconfig output). Anyway new image finished uploading: http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz
 
In my opinion the fex file is fine now (looking at it not that much from an Armbian perspective but more having users of other projects in mind like H3Droid, RetrOrangePi, Lakka or @jernej's OpenELEC who hopefully can use the fex 1:1). For Armbian we would need mainline kernel/u-boot support contributed by volunteers.

That's Ethernet (so packets in this direction travel over the other interface -- which might have slightly improved your wifi numbers before, it's not that easy to correctly measure wifi performance when more than one interface is active and two or more interfaces are connected to the same subnet). Anyway we already know we can't expect wonders from XR819, it works somewhat ok-ish (see @t.munzer results) and anyone wanting to have decent Wi-Fi performance can always add an RTL8211AU 2x2 MIMO dongle anyway (well, that needs most probably mainline kernel support so someone has to hack together a .dts and submit upstream)
 
Ok, then blue and visible led is connected to PA15 (and labeled wrongly red) and there's another rather invisible led connected to PL10 and wrongly labeled green. To make things worse I decided to now label the blue one green just to get almost consistent boot behaviour on all H2+/H3 boards (blue led labeled green will light up when kernel starts to load, at the time login is possible it will blink 3 times and then turn into solid mode again): https://github.com/armbian/build/commit/6981e324192dd6aad06e9ebd1a21a4c2f5c47d32
 
Will now create the Xenial image again (just check the timestamps at the download location). So now two contributions are IMO needed to consider switching from 'community supported' OS image to fully supported:
Someone has to create a device page in linux-sunxi wiki Someone has to submit pull requests with u-boot config (576 MHz DRAM clock, 1008MHz CPU clock and MMC2 setting for eMMC) and a patch adding DT for the board (please keep in mind that 3.4 LTS kernel support ended already half a year ago)

Hi!
 
Yesterday i upgraded ugly Chinese linux to Armbian 16.04 LTS and tested h3control on it. All, except daemon installer, worked fine. Now daemon installer had been fixed. I need any help in testing of it on H3/H2/H5 boards with legacy/mainline kernels.
 
h3control - is a headless daemon/console tool to check and control CPU, DDR frequency and built-in temperature sensor via embedded http-server.
It distinguishes from Armbian tools (h3's consumption and monitor):
It doesn't rely on particular linux distribution. The only prerequisite is a mono. It tested with mono from 3.2.8 (released in Feb 2014) to 5.4 (current stable). It is a web app. App was designed for compatibility with many-years-old mobile tablets/phones. Built-in browsers from Android 4+ and iOS 7+ are fully supported.  
Here are two kinds of one-line installers:
- launch h3control in terminal:
wget -q -nv -O - https://github.com/devizer/h3control-bin/raw/master/public/h3control.sh | bash - install and launch h3control daemon:
wget -q -nv -O - https://github.com/devizer/h3control-bin/raw/master/public/h3control-install-daemon.sh | bash links: 
User/Install Guide and screenshots: https://github.com/devizer/h3control-bin
History and Whats New: https://github.com/devizer/h3control-bin/blob/master/WHATS-NEW.md
First topic on Orange PI forum: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=645
Source code: https://github.com/devizer/h3control
 
picture: 
 
Looking forward for feedback
Vlad
 
P.S. Please install mono first: apt-get install mono-complete

The nice thing when used this RAID variant in NAS situations on GbE equipped H3/H5 boards is that the larger the available DRAM the less you realize that IO write speeds are limited to below 40MB/s since all NAS writes end up in filesystem buffers first and will later be flushed to disk. So with an OPi Plus 2E or OPi Prime you can transfer up to 1.5GB of data at +70MB/s and only then it slows down to ~35MB/s. On the boards with less memory this can happen already after just a few hundred MB written.