manuti

Thank you for informing us, will be noted. I am not sure we will be able to fix this in a time frame we have for a next release. In a mean time you can use a kernel 4.19.y images which should work without issues.
 
Those drivers are mainly maintained upstream. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS?h=v5.4.15 or by 3rd party.

I never tested it with 256M as I only have 512M units.
 
It should be fixed in this branch: https://github.com/armbian/build/tree/rockpis-fix-256m-boot.
If you can build the image yourself then try it - otherwise it should make it into Armbian 20.02 release.

Thanks Piter it works with the changes. I made a minimal image.
 

Well, the overlays actually work in this kernel 😜
 
It's just that they need to be Armbian style and not Radxa's so overlays for waveshare LCDs need to be named "rockchip-*.dtb, placed in /boot/dtb/rockchip/overlays folder and referenced in /boot/armbianEnv.txt's overlays stanza.
 
Dynamic overlays are not supported.

The first RC Images are out for Armbian 20.02.     We need your help testing Supported Boards for this release.   The download site is already configured for the RC1 images as the default download.  (We intend to improve this process in future releases, and provide separate download links.)
 
Here's how to help:
 
download and configure our testing tool (currently in alpha state) identify supported boards you have on our test tracking google sheet Run testing tool Perform any additional independent testing that you can Update test tracking google sheet with your results Please share major issues on our Armbian 20.02 (Chiru) Release Thread  

I did not test it with LCD but... looking at the last post in the discussion you linked one cannot expect it to display cli on LCD without programming it themselves as it is using SPI and not the DSI interface.

Buy!
 
I personally have HC1 for almost two years and no problems. Alternatively, you might think about HC2 if 3.5 inches will interest you in the future, especially if you need something above 5TB at normal prices it will be a better solution than 2.5.

As for OS, install Armbian based on buster but with 4.14.y kernel because currently 5.x has big problems with HC, it doesn't boot at all. But 4.14 is not a problem because some time will be supported.
As for samba, stretch has 4.5.16, buster has 4.9.5 If you need 4.11.3, you will need to install samba from bullseye / sid sources.

Buy a decent PSU, don't save !!!
I also recommend buying a branded A1 / A2 SD card.
If you are thinking about using a USB port, it would be good to have a HUB with power. In general, imho Odroid has something of poor quality USB ports, quite loose and likes to have problems with pin contact, sometimes you need to bend the metal plates for better contact but these are random cases. My HC1 works well with the rf receiver and the USB sound card.

After buying it is worth checking if the Firmware is new, if not update ... https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

My armbian HC1 handles omv, pihole, kodi, xrdp and chromium. If you have fast hdd / ssd then getting 80-100MB/s should not be such a problem with SMB.

You can also think of a uart-usb cable especially dedicated to odroid just in case.

Generally it's ok and stable, I do uptime 20/30/50 days.

The latest libgl1-mesa-dri upgrade brought with it panfrost to the desktop
 

this is just a quick note that in my experience the amount of tv boxes with fake specs has grown quite a bit in the last months and that this is something to always have in mind when getting a box for a surprisingly cheap (i.e. quite a bit cheaper than usual or most of the other offerings) price - you might be lucky and it will be a bargain or you might hit one with fake specs. some examples i saw recently: a qplus 4g ram / 32g emmc ended up to be 2g ram and 16g nand, a h6 box sold as 4g ram / 32g emmc ended up as 2g ram / 16g emmc, a x96mini 2g ram / 16g emmc ended up at only 1g ram / 16g emmc, a r39 2g ram / 16g emmc with rockchip rk3229 ends up as 1g ram / 16g emmc and an allwinner h3 cpu and so on. the fake specs are not that easy to spot: in android they even fake the storage size shown in the storage settings and with a terminal installed even the "free" command tells you most of the time that the memory amount is proper. what usualy works for storage is "cat /proc/partitions" and watching for the device itself (for instance mmcblk0) - this also quickly shows you if its emmc (=mmcblk) or nand (=nand) and for memory "dmesg | grep -i mem" (do this immediately after booting android, otherwise the memory lines from the bootup might run out of the log buffer) - both of course called in a terminal app. booting one of balbes150's armbian images usually quickly shows you the real specs of the box too.
 
good luck at not ending up with fake boxes and best wishes - hexdump
 
p.s.: one thing to keep in mind is that allwinner h6 boxes always only can use 3g ram, even if they have 4g installed - this is a limitataion of the soc ...

