jock

@Ikesankom hello, no I didn't test it yet. Actually, I have been busy with other issues and totally forgot to test for the upgrade path. If you have a bit of patience I may give it a shot in the next few days, probably tomorrow.

@A9 they are not errors, just missing firmware files for various wifi devices that you don't really need

@lucky62 looking with elixir, it turns out that the function was already deprecated in 6.6: https://elixir.bootlin.com/linux/v6.6.27/source/drivers/gpio/gpiolib.c#L1022 You could copy the body of the deprecated function in place of gpiochip_find About of_get_named_gpio_flags you should see if you can afford to use the suggested function

@PLaume Hello! Well, a power loss is a power loss... you won't know what will be gone when the cache is not flushed. I read from the eMCP the code "JY941" or "JY94I", but according to micron part decoder (https://www.micron.com/sales-support/design-tools/fbga-parts-decoder), that chip does not exist. Perhaps it is a fake chinese chip with "micron" printed on it with unknown reliability? About the errors, the hdmi "error" is rather an information and does not affect any feature. The ssv6200 error instead says that the wifi chip does not work because the driver only support ssv6051p chip and not the ssv6256p your board has.

@astrosky I can't recommend you an image you can just install and everything works... tvboxes have this little problem about the changing hardware and that's not so easy. I have repeated dozen of times that tvboxes are not the way to go, buy an SBC if you need reliability. About 6.6.25 kernel, now I understand that you repeated the procedure starting from 6.6.23 image and this time the board rebooted fine but still without HDMI, am I right?

@astrosky mmmh, pretty weird that it broke your setup, it is a quite standard 6.6 kernel, also it does not touch the bootloader. Did you perhaps alter a device tree and changed it in /boot/armbianEnv.txt? because the /boot/dtb directory is replaced when the new dtb package gets installed.

@Hqnicolas thanks for the instructions, but I already have a backup of my box I had taken with multitool. The problem that is puzzling me is why the box does not boot from sdcard when the emmc is empty, something which is absolutely normal for other rockchip devices.

i have one of those boards, the silkprint on the PCB says RK3528_DDR3, that's the one I used to bring up the mutltool for rk3528. A major "problem" I have it is that the board does not boot from sdcard when the eMMC is blanked. I had no time to understand what is the reason behind. Though it should boot when a bootloader is available in eMMC.

Hello, for anyone who is having difficulties with HDMI, I made an experimental 6.6.25 kernel with a very small number of patches from LibreELEC project available here. I can't test by myself because the rk3318 board I have was already working with my monitor, yet the patched kernel did no harm on my setup. If there are some successful reports, the patches will be merged into armbian and hopefully the HDMI issues will be fixed once and for all. Thanks!

Hello; for anyone is still having issues with HDMI output, I have arranged a minimal set of patches that could go into mainline armbian. The .deb packages for an experimental 6.6.25 kernel and dtbs are here. Just install them with dpkg -i I can't test if they are effective by myself because I have no setup where HDMI fails, nonetheless they seem not to harm my current setup. If you can afford to try that experimental kernel, please report your experience, thanks!

You can take a look to this thread also: it does not contain any solution, but there I posted an experimental image with kernel 6.3 and some patches cut out from libreelec patches set that solved the problem. The problem is that it is a wide number of patches to import to solve the issue, and since I don't have a setup with HDMI issues I can't do tests to reduce the number of patches to an essential set.

I did not experience all the issues you had, and it is strange that so many issues appeared just with updated kernel revisions.

Yes, I have similar reports for both rk3328 and rk3399 devices. Looking into the kernel, effectively something has been changed upstream, but unfortunately I don't have such issues with my monitors and it becomes hard to debug

@moddien Why did you try to burn the image in the eMMC without being sure it would have worked? If you can boot multitool again, clean the eMMC and start fresh. I have prepared an armbian bookworm image with opensource optee in place of the proprietary one, you can download from here; I have not tested it at all, so can't guarantee it works. If you want to try it, first clean the eMMC with multitool and then try to run the image from an sdcard to see the outcome.

@Netraam31 I did a quick check on a board with rk3328 (not rk3318, but should be the same) and you can use both the USB2 OTG port or the USB3 port as peripheral. in the device tree the device usb@ff580000 is the USB2 OTG port controller and usb@ff600000 is the USB3 port controller. I quickly tried ethernet gadget to check if it works. This command loads the USB ethernet gadget module. which is a bit of "deprecated" in favor of configfs, but it is handy for tests (run it with the USB cables connected): modprobe g_ether iSerialNumber=0x00000001 Then a device usb0 should spawn on both the machines, which is nothing more and nothing less than a regular network interface. You have to give an address to both the endpoints and then you should be able to ping and exchange data. The result is that, at the current state of the kernel 6.1 I have right now (but 6.6 is exactly the same, since nothing changed), the USB 3.0 port is working plenty well, instead the USB 2.0 port is suffering the same problems experienced for rk322x, which disconnection and system freeze. Things seems to have changed with kernel 6.8, where also the USB 2.0 ports seems to work, thanks to the upstreamed fix for clock gating. You should be able to upgrade to kernel 6.8 installing the linux-image-rockchip64-edge package or, more appropriately, via armbian-config. Don't forget to put kernel and dtb packages in hold if you modify them manually, otherwise updates will overwrite your modifications!