jock

@digicroxx @Carlos Ervedoso add line overlays=led-conf7 in /boot/armbianEnv.txt

Source code is open, I have no rk3128 board but support can easily added (not by me though!)

That is intended to work that way, for an important reason: the bootloader is not just a mere bootloader, but installs complex code in memory and you don't know what it does. More on that: that code runs in a secure context, which is not accessible by anything, so you really don't know what it does and what it can do. One clear example is the fact that the stock bootloader artificially blocks the rk3318 when it runs beyond 1.1ghz, while we have seen it is pretty capable of running at 1.3ghz perfectly fine like the rk3328. The idea is to remove as much as possible of the proprietary blobs (ie: the stock bootloader) and provide open alternatives; tinkering with the bootloader may work now but surely will cause troubles when there will be an updated bootloader. Your case with broken emmc is a different condition by the way, because you have limited alternatives. However there are no real secrets in the boot process, just some complexities and some of them are explained here

@aht2000 Perhaps this helps

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!