Thanks for providing the new Buster image (5.4.7) for Orange Pi One Plus. All the essential stuff works well, giving me new software possibilities.
 
As a technical feedback, I'd just like to mention
1) the red light keeps shining (instead of turning green, but Armbian runs very well, anyway)
2) an attached monitor doesn't receive any signals (but I prefer SSH anyway)
3) the console keyboard layout wouldn't accept any changes (but using SSH, that doesn't make any difference now).
 
Everything else in armbian-config worked fine. Great tool!

So the main Armbian page now lists Rock Pi S and has an unofficial image. Rock Pi S page
I can't see any information about what works and what not. I'm thinking about purchasing this board. Can somebody tell me how well it's supported?
I'm using Armbian on my Cubieboard 1 at the moment, and I'm really fond of it, so it's a nice pro if it's supported there.

Probably, depending on your content type and target device.  I did some rudimentary testing with transcoding on the NanoPi M3, and it technically worked. 
I had stability issues though, so I switched to a small/cheap x86 box that supported hardware transcoding.

I run a Plex server at the moment, on an XU4.  I'll have to try this out on my test board and might have to migrate if it as good as advertised.

As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
 
Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
 
However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
 
So this is a step-by step guide on how to make everything work:
 
0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
 
>> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
Hold the ffmpeg packages, so they don't get upgraded:  
$ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
Restart the service:
$ sudo service emby-server restart  
Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
 
 

 
And that's it!
 
As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
 
Enjoy! And please, share your experiences and comments here.

The ffmpeg provided in the thread above should work, if you are using Debian Stretch. Please follow these steps:
Install the ffmpeg packages, and hold them to avoid upgrades, as described in the thread above Make sure your user is part of the "video" group: sudo usermod -aG video <yourusername>  
Then reboot, and try the following command line: ffmpeg -i <infile> -an -vcodec h264_v4l2m2m -b:v 2M -pix_fmt nv21 <outfile>.mp4  
Post here the results. 

Hello, 
I am the happy owner of the Odroid HC-1 running Armbian currently. Is there support on the Debian side of things regarding this devices ability to encode video using ffmpeg? Ive been trying to find instructions on how to compile the code myself

The UN-official, UN-supported, UN-timely, UN-derrated...
Exynos 5422 MEDIA TESTING SCRIPT
 
Yes, the script is somewhat untimely, because it comes when including kernel 4.14 in Armbian next images is getting troublesome. And underrated, because this old SoC seems to be losing the focus of attention in favor of some more modern powerful ones. But it is still a great SoC, and it is worth trying to get the best out of it.
 
The script will provide the installation of all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL,VPU decoding/encoding acceleration through MFC, and GLES 3.1 / OpenCL 1.1 support.
It will also install two media players (MPV and Kodi stable) and FFmpeg, all of them using VPU acceleration.
Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple).
Two additional small packages, that have no big interest from the developer prospective, but I find them interesting to play with: Support libraries for commercial web video streaming (tested with Netflix), and a simple Pulseaudio GTK equalizer using LADSPA.
 
Since all the features require the 4.14 kernel to work, the script will also give the option to install an archived 4.14.43 Armbian kernel, in case some other version is detected in the system. Of course, the best option is to use armbian-config to perform a kernel upgrade, but we are providing the archived version just in case the 4.14 packages disappear temporarily from Armbian repos.
 
Also, this script can be tailored for desktop or headless installation, by selecting the appropriate options in the main menu.
 
Here is a more thorough documentation:
>>> DOWNLOAD LINK <<<
Instructions:
Download the file above
Untar it: tar xvf media-exynos5422_1.0.tar.xz
cd exynos5422
./media-exynos5422.sh
 
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!

In theory, yes, in practice there may be little power. Although I've heard that some use, the same gutters as XU4, HC1, HC2 so look for information about XU4/HC and plex.
First you would have to take care of hardware support ... 
 

Hi. I use the NanoPi M4V2 as main desktop. Works great with the default kernel and the media script from jmcc.
Video playback for youtube is 1080p 30fps or 720p60fps. While video files up to 4k can be watched. 

In mainline we're working on getting good video playback. Now that only works in default kernel, but GPU drivers now work in mainline.

I've got many other sbc's. None that is this powerful, has such good software, and great I/O with the PCIe gpio's.
Greetings.

Hello,
 
