MX10.AC2N

@callegar@Willy Moto@MX10.AC2N
Ok, I double checked the cpu voltage supply and effectively it seems that in the latest device tree I pushed it way too low... The original device tree of my box said 1.375v@1.3Ghz, the voltage in mainline kernel says 1.300v@1.3Ghz and I set 1.200v@1.3Ghz. That is very good for temperatures and power consumption, but maybe it is a bit too low for stable operations.
 
I will rebuild the whole set of images, but in the meantime I updated the dtb deb package you can install that should fix issues: https://users.armbian.com/jock/rk3318/upgrade/linux-dtb-edge-rockchip64_22.08.0-trunk_arm64.deb
 

Yes, an adapter like that is fine; beware you need some basic soldering skills and your board must have accesible serial pads (usually marked with TX RX GND labels, in rows of 3 or 4 holes one after another) to get things done.
If you don't feel acquainted with electronics mind your choices, but surely a serial adapter like that is always handy when you need to do some debug on various devices (tv boxes and routers mainly, but also televisions, decoders, phones, ...)

@jock
Yes, for moment kernel v5.18 system run from 5h46 without freeze under 1.08ghz
Seems to be stable at 1.08ghz..

Yes. true!
Thanks for reporting, I need a definitive solution for that

No, it is led: Light Emitting Diode. The infrared receiver is not emitting anything, hence it is not a led.
Probably there are other variants of your board which have a led that must be react on remote controller activity.
Your board hasn't this led, but the chinese guy that wrote the dtb thought that the ir node may be left there.
 
That's not possible: /sys is a virtual filesystem exported by kernel itself.
Files in that directory does not really exist on partition but are generated by kernel.
 
This is what I get on my board (with a keyboard attached):
root@rk3318-box:~# cd /sys/class/leds/ root@rk3318-box:/sys/class/leds# ls input0::capslock input0::numlock input0::scrolllock working  
 And this is the content of working directory:
root@rk3318-box:/sys/class/leds# cd working root@rk3318-box:/sys/class/leds/working# ls brightness device max_brightness power subsystem trigger uevent root@rk3318-box:/sys/class/leds/working# cat trigger none usb-gadget usb-host kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 [mmc2] mmc1 activity default-on panic mmc0 mmc3 rfkill-any rfkill-none rc-feedback bluetooth-power hci0-power rfkill0 rfkill1 stmmac-1:00:link stmmac-1:00:100Mbps stmmac-1:00:10Mbps  

Sorry it was not 4 leds, but 3 leds in the original dtb:
leds { compatible = "gpio-leds"; power-green { gpios = <0xfb 0x00 0x00>; linux,default-trigger = "none"; default-state = "off"; mode = <0x23>; }; net-green { gpios = <0xfb 0x01 0x00>; linux,default-trigger = "none"; default-state = "off"; mode = <0x05>; }; ir { gpios = <0xa5 0x12 0x00>; linux,default-trigger = "ir"; default-state = "off"; mode = <0x00>; }; };  
0xfb is the phandle to rk805 node and 0xa5 is the phandle to gpio2 node.
 
This instead is the content of the led-conf3:
&gpio_led { pinctrl-names = "default"; pinctrl-0 = <&ir_led>; working { gpios = <&rk805 1 GPIO_ACTIVE_LOW>; default-state = "on"; linux,default-trigger = "mmc2"; mode = <35>; }; net { gpios = <&rk805 0 GPIO_ACTIVE_LOW>; linux,default-trigger = "eth0"; default-state = "off"; mode = <5>; }; ir { gpios = <&gpio2 RK_PC2 GPIO_ACTIVE_LOW>; linux,default-trigger = "ir"; default-state = "off"; mode = <0>; }; };  
The two leds controller by rk805 are working (net-green on old dtb) and net (power-green). Working and net already match the order in the dtb you just sent me, so they should already fit your need.
Moreover there is the specification of this other ir led, which I don't know if it is present on your board or it isn't.
 
From what I can see, working and net are pointing to the same rk805 device and pins in both mine, yours and original dtbs, so they should work with led-conf3.
 
