Search the Community

Hi all, I would like to ask support for the board EMB-3531. I'm having problem with booting this board from SD card. Here are some informations about this board. I hope that someone can help me with it. Thank you so much! I try to erase the emmc and flash the MiniLoaderAll.bin but it doesn't help. Or i don't have a correct image with armbian for this board. https://my.kos.org.cn:5154/rockchip/EMB3531/emb3531.pdf

Updating via `apt update && apt upgrade` causes Armbian to fail to boot on the single-board computer. I'm attaching the UART logs in the file `failed_log.txt`. Start-Date: 2025-11-13 04:45:12 Commandline: apt -y upgrade Upgrade: armbian-bsp-cli-nanopct4-current:arm64 (25.11.0-trunk.146, 25.11.0-trunk.469), linux-dtb-current-rockchip64:arm64 (25.11.0-trunk.146, 25.11.0-trunk.469), linux-image-current-rockchip64:arm64 (25.11.0-trunk.146, 25.11.0-trunk.469), linux-u-boot-nanopct4-current:arm64 (25.11.0-trunk.146, 25.11.0-trunk.469), armbian-firmware:arm64 (25.11.0-trunk.146, 25.11.0-trunk.469) End-Date: 2025-11-13 04:47:04 out: Starting kernel ... efi_free_pool: illegal free 0x00000000f0f09040 "Synchronous Abort" handler, esr 0x96000004 elr: 00000000002856e4 lr : 00000000002702f0000000f3f9b2f0 x0 : dfb6333a7ba2b4b7 x1 : 00000000f3fba060 x2000000 x5 : dfb6333a7ba2b4b7 x6 : 00000000f0d07000 x7 : 00000000000ef98 x11: 00000000f1f0b5bc x12: 000000000000ef98 x13: 000003f558a4 x17: 00000000d8136251 x18: 00000000f1f22d90 x19: 000000000000001 x23: 00000000f1f303c0 x24: 00000000f3fdcff0 x25: 00000000000000001 x29: 00000000f1f0b470 Code: eb04005f 54000061 5resetting ... To reproduce the issue (~13.11.2025-16.11.2025), simply download and flash the current `Minimal/IOT for Armbian Linux v6.12 [Debian] Debian 12 (Bookworm)` images (`https://www.armbian.com/nanopc-t4/`) and run `apt update & upgrade` on a running system, then reboot. After this, the system, regardless of whether the `SD card` or `EMMC` is used, will enter an infinite boot loop (`out` and file `failed_out.txt`). Thank you. failed_log.txt armbian_release.txt normal_log.txt

I have a working img that boots fine from sd card. However the dtb is not perfectly working. Below are dts from android and linux (partial working). I hope that someone can help me with rewriting device tree source for it. Thank you! rk3399-emb3531.dts.txtrk3399-emb3531-android.dts.txt

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg 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 ffmpeg package that integrates and substitues the base ffmpeg package and its related packages. Preconditions: Mainline kernel 6.1 or more recent armhf or arm64 architecture Supported distributions: Debian 12 - Bookworm Debian 13 - Trixie Ubuntu 22.04 - Jammy Ubuntu 24.04 - Noble 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 in a terminal: $ sudo wget http://apt.undo.it:7242/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ . /etc/os-release && echo "deb http://apt.undo.it:7242 $VERSION_CODENAME main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list $ echo -e "Package: *\nPin: release o=apt.undo.it\nPin-Priority: 600" | sudo tee /etc/apt/preferences.d/apt-undo-it INSTALL FFMPEG AND MPV PACKAGES $ sudo apt update $ sudo apt install ffmpeg 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) you may want to add --gpu-hwdec-interop=drmprime-overlay to the mpv command line if used in pure virtual terminal (no X, no Wayland) to use direct-to-overlay output 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

Hi, In 2025, Helios64 is now stable for me and for my brother, who also uses it. The only thing to do is, just after installation or after any upgrade, you must reinstall the special file rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp because I think the specific tuning in this file is not included in the official image. For me, I suggest keeping it, using it, and saving your money for other things. Bye.