a few months ago I wrote a tutorial to enable the 7" touch display for Banan Pi and Banana Pi Pro.
Unfortunately the files (*.dts e.g. sun7i-a20-bananapro.dts) have changed and I don't know how to integrate the patches in the current armbian version.
 
Does anybody know how to do it?
 
Is there already a overlay to enable it?
 
Thanks.
 
Steffen
 
 
 

@raschid that ONLY  the same dtb-problem as in 5.4
I copied my changed sun8i-h2-plus-sunvell-r69_guido.dts from the 5.4 kernel to the 5.3 buster installation via ftp 
 
then compiled it with kernel 5.3 as .dtb
dtc -I dts -O dtb /home/guido/r69_dts_dtb/sun8i-h2-plus-sunvell-r69_guido.dts -o /home/guido/r69_dts_dtb/sun8i-h2-plus-sunvell-r69_guido.dtb backuped the 5.3 original .dtb
cp /boot/dtb/sun8i-h2-plus-sunvell-r69.dtb ./sun8i-h2-plus-sunvell-r69.dtb_org_53 and inserted the new compiled .dtb into /boot/dtb
cp sun8i-h2-plus-sunvell-r69_guido.dtb /boot/dtb/sun8i-h2-plus-sunvell-r69.dtb after that I deleted the follwoing lines from /boot/armbianEnv.txt (because the overlays are included in the dtb)
overlay_prefix=sun8i-h3 overlays=cir analog-codec now reboot and you will have analog audio (and cir) also in kernel 5.3 (Ok I got debian buster and not ubuntu bionic):
Welcome to Armbian Buster with Linux 5.3.13-sunxi package bsp-kernel[19.11.3] u-boot[19.11.3] dtb[19.11.3] firmware[19.11.3] config[19.11.3] branch[current] root@sunvell:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: allwinnerhdmi [allwinner-hdmi], device 0: 1c22800.i2s-i2s-hifi i2s-hifi-0 [1c22800.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 I will attach the compiled 5.3 version which you could copy to /boot/dtb  and reboot - I think the "debian" version 5.3 should work with ubuntu 5.3
(and dont forget to kill the 2 lines in /boot/armbianEnv.txt)
sun8i-h2-plus-sunvell-r69.dtb

In the new year, I plan to focus on improving and developing Armbian-TV  (Armbian-TV is a version that is based on the official Armbian, aimed at improved support for media capabilities and ease of use by ordinary users) support for the platforms Rockchip and Allwinner  (perhaps a few more platforms will be added that are not yet in use). To do this, I have already ordered several popular models based on rk3399 (NanoPC T4, RockPi 4, Renegade-Elite), in a complete set with obligatory Support of nvme carriers (I consider this support essentially important, for transition of TV boxes and SBS to the category of mini-PC, as highly effective and improved replacement of the usual PC). I'm plan to buy several more models on Allwinner (I'm still evaluating the capabilities of the selected models). 
I had plans to buy some more models based on rk3399 from other manufacturers, but there were problems with delivery and / or payment for my country.
 
If anyone has any suggestions for models that I should consider, I'm willing to listen to reasonable descriptions of the models.

First of - massive thanks to@jernej, @hexdump and @balbes150 for making these devices useful!
 
I have two TV boxes that successfully boot balbes150's armbian distros:
 
The first one is called T95max+
This is a quad-core Amlogic S905X3 device
I have 4G RAM/32G rom version.
Booting armbian with meson-g12a-sei510.dtb,
eth0 works
 
I quite like this box, it's cheap on aliexpress,
it's easy to open, got a small-ish board,
real 4G RAM (not like the H6 one). Will be building
a compute rig of several of these!
T95max - I foolishly thought it'd have the same
hardware as the first one but alas it's an Allwinner H6
 
Using the RK_AML_AW repo with U-BOOT-TANIX-TX6
and sun50i-h6-tanix-tx6.dtb - booting successfully!
Many thinks to the abovementioned guys for getting this
one covered as I was preparing to toss it to the bin ;
 
It's a 4G RAM but only ~3 available, HDMI+sound+eth0
work. This one is crappy as a TV box, only does 720p
max in android so I would no recommend it. But it will
be useful after the "upgrade"

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
@balbes150 I love your choice of the test clips! ;

This website might be useful in this context: https://linuxjourney.com/

Hi there,
 
I was wondering if there is a GPIO generic Python library somewhere for Armbian?
I think I remember that the pins are not always announced the same way on Armbian and on OrangePi distros.
I have seen this effort by @chwe, but is there anything else?
 
Thanks.