Maybe triggers are not exactly what you want, but they should not be changed in the dtb: it is expected you change them for your needs using /sys/class/leds filesystem objects at startup.
I have proposed a boot script to armbian developers to stash led state at shutdown and restore it as startup, so once you configure the leds for your tastes, they will be automatically restored at boot and there will be no hassle to do that manually.

Hi all,
Little feedback, I tried installing CasaOs, CasaOS - A simple, easy-to-use, elegant open-source Family Cloud system
it works..
It may be useful for some of you.
Thank you to the entire IceWhale team for this sharing..
 
https://github.com/IceWhaleTech/CasaOS
 
 

Now that is something I may be interested in! Thanks for the ideas!

You can try YUNoHost, it's cool I use it on my beelink gt-king pro with armbian-meson64 works fine and have many apps.
Today I try install of Swizzin, on my RK3328 box that's work ( install process need root user "su -" )
it's another possibility..
https://github.com/swizzin/swizzin
https://swizzin.ltd/getting-started/

You can try YUNoHost, it's cool I use it on my beelink gt-king pro with armbian-meson64 works fine and have many apps.
Today I try install of Swizzin, on my RK3328 box that's work ( install process need root user "su -" )
it's another possibility..
https://github.com/swizzin/swizzin
https://swizzin.ltd/getting-started/

My French is not the best but for me it seems like the folders named "/boot/dtb-5.14.13-rockchip64/rockchip", "/boot/dtb-5.14.13-rockchip64/rockchip/overlay" and "/var/lib/initramfs-tools" are missing and the packages "bison" and "flex" needs to be installed.

@MX10.AC2N
 
As @curse noticed, probably you need the bison and flex packages to install headers. But you don't really need headers in case you don't want to compile kernel modules by yourself.

!! DEPRECATED !!
Instructions in this thread are oudated and superseded by the new experimental APT repository for hardware video decoding ffmpeg.
Please refer to this thread from now on!
 
Hello, recent upgrades to armbian are regarding kernel 5.15.
I noticed that many v4l2 fixes and enhancements went into this release, so I decided to compile ffmpeg using LibreELEC patched version and mpv over it.
mpv turns out to be statically linked with ffmpeg, so I propose it here for people who is interested in cutting edge kernel and wants to do some tests.
 
This has been tested on Debian Bullseye and Ubuntu Hirsute on following platforms:
Rockchip RK3228/9 (kernel 5.10, 5.14) Rockchip RK3288 (kernel 5.14) Rockchip RK3318/28 (kernel 5.15)  
It should work on allwinner platforms too, but I didn't test it there.
Binaries are built by me on developing boards.
 
The binary for armhf is available here
The binary for arm64 is available here
 
Copy the binary into /usr/local/bin directory of your system (mpv-armhf for 32 bit systems, mpv-arm64 for 64 bit systems):
sudo cp mpv-armhf /usr/local/bin/mpv  
Install dependencies for Debian Bullseye and Ubuntu Hirsute:
apt install libass9 libbluray2 librubberband2 libsdl2-2.0-0 libva-drm2 libva-wayland2 libva-x11-2 libva2 libvdpau1 libx264-160 libx265-192 libxss1 libxv1 libfdk-aac2  
I have had issues with dependencies on Debian Buster/Ubuntu Focal, in particular libx264-160 and libx265-192 are not available there.
I Solved the issue downloading the packages from Debian Bullseye web page and manually installing them.
There may be the need for some other dependency depending upon your actual installation.
 
Run mpv in a virtual terminal (videos up to 4K) with this CLI:
mpv --vo=gpu --hwdec=drm --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary <video.mp4>  
Mpv can be run in X11 with this other CLI, but due to buffer copying it requires a good CPU - rk3228 and rk3328 won't even play 720p, rk3288 do 720p fine:
mpv --vo=gpu --hwdec=auto-copy --gpu-context=x11egl --gpu-hwdec-interop=drmprime-drm <video.mp4>  
This is an experiment and your mileage may vary a lot:
H.264 codec should be well supported around the boards; H.265 has more limited support VP8 should be generally supported VP9 seems to still require some work.