Hello! First of all, thank you robertoj for this treasure trove of information - truly, I searched so much of the internet before finding this, because seemingly nobody is sharing DTS files for tft screens at all that aren't on a raspberry pi (which uses a different system afaik). I am using a rockpi 4bplus, trying to get an ili9488/86 tft screen to work, and struggling. I've used your latest DTS from page 1, using panel-mipi, verified it loads into initramfs using your other threads, compiled my own armbian edge on kernel 6.18 (and tried on kernel 6.12), corrected all FDT err not found errors on the DTS for my use case (my gpio numbers were out of scope)... still, all I get on my display is a blank white screen with no dmesg errors or comments about spi, panel etc... ;-; Not sure what else to try at this point. I'll post my files below, along with translated gpio pin numbers: /dts-v1/; /plugin/; /{ compatible = "radxa,rockpi4b-plus", "radxa,rockpi4", "rockchip,rk3399"; fragment@0 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; /* new for linux 6.13 */ pinctrl-0 = <&spi1_clk &spi1_cs0 &spi1_rx &spi1_tx>; /* new for linux 6.13 */ cs-gpios = <&spi1_cs0>, <&gpio4 26 0>; /* lcd, touch chip select */ panel: panel@0 { compatible = "panel-mipi-dbi-spi"; status = "okay"; reg = <0>; spi-max-frequency = <40000000>; width-mm=<84>; height-mm=<56>; reset-gpios = <&gpio4 29 1>; /* taken from rock3c setup, then modified for armbian */ dc-gpios = <&gpio4 28 0>; /* 1 is low, 0 is high */ write-only; format = "b6x2g6x2r6x2"; panel-timing { hactive = <480>; vactive = <320>; hback-porch = <0>; vback-porch = <0>; clock-frequency = <0>; hfront-porch = <0>; hsync-len = <0>; vfront-porch = <0>; vsync-len = <0>; }; }; ads7846: ads7846@1 { compatible = "ti,ads7846"; reg = <1>; pinctrl-names = "default"; spi-max-frequency = <1000000>; interrupt-parent = <&gpio4>; interrupts = <21 2>; /* 2 is IRQ_TYPE_EDGE_FALLING pendown-gpio = <&gpio4 21 0>; /* same as interrupt, pulled high */ vcc-supply = <&vcc5v0_sys>; /* Fill in the voltage according to the actual power supply c> /* OPTIONS */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0XFFF>; ti,y-max = /bits/ 16 <0XFFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0XFFF>; ti,x-plate-ohms = /bits/ 16 <400>; ti,swap-xy = <1>; }; }; }; };

Hi, can you please share which USB to TTL adapter to use for uart logs? I have an RK3399 board but it failed to show uart logs with CP2102 and CH340 adapters. Thank you!

Hello all. I have an Android-based Yundoo Y8 TV box, which I want to use for UPS management. I want it to be able to run Armbian to install the UPS management software, but I cannot figure out which Armbian I should download. The board is based on Rockchip RK3399. In cpu-z app I see the board identified as rk30sdk, and the hardware is rk30board. Can you please help me identify the board so I can understand which version of Armbian I need? I couldn't find anything in the forum about RK3399... I really appreciate any help you can provide.

I saw some initial work on supporting uugear's vivid unit (rk3399 based). I was wondering in what state that is, what is required to complete that work and if there are plans to add that support to the mainline? Thanks in advance, Markus

Hello Armbian community, I am writing this topic because, despite the drivers for the processor's integrated GPU are installed within the operating system, they do not seem to work properly. Precisely the system seems to work but as soon as I try to play a video it is played by the CPU and not by the GPU with lag and the CPU is at 100%. I leave the link and the attachment of the result of the armbianmonitor -U command that I posted here: https://paste.debian.net/1337993/ it is a compressed tar.gz file since I included all the results of the command Analysis.txt

