jock
-
Posts
2139 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
@Harleyyyu See this thread; hardware video decoding works fine with mainline kernel and does not need vendor MPP. Debian Trixie although has a "broken" mpv that won't work, better stay with Bookworm
-
9 hours ago, digital said:
Thanks, but I cannot run rk322x-config (or can I without being fully booted?). I suppose I can try in overlays=... line in /boot/armbianEnv.txt, but what should I write here?
Can't you run on sdcard? It is heavily suggested to run on sdcard before installing on emmc.
However the overlay is emmc-pins
-
11 hours ago, digital said:
I have Dolamee D5 box. The legacy kernel 4.4.194-rk322x boots ok, but newer images from @jock or my own built image does not see EMMC. Any ideas? dmesgs attached.
hello @digital, in some rare cases there are some minor trickeries to try and improve compatibility with eMMC.
If you run rk322x-config, there is a panel dedicated to eMMC which allows you to select some compatiblity options, like emmc-pins and DDR/UHS modes. You may try first enabling emmc-pins and rebooting to see if it gets recognized. Anyway photos of the board and the original stock device tree could be useful to identify the compatibility problem.
-
@0230826 you can follow instructions in this page by @fabiobassa The loader is there too
-
16 hours ago, Leneren said:
I burned the armbian image to sd card, which insterted into the sd slot on the T9 board, however I am unable to get the board to boot from the sd card.
Probably you have to read again the installation instructions in the first page, in particular you have to use the multitool
-
2 hours ago, Kuroi Akuma said:
I followed most of the instructions here without hope. My dmesg said "esp8089: unknown parameter 'crystal_26M_en' ignored" for:
options esp8089 crystal_26M_en=1
and "esp8089: unknown parameter 'config' ignored" for:
option esp8089 config=crystal_26M_en=1
modprobe parameter should be crystal=1, not crystal_26M_en anymore (see here)
Otherwise you could try led-conf6 overlay (but I don't know if it fits your board...) which has the attribute esp,crystal-26M-en = <1> in the device tree to set the crystal to 26 MHz
-
17 hours ago, robertoj said:
Start by recompiling armbian for your Rockchip SBC, with the edge kernel option, then follow the ffmpeg install instructions
No need to recompile, rk322x already have had all the right bits in the right place for years. Everything is written down in the first page of the thread for rk332x tv boxes (What works: ---> Hardware video acceleration) in the hope people read it.
-
3 hours ago, Antom said:
If not, which distribution is better to choose? Please tell me.
I tell you to read the first post of the thread.
-
On 11/21/2025 at 4:02 AM, QwertyChouskie said:
Is there any chance of this image running on a device using the RKPX30 chip? From some research, it seems to be a variant of the RK3326, and I'm not sure how similar the 3328 and 3326 are or are not. Or is there another Armbian image for the RKPX30/RK3326? Specifically looking to run Armbian on this: https://docs.revrobotics.com/duo-control/control-system-overview/driver-hub-specifications
rk3326 and rk3328 are not the same thing, neither is px30. Definitely no chances to run this on those SoCs; I don't know if there are images for boards using px30/rk3326 in armbian.
-
@GmP oook, so now I understand the differences between the two dtso files provided here and in the other thread.
Do you spot other differences or peculiarities? Things that are useful are:
* the gpio led (do the separate red/blue/green led blinks on both boards?)
* wifi reset gpio (do wifi get detected in both boards with base configuration?)
* is there a separate PMIC like rk805/rk808 on any of the boards?
Things like these go into the dtso for full board support. The PMIC is very important since missing that could cause stability issues.
-
-
@GmP thanks for the contribution, but I want to advice you that the driver changed in kernel 6.17 due to kernel developers requests and suggestion, so that device tree overlay is suitable only up to 6.16
I made a pull request to include the device tree overlays: https://github.com/armbian/build/pull/8848
-
The optimal would be understanding the reason why the watchdog triggers, but could be a difficult task without a hint because of the closed source proprietary trust os.
The easiest thing is to provide armbian images with the opensource trust os rather than the proprietary, which is totally feasible because it just requires to swap a file in the armbian build scripts. That would blow the issue away, but unfortunately the proprietary trust os provided DDR scaling and virtual poweroff. The latter is a seldom used feature, but the DDR scaling provided a dramatic improvement in performance and it is hard to give up on that.
Swapping the things at runtime is not savvy: when u-boot updates, the proprietary trust os will be reinstalled overwriting whatever you put in there.
I would be happy with opensource Trust OS and no runtime DDR scaling, but stil having it at a fixed decent rate (660MHz, instead of the default 330MHz), but some boards do not boot at all when they are instructed to boot at 660MHz.
-
1 hour ago, Igor said:
I had to rebuild server and this was not fixed yet. Temporally location https://stpete-mirror.armbian.com/users.armbian.com/
Thanks!
For @Victor Picinin the temporary working URl is https://stpete-mirror.armbian.com/users.armbian.com/jock/web/rk322x/armbian/beta/Armbian-unofficial_24.11.0-trunk_Rk322x-box_noble_current_6.6.56_xfce_desktop.img.xz
-
@Virgilio Junior you can use multitool, and use the "jump start" installation: you should be able to boot from sdcard and USB as well without doing the process by hand.
Forget about the NAND, it causes troubles you would not deal with
-
4 hours ago, Victor Picinin said:
I've seen this post before but the link is "404 Not Found" thats why i resorted to trying to build my own multitool and armbian hahahahahha
uhm, there is misconfiguration in the server actually; I see users.armbian.com is serving the certificate for stpete-mirror.armbian.com, perhaps @Igor can fix the issue
-
14 hours ago, Victor Picinin said:
If anyone here has a working build that does not trigger this watchdog, please let me know.
Found with google: https://forum.armbian.com/topic/34923-csc-armbian-for-rk322x-tv-box-boards/page/96/#findComment-218361
-
-
2 minutes ago, Victor Picinin said:
Is there a armbian distro that will work, what should i do here?
Mmmh, the easiest thing you can do you can build an armbian image taking rk322x_tee_os.bin from this branch in my repo and overwrite rk322x_tee.bin in the same path of your armbian copy, then build a regular image which will have an opensource TEE and should have no issues anymore.
Actually you could even reinstall u-boot without reinstalling the whole system, but it is just a tiny bit more involved. If you can restart from scratch, rebuilding the image with opensource TEE is easier.
-
6 minutes ago, Victor Picinin said:
The one in your multitool git did not work for me, also it shows the last change was 2 years ago hahahha.
Multitool uses the proprietary miniloader blob for booting and it does not work with opensource OPTEE unfortunately. I guess the issue is related with this patch that allows mainline opensource u-boot to support proprietary Trust OS, but that's just an ineducated guess.
-
Hello @Victor Picinin
yes the problem is exactly a watchdog in the proprietary trust os. Some people have issues after 60 seconds, others after 30 seconds and others after 30 minutes.
Being the proprietary Trust OS closed source, we can't know what is happening. I suspect it is a sort of automatic "suspend" feature of some sort, but can't be sure because digging into practically is diffucult.
What is sure is that if we use OPTEE Trust OS compiled from open sources (OPTEE is the base for the proprietary Trust OS too), there are no issues of sort, but we lose some features like DDR3 memory scaling and "virtual power off" (a suspend mode that can awaken the board via IR-control; there is a driver and a device tree overlay for that to work in armbian)
-
37 minutes ago, GmP said:
I will try to upgrade to tm16xx driver and be back.
38 minutes ago, GmP said:As for the HDMI, do you mean that Multitool shoud work anyway?
Yes, or at least there should be less chances to hit some corner case that reduces the compatibility. LibreELEC is using the mainline kernel only for years though, so it is really strange you have issues with both armbian and multitool. I may wonder there is something odd in the device tree, but it would be odd that a misconfiguration in the device tree causes a kernel fault in the DRM code and in particular in the wait for vblank function 🙄
-
42 minutes ago, GmP said:
Still not clear why HDMI not working, However VFD display based n FD650 is working. Attached the vfd.conf file for openvfd: clock , USB, ETH,WIFI and COLON working.
Very weird HDMI is not functional in both armbian and multitool: they use very different kernels. Multitool uses the 4.19 vendor kernel, which should be supposed to provide "best" compatibility.
The dmesg error is highly related to the missing HDMI, but in a way I can't recognize.
About the VFD driver, I guess you're using OpenVFD driver. Latest kernels (both 6.12 and >= 6.16) come with tm16xx driver which is by far much much better and candidate to be upstreamed in the mainline kernel. Here is the github project reference; the driver is already compiled in the kernel, but you may need to edit a device tree overlay by yourself to let it work with your board.
To try some debugging, the complete dmesg output and the original device tree of the stock android firmware would be very useful.
-
2 hours ago, robertoj said:
I would rather stay with trixie and low fps, because it seems easier to solve my other problem: need 100% wayland and 0% X11 due to a LCD driver problem.
AFAIK bookworm is fine with wayland (weston, kde, ...)
CSC Armbian for RK322x TV box boards
in Rockchip CPU Boxes
Posted
@Dangrain There is a paragraph Partecipation and debugging with the suggested operations to let other people help you in a proper way and perhaps improve support for your board in the mainline armbian codebase. You may want to go your own way, but then helping will be much harder.