jock

Don't know, I never experienced such issue with either FAT or NTFS partitions, since the multitool uses the standard debian tools to do the resize and it works either in Linux and Windows.

@jins what board do you have? It should be sufficient to connect an USB male-to-male cable and flash a backup (or the mere bootloader, if you have it or are able to craft it) with rkdeveloptool or rkflashtool and then it should be able to boot again from sdcard. What board do you have?

A good thing would be the original android device tree, although looks strange to me because the board is a regular R29 and should not behave differently than others.

And it is my advice too. tv box are cheap shit, as @fabiobassa said it is a nice roulette and mostly they are made of scrap parts. If you're very lucky, you get something that works and has some kind of support, if you're unlucky you get crap that breaks after a bunch of weeks because soldering is weak and parts are refurbished scrap. The advice I always give is, if you need something that is required to be minimally reliable and much less painful to setup, go with an SBC supported by armbian; tvboxes are for toying around

@Bert Kortenbach paolo@predatorg:~$ sha1sum rk322x-led-conf7.dtbo f599404e8ccb9d9002da9864a1fe32424400be10 rk322x-led-conf7.dtbo seems like different; by the way I downloaded twice form the post and it worked for me.

Mmmh, apparently it is a forum issue. The same resource can be downloaded from the box in the footer of the post

@Bert Kortenbach Mmmh, looks strange to me it does not work with the updated led-conf7. This is a fresh copy of the overlay for kernel 6.1, in case the one you picked up was experimental or not really working: rk322x-led-conf7.dtbo This is the source reference, for instance. rk322x-led-conf7.dtbo

Then it would not be a maintenace tool anymore but something else; but feel free to take it as a base for anything else! Hint: speaking of Kodi, you are just heading on something like LibreElec Yes, and also because it is the only what to make it cross-OS down to Windows XP. Previously (four months ago) the partition was FAT32, but it would not support files larger than 4Gb

@Arthur Ferraz sorry but without dmesg logs it is impossible to suggest something. It may be that your emmc is broken or who knows?

@Bert Kortenbach Hello; indeed it fails. There's a reason the file is .dtbo and not .dtb: it is an overlay which applies on top of the base dtb. Restore the original rk322x-box.dtb file exactly where it was and restore also the entry in /etc/armbianEnv.txt. rk322x-led-conf7.dtbo has to be put into /boot/dtb/overlay directory, and then has to be activated by adding a line: overlays=led-conf7 in /boot/armbianEnv.txt. Note that rk322x-config script will overwrite the overlays= line in armbianEnv.txt, so you should manually add led-conf7 if you run it

hardware video decoding is still a complex beast, mostly because ffmpeg is still missing the necessary bits which are available as separate patches. v4l2m2m is not the right codec: those are suitable for stataful decoders (rpi and amlogic), but rockchip has a stateless decoder and you have to use v4l2_request decoders. I'm currently working on bringing a ubuntu and debian apt repository which should ease the pain with ffmpeg. It is in an early state and works better in debian bookworm rather than ubuntu jammy currently. I would not disclose the repository yet because it is very early and hosted in my personal lan, but if you're interested in give it a chance I may give you some instructions via private message.

@gpsvitor perhaps your multitool copy is an old version. Download a new copy from the first page of this thread

No chances you ever get that working if there's no driver. And there's no driver, unless you want to write it.

so is life 🤷‍♂️

https://linuxreviews.org/HOWTO_Control_LED_Lights They are not applied at level of ddrbin, but the DMC driver is loaded by kernel; in case you're stuck and your system does not boot anymore, you can always boot via multitool, mount the rootfs partition and remove the ddr3-* overlay in /boot/armbianEnv.txt to restore the default. Default frequency is 333 Mhz and is defined in ddrbin. Armbian is not the stock firmware, hence the factory dts is absolutely not applicable here and would lead you to misunderstandings.

DId you already run rk322x-config and select the proper led-conf gpio preset for your board? There are several presets to chose from depending on the board signature and design; if you don't find any match perhaps your board is new and would be very nice if you could share high resolution photos of the board front and back, the original device tree and, if possible, the backup of the original firmware.

Nope, but I think you can install bookworm and then upgrade to testing repositories. armbian repositories should stay with bookworm though

@NiTr0 in fact it is very strange, and I may guess there's a bug somewhere in the armbian building script. Also running ./compile.sh ARTIFACT_IGNORE_CACHE=yes that forces uboot and kernel being rebuild still produces images with v1.10, despite the bootloader package u-boot-rk322x-with-spl.bin has v1.11 in it. 🤔

It could indeed be, looking at the rk3528 device trees, it has 4 mmc controllers as like as rk3328. Looking in the vendor kernel 5.10, I can guess that the "right" mmc controller for the sdcard is the 4th (mmc@ffc30000), and this matches my board device tree; nonetheless the board refuses to boot from sdcard when internal flash is empty.

@gpsvitor you clearly need to go in maskrom mode shorting the emmc clock pin to ground. You installed armbian on emmc without testing first on sdcard, which is something I always suggest to do. Perhaps your board has 1.5gb of ram like @NiTr0's one? In such case you will need an image with an updated ddrbin, which is the component failing in your situation. If you get in maskrom mode, just erase the flash; don't try to reinstall any armbian image because they will all fail and wait for an updated image.

Oh right, you still need the v1.11 There are some caches around, but should not affect the bootloader which is always rebuilt from scratch AFAIK. Will double check soon, stay tuned!

Which are known to "steal" the work of others without giving credits and support. That's the best way to kill armbian project 😒

@Rodrigo Campos hello; I don't think HDMI stopped working, but instead something went wrong with xfce installation via armbian-config. Honestly, I never try to install a desktop enviroment via armbian-config, but instead I usually build and use images with xfce already installed. Some fresh debian and ubuntu images have been built by armbian servers just yesterday: https://imola.armbian.com/dl/rk322x-box/archive/ You may want to give a chance to them perhaps? They are still command-line only, but maybe they work better. In case they don't work, maybe you could post on this other forum, since I guess it is a userspace issue.

don't know, I don't care about overclocking No, maximum is 7 no, it is useless

Hello! If you mean overclock the cpu, it depends on your sample. rk3318 are rated for 1.1ghz, for so far it looks like a software limitation rather than a hardware one. Some people pushed them up to 1.5ghz, but the increased horsepower is not worth the heat at all IMHO. About overlocking the ddr, actually they are underclocked at 333mhz: dynamic reclocking requires a proprietary Trust OS blob, but this won't allow CPU to go beyond 1.1ghz. On the other side, booting the device at 667mhz caused many boards to not boot at all (notably X88 Pro 10 market models) About the LED Clock, if you mean the frontal led panel, there is a kernel driver + userland application which work together; they do the job, but are rather suboptimal for technical reasons and not included into regular images.