jock

@baryon actually you don't need to take @ilmich's branch 4.4.1, but you can use the ffmpeg 6.0 coming from libreelec's master branch: the package details, it's source and the patches to apply are self-explained in the package.mk file; compilation flags also are in the package.mk, you just need to assemble them "manually"

Unfortunately, it is not that simple. v4l2 (ie: kernel) was a moving target in those days, and ffmpeg also was a development version from libreelec project, and things have changed a lot in the meanitme. Replicating the exact setup of that build is very difficult because many pieces have to come together. @baryon it requires to align the kernel user-space headers, a patched version of ffmpeg (v4l2-request and drmprime APIs have not been mainlined yet into ffmpeg, unfortunately). mpv is the easiest piece of code to compile and get it ready here, but the final binary will depend upon: the kernel version, probably kernels >= 6.1 won't have problems because API finally got frozen, but older kernels may have issues the distribution, because mpv uses ffmpeg and ffmpeg is dependant upon a slew of dinamically linked libraries that are often distro-specific (read: libx264 and libx265 to the most); sometimes soft-linking libraries is a workable workaround, but not always I may give a shot and compile on a more recent kernel/distro, but the last time I did there were some regressions that may have not yet fixed. Plus it takes a lot of time because compiling ffmpeg in particular requires a lot of time.

@Brasil150 more than the cable, there are some reports that USB3 ports can give some issues; USB2 port with an USB2 cable is the recommended choice

Yeah, we live in the clouds and sometimes we land to go to the grocery store ...

I have quite to no experience with windows tools, but if your box enters maskrom mode without pinning the eMMC clock pin to ground, then it is either empty or broken. If you didn't erase it, probably it is just broken, as often happens with tv boxes.

@H1H1 closed source blobs like TEE/TrustOS are always a pain... try with this other multitool version: https://users.armbian.com/jock/rk322x/multitool/multitool-old-tee.img.xz, now it is version 1.0.1-72 and boots fine on my MXQ_V73 board (by the way 1.1.0-333 also was pretty ok) I hope it works for you too, otherwise you should boot in maskrom mode, make a backup with rkdevelopertool/rkflashtool and share the original firmware image so I can extract the trust from there. Once you have the backup, perhaps you can also erase the emmc with the tools and try booting armbian from sdcard (remember that armbian and multitool use 115200bps for serial output)

@H1H1 Try with this other multitool: https://users.armbian.com/jock/rk322x/multitool/multitool-old-tee.img.xz

