jock

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.

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