jock

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

@Ineptitude unfortunately the driver is not yet included into armbian. I tried to take a quick look to it and there is the usual mess of preprocessor directives to compile and run on the various manufacturer platforms, plus some low general quality code. I gave it some hours for inspection, then I gave up. Perhaps I will give some more love to it sooner or later, but I don't promise anything.

it would require more inspection to understand why your board requires that specific version of the trust, but it is something hard to do without the board at hand 🫤

Well, rk3528 are a new thing around; multitool is half-working so far. It is enough to grab a backup in my case. During my tests and experimentations, I found I was unable to boot from sdcard if the eMMC was completely erased. I would like to understand what is wrong here and why this boot issue is happening, since all other rockchip socs I know do boot from sdcard when the eMMC is empty. This is quite essential for multitool, since it should be a maintenance tool and if it does not boot in maskrom mode it loses half the uses. Anyway in my case it boots fine when the original firmware is installed. At the moment my experiments go really slow because I'm busy with other things, but I managed to bring up am working rk3528-box config for armbian scripts that produces a working image. It can be found in my personal github repo. Since rockchip dropped their proprietary miniloader in favor of their proprietary (but open) u-boot, the armbian image should boot fine from sdcard without erasing the internal flash memory first. I don't know if I will keep this behaviour, but for now it is so. edit: ah, photos are very welcome, but perhaps logs from the serial, original firmware and the original dtb are indeed very useful in this discovery phase. edit 2: I'm just realizing I never published a working multitool image for rk3528, which one are you using? Did you built one yourself? By the way, here is a build for rk3528 soc, but your mileage may vary a lot: https://users.armbian.com/jock/rk3528/multitool/multitool.img.xz

@H1H1 I managed to build another multitool, this time with the Trust OS coming from your image. I noticed that your trust is one of the "bad" ones, in the sense it forces the box to sleep after a while if there is no activity. It was supposed to bring the box in suspended mode when not in use in Android, so probably after some seconds your box may become unresponsive and screen will go blank. @fabiobassa will surely remember such issue; nonetheless you can try it to see if at least multitool boots. You can download it from here Also you and @NiTr0 may also give shot to the latest multitool updated with the latest ddrbin v1.11 @NiTr0 has posted in the other thread. You can download it here @NiTr0 also you may send back feedback if it boots for you, so I may build an armbian image with the updated ddrbin before the official updates

It looks like a very old trust, I see version 1.0.1-88 from the binary; currently there's the version 1.1.0-333. I will try to extract it from the partition and make a custom multitool with the old one!

More than that, which is something would just affect performance rather than "stability", most of the issues with USB devices are 1) the USB current of the ports on tvboxes is kind of limited. Gigabit ethernet requires a decent amount of current by design, and the USB ports can't always supply the requirements 2) PSU adapters coming with tvboxes are crappy chinese cheap devices as the box themselves. Don't expect great numbers from them despite what their labels say. A serious SBC with a decent PSU will probably handle anything much better and provide onboard gigabit ethernet

@NiTr0 thanks for extracting the bootloader, I will update the ddrbin ASAP 👍

@Lukas S. Four months ago I switched back to ddr 333 mhz ddrbin in place of 667 mhz one which was causing issues on some boards. Any recently built image will have the slower but more compatible ddrbin.