chwe

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

And more fixes were added by Armbian too! Just the mali4xx/mali-midgard conflict was causing a flood of error messages in syslog, until @TonyMac32 found it and fixed it.

I haven't read posts here and install anything yet since I do try to get some rest on weekends ... It has been a busy week and upcoming looks even more. Fixing cosmetic issues on a forum has low priority and can wait for a while. In any case, I will seek help from theme designer since I don't want to spend precious weekends solving this. 

hmm... sounds familiar...  
 
 
btw.. the like looks a bit messed up (looks quite that they wanna implement more reaction possibilities - I think we had this once before but disabled it?).

quote is also a mess.. the button shows up random somewhere on my browser..   --> maybe a 'opera only' feature?  
 
 
 
 

I get a bunch of approval messages for stuff which is already approved..  From the experience I had before.. those didn't show up that much when they were approved by another mod before (not 100% but more). Seems once more that the UI isn't really friendly for low resolution displays like mine (13XX) but at least coding template works quite well even when not fullscale window.  Seems that there is a 'Add tag' feature which is broken:
Sorry, there is a problem There are no tags available Error code: 2S131/3  
 

okay, I try to explain the situation a little bit.. Armbian has 3 different kernels for most SBCs we provide images. Legacy (which is for the H3 board the 3.4.113 BSP kernel), next (kernel from kernel.org currently pinned to 4.14.y) and dev (kernel from kernel.org currently pinned to 4.16.y). 
 
On the normal downloadpage the maintainers provide images which are suggested for a different use-case. One of the main reasons why we suggest the legacy kernel for desktop usage is that it has hardware acceleration (e.g. when you use the MPV player, videodecoding happens on the VPU not CPU). In case you only use CLI and no desktop, video acceleration is mostly of minor interest therefore a more recent kernel might be more important than hardware acceleration therefore we often suggest to use the mainline kernel.
For example the 3.4 kernel is to old to build debian stretch images, but with the mainline kernel stretch images are possible (and you get the newer packages of some libraries provided by debian stretch). 
3.4 Kernel is EOL since a while and doesn't get updates anymore whereas 4.14 should get update at least until 2020. As soon as hardware acceleration is possible with the mainline kernel (see Bootlin mainlining the VPU), legacy images based on Allwinners BSP kernel might get dropped and Armbian will only provide images based on mainline. The reason why there are also legacy CLI images available is due to hardware which do not work at the moment (e.g. the camera interface is not supported by mainline yet).
You can also use mainline images with a desktop but you won't have any hardware accelerated videodecoding capabilities and therefore playing videos will be painful, and might only work on low resolution if at all. 
If you download a mainline image you get this warnig:

Cause we can't test everything for all the boards and every use-case armbian users think about, there might be bugs which we didn't found or which are not solved yet. The BSP kernel is better known and therefore devs know most of it's limitations. For mainline, we rely mostly on upstream plus a 'few' (for Sunxi boards this means ~100 )  patches to fix things which aren't mainlined (yet). With every kernelupdate those patches can break things or can get obsolete cause they're no longer needed, you can imaging that this can't be tested for every board and every use case (e.g only for H3, we provide stable images for 15 different boards). 
 
Depending on what you want to do on your display, you might not need hardware acceleration that much and mainline is fine for you. Test it and find out if it works well for you.

is based on Allwinners BSP kernel and therefore not mainline. Images based on mainline kernel is for example the right on the downloapage (Debian server – mainline kernel) or the ones under the 'other download options and archive' section called next or dev (whereas the nightly images are mostly untested and therefore only recommended for testing and not production use-cases). You might change the topic name as long as you use a legacy image.
 
from the tutorials you linked to:
 
I don't know if this statement is still correct or if there's a workaround for it but can this be an issue? The second tutorial you linked is about a HDMI display and from what I saw, yours is a SPI one so this tutorial might be not that useful for you. 
 
From what I saw you need to proper defined CS pins (one for the touchscreen one for the display). Are you sure that those pins are properly defined? It's more a generic answer since I haven't this display to test it. Maybe @yam1 a bit more precise can help you, since he did a lot of display stuff : 
 
 

is not mainline..  that's the old legacy kernel.
 
you might need to know which driver is needed for your display.. and which touchdriver... 

