jock

@Vladimir Trondin I see no issues about eMMC in that dmesg

@haven could not check right now, but nothing should have changed from the audio side. Perhaps the order of the devices changed and what was once the default, now it is not anymore? Recently I enjoyed some Quake running on an rk3318 box and analog audio was the default. Those errors also are not relevant, the audio devices will still work with no issues.

Hello @Vladimir Trondin, as @fabiobassa already pointed out, there is no driver for ssv6158. Doing some research, it seems that it may use the ssv6x5x driver, but it would require adaptation, plenty of time, plenty of patience and you would not be sure if it will finally work. About the eMMC of your board, it would be handy to get the output of dmesg command, but in the meantime you could do some experimentation with the emmc parameters in rk322x-config withing this page: In particular, try to enable emmc-pins and emmc-ddr-ph45 or emmc-ddr-ph180 or emmc-hs200 (these last three are alternative, only one should be enabled) and see if your emmc gets detected after a reboot. Also your board r3229q is not listed within the led-conf options, but I see some similarities with r329q board (led-conf2) MXQPRO_V72 (led-conf6), so you may start trying with those ones, or stick with generic since your wifi is already detected despite being useless.

Exacty, mpv in debian bookworm already has full support for drm-prime, so there is no need for a patched version of that the instructions that work are there, in the meantime it can be that mpv changed some default, actually I didn't check recently

There is a post on the rk3318 tvboxes forum with a kernel dump and something that did not went good with work queues: https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=203586 I did take a little look into the code, but could not spot anything wrong. By the way @Jean-Francois Lessard wasn't it simpler to use .led_set_brightness_blocking in place of .led_set_brightness and let the led core do the job with the work queues?

@Parth the soc is slow, it is one of the slowest socs around with a modest amount of memory on board , so don't expect stellar performance. The image with debian bookworm is a minimal image: small and good for servers. For all the other questions, you can consult the official armbian documentation https://docs.armbian.com/ and related forums

@Vidhome I'm glad it worked, but you didn't really need to compile the driver yourself, it should have worked out of the box after choosing led-conf5 and rebooted

I uploaded also a bookworm with kernel 6.11 image here

you should get the regular log on the uart and then kernel and systemd messages. You shoul also get proper HDMI output (except for R29/R2B/H10 boards, which require to be first configured with rk322x-config). edit: ah, uboot is fully functional both via uart and via usb keyboard

You can burn it on an sdcard and test directly from sdcard if you blank your emmc with rkdeveloptool or a similar tool. When emmc is empty (as well as when it is "masked", hence maskrom), the board will boot from sdcard and it is the suggested way to verify the board boots with armbian or has issues.

@Parth here it is, you may try to run this image and see if it boots

@Parth Yatin Temkar hello; I'm a bit confused about your journey. First of all, as @RaptorSDS said, the specs of the rk3228a board are fake because the chip cannot support more than 2gb of DRAM. You have 1gb of DRAM and the proof is the ddrbin that is reporting the DRAM size. A backup of the original firmware would have been really useful, I suspect you have some issue with the trust os. This: makes me think there is some artificial in the proprietary trust os that is freezing the board. You have to try with a bootloader with opensource optee but at the moment I don't have it at hand, but can give a chance to build an image with the older opensource trust os and see if it works for you. As long as you have the serial working, could you please post the output of the multitool boot?

@SuperMaximus I just double checked on a pristine armbian installation on my tinkerboard and enabling pwm1, pwm2 and pwm3 does not incur in any inconvenience. All the 4 pwms are available in my case: root@tinkerboard:/sys/class/pwm# ls -lah total 0 drwxr-xr-x 2 root root 0 Oct 14 12:26 . drwxr-xr-x 66 root root 0 Oct 14 12:26 .. lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip0 -> ../../devices/platform/ff680000.pwm/pwm/pwmchip0 lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip1 -> ../../devices/platform/ff680010.pwm/pwm/pwmchip1 lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip2 -> ../../devices/platform/ff680020.pwm/pwm/pwmchip2 lrwxrwxrwx 1 root root 0 Oct 14 12:26 pwmchip3 -> ../../devices/platform/ff680030.pwm/pwm/pwmchip3

@SuperMaximus oh, that's weird, sorry for the inconvenience! You should be able to attach an usb cable to the USB micro OTG port and then to a computer: the tinkerboard will appear as a mass storage device and you should be able to revert the changes. By the way, always enable only the overlay you need. I double checked and to use pwm2 or pwm3 ,you need to disable uart2 because some pins are muxed. Anyway I see something wrong in the device tree for the tinkerboard: all 4 uarts are enabled in the base device tree, thus having the overlays to enable is not useful and, moreover, uart2 should be the debug uart which is not a good idea to disable. I need to investigate a bit in this, but I hope you will be able at least to restore functionality of the board.

Here you get the pwm1, 2 and 3 overlays. Put them in /boot/dtb/rockchip/overlay directory and enable those you need in /boot/armbianEnv.txt or via armbian-config and you should get the pwm devices. rockchip-pwm1.dtbo rockchip-pwm2.dtbo rockchip-pwm3.dtbo

Unfortunately I don't have a Tinkerboard S R2.0 but a Tinkerboard S R1.0. I took a look into the device trees and in fact I have the confirmation: for the Tinkerboard (all versions) only the pwm0 is enabled. pwm1, 2 and 3 are disabled. If you're still interested, I can provide the necessary device tree overlays to enable them selectively.