Update!
 
New testing minimal and xfce desktop debian images are available on first page!
Latest kernel 5.15: plenty of fixes and upgrades for hardware video decoding Initial (and untested) support for boards with sdcard on external controller U-boot v2021.07, should make USB2 boot more reliable To test hardware video decoding capabilities follow this link to a tutorial with prebuilt mpv binary and instructions on how to use it.

Hi all, So I started from scratch, everything works fine without any overlays but this morning I tried adding overlays=rk3318-box-led-conf3 in armbianEnv.txt and the box freezes at startup

At moment, I have system just on sd-card..
I switched to verbosity = 10 but then it scrolls too fast on the screen, suddenly I tried to film it and bring out some photos but hey it's not super easy ..
It gives a lot of image very blurry finally I did the best, at the end I only have 5 lines with the rest of the black screen .. Hope that can help you ..

copy of dmesg without rk3318-box-cpu-hs and rk3318-box-led-conf3 => https://paste.yunohost.org/ogasoqumeq.vbs

Thank again @jock
So on the emmc I still have the armbian bulleyes system from the station-m1 image
So I replaced the rk3318-box.dtb file (yours is slightly heavier 63761 bytes against 62913 for the dtb already present in the image) here is the new dmesg => https://paste.yunohost.org/alatoyakud.md

Hi @jock and thank you for these explanations it enlightens my knowledge a little more, suddenly I left the emmc as it is and tried adding overlays, it works I was able to put led-conf3 and cpu-hs without problem here is the copy of dmesg => https://paste.yunohost.org/ewutojutal.md
 
However I come back to your explanations, you indicate that ATF would be useful for DRM rights, suddenly this attracts my interest because I am looking for a solution to be able to read the amazon prime videos and unfortunately I still have this damn message missing drm rights .. do you know a parade with this problem? I looked a lot on Github, I even tried a few installs but nothing convincing, often the problem is that we are under arm64 (no drm rights under arm64) because with armhf apparently there will be solutions .. Y -will there be a way to build a multiarch arm64 / armhf image or maybe just an armhf image ..? For the moment I am in the idea of using a docker like https://github.com/HenningThiemann/docker-chromium-armhf ..
 
Thanks again, apparently the problems seem to be solved, I will go back to 1.3GHz.

Glad to hear everything is back to normal.
About the Amazon DRM etc... I don't know anything about. I see that libreelec is downloading chrome and extracting the widewine DRM binary to let some plugins work, but I did not ever try Amazon Prime and don't know what are the requirements for that.
The proprietary ATF may provide a "secure" application of some sort for DRM, but this is a guess. I never digged into what in reality there is. I may guess that "secure" ATF software is tailored with some other userland software which I'm not aware of that may lie in the Android image, but this is all purely guessing

Hi @jock and thank you for these explanations it enlightens my knowledge a little more, suddenly I left the emmc as it is and tried adding overlays, it works I was able to put led-conf3 and cpu-hs without problem here is the copy of dmesg => https://paste.yunohost.org/ewutojutal.md
 
However I come back to your explanations, you indicate that ATF would be useful for DRM rights, suddenly this attracts my interest because I am looking for a solution to be able to read the amazon prime videos and unfortunately I still have this damn message missing drm rights .. do you know a parade with this problem? I looked a lot on Github, I even tried a few installs but nothing convincing, often the problem is that we are under arm64 (no drm rights under arm64) because with armhf apparently there will be solutions .. Y -will there be a way to build a multiarch arm64 / armhf image or maybe just an armhf image ..? For the moment I am in the idea of using a docker like https://github.com/HenningThiemann/docker-chromium-armhf ..
 
Thanks again, apparently the problems seem to be solved, I will go back to 1.3GHz.

Ahhh ok, we got the right explanation.
Now the message is properly gone from dmesg.
 
The problem is this: the box always boots from eMMC because there is a valid bootloader there. The bootloader is in reality composed of many parts executed one after another.
The station-m1 bootloader contains a thing that is called ATF (Arm Trusted Firmware). This piece of software is like a protected sandbox, something that runs outside the kernel or, if you prefer, above the kernel. It can whatever do it wants, can even stop the linux kernel. In fact it controls some very low level things, like system reset, core initialization, standby/resume, and so on...
 