You need to imagine it as a chip, the entire board; each change to the board alters the description of the "chip" you're referring to. Search for your board model on the forum. I don't own any boards using RK3399, but I believe you can find several users mentioning the board on the forum. for YY3568 board, the factory already have all information https://wiki.youyeetoo.com/en/YY3568/sdCardSystem

Hi @Hqnicolas I have same issue with booting from SD card for a board (RK3399) . Can you please share the u-boot image or guide to compile for that chip?

Hi, my feedback with rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and agressif fancontrol setting like this: # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input MINTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=30 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=30 MAXTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=50 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=50 MINSTART=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINSTOP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINPWM=20 is: All it's Okok Without the tunning file DTB and Fancontrol, the nighmare restart. Today, update, original DTB file restore and CRASH when Luks begin to unciffer my DDs Il restore DTB file and my fancontrol setting and: Return to Okok situation. To conclude, i use my helios without problem when this files is installed. My helios64 always crash if i return to original setting after a update.

Description Fix Type-C DP altmode on some rk3399 boards. Currently only on rockchip64-6.15. The old implementation is tricky, and only works in normal orientation. If the plug is flipped, there will be only USB2.0 connectivity. With the proposed changes, the type-c ports on related rk3399 boards should work in both orientations. A few patches from Megous are picked(some of them already present in sunxi64 kernel patches). The tricky part is how to notify rk3399 cdn-dp driver about DP HPD(hot plug detection), and a workaround is written. A caveat is that the c port has to be OTG mode, otherwise it will behave very similar to the old implementation if DP is enabled. I'm not sure if orange pi 4 / 4 LTS support this, so there's no change to their dts yet. Apart from the work above, the missing fan node is added to tinkerboard 2's dts. list of changes fix type-c dp altmode Megous' glue driver and related improvements are imported this involves enabling the driver in defconfig CONFIG_TYPEC_EXTCON=m a workaround for notifying DP HPD to cdn-dp is written(not merged anywhere) related device tree files/patches are updated accordingly(what about orangepi 4?) add missing fan node in tinkerboard 2's dts along with some minor tweaks How Has This Been Tested? [x] build tinkerboard-2 with edge kernel [x] test on tinkerboard 2s with a hub [x] hub alone works in both orientations [x] hub with display connected works in both orientations [x] when hub is connected, display hot plug/unplug works [x] USB 3.0 type-c drive works in both orientations [ ] test with a DP-only dongle [ ] test on pinebook pro [ ] test on nanopc-t4 [ ] maybe test on orangepi 4 (need dts change) [ ] maybe test on orangepi 4 LTS (need dts change) Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

To maintain changes between different kernel versions, you can use overlays. I did this by following some dts changes from @ebin-dev. Add this line user_overlays=rockchip-rk3399-op1-opp rockchip-rk3399-l2-cache to /boot/armbianEnv.txt Copy the dtbo files to /boot/overlay-user (mkdir -p /boot/overlay-user if the folder does not exist). rockchip-rk3399-l2-cache.dtborockchip-rk3399-op1-opp.dtborockchip-rk3399-op1-opp.dtsrockchip-rk3399-l2-cache.dts