Here you have H5 mali DT node patch. Kernel side driver can be found on @Icenowy github page here. However, the biggest question is where to find appropriate userspace drivers if you care about licensing stuff. For private builds you can take them from anywhere you can find them, but it won't be redistributable. Don't forget that mali kernel driver version has to match to userspace version.
 
About how to add your own patches to build system - you can find some documentation here.

Hello Everyone, I would like to share my experience about how to boot Orange Pi almost silently in console mode (eliminate a lot of kernel messages on startup) without desktop and remove cursor blinking that can cause black rectangle appearing over white background, when painting to framebuffer. Many options that proposed as being able to reduce kernel messages on boot didn't work for me. So based on Armbian documentation I started to experience with armbianEnv.txt file in the /boot folder. The extraargs setting was not part of the default armbianEnv.txt file, but appeared in BOOT.CMD file. The setting
 
extraargs=vt.global_cursor_default=0 quiet
 
solved both above problems. Hope this will be helpful for somebody else.

All of the benchmarks on libre.computer were ran on the standard bl30 from Amlogic's openlinux site.  The blob I have is for my testing only since using them and advertising the results is cheating.

Hi, chwe
    Thanks for your remind. It indeed is our mistake. We have updated the commit and reserve all of the original information.
    https://github.com/TinkerBoard/debian_kernel/commit/de8ac6cdee368fd27bea9ecaa9149087029ea52c

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.  

Hello,
 
I did some testing with the Nightly Build Image for the Odroid HC1 / XU4, and made 2 observations:
 
First a nice one:  Seems the idle power consumption with the Nightly Build is even lower than with the current Stable Version (measured with an "ELV Energy Master", and very same Hardware for HC1 / SD Card / HDD in standby):
4.0 - 4.1 Watts with 5.43.180423 nightly, Debian stretch, kernel 4.14.35-odroidxu4 4.3 Watts with 5.41 stable, Debian jessie, 4.9.86-odroidxu4 During the boot process however there seems to be some 12 seconds delay on the Odroid HC1, which does not occur on a XU4.  Seems the Kernel is running into some timeout?  (Perhaps because the HC1 is headless and has no HDMI?)
 
Here the "dmesg" output on the HC1 (with ARMBIAN 5.43.180423 nightly):
[ 2.269968] exynos-gsc 13e00000.video-scaler: Linked as a consumer to 13e80000.sysmmu [ 2.270023] iommu: Adding device 13e00000.video-scaler to group 6 [ 2.271205] exynos-gsc 13e10000.video-scaler: Linked as a consumer to 13e90000.sysmmu [ 2.271263] iommu: Adding device 13e10000.video-scaler to group 7 [ 14.599003] device-mapper: uevent: version 1.0.3 [ 14.599314] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com And here the same on the XU4 (used exactly same SD Card): 
[ 2.265929] exynos-gsc 13e00000.video-scaler: Linked as a consumer to 13e80000.sysmmu [ 2.265984] iommu: Adding device 13e00000.video-scaler to group 6 [ 2.267160] exynos-gsc 13e10000.video-scaler: Linked as a consumer to 13e90000.sysmmu [ 2.267219] iommu: Adding device 13e10000.video-scaler to group 7 [ 2.291153] device-mapper: uevent: version 1.0.3 [ 2.291472] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com Up to this point, the messages in "dmesg" match line-by-line on HC1 and XU4 (of course, the timestamps vary slightly).
 
The Odroid HC1 with the current stable build image (5.41, kernel 4.9.86) doesn't not show such a delay in the boot process.
 
Not a big deal, but I thought to report it here ...

Summary of diff between development and master + related from armbian-config. I left out some minor changes:
 