It also controls the RAM frequency scaling, so memory can switch from 300 Mhz up to 800 Mhz and more.
 
Now there are two "flavours": the proprietary rockchip ATF (compiled by rockchip with their own customizations) and the public one provided by ARM.
The proprietary ATF is fully-fledged, but actually we don't really know what is inside: it's a blob provided by rockchip.
The public opensource ATF has just basic features, but we know it is harmless.
 
When I say harmless I want to stress out the fact that the ATF can peek his nose everywhere in the system, in fact it is widely used to implement DRM (Digital Rights Management) and HDCP (HDMI Copy Protection) features in tv boxes, to prevent piracy and restrict user rights in some form.
 
A proof of some harmful behaviour (not yet fully understood) is the fact that if I run rk3318 boards with proprietary ATF, the system crashes when cpu frequency is > 1.1Ghz. 1.1Ghz is the advertised speed for the rk3318 chip.
When I run the opensource ATF, rk3318 boards runs happy at 1.3 Ghz or even above.
 
Now this behaviour is a bit suspect: I don't want to state that the rockchip ATF is crashing the system on purpose to limit the frequency speed of the chip, but if we consider the final effect, it is so.
 
All this long explanation is to say that maybe the bootloader installed in the eMMC may cause headaches of some sort. I don't know if there are limiting behaviours on rk3328 too, but as we are used to say in Italy, the wolf loses the hair but does not lose the vice (ie: what they do once, they can do again)
 
It would be wise to clean the eMMC bootloader. If you're not afraid to lose the eMMC installation, you could erase the eMMC with blkdiscard.
If you don't want to lose it, you may make a backup of the first megabyte of the eMMC on the sdcard, zero-fill the first megabyte of the eMMC, and finally reboot.
Otherwise leave it as-is and just and see what happens with led-conf3 overlay again.
 