Choosing the right input voltage and ensuring stable power supply for SBCsWhen working with single board computers (SBCs) like those supported by Armbian, one of the most overlooked but critical factors for performance and system reliability is the power supply. Whether you're running a lightweight server, a development environment, or a complex home automation system, power instability can lead to frustrating and difficult-to-diagnose problems. Understanding the correct input voltage and ensuring a stable power supply is essential for the long-term health of your SBC. Why Power Supply Issues Are So CommonUnlike desktop systems that come with regulated internal power supplies, SBCs rely entirely on external power adapters. These small boards are expected to do a lot run desktop environments, manage network traffic, operate storage devices, or even handle video output and all of it depends on steady power. Many users assume that any 5V adapter or USB-C charger will suffice. This assumption often leads to problems like: Random rebootsFailed bootsUSB peripherals disconnectingSD card corruptionOverheating from inefficient voltage conversionWhat’s worse, these symptoms are often mistaken for software bugs, when in reality, the board is simply not getting the power it needs. The importance of voltage AaccuracyMost SBCs supported by Armbian require a 5V input, but not just any 5V. The tolerance for voltage drop is narrow often less than ±5%. A supply that delivers 4.75V under load may already be too low, especially when additional peripherals draw current. For boards like the Orange Pi 5/5 Plus or Rockchip RK3399-based systems, this becomes more critical. These boards include CPUs that demand bursts of current during processing spikes. If your power supply cannot maintain a solid 5.1–5.2V under load, you’ll start seeing intermittent failures or throttling. Boards that support USB-C PD (Power Delivery) can negotiate for higher voltage levels (e.g., 9V or 12V), but this only works correctly if the power supply and USB-C cable both support PD and follow the standard. If they don't, the board may only receive 5V or nothing at all. Current (Amperage) capacityVoltage is only half the story. You also need enough current (measured in amps, or A). For most SBCs: Lightweight boards (like Orange Pi Zero) require at least 1–2A.Mid-range boards (like Orange Pi 3 LTS, RK3328) should have at least 3A.High-performance boards (RK3588, RK3399, etc.) often need 4–5A, especially under load or when powering peripherals.A common mistake is to use a "fast charger" designed for phones. These may list high amperage (like 3A), but they rely on USB Power Delivery protocols. If the board doesn't negotiate the higher voltage profile, it may default to 5V @ 500mA which is far too low. How to test your power supplyThe best way to confirm your power supply is adequate is by using a multimeter or USB voltage/current meter: Check idle voltage: Connect the power supply to your board. Using a multimeter, probe the 5V and GND pins (or use a USB tester). You should see between 5.1V and 5.25V. Less than 5.0V is a warning sign.Test under load: Stress the CPU (e.g., with stress-ng or compiling software). Watch the voltage. A good supply should not drop below 5.0V. If it does, expect instability.Measure at the board, not the adapter: Long or thin cables can cause voltage drop even if your adapter is good. This is especially true with Micro-USB or low-quality USB-C cables. Always test at the input connector on the board itself.Recommendations for stable powerUse a quality PSU: Avoid generic adapters. Use brands known for clean power delivery (e.g., Mean Well, Anker, official Raspberry Pi or Orange Pi supplies). A 5V/4A supply with a barrel jack or PD support is ideal for high-end SBCs.Prefer barrel jack over Micro-USB: Micro-USB is notorious for unreliable power delivery due to thin connectors and cable resistance.Use short, thick cables: The longer the cable, the more voltage drops across it. Choose 18AWG or thicker cables, especially if using USB.Avoid USB hubs for power: Even powered hubs often introduce noise or underperform when multiple devices draw current.Monitor system logs: Look for undervoltage warnings in dmesg or Armbian’s armbianmonitor output. This is an early sign that your supply may not be sufficient.ConclusionPower issues are one of the leading causes of instability and hardware failure in SBC projects. Armbian users can save countless hours of troubleshooting by investing in a good power setup from the start. Always ensure you're providing the correct input voltage (typically 5.1–5.2V) and enough current (up to 4–5A for high-performance boards). Measure voltage under load, use high-quality adapters and cables, and stay vigilant for undervoltage signs. A stable SBC starts with stable power it’s the foundation of everything else. View the full article