@H1H1 Yes, the original firmware uses 1.5mbps uart rate, but the multitool uses 115200bps, so you should be able to see the output of the multitool if you set your uart adapter to 115200bps. However I see some unexpected messages : [9hjjNa:N\xDF\xC7\xDF\xC1\xD0\xC7\xDF\xC5l\xDF\xC2\xDF\xC3@NfN\xDF\xC0\xDF at the bottom of the log. It may be garbage, or may be something the TEE (the Trust OS) does not like at all, hence the freeze with the multitool. Could you please try 115200bps and see if you get any output? Also the output of the original firmware boot (1.5mbps) would be interesting. It could be that I need to craft a special multitool with a different Trust OS, but I need to know which version boots on your board

@H1H1 Hello. That board is very well supported in armbian. The serial port is available on those 4 pins between the two USB ports. The pin with the square frame is GND. The only problem with the serial is that it is disconnected, but can be connected with a very very small amount of soldering over two couple of pads that have been left without the component. You have to be very careful and need a steady hand to do a good job. Using some paper tape to cover a couple of pads while soldering the other couple may help you avoid damage to the board.

Fixed

@ego worker well, that's very curious that on your first attempt it did not work... I still see that, despite the newer v2022.04 u-boot version, the dtbo overlay was still not applied 😕 Anyway, good to see that you finally got it working!

@ego worker thanks for checking in. Perhaps the bootloader installed in the internal flash memory is too old. I see that u-boot is v2021.04, but current one is v2022.04. Your version is not applying the device tree overlays at all, hence the instability and the missing HDMI when trying to run armbian. You may try to transfer the updated bootloader from the sdcard to the internal flash with: sudo dd if=/dev/mmcblk0 of=/dev/mmcblk2 bs=32k skip=1 seek=1 count=32 but also double check that you have overlays=led-conf7 in /boot/armbianEnv.txt (check also on both the internal flash and sdcard; u-boot should take the one from the boot device, but bugs in u-boot are around the corner...)

That's the main problem for the general solution you propose. Looking into the base device tree of the kernel (rk322x.dtsi), that gpio pin (gpio 2, pin RK_PB3) is declared in use only by gigabit ethernet devices. Also looking in the original device trees of the boards there is no other trace than gigabit ethernet pin. Surely no tv box with rk322x has been produced with gigabit ethernet, so from that point of view it could be safe to enable it. But looking at the base dtsi is not enough to declare that any board does not use that pin: as it happens on r29/r2b/h20, any other manufacturer may have decided that the pin may control something more or less important, or perhaps it is internally wired to something, tinkering with that may affect other boards. It is a remote possibility, though it can happen. Multitool (and libreelec too) has the pin enabled by default, so we will see if it can have side effects on other boards.

I already opened a pull request on armbian, when it will be accepted, new kernel will be built with fixes, but I have no control on when the new kernels will be built by the armbian servers.

Yes, it is expected that is so: you must run rk322x-config, set led-conf7 and reboot (or setup led-conf7 manually in /boot/armbianEnv.txt) Legacy kernel is discontinued, has some reason only for those who have old boards with NAND. You have no reason to stay with legacy kernel, it's old, insecure and unmaintained!

@Benedito Portela Here it is a debian buster minimal image with latest 6.5 kernel. I did not had time to test it though, so try it with an sdcard first! edit: tested the image, it works plenty well!

@occams razor I produced a bunch of deb packages with update dtbs, you can find them here, in particular you can test this deb package for edge kernel 6.5. You should get a new led-conf8 overlay, so you can remove led-conf7 and add led-conf8 in /boot/armbianEnv.txt, reboot and see if the board boots and works.

@MattWestB I've uploaded convenient deb packages with update dtbs for both kernel 6.1 and 6.5; now they should be finally fixed and work, at least I tested on my board and they work pretty fine. You can download the deb package from here - for your installed system with kernel 6.1 you may want to download and install linux-dtb-current package Please do a backup as you already did of the /boot/dtb directory on your existing installation!

I resume this thread because there have been some advancements in the HDMI problem on the R29 boards and, discussing with @ilmich and @fabiobassa, we noticed that there are some similarities with the H20 boards. @occams razor here also posted his experience with a H20 board and the photos are very informative because his board has the marking H20_221_V1.71, while the board in this thread is H20_221_V1.5. The difference is important, because @occams razor's V1.71 boots but has no HDMI, while V1.5 board does not boot at all. Despite the different form factor of the two boards, the V1.71 looks like having three high power switching regulators, while the V1.5 has just two of them. Looking at the DTB, probably both of them require to switch a GPIO to enable HDMI exactly as like as R29/R2B boards, but the H20_221_V1.5 probably is not capable to run the CPU above 1Ghz, while the V1.71 can. Multitool has been fixed for R29/R2B boards, but now it should run and show HDMI also on all H20 boards. I posted here an experimental image that H20 users can test too, enabling led-conf7 overlay as well. I may also provide a special overlay for @occams razor for his H20 V1.71, which should perhaps be able to run cpu up to 1.4 ghz

The Debian version has nothing to do with the underneath hardware. It's just that if you use an older image simply you miss some corrections and compatibility fixes here and there that allowed the eMCP boards work in a stable way.

Ok, I need to better check what is going on with kernel 6.1 then; perhaps it is a misalignment with the base dtb, but I will try to be more specific tomorrow. Thanks in the meantime!

@Benedito Portela I checked your firwmare and actually R29_MXQ and R2B_MXQ share the same identical original device tree, so you can go testing the image, just follow the instruction and try with a pristine system on sdcard/usb stick, not juggling with dtbs on existing systems

@MattWestB This is the dtb for kernel 6.1, it should work on your existing installation: rk322x-led-conf7.dtbo

@MattWestB Perfect, thanks! I see the eMMC is correctly detected and ethernet working too, so probably my sample is just defective.

@MattWestB Ubuntu or debian does not matter, the dtb depends upon the kernel version. The image above has kernel 6.5 (edge) and I ask to briefly test it as is, in particular look over hdmi, emmc and ethernet and report dmesg. Jiggling with dtbs over other kernels, or use multitool dtb on armbian (baaad!!! never do this!) is a hazard: it may work or may end up with a broken system and a broken system surely does not help anyone 😐