ju@rk3328-mx10-TvBox:~/Téléchargements/deb_upgrade$ sudo apt --fix-broken install Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait Correction des dépendances... Fait Les paquets supplémentaires suivants seront installés : bison flex libsigsegv2 libssl-dev m4 Paquets suggérés : bison-doc flex-doc libssl-doc m4-doc Paquets recommandés : libfl-dev Les NOUVEAUX paquets suivants seront installés : bison flex libsigsegv2 libssl-dev m4 0 mis à jour, 5 nouvellement installés, 0 à enlever et 3 non mis à jour. 1 partiellement installés ou enlevés. Il est nécessaire de prendre 3 442 ko dans les archives. Après cette opération, 12,5 Mo d'espace disque supplémentaires seront utilisés. Souhaitez-vous continuer ? [O/n] o Réception de :1 http://deb.debian.org/debian bullseye/main arm64 libsigsegv2 arm64 2.13-1 [34,7 kB] Réception de :2 http://deb.debian.org/debian bullseye/main arm64 m4 arm64 1.4.18-5 [199 kB] Réception de :3 http://deb.debian.org/debian bullseye/main arm64 bison arm64 2:3.7.5+dfsg-1 [1 084 kB] Réception de :4 http://deb.debian.org/debian bullseye/main arm64 flex arm64 2.6.4-8 [431 kB] Réception de :5 http://deb.debian.org/debian bullseye/main arm64 libssl-dev arm64 1.1.1k-1+deb11u1 [1 693 kB] 3 442 ko réceptionnés en 1s (3 536 ko/s) Sélection du paquet libsigsegv2:arm64 précédemment désélectionné. (Lecture de la base de données... 173316 fichiers et répertoires déjà installés.) Préparation du dépaquetage de .../libsigsegv2_2.13-1_arm64.deb ... Dépaquetage de libsigsegv2:arm64 (2.13-1) ... Sélection du paquet m4 précédemment désélectionné. Préparation du dépaquetage de .../archives/m4_1.4.18-5_arm64.deb ... Dépaquetage de m4 (1.4.18-5) ... Sélection du paquet bison précédemment désélectionné. Préparation du dépaquetage de .../bison_2%3a3.7.5+dfsg-1_arm64.deb ... Dépaquetage de bison (2:3.7.5+dfsg-1) ... Sélection du paquet flex précédemment désélectionné. Préparation du dépaquetage de .../flex_2.6.4-8_arm64.deb ... Dépaquetage de flex (2.6.4-8) ... Sélection du paquet libssl-dev:arm64 précédemment désélectionné. Préparation du dépaquetage de .../libssl-dev_1.1.1k-1+deb11u1_arm64.deb ... Dépaquetage de libssl-dev:arm64 (1.1.1k-1+deb11u1) ... Paramétrage de libsigsegv2:arm64 (2.13-1) ... Paramétrage de libssl-dev:arm64 (1.1.1k-1+deb11u1) ... Paramétrage de m4 (1.4.18-5) ... Paramétrage de bison (2:3.7.5+dfsg-1) ... update-alternatives: utilisation de « /usr/bin/bison.yacc » pour fournir « /usr/bin/yacc » (yacc) en mode automatique Paramétrage de flex (2.6.4-8) ... Paramétrage de linux-headers-edge-rockchip64 (21.11.0-trunk) ... Compiling headers - please wait ... Traitement des actions différées (« triggers ») pour libc-bin (2.31-13+deb11u2) ... Traitement des actions différées (« triggers ») pour man-db (2.9.4-2) ... Traitement des actions différées (« triggers ») pour doc-base (0.11.1) ... Traitement de 1 fichier de documentation ajouté… ju@rk3328-mx10-TvBox:~/Téléchargements/deb_upgrade$ sudo dpkg -i *.deb (Lecture de la base de données... 173818 fichiers et répertoires déjà installés.) Préparation du dépaquetage de linux-dtb-edge-rockchip64_21.11.0-trunk_arm64.deb ... Dépaquetage de linux-dtb-edge-rockchip64 (21.11.0-trunk) sur (21.11.0-trunk) ... Préparation du dépaquetage de linux-headers-edge-rockchip64_21.11.0-trunk_arm64.deb ... Dépaquetage de linux-headers-edge-rockchip64 (21.11.0-trunk) sur (21.11.0-trunk) ... Préparation du dépaquetage de linux-image-edge-rockchip64_21.11.0-trunk_arm64.deb ... ls: impossible d'accéder à '/var/lib/initramfs-tools': Aucun fichier ou dossier de ce type Dépaquetage de linux-image-edge-rockchip64 (21.11.0-trunk) sur (21.11.0-trunk) ... dpkg: concernant linux-u-boot-edge-rk3318-box_21.11.0-trunk_arm64.deb contenant linux-u-boot-rk3318-box-edge : linux-u-boot-rk3318-box-current entre en conflit avec armbian-u-boot linux-u-boot-rk3318-box-edge fournit armbian-u-boot et doit être installé. dpkg: erreur de traitement de l'archive linux-u-boot-edge-rk3318-box_21.11.0-trunk_arm64.deb (--install) : paquets en conflit - linux-u-boot-rk3318-box-edge non installé Paramétrage de linux-dtb-edge-rockchip64 (21.11.0-trunk) ... Paramétrage de linux-headers-edge-rockchip64 (21.11.0-trunk) ... Compiling headers - please wait ... Paramétrage de linux-image-edge-rockchip64 (21.11.0-trunk) ... update-initramfs: Generating /boot/initrd.img-5.14.13-rockchip64 update-initramfs: Converting to u-boot format Des erreurs ont été rencontrées pendant l'exécution : linux-u-boot-edge-rk3318-box_21.11.0-trunk_arm64.deb ju@rk3328-mx10-TvBox:~/Téléchargements/deb_upgrade$  

@jock I try upgrade via deb. There is some errors => https://paste.yunohost.org/dirafakuve.erl

No worries, I'm only in the testing phase so nothing important ..
Too bad it didn't work ..
Hoping that my feedback can help,
Thank you again for everything you do .. Great @jock