jock

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.

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.

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.

This is not a place for Android ROMs, only armbian here.

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

@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

Can't you run on sdcard? It is heavily suggested to run on sdcard before installing on emmc. However the overlay is emmc-pins

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

Probably you have to read again the installation instructions in the first page, in particular you have to use the multitool

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

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.

I tell you to read the first post of the thread.

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 ok, so the leds in the previous dtso are wrongly addressed? Because in the latest dtso I see 7 leds addressed on segment 0, instead the previous dtso declares 4 sparsely addressed leds. edit: note also that your board is T98_RK3318, not T9_RK3318

@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

@Aroldo Bossoni 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.

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

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