jock
-
Posts
2154 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
5 hours ago, vklimk said:
I am not sure what have you implemented to make armbian supports rk3288. And it make me unsure if "apt update && apt upgrade" if safe. Are there system packages I shouldn't upgrade (maybe kernel or hardware-specific tools...)?
Armbian supports boards, not bare SoCs. This thread is about xt-q8l-v10 rk3288 board, which is supported by community and not officially. If you want official support, prefer a SBC which is declared as officially supported, like the Asus Tinkerboard.
Community supported boards are "best effort", officially supported boards are usually checked before new armbian releases to maintain general support and functionality.
-
UPDATE for Multitool
Finally I managed to let the Opensource OP-TEE work with the rockchip miniloader!
This means that the Multitool should now work on any board, without freezes and booting issues!
The new version can be downloaded from the first page of this thread.
Please report if it works for you, thanks!
-
2 hours ago, vklimk said:
Have a look here: https://k-space.ee.armbian.com/archive/xt-q8l-v10/archive/
This is the official armbian page with nightly images for all targets (supported and community)
-
8 hours ago, ArturHey said:
I have no idea why, or how, but that worked. Thanks for all the help. Do you think I'll have any problems in the future when updating the OS?
Me neither have any clue about. Surely the problem lays in the closed source proprietary binary Trust OS. It does or expects something and then locks the system with that typical string [2accGZ3... which is probably known only to rockchip engineers.
Unfortunately I don't have any board here that exhibit the same behaviour, so the issue is hard to study.
To avoid issues with updates, you may want to put the u-boot package on hold using apt-mark hold, so in case of updates, the bootloader won't get updated and you'll be fine.
-
Just now, ArturHey said:
Any suggestions?
The issues are definitely related to the Trust OS, as you already noticed in your experiments.
You need a build with a different bootloader that contains a different Trust OS or the Opensource TEE, which has no issues so far. An old rk322x_tee.bin file can be found in this old commit, if you want to build an armbian image/bootloader by yourself: substitute it with the existing rk322x_tee.bin and try building an image.
-
52 minutes ago, ArturHey said:
Result: Absolute silence. No LED, no UART output.
Perhaps you need to set the UART baud rate to 115200bps. Original stock firmware and binaries uses 1.5Mbps, armbian bootloader is set to 115200bps for broader compatibility.
You should at least get the ddr initialization messages, there are no chances you get no uart output with armbian unless the image is invalid itself.
-
7 hours ago, BoringName said:
Now I have version 35.1 which fixed the drm_prime errors for me.
The drm_prime error is somehow "normal": AFAIR mpv was trying each hardware decoder in turn and, if it does not support the codec, prints the error and tries the next hardware decoder in line. If you try to decode h.265, perhaps it first picks an hardware decoder which does not support such codec with such parameters and prints the error, then tries another decoder which is capable and everything works. Usually rockchip devices have two hardware decoders, Hantro and rkvdec; Hantro does not support h.265 at all on older chips, but rkvdec does.
-
@ArturHey you did a lot of experimentation, but actually I think you are stuck on something different. GPT partition error message is something you can totally ignore, either because stock firmware usually don't provide a GPT partition, and armbian images neither do.
The rockchip miniloader supports GPT partition table, but it is not mandatory to work. If there's a GPT partition, the miniloader searches for "uboot" and "trust" partitions to use them as hints for the base addresses. If there's no GPT partition, it will just use default base addresses and look for the LOADER and TRUST signatures.
Anyway, armbian does not use anything from that: there is no rockchip miniloader, neither are GPT partitions or other proprietary code, except for the Trust OS, which is embedded into u-boot. The boot process is totally different on armbian.
Now, the issue you have with flash not being recognized by rkdeveloptool makes me think about three possibile situations:
- a bug in rkdeveloptool
- you are still in maskrom mode and did not upload the usbplug firmware with rkdeveloptool db (ie: the board is not yet initialized)
- a broken flash in the eMCP part
You can, for example, refer to the procedure Installation (without SD card, board with eMMC) described in the first post of this thread if you want to write a raw image in the flash memory but I always suggest to erase the flash memory and test the image via sdcard first, rather than installing the image immediately, because you can softbrick the board.
About the non-booting multitool, you should post some logs from the serial uart, but probably the main issue is related to the trust os which freezes the board after few seconds.
-
5 hours ago, Harleyyyu said:
ffmpeg benchmarks actually run successfully on both 16MB and 256MB despite the warnings. However, I decided to keep the requirement at 256MB purely as a precaution. Given that a 1080p NV12 pipeline with multiple buffers can eat up memory quickly, leaving it at the default 16MB felt risky for long-term stability in a car environment, even if it 'technically' runs.
Technically CMA is not needed at all for the VOP. Rockchip VOP has its own MMU, it is not like raspberry pi or amlogic devices. It should not require to reserve and map memory by the kernel for the VOP as long as the MMU is enabled in the device tree and it is working correctly.
-
Nice, congratulations!
I wonder why cursor does not show when video is playing by the way: there has always been a patch in the armbian code to support hardware cursor, in fact in X11/Wayland the cursor is handled in hardware and it is perfectly visible and usable when a hardware accelerated video is playing.
Also I wonder why you need CMA=256M; normally rk322x VPU has its own MMU that is capable to handle direct to memory access without the need of CMA.
-
@robertoj the problem is not ffmpeg, which already is works totally fine on debian Trixie (and backwards), the problem is within mpv that changed in v0.4.0 carried by debian Trixie, and at the moment I don't have enough motivation to carry on a custom mpv package for Debian Trixie.
You may try with debian forky by the way, but it is a moving target as long as it is still in development.
-
7 hours ago, SanchopansA said:
Is eMMC died? or?
Probably dead, yes. It looks like it is in read-only mode, so you cannot even erase it.
Unfortunately for you, the way I designed the armbian boot requires either an empty flash or an installed u-boot that boots from sdcard first.
You have three options:
1) hack the armbian boot using the multitool bootloader, but I don't suggest doing so because updates may overwrite the changes
2) remove the eMMC phisically, desoldering it
3) short the eMMC clock pins permanently, similar to what you would do when you want maskrom mode. The board will then always boot from sdcard. See the unbrick paragraph in the first post for some instructions.
-
Sorry @Harleyyyu, but me and @fabiobassa were a bit puzzled about your journey within the hardware video decoding.
I recently tested the kernel 6.18 (but I am pretty sure it works fine also in kernel 6.12/6.6/6.1), but everything was already in place even with zero-copy DMA buffers, using the LibreELEC patches which are already compiled in the mainline kernel shipped with armbian for years right now.
Then there is also this apt repository I brought up few months ago with ffmpeg already patched and some instructions to run mpv with hardware decoding, which so far works for me either in virtual terminal and wayland (although sometimes with some glitches).
Just to let you know, because it looks like hardware video decoding, HDMI and GPU things are unsupported, but actually everything works fine.
-
15 hours ago, X Hamster said:
I'm looking for a ROM because this Android box only stops at the logo. However, there's a problem with the PCB board type 3328 but the chip is 3318. How do I find the firmware? Is there anyone here who has it? And I've tried flashing with RK3328 but it still bootloops.
This is not a place for Android ROMs, only armbian here.
-
-
@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.
SV6256P WiFi Now Working on Linux 6.x (Armbian Tested)
in Allwinner CPU Boxes
Posted
Hello, congratulations for your achievement!
I wonder if you had the chance to give a shot to the ssv6051 sibling... the original drivers (one for ssv6051 and another for ssv6x5x) were really a mess that @ilmich and me did a lot of work at the time to cleanup and fix things in the past time. We concentrated against the ssv6051 driver at the time and in fact the ssv6051 driver already works in mainline kernel (it is in the rockchip 32bit patch directory), although it is still quite a mess. Here it is the repository if you want to take a look to the commits.
We also started an attempt to do a clean and proper reimplementation of the ssv6xxx driver, but actually never went over firmware loading (the repo is private since it was a heavy WIP, but can share if you have enough will to take a look to that)