It seems that your board is freezing after DDR initialization and before miniloader boot. It could be an issue with the DRAM or an issue with flash memory, but since you said you swapped the sdcard and moved to eMMC, probably the problem may somewhere in the DRAM. I'm more prone to suspect some power issue or interference issues though. I see from your dmesg that you have a faulty USB device attached: USB device could easily cause the board to misbehave, either by direct effect (faulty or shortcircuited USB device) or indirectly (interference coming from external equipment attached to the USB device). I have seen once a faulty USB stick that was preventing a Raspberry Pi to boot at all; removing the stick allowed the board to boot fine.

Well, the X88 Pro board is supported, so you may just want to try it

@Alex ThreeD yes, the proprietary SPL (the "miniloader") bahaves that way: I'm going by memory so I may be faulty about numbers, but in general it starts from an address (sector 0x2000) and tries to find the LOADER signature; if it does not find the signature, retries adding 0x800 sectors and so it goes on... Then does the same for the trust os (looks for TOS), starting from sector 0x4000. As said, numbers may not be exact. What is not really widely known is that you can put a GPT partition table on the flash and name the partitions uboot (or u-boot, can't remember exactly) and trustos and the miniloader will start looking directly there. About the bootrom and miniload order, you're right: bootrom first tries from emmc, then from sdcard. miniloader first checks the sdcard, then emmc. This is a great source of pain when dealing with booting on rockchip; allwinner, for example, has the bootrom that boots first from sdcard and then emmc and everything is much simpler there.

@Vidhome drop the openvfd driver, recent armbian kernel have the tm16xx driver from @Jean-Francois Lessard already compiled in for rockchip64. You have to enable the beta repository, upgrade and everything should be already set up for X88 Pro 10: https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=203491 Don't forget to take a backup of your installation before enabling beta repository. Otherwise, you could compile the tm16xx driver it by yourself: https://forum.armbian.com/topic/43667-help-wanted-to-test-a-new-openvfd-alternative/?do=findComment&comment=202875

Actually the main trigger for bootloading is the miniloader, which leads to boot from sdcard or emmc depending on what it finds in sdcard. If there is a proper signature in some expected addresses, it will load u-boot and trust OS from sdcard, otherwise goes with emmc. Also it will check for GPT partition table searching for the address hints where to find uboot and trust os. Actually you should not need to supply a trust os: uboot (called the "loader) should suffice for the rockchip miniloader. Anyway, the main idea is to wipe all the proprietary blobs and keep the bare minimum to do the job. Currently, despite u-boot is capable of initializing DDRs on rk3328, the rockchip ddrbin is kept proprietary for broader DDR compatibility among the boards, the rest is fully open source. The proprietary trust OS would also allow DDR frequency scaling, but it is doing nasty things and crashes the SoC when you run it faster than 1.1GHz. Dual boot may be interesting, but at the moment I won't merge that unless there are very important advantages.

About the service and driver issues, you could post in the post of the author about the kernel module: I'm glad you tested also the indivual leds and they work; I will integrate those into the RK3318_V1.4 device tree overlay

@MattWestB I decided not to provide the service scripts yet because they provide different functionality and can be installed or altered manually by any user. Also not all the boards have the front display. The driver, clearly, is a different beast and is easier to be shipped within the kernel package. As you can see, the services can be downloaded from the github repository and installed manually or, if you like, you can package them into a .deb and I will be happy to host it on users.armbian.com By the way, the driver requires a device tree node, you can't just modprobe it into and expect it works. You have to select the right device tree overlay with rk3318-config and some leds (LAN, for example) will be autoconfigured as well. About the "command package", route is deprecated, you should use ip route instead thanks for reporting the digits order and segments order; individual leds can be accessed within /sys/class/leds as well

@MattWestB led-conf7 does not exist on rk3318 build, it is just up to led-conf5 I introduced very recently; your board should fit into the base device tree. Anyway, if you'd like to test the new tm16xx driver (which include support for fd6551 and several other led driver chips) you'd need to switch to the armbian beta repository, but beware of the dragons ahead! So take a full backup first! You can switch to beta repository in armbian-config or by changing apt.armbian.com to beta.armbian.com in /etc/apt/sources.list.d/armbian.list Then run apt update and upgrade at least the kernel, dtb and armbian-bsp-cli-rk3318 packages, then reboot, run rk3318-config and (for your specific case) you should be able to test the fd6551 driver with led-conf5 (YX_RK3318 board) Now that you are confirming me that RK3318_V1.4 also have a display panel and the fd6551, I can update your board device tree too. Notice that it should be handy to know if leds and segmentes are displaying correctly. You can make reference to the original driver https://github.com/jefflessard/tm16xx-display on how to configure and tweak the driver for your specific board. Everything which is there applies as-is. The same applies for other people with X88 and YX_RK3318 boards: there the led-conf that applies to their board should be already working out-of-the box!

In the meantime I integrated the driver into armbian for rockchip64 targets: https://github.com/armbian/build/pull/7338 , so it will be a bit easier to test it out-of-the box and it would also be easier for amlogic people to copy-paste the driver patch and integrate the device trees as well. My tests on hk1 rk3318 tv box (board silkscreen YX_RK3318) worked like a charm and the display is now pleasantly showing up-to-date date and time