jock

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

Actually the issue was fixed only for rk322x in 6.6; if you take a look to the patches, I didn't backport but made a special case for rk322x on my own: I was not aware if other rockchip chips were affected by the issue. A few days after, the same clock gating fix materialized in the 6.8 kernel for all the rockchip chips. Anyway, this is just for the chronicles; about your specific question the answer is yes, the issue is still present for rk3318/rk3328 in kernel 6.6. I'd like to take a look this evening and do some tests and in case make a patch for rk3318 too, stay tuned for news!

@Netraam31 hello! You're in the right direction, dr_mode="otg" simply can't work without a micro/typec usb connector. The main feature of the OTG port is the capability to switch on the fly in host or peripheral mode, but to do that a fifth pin in required. Regular USB-A ports have only 4 pins, so when you get them you surely cannot exploit the OTG feature. The USB port is still called OTG because it is "dual role" (host vs. peripheral), but simply cannot switch automatically, hence you have to change it in the device tree. Finally what is true for the rk322x is true also for rk3318: during my tests the peripheral mode was not behaving correctly without disabling the clock gating and adjusting the core reset timing. The clock gating issue has been fixed in kernel 6.8 (the patch addresses the issue on 6.6), but the reset timing can still give some trouble. Mass storage mode was my testbed, along ethernet emulation; what is still not working at all is the audio gadget which, I guess, uses isochronous mode which is still buggy. Anyway you surely have to set the OTG port as device mode you have to use dr_mode="peripheral" in the device tree. On rk322x there is a quick device tree overlay to do that, without editing and fiddling with details. I don't remember if there is a similar overlay for rk3318/rk3328, but I guess not. Notice also that you will not see any USB device connected on the other side when USB2 port is in peripheral mode until a gadget is set up. There are several guides around (especially for raspberry pi) on how to setup a gadget, you can use them to actually test the port.

Ok then I would first try with a pristine image on a different sdcard if possible, just to understand if the problem is the sdcard itself or something messed up in the kernel

@astrosky as I already told you, there are no spare buses to tinker with on tvboxes. The second uart (ttyS0 usually) you found perhaps is in use for communications with the bluetooth chip which happens via plain serial data. If your board has no bluetooth, then you may use it for your business, otherwise you will get garbage there too. Still an SBC is far better for these tasks, you easily get three or four UARTs on the pin headers you know what purposes are for.

@Ikesankom sorry but you did not share details on your system: you didn't tell where your rootfs is installed (emmc? sdcard? usb?), just a "yes, it is an USB drive attached", so I supposed the rootfs was on the USB drive. The rootfs is elsewhere and from the piece of dmesg you posted it looks like the eMMC (mmc@ff0f0000) is "busy" for some reason and sdcard (mmc@ff0c0000) initialization is getting delayed. I did not experience such glitch, but I can try later to double check if my board is ok. In order to get decent support, you should tell first of all what Tinkerboard version (regular? version S? version 2?) and revision you have, if the eMMC is soldered on board or added as separate module.

@Ikesankom there are some messages in dmesg I don't like at all, but surely the the rootfs UUID seems to be the wrong one. You can alter it editing /boot/armbianEnv.txt and pasting the right one. When you are in the initramfs you have to manually mount /dev/sda1 somewhere and then you can edit the file. The right one is the one you get from blkid 4ca8....43ad; I don't know why the UUID changed after the upgrade, perhaps an sdcard was plugged in during the upgrade?

@astrosky your setup is involved but works, nonetheless the kernel can and will write its debug output to ttyS2 despite you stopped getty process, because getty just handles the login and interactive terminal. That can be easily fixed changing the kernel command line, but still the bootloader and trustos will use ttyS2 to output their debug info. If you're comfortable with occasional spourious data, then it's ok, but personally I would not rely on that if I would control something remotely like a boiler, a relais or whatever...

@Ikesankom Hello, your problem seems different than the bootloader issue described in this thread. In your case the bootloader is ok and the kernel boots fine, but the rootfs is not detected. It could be due to a missing module in the initramfs, which is weird because emmc/sdcard storage are built in the kernel and not as modules. It would be useful if you can submit the output of dmesg and blkid. initramfs has a limited set of commands, but you should be perfectly able to mount devices and write the output there.

@tj13 don't worry, it's no pain. Bug reports are always appreciated, but without logs or whatever it is very uneasy to guess if the problem is related with the broken installation script or whatever. Surely you can follow the posts of this thread to get a clue; if you installed the system in eMMC perhaps you can try the Multitool from this page and see if it works (I never tried it on TInkerboard), so at least you have a way to backup and access the filesystem. At last, the uart adapter suggested by @SteeMan can give some important hints about what went bad.

@Caio Lima Viana great job! Now it looks to me that u-boot is unable to work with the eMMC (it is dwmmc@30020000 device, or mmc0 in the uboot log), or for some reason is unable to find the device tree (FDT_BAD_MAGIC). It seems that there is something off with: the internal eMMC: the u-boot version is an old one, I wonder if your board is a recent one with eMCP (see first page) chip instead of regular eMMC the filesystem installed on the eMMC: you can use an sdcard with the multitool and get a shell, run fsck.ext4 /dev/mmcblk2p1 and see if finds errors; you can even mount the partition and inspect manually if /boot files are in place At the moment I have no more ideas, but these two above worth trying.

@Caio Lima Viana Yes, copying sdcard to emmc should work, there is no difference. About the reason it does not boot, if you don't get any output on the HDMI and the board does not answer on the network, serial UART is the essential tool to get some clue about. You can surely do a clean installation on eMMC with multitool, then "transplant" the whole rootfs, but if you don't know where the issue is, you may transfer the problem too and get stuck again.