- Network manager is now by default except Espressobin which needs systemd network. Ifupdown can still be overridden if one wanted.
- upstream patches for many kernels ...
- Ubuntu Bionic target (under expert mode, fully functional testing version)
- RFC for firstrun config to set IP or connect to Wireless. Using Network manager method now.
- switched NEXT to 4.14.y on Odroid XU4
- kernel packaging support for 4.17.y
- RK3399 kernel upstream updates (can't produce bootable image yet)
- docker support for RK3328 DEV kernel
- sign "sha256sum.sha" instead of "armbian.txt"
- add missing dependency libpam-google-authenticator to armbian-config
- reworked SSHD management, kernels and nightly/stable switching with armbian-config
- added upgrade to desktop from armbian-config (only generic desktop)
- added CODA module on imx6 and upstream patches. Requirement for video acceleration but ... haven't got it working under mpv
- Olinuxino. Enabled USB within atf, sane RAM speed
- icon pack moved to our repository. (Note to myself: remove .deb from build script)
- created desktop package per release, architecture independent, could be installed on top of any Debian / Ubuntu base
- removed old way of making desktop
- moving Odroid away from their mainline sources with a patch
- added bionic to the beta repository, soon to main
- added Z28PRO to the RK3328 kernel source (tested, working everything but wifi)
- meson64 default becomes 4.14.y, next 4.16.y, DEV master
- sunxi-dev pinned to 4.16.y and u.boot to v2018.03, most of the patches were adjusted
- S56818 is breaking. pinned to last known working kernel 4.14.15
- fixed eMMC install on Rock64
- adding eMMC support for Neo and Neo2 to make images usable for Core / Core2
- added Odroid C1 mainline config (DEV, it should boot but it doesn't)
- removing GKSU and rework dependencies

Those are areas where we should be focusing. Some are important now, some later. I have done many tests but it's impossible to predict and catch everything. Latest changes will show up in tomorrow's beta repository update and those images which are enabled for the nightly remake. No larger moves until testing and the big merge from my side.
 
I haven't checked:
- how changes will affect firstrun and armhwinfo
- networking in general. I did only a few tests and notice at least one power management set to "on" ... I think on OPI Prime.
- haven't made OMV images

It is a media player on OpenELEC so yes it is idle almost all the time.  Some details are below. 
 
It was about 64 °C now it is about 59 °C. 
 

Attachments are not visible... 
 
to my knowledge, we don't deliver wiringPi with armbian.. So, did you install it or do you use TinkerOS (whitch is no part of Armbian)?
 
From a quick google search, I might be wrong, but tinkers wiringPi has a 'fallback' to sysFS (/sys/class/gpio) and RPis wiringPi is based on gpiomem (writing direct to the SoCs registers). sysFS in known to be slower than gpiomem. 
 
in development branch we do provide a rootless gpiomem access, but at the moment you have to build those images on your own.
https://github.com/armbian/build/pull/907
 
You might build your own image and test wiringPi again and look if this speeds up the process. Just as a side-note, I've only tested if it works, I didn't do any performance tests, simply cause I don't have any oscilloscope to 'benchmark' the speed.  
 
How to build images:
https://docs.armbian.com/Developer-Guide_Build-Preparation/
How to switch to development branch:
LIB_TAG="development"
 
Edit:
and otherwise, you can test ArmbianIO from @Larry Bank which is also based on sysFS but might be a bit more 'lightweight'.. Not sure, cause I didn't do 'benchmarking' and I don't know if somebody ever tried to get at it's limit.. 

Attachments are not visible... 
 
to my knowledge, we don't deliver wiringPi with armbian.. So, did you install it or do you use TinkerOS (whitch is no part of Armbian)?
 
From a quick google search, I might be wrong, but tinkers wiringPi has a 'fallback' to sysFS (/sys/class/gpio) and RPis wiringPi is based on gpiomem (writing direct to the SoCs registers). sysFS in known to be slower than gpiomem. 
 
in development branch we do provide a rootless gpiomem access, but at the moment you have to build those images on your own.
https://github.com/armbian/build/pull/907
 
You might build your own image and test wiringPi again and look if this speeds up the process. Just as a side-note, I've only tested if it works, I didn't do any performance tests, simply cause I don't have any oscilloscope to 'benchmark' the speed.  
 
How to build images:
https://docs.armbian.com/Developer-Guide_Build-Preparation/
How to switch to development branch:
LIB_TAG="development"
 
Edit:
and otherwise, you can test ArmbianIO from @Larry Bank which is also based on sysFS but might be a bit more 'lightweight'.. Not sure, cause I didn't do 'benchmarking' and I don't know if somebody ever tried to get at it's limit.. 

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.

done, maybe your first hijack post should also be here.. but it somehow good in both threads.. 
 
For me an more interesting point is that RPi hides 'all the magic' behind threadX, but we have somehow a similar situation with Amlogic when they only provide blobs for hardware responses/interaction.
 
Part of me thinks that people who buy by  >GHz=better performance deserves it to get cheated on, but from my more serious side... It's not the right thing to cheat on your customers.. Remember the shitstorm apple got for the clockdown of their older iphones when the battery got bad? It's not that it is the false thing to avoid that you users got fooled by a bad battery, but it's completely wrong to not inform your users that this happens. If the s912 can only reach 2GHz in a single core mode, I'm fine but lie to the customer is a shot in your own knee. It needs a lot of time to rebuild your reputation, probably not that much an issue for the 'cheap as hell' tv box, but in case you want to be one of the 'premium' TV-Box SoCs it gets problematic.  They have a nice SoC for TV boxes with a VPU which seems to be powerful enough for a lot of this use cases. So no need for cheating. 
 
99.9% irrelevant..  (assuming that 'few' is in the same range than the multiple of millions) [/smartass mode off]. IMO the main reason you should care about linux users is that you also get free development from experienced kernel developers. E.g. Allwinner could rebase their android kernel on a mainline kernel where a lot of their SoCs features are properly mainlined and then add their 'crap' to have an enhanced recent kernel... I'm somehow fascinated that the linux-sunxi community is so patient in mainlining their SoCs even when AW showed multiple times that they don't care (I know they stopped to actively avoid people from contributing by sharing parts of the documentation but they could do it better without that much effort).. 
 
IMO the 'next' generation of TV boxes will combine something like TV-box (with recording function) and cheap home NAS with acceptable performance. People don't want to have multiple devices for such tasks, so at least USB3 or a sort of pci is a must, that's where I see the H6 in front of the current Amlogic SoCs (despite the fact that their PCI implementation seems to be 'broken by design' and I don't know how well their VPU stuff performs). The RK3328 seems to be developed with this use-cases in mind and might perform well. Imagine an adroid TV-Box with something like OMV working in the backgroud which can be configured through the gui or browser... I'm sure.. people would buy it..  If you have all the graphics/decoding stuff on the GPU/VPU, the CPU should be fine to handle some server tasks in the background without affecting UI and their applications that much. 

I'm not so sure about that. I think the best option would be to have a thread where the OP holds the link to the scripts and the instructions, and gets updated with every new release, so users don't need to search through all the thread for the latest version. And having you update the OP with each bug fix or new release would unnecessarily slow down the workflow and make you work. I think it is better if I start a new thread for that, focused only on providing the scripts and commentaries/support about them, and we keep this one for informational/research purposes.
 
(BTW: I don't think it would be a bad idea to create an Armbian community wiki for "unofficial" info like the one provided in this post, apart from the "official" docs).

To be honest if they drive the chip at higher voltages like 1.3V like the Allwinner H3, I think they can hit 2GHz. However, power consumption, heat, and reliability become concerns. I think they originally tested at 2GHz and made all the marketing materials but had to scale back to make power consumption and other factors look pretty. Amlogic is pretty ahead of the curve in low cost quad-core A53 SoCs. We just started getting competitor chips last year which means Amlogic is almost 2 years ahead of the curve with S905.

Seems that hardware accelerated Videodecoding & GPU usage is the new 'hot topic' at the moment. A lot of this stuff is discussed in various topics and threads and subforums here. As nice at it is to bring this topics up, it's hard to follow them across the forum and when those questions come up from users you have to link the to a bunch of topics which they probably don't read cause it's simply to much to read (I now that this is a shitty argument, but reading is boring for most people in those days..  ). 
So why does it make sense to open another thread targeting this topic? This should summarize the things that work, no suggestions what could work, should work, may work and hope that it could work.. That's what all those other threads are for...  And it's focused on Armbian not raspian, not android, not what ever OS you use on your board. Focused on Armbian means also, the board has at least wip status and you can download images from our downloadpage.
Theres a lot of ongoing topics which might find their way into this thread as soon as this stuff is ready (e.g. hardware accelerated video encoding on allwinner in mainline).
 
Basics:
For the most more experienced users it's obvious, video decoding doesn't happen on the GPU which means Mali Support != good videodecoding performance (this might come true when those VPU stuff from mali finds its way into the SoCs we support - that will make things even more confusing ). As a side-note for the KODI users, you need also GPU support to bring it up (OpenGL ES 2.0 as described in their wiki). But videodecoding happens on the VPU not CPU nor GPU (software accelerated videodecoding is possible on the CPU, but the CPUs on ARM boards are mostly not powerful enough for software decoding in high-resolution). The GPU is responsible to keep load from the CPU for desktop usage but not for the video stuff (despite some special hacks).
A second topic which might be important, even when hardware accelerated video decoding is possible from userspace, this doesn't mean every application on your Armbian SBC can benefit from it (e.g. browser etc.).  A bit old, but I think this explains things better than I can do:
https://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
 
Allwinner:
Currently, VPU support is only possible with the Legacy Kernel (3.4.113) and very limited by using desktop builds of Armbian. Behind the scenes Cedrus is responsible for the usage of the VPU. Under Armbian hardware accelerated videodecoding is possible by use of the provided MPV player. To Summarize it:
Legacy & Desktop images only MPV player uses it H3 & A20 SoC As far as I know, nobody tried the new drives for mainline yet on armbian. 
 
Rockchip:
RK provide a lot of stuff to make HW acc. video decoding possible with their 4.4.x legacy kernel. The efforts taken to bring this to armbian can be followed here: https://forum.armbian.com/topic/6506-tutorial-3d-video-acceleration-and-opencl-in-rk3288-boards-with-new-44-default-kernel/
 
At the moment hardware accelerated video decoding is possible with RK3288 SoCs. Supported is
Hardware acc. video decoding by using gstreamer (up to 4k@30fps HEVC) H.264 HW acc. videodecoding in chromium browser (no VP9) by using MPV video decoding happens on CPU (up to 1080p@30fps HVEC by 80-90% CPU load) and accelerated display layer through EGL. That makes a huge difference in playback smoothness over the stock unaccelerated MPV. openCL (1.1) and openGL ES (3.2) is supported Chromium supports webGL HW encoding is also possible, in addition to Gstreamer, through a custom FFMPEG (included in the package from the referenced tutorial, although undocumented) All this stuff is at the moment not provided by a stock Armbian, but @JMCC wrote an installation script for Ubuntu Xenial:
 
 
Exynos 5422
Exynos 5422 which can be found in Odroid XU4 (HC1/HC2 too but there's no HDMI output) has a less powerful VPU than the RK3288 but hardware accelerated video decoding and mali support is possible as discussed here.
OpenCL (1.1) and openGL ES (3.1),  with excellent performance thanks to the hexa-core Mali T628. MPV, by default it works like in RK3288: SW decoding and accelerated EGL display. But you can add the "-hwdec" option to get HW decoding through the v4l interface (H.264 only: tested up to 1080p@30 to work well, 1080p@60 so-so). Chromium supports WebGL and accelerated H.264 video decoding. 
Emby Server
All this stuff is at the moment not provided by a stock Armbian, but @JMCC wrote an installation script:
 
This thread is supposed to be updated over time as soon as things are implemented in Armbian or proper tutorials are available to do it on your own. IMO development discussion for support shouldn't happen here (this should happen on threads dedicated to a specific board/kernel) and as soon as it is confirmed to work write it here and I'll update this post to get the latest news on the starting post which makes it easy for the 'lazy' ones to get an overview of the current status for a specific board/soc/kernel. I might miss part of the things which are currently running and I'll happily update it when someone points me to those threads or writes a short summarization (preferred ) below this post. I suspect that hardware accelerated video encoding will also come up soon, so this might be also added in this thread as soon as proved results are available.
 
Side-note: I'm not sure if we should place this thread here (General chit chat) or in the Research guides & tutorials section. Cause this is more a overview and not a guide it's here, but might change in the future (depends on other opinions). @JMCC I have in mind that such a summarization was on your 'to-do' list, feel free to correct & add things I might missed here. 
 
Side-note II: The thread only represents work on top of 'stock armbian' @balbes150 work which is done for TV boxes is highly underrepresented here.  Feel free to add your opinions and additions directly into my post (as mod you should be able to do it directly). 
 

armbian-config -> system and security settings -> switch to alternative kernels

no, that's the original.. and actually also present in ours, cause we don't install the needed drivers, it is (at the moment) useless. In case you go for the OV5647 camera, you have to change it to something like: 
camera0: ov5647@36 { compatible = "ovti,ov5647"; reg = <0x36>; clocks = <&ext_cam_clk>; status = "okay"; port { imx219_out: endpoint { remote-endpoint = <&imx219_in>; data-lanes = <1 2>; }; }; }; camera1: imx219@10 { compatible = "sony,imx219"; reg = <0x10>; clocks = <&ext_cam_clk>; status = "okay"; }; Cause the port names in the rest of the DTS (where those ports end) are named imx219.. this should work... Actually a proper naming like camera_out would end in less confusion..