jock

You're welcome
 
This is actually not possible with the openvfd driver because it is not wired to the kernel led framework but is a totally custom module that just exposes the hardware to userspace.

It would be nice to have a proper kernel driver for such device. As far as I remember, it uses a i2c-like bus with some minor differences; I looked into some time ago, but had to give up due to not enough time, but a proper driver would wire the led chip hardware with the kernel led framework to exploit all the kernel triggers and goodies.

You're welcome
 
This is actually not possible with the openvfd driver because it is not wired to the kernel led framework but is a totally custom module that just exposes the hardware to userspace.

As this is not orange pi 4 that is being used, moved the thread to community forum and removed orange pi 4 label

It is quite common that boards actually like slight overvoltage. This is last but not least to compensate for voltage drop across connectors, wiring and the PCB itself.
As an example the official PSU for Orange Pi 5 boards, while being marked as 5vdc output, in reality output around 5.3 volts.
Also cellphone chargers are not recommended since they are not designed to handle variable but constant charging loads. Also voltage very likely drops well below 5 volts under load.

@Jaisere Hello, I wonder why you are using an image with the legacy 4.4 kernel, which I don't maintain anymore. That is an ancient kernel supplied by the vendor and it is several years old; the vendor (rockchip) maintained up to a couple of years ago, but now it is totally deprecated and unmantained. The only usefulness for that kernel is that it works with the internal NAND flash.
 
Use images with current kernel (at the moment, current version is 6.1), which is mainline kernel. It does not support NAND, but it is maintained and supports practically everything.
 
 

I bet: your internal flash is NAND and you are installing the image in the internal flash. Read the first page for more info.
Use sdcard and mainline kernel if you don't want up to date kernel and opensource drivers.

Yes
Yes, but you won't get any lima or panfrost anyway, 4.4 is way too old kernel. Also Panfrost is of no use, since it does not support Utgard (Mali-400) but only Midgard and above

@Jaisere

you welcome.  Just grab the boot folder from a working image and put into the linaro one. then burn this " frankenstein"  image with multitool.
But I repeat, if you want latest patches use the @jock 's very last images on a sd or usb and you will be surprised how amazing are those boxes

Don't forget to add a like to the posts, it help good consideration and reputation of the authors of this thread on the forum. Ty

@ego worker Now I'm checking edge 6.6.7 kernel and it works like a charm: made some stress tests with openssl speed -multi 4 while running KDE and hardware video decoding with no particular issues
My eMCP reads at most at 28.4mb/s in DDR mode, sometimes also times out, but it is a scrap board with plenty of issues; decent and non-abused eMCPs read  up to 90mb/s in DDR mode.

@ktolisgr
Nand Is ONLY  supported on Legacy kernel
 
Stay on 4.x.x and everything will work.
 
This Is clear said in first posts and throught the whole 3ad but i know.....Reading Is boring and forum huge, better direct ask  thing already explained billion times !

Actually I don't know, but I think that tv box manufacturers do little to nothing adjustment on their android images. I think they deal with the software as little as they can do. Despite there are dozen of tv box brands out there, all of them have the same exact software, the only difference is the device tree to adapt little differences of the boards here and there.
 
Software support costs, and costs a lot, and tv box manufacturers have to keep the price as down as possible.

@Le Best Noob looks like your board is a new one; could you please post a couple of photos of the front and back?

You should not advise to buy shit, they are cheaper because:
* they are made of scrap parts, that often break after very short usage (see the emmc in the rk3318 thread)
* they have no kind of warranty
* the power supply is a joke, made of cheap components and very lousy - switching power supplies are one of the thing the more they weight the better; confront with a quality 5V/2A power supply and see the difference
* the HDMI cable is crap quality, often not capable to transfer CEC or collects any kind of interference at 1080p/4K
* the case is a bit of plastic, with little to no design for heat dissipation - right now I have a rk322x board here withing its case that reaches 97°C while simply installing a package with apt...
* many sorts of limitations to keep them as cheap as possible: no sd card UHS mode, no real shutdown/suspend, USB ports have limited power: be prepared to have headaches if you try to attach something that requires just a tiny bit more power like an external hard drive.
* wifi is a lottery and clearly tells you the general quality: you can find freshly made boards with wifi chips discontinued years ago!
 
Most of all: they have absolutely no software support; if you are able to run armbian on your tv boxes it is because some people within armbian and other projects spent their time for the fun of making it.
Tv box makers don't care at all, they just need to sell their cheap shit to make some profit. Some (not all) SBC makers at least in some way provide support, but tv box makers are mostly parasitic and should not be endorsed.
 
Now that you stated that about 20 pcs of different tv boxes run armbian, may I also ask you what you did in change for that for armbian? Because tv box makers obviously did nothing for armbian, still keeping up the servers infrastructure and the general maintenance cost real money to real people, and who pays that?

You should not advise to buy shit, they are cheaper because:
* they are made of scrap parts, that often break after very short usage (see the emmc in the rk3318 thread)
* they have no kind of warranty
* the power supply is a joke, made of cheap components and very lousy - switching power supplies are one of the thing the more they weight the better; confront with a quality 5V/2A power supply and see the difference
* the HDMI cable is crap quality, often not capable to transfer CEC or collects any kind of interference at 1080p/4K
* the case is a bit of plastic, with little to no design for heat dissipation - right now I have a rk322x board here withing its case that reaches 97°C while simply installing a package with apt...
* many sorts of limitations to keep them as cheap as possible: no sd card UHS mode, no real shutdown/suspend, USB ports have limited power: be prepared to have headaches if you try to attach something that requires just a tiny bit more power like an external hard drive.
* wifi is a lottery and clearly tells you the general quality: you can find freshly made boards with wifi chips discontinued years ago!
 
