Search the Community

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

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!

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 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

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.

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

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.

Hello Armbian community! Take a look at the latest developments and improvements in Armbian over the past weeks of August 2025. Our focus remains on enhancing stability, expanding hardware support, and streamlining the build process. HighlightsImproved ethernet stability for Rockchip SoCs A crucial workaround has been implemented to address gigabit Ethernet issues on several Rockchip SoCs when using the edge kernel, bringing more reliable network connectivity. PR #8515Enhanced BPI-R4 SFP support Fixes improve SFP (Small Form-Factor Pluggable) module support on the Banana Pi R4 and Filogic-based boards, ensuring better compatibility and functionality. PR #8517New featuresNanoPi M6 LCD support Added support for the YX35 LCD on the NanoPi M6 via the edge kernel, expanding display options. PR #8512Bug fixesCAN Module compilation fix Removed CONFIG_CAN_TI_HECC as it failed to compile, preventing build failures. PR #8534, PR #8527motd Alignment correction Another alignment fix for the Message of the Day (motd) display for a cleaner console experience. PR #8533Sunxi64 Edge build stability Fixed breakage in sunxi64 edge kernel builds. PR #8516Odroid XU4 patching consistency Ensured double-digit numbers in odroidxu4-6.6 and spacemit-6.6 patches are padded with a leading zero. PR #8522ImprovementsKernel Updates - Updated odroidxu4-current kernel to 6.6.102 (PR #8523)Build system & configuration - Temporarily disabled daily builds for Qualcomm Robotics RB5 (PR #8535) - Switched kde-neon to stable branch, adjusted support to csc (PR #8519) - Updated TI k3 configuration to use new official GitHub mirrors (PR #8530) - Changed preferred kernel order for Banana Pi M2+ to prioritize current and edge over legacy (PR #8524) - Dropped abandoned Collabora kernel support for RK3588 (PR #8532) - Removed rk3399-fix-pci-lanes.patch from the 6.16 kernel (PR #8526)Community contributionsBig thanks to our contributors this week: @igorpecovnik @leggewie @Grippy98 @EvilOlaf @tabrisnet@paolosabatino @efectn Get involvedWant to contribute to Armbian? Join the community! GitHub RepositoryArmbian ForumsSupport ArmbianView the full article

Hi, my feedback for fancontrol service here : for 2.5Gbits, i don't use. for rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp, same has i writed up: "It is better to have a good solution in time than a perfect one too late.", my helios64 going to the trash without this workaround.

Hi, Today i upgrade to Armbian Trixie my Helios64 with upgrade from bookworn to trixie, not clean install All seen to be Okok only with use of rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp file inside of original rk3399-kobol-helios64.dtb Only problems for moment are: - fancontrol not seen to work lm75 module... service crash... i will investigate soon if i have the time. - apt show warning with SHA1 checksum or anything i can't investigate for the moment

Hi, I continue to use file rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp on the last Helios64: v25.8.1 for Helios64 running Armbian Linux 6.12.42-current-rockchip64 Without this file, i have crash or problem with ciffer orperation (Luks and another program...) With this file, all it's Okok. Have a good day.

This remembers me a recent set of changes to the DWC3 driver for RK3399 to fix exactly these kind of issues exposed here, including the single-orientation problem, plus some more issues with the displayport over usb type-c functionality. The PR had a lot of comments but finally it got merged because both the author and me tested the whole apparatus and it proved to improve significantly the situation on rk3399: https://github.com/armbian/build/pull/8271 Patches should address some issues in the dwc3 driver in general, and I see from the device tree that rk356x uses the snps,dwc3 compatibility string, so probably also rk356x benefits from them as well. It would although require some device tree tinkering: I tested on Orange PI4 LTS board and the device tree fixes are within this hunk; rk356x-based devices can probably share several declarations but that depends upon the rk356x capabilities. I would start from changing dr_mode to otg and removing regulator-always-on; property from the vbus supply.

I tried Armbina25.5.1 with 6.16.0-rc3-edge-rockchip64 on nanopc t4(rk3399), both hdmi and dp(type-c) works ok. But Armbina25.5.1 with 6.12 only works ok when both typec(dp) and hdmi are pulgged in. There is no output when I only plug in hdmi or typec(dp) .