Hello, friends... The current MIPI DSI driver provided by Rockchip Inc. in older U-Boot versions (v2023 and earlier) is not compatible with U-Boot’s uclass subsystems.(a waste of time if you want to develop). I have done extensive research and made modifications to several files to make it work with the latest U-Boot versions. I have tested it with U-Boot 2023.10, 2024.10 and v2025.rc3 on orange pi 4 lts, and it works perfectly. I'm attaching the necessary files for those who need them. This u-boot driver is nearly identical to Rockchip's Linux kernel driver, uses same driver file but there some limitations because of u-boot system, but it correctly displays the splash image when vidconsole0 probed by u-boot.. Additionally, i want to say that, in linux kernel side, the same dw-rockchip-dsi driver in latest armbian distribitions works with from kernels 5.18 to latest kernel v6.6 and v.6.12. I tested it. Tested with custom 400x1200 60hz 4 lane standart mipi dsi panel from chinese panel manufacturer. I attached all modified files as attachment. Good lucks. dm tree command output from u-boot is reset 1 [ + ] rockchip_reset | `-- reset syscon 27 [ + ] rk3399_syscon |-- syscon@ff770000 nop 3 [ + ] rockchip_iodomain | `-- io-domains video 0 [ + ] rk3399_vop |-- vop@ff8f0000 vidconsole 0 [ + ] vidconsole0 | `-- vop@ff8f0000.vidconsole0 video 1 [ + ] rk3399_vop |-- vop@ff900000 vidconsole 1 [ + ] vidconsole0 | `-- vop@ff900000.vidconsole0 video_brid 0 [ + ] dw-mipi-dsi-rockchip |-- dsi@ff960000 dsi_host 0 [ + ] dw_mipi_dsi | |-- dsihost panel 0 [ + ] rm68200_panel | `-- panel@0 pinctrl 0 [ + ] rockchip_rk3399_pinc |-- pinctrl U-Boot 2024.10-armbian-2024.10-Sf919-Pbfb2-H3d34-Vade7-Bb703-R448a-dirty (Mar 03 2025 - 06:16:04 +0300) SoC: Rockchip rk3399 Reset cause: RST Model: Orange Pi 4 LTS Board DRAM: 4 GiB (effective 3.9 GiB) PMIC: RK808 Core: 285 devices, 32 uclasses, devicetree: separate MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... Reading from MMC(0)... *** Warning - bad CRC, using default environment rm68200_panel_of_to_plat() rm68200_panel panel@0: reset pin set done rm68200_panel_probe() rm68200_panel panel@0: Initializing MIPI DSI Panel Driver rm68200_panel_probe() rm68200_panel panel@0: Reset sequence done rm68200_panel_probe() rm68200_panel panel@0: dsi set 4 lane, video-burst, RGB 24-bit mode rm68200_panel_enable_backlight() rm68200_panel panel@0: Panel set backlight func(), initializing panel rm68200_panel_enable_backlight() rm68200_panel panel@0: attaching mipi dsi panel rm68200_panel_enable_backlight() rm68200_panel panel@0: perform panel initialization sequence rm68200_panel_enable_backlight() rm68200_panel panel@0: panel initialization sequence done, panel probed! rm68200_panel_enable_backlight() rm68200_panel panel@0: Panel set backlight func(), initializing panel rm68200_panel_enable_backlight() rm68200_panel panel@0: attaching mipi dsi panel rm68200_panel_enable_backlight() rm68200_panel panel@0: perform panel initialization sequence rm68200_panel_enable_backlight() rm68200_panel panel@0: panel initialization sequence done, panel probed! In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Orange Pi 4 LTS Board Net: Could not get PHY for ethernet@fe300000: addr 1 eth_initialize() No ethernet found. Hit any key to stop autoboot: 0 => dcdcddcdcdcdc<INTERRUPT> => setenv splashimage 0x82000000 => setenv splashfile /boot/splash.bmp => load mmc 0:1 ${splashimage} ${splashfile} 1920138 bytes read in 61 ms (30 MiB/s) => bmp display ${splashimage} => <INTERRUPT> => uclass_get_device_by_ofnode() Looking for clock-controller@ff760000 uclass_find_device_by_ofnode() Looking for clock-controller@ff760000 uclass_find_device_by_ofnode() - checking reset uclass_find_device_by_ofnode() - checking reset uclass_find_device_by_ofnode() - result for clock-controller@ff760000: reset (ret=0) uclass_get_device_by_ofnode() - result for clock-controller@ff760000: reset (ret=0) rm68200_panel_enable_backlight() rm68200_panel panel@0: Panel set backlight func(), initializing panel rm68200_panel_enable_backlight() rm68200_panel panel@0: attaching mipi dsi panel rm68200_panel_enable_backlight() rm68200_panel panel@0: perform panel initialization sequence rm68200_panel_enable_backlight() rm68200_panel panel@0: panel initialization sequence done, panel probed! dsi_phy_post_set_mode() dw-mipi-dsi-rockchip dsi@ff960000: Set mode 00000000f4f3b4a0 enable 1 device_bind_common() Bound device vop@ff900000.vidconsole0 to vop@ff900000 notify_dynamic() Sending event 5/(unknown) to spy 'efi_disk add' notify_dynamic() Sending event 5/(unknown) to spy 'efi_disk add' In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Orange Pi 4 LTS Board raydium-rm68200.c dw_mipi_dsi.c rk_vop.c dw_mipi_dsi_rockchip.c clk_rk3399.c .config rk3399-orangepi.dts

Well, I've been tinkering with different dtb's and Armbian versions, matching kernel 4.4 and using H96 Max RK3399 dtb as well, but the device does nothing. In fact, I entered the recovery to see if the SD card could be read and it didn't mount, then turned the device off through the button and now it does not turn on anymore. The red light does not go blue, I can still enter maskrom but if I want to boot Android normaly the device does nothing. I am kind of tired with this crappy TV box, wasting 2 days it's not worth it for something that costed 15€. My time is more valuable. Thank you for the help anyways.

The dtb files I've tried for rk3399 do not work, I've read that Firefly-RK3399 is very similar to this board, but even so it does not start. The small Rockchip chip is very difficult to see through a picture, at least with my phone camera. I tried with this picture: Anyways, I can write it here: RK808-D FAD7P841 1703

Or wait until the end of the year when 6.18 will be the new Linux version, that enables pretty much everything. RK3588 Mainline Linux Status: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md If you really need a bleeding edge working mediaplayer, LibreElec has experimental support for R6S/R6C: Thread: https://forum.libreelec.tv/thread/29953-le13-testing-for-rk3288-rk3328-rk3399-rk3566-rk3568-rk3576-rk3588/ Downloads: https://chewitt.libreelec.tv/testing/

You can not use android dtb. You must try without It or try the rk3399 files included in the sdcard. i cant see the second rockchip (pmic)

I attached some pictures of the device inside, I don't know if they can be of any help. I tried to use te dtb extracted from Android with the Armbian for Firefly-RK3399 and it does not boot. I configure the extlinux.conf file as advised, but the same moment I insert the SD card and turn on the device, the red light never turns blue. I tried that board because I've read in some forum that is similar to this device, but I know that's kind of hit and miss. At least I expected to see something on screen, even if it threw tons of errors, because I assume the dtb file is not the problem so the issue should be somewhere else that needs to be modified. Much appreciated for the help

No, the support for rk3399 is quite good. The problem is that each box/board needs someone to develop a device tree (dtb) for that box/board and each is different depending on the specifics of that box/board. That is what is lacking to support your box. (and if your box has obscure hardware on it, then those drivers may also be lacking)

I have the same Android TV, and I've been trying to boot Armbian but I don't seem to successfully accomplish it. I believe we are all alone with this, and nobody will ever help us. Maybe RK3399 SoC is still problematic after 9 years.

Since the RK3399 U-Boot can use an HDMI display and a USB keyboard, I would simply configure a jumpstart option in the boot flow that mounts a different root filesystem. When booting, you just have to select this option. If interacting with the firmware console is too complicated, the recovery system can be placed on a removable storage device. In this way, in case of need, only the rescue media needs to be connected and the system restarted; no firmware console access is required. A completely firmware-controlled fallback mechanism is also possible, but it requires further special configuration of the firmware. Read this thread to understand what I mean by my statement.