Most of all: they have absolutely no software support; if you are able to run armbian on your tv boxes it is because some people within armbian and other projects spent their time for the fun of making it.
Tv box makers don't care at all, they just need to sell their cheap shit to make some profit. Some (not all) SBC makers at least in some way provide support, but tv box makers are mostly parasitic and should not be endorsed.
 
Now that you stated that about 20 pcs of different tv boxes run armbian, may I also ask you what you did in change for that for armbian? Because tv box makers obviously did nothing for armbian, still keeping up the servers infrastructure and the general maintenance cost real money to real people, and who pays that?

Hi
I had heard that you can install LINUX on a TV BOX, so I got an X96 which has the RK322X CHIPSET.
Since I am a Hamradio and I did some tinkering I told myself that I would create an interconnected repeater with the X96 as a server.
After installation and configuration I was able to create my repeater which worked very well for more than three months.
Here is the photo of the interconnected repeater in working order:
 

 
I made a tutorial on my site where I described my configuration and installation of the system: https://www.dmr-maroc.com/Repeteur_sans_Raspberry.php

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs.
 
The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages.
Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders.
 
Preconditions:
Kernel should be 6.1 or more recent armhf or arm64 architecture Supported operating systems are Debian Bookworm and Ubuntu Jammy Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel  
APT REPOSITORY SETUP
To install the repository, just copy and paste the lines for your operating system in a terminal
 
For Debian Bookworm:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
For Ubuntu Jammy:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
INSTALL FFMPEG AND MPV PACKAGES
$ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv  
SETUP MPV CONFIG FILE
$ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf  
You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!
Enjoy!
 
Notes:
your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that  
 
 

Hello, first of all I would suggest you to avoid DietPI; there have been some circumstances were has been reported that credits were not due to the big work done here by armbian maintainers and taken without proper attribution.
This is sad to say, but until I hear the opposite, I woudl stay away and don't endorse such "distribution".
 
More about the hardware decoding and rk3318: legacy kernel is now completely deprecated and not suggested to be used at all. It is old and unmaintained code, plus standard linux tools won't work because it contains vendor-specific modules and paths.
 
You would rather stay stick to a regular armbian image with recent mainline kernel.
You could also advance to edge kernel (at the moment it is 6.6), but it is not necessary.
For the hardware decoding capabilities, I recently made an apt repository for both debian bookworm and ubuntu jammy that may be helpful to you:
 
That repository provides ffmpeg compiled with the right patches to work with hardware decoding, and the player of choice is mpv which is working pretty fine.
Unfortunately there is a bug for Mali 400/450 in mpv (or mesa) that causes the video to be pink-colored when played in X11 or wayland, but when run from virtual terminal is works fine though.
Also rockchip64 does not have yet the patch to enable hevc, something which I would like to fix soon
 

Post reserved

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs.
 
The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages.
Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders.
 
Preconditions:
Kernel should be 6.1 or more recent armhf or arm64 architecture Supported operating systems are Debian Bookworm and Ubuntu Jammy Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel  
APT REPOSITORY SETUP
To install the repository, just copy and paste the lines for your operating system in a terminal
 
For Debian Bookworm:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
For Ubuntu Jammy:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
INSTALL FFMPEG AND MPV PACKAGES
$ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv  
SETUP MPV CONFIG FILE
$ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf  
You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!
Enjoy!
 
Notes:
your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that  
 
 

Hello, for those still interested in hardware video decoding, I made a new thread introducing an APT repository to make installation easier for Armbian Debian Bookworm and Ubuntu Jammy distros:
 
 

Hello, for those still interested in hardware video decoding, I made a new thread introducing an APT repository to make installation easier for Armbian Debian Bookworm and Ubuntu Jammy distros:
 
 

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs.
 
The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages.
Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders.
 
Preconditions:
Kernel should be 6.1 or more recent armhf or arm64 architecture Supported operating systems are Debian Bookworm and Ubuntu Jammy Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel  
APT REPOSITORY SETUP
To install the repository, just copy and paste the lines for your operating system in a terminal
 
For Debian Bookworm:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
For Ubuntu Jammy:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
INSTALL FFMPEG AND MPV PACKAGES
$ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv  
SETUP MPV CONFIG FILE
$ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf  
You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!
Enjoy!
 
Notes:
your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that  
 
 

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs.
 
The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages.
Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders.
 
Preconditions:
Kernel should be 6.1 or more recent armhf or arm64 architecture Supported operating systems are Debian Bookworm and Ubuntu Jammy Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel  
APT REPOSITORY SETUP
To install the repository, just copy and paste the lines for your operating system in a terminal
 
For Debian Bookworm:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
For Ubuntu Jammy:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
INSTALL FFMPEG AND MPV PACKAGES
$ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv  
SETUP MPV CONFIG FILE
$ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf  
You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!
Enjoy!
 
Notes:
your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that  
 
 

That is intended to work that way, for an important reason: the bootloader is not just a mere bootloader, but installs complex code in memory and you don't know what it does. More on that: that code runs in a secure context, which is not accessible by anything, so you really don't know what it does and what it can do.
One clear example is the fact that the stock bootloader artificially blocks the rk3318 when it runs beyond 1.1ghz, while we have seen it is pretty capable of running at 1.3ghz perfectly fine like the rk3328.
 
The idea is to remove as much as possible of the proprietary blobs (ie: the stock bootloader) and provide open alternatives; tinkering with the bootloader may work now but surely will cause troubles when there will be an updated bootloader.
 
Your case with broken emmc is a different condition by the way, because you have limited alternatives. However there are no real secrets in the boot process, just some complexities and some of them are explained here