jock

@haven openvfd is long time deprecated. Armbian images have tm16xx driver which is far better and superior and x88 pro is supported out of the box via device tree overlay.

It is already mentioned in the first page under the "Special Hardware" paragraph.

Then you may want to follow the instructions on first page for boards without sd slot

@lopanrs ssv6051p is already supported out of the box with rk322x-box armbian images, you should not have to compile anything. Anyway this thread is about ssv6256p, which is another chip and requires another similar, but different, driver.

@Mitti Why do you say the board has no sdcard slot when the sdcard slot is just there? BTW, you have few options, but I suggest you not to use the NAND for the system at all. You can clean it completely, then the system will boot from sdcard, or you can use multitool to install the Jump step to boot from sdcard and USB stick.

Legacy is deprecated and long time discontinued. You'd better use mainline kernel with sdcard and forget the nand flash chip.

Three options: multitool boot armbian from sdcard and erase eMMC (or reinstall) from there keep "reset" button pressed (5 seconds will suffice) while turning on the board: armbian u-boot will immediately trigger maskrom mode

Hello, normally audio on Asus Tinkerboard works out of the box. I have not tested HDMI audio for a long time because I don't have a suitable monitor. It should work, but I can't bet on it. Analog audio also should work. You need to set the correct device to aplay because the default may be set to HDMI (or SPDIF). The command aplay -L will give you the various ALSA outputs you can play on, find something like plughw:CARD=analog,DEV=0 and then use -D aplay flag to specify the device. You should get something similar to this: aplay -D plughw:CARD=analog,DEV=0 my-audio-file.wav

Well I don't know what is that firmware and I'm not going to touch it even with a 6 meters stick, sorry. Random software from the internet is not a wise idea, even more if it is a software you are going to install onto a computer laying in your private network. About the serial adapter, I don't know, you should post logs or something useful to give you sensible guidance; giving you blind instructions won't help. If you're a newbie, probably it is better to wait for someone telling you a way to get maskrom mode on your board. I just want to ask you if you tried to put the multitool on a sdcard and boot the board with it.

Hard bricking is not compatible with the led flashing alternatively: you did not hard bricked the device, you're just having difficulties in changing the firmware. The maskrom pin may help, but also a serial adapter attached to the uart may let you solve the issue without maskrom. You could also tell us what is the bad firmware that makes your leds blink alternatively.

I warmly back @Werner suggestion; dkms for legacy wifi drivers is the best way to go (I only need to do it myself for some wifi drivers still laying around ...)

I have been able to download it from the first page, are you sure?

You'd better upgrade the kernel to 6.18 and keep Debian Bookworm, because Trixie has an mpv version which is not exactly friendly with hardware video decoding because some things are in the middle of a transition

@reinoldo vieira nice you found a pipeline that works with gstreamer! I have a couple of notes though: why using such an old armbian image with such old kernel? Current images are on Debian Trixie with kernel 6.18 (edge packages are on 7.0) hardware video acceleration is working for years on rk3229, there is a thread mentioned in first page to an ffmpeg repository to achieve that with mpv

@Suly rtl8703bs works with 8723cs driver, but the proprietary driver has been disabled so far in newer kernels because maintenance was becoming more and more complex. Actually I don't remember if it works with the mainline kernel driver. Probably it works, but I don't know if it is enable in rockchip64 kernel; it is surely enabled in rockchip armhf family.

Need to a build a recipe for that, hopefully it will be supported as well (but let's hope mpv + ffmpeg combo works)

@epost.deb Hmmm, I am a bit skeptical about that; mainly because the SoC (on my board <-- this is important!) does not peek for sdcard at all during boot, thus u-boot is not involved; moreover if I read the SARADC2 from userland, I get it in the range of the eMMC-only boot configuration. I emphasize this is on my board, because the manufacturer can chose the boot configuration placing a pair of resistors on the board. The manufacturer of my board choose the eMMC-only boot configuration. If I find the two resistors, and remove the "pull-down" one, my board would try booting from all the options.

@lsdlsd88 hello! Thanks for sharing the photos and the serial logs; it looks like the stock firmware did not pick up the sdcard at all. The sdcard seems to be detected, but for some reason the rockchip miniloader of the stock firmware does not it as first source. Are you able to retrieve the first 100-200 megabytes of the original firmware via serial? You should be able to use dd even within Android. edit: ah-ha ok, I understand! there is misconfiguration in the webserver and the link changes; thanks, I updated it!

@Alexander Polko Do you still have stock firmware in eMMC? You should get some output from the serial uart if you have the stock firmware, otherwise your serial is not working correctly. Also, boot from sdcard only works via u-boot from stock firmware on this board, for the reason I stated above.

The install process is the same from the beginning of the project, you're confused.

Hello, you can only boot from sdcard with that device if you follow the rockchip boot sequence, ie: you have to pack u-boot and trust.img using loaderimage tool from rockchip rkbin repository. That tools decorates the uboot/trust.img binaries with some signature and checksum, then you have to put on specific positions on your sdcard and the miniloader, residing in the emmc, will boot from sdcard once it validates correctly the binaries you supplied. You may take a look to my multitool github project for some reference. I have you same box and it boots on mine. Unfortunately on this particular box, the manufacturer disabled the sdcard boot at SoC/hardware level: this means that the trick to erase the internal flash to boot from sdcard, which worked fine for older SoCs, does not always work with rk3528-based (and probably other rk35xx) boards

@andrey.lobov try to upgrade the kernel or pick a fresh image from the github repository. The tm16xx driver has been reenabled recently after having being disabled due to partial kernel upstream.

@andrey.lobov openvfd is a badly written old driver, currently there is already tm16xx driver in the kernel for led front panels. You should configure your board appropriately with rk3318x-config and will enable the front panel. If your board is not in the list, please provide photos of the board (back and front) and the dtb

That's the proprietary trust OS problem Let me understand: if you erase the emmc, and boot armbian from sdcard, doesn't it freeze anymore?

@kisgezenguz you're welcome. You can check the UART RX/TX paths with the multimeter in diode/continuity mode and checking the continuity against RX (or TX) and the various SMD components. But anyway, if you read 3.3v on all the UART pins, I can guess there are three other hypothesis: * the UART RX/TX pins are correctly connected, but not to the usual debug UART. rk3399 has several uarts, so perhaps that exposed UART is not the same configured in software to be used to log the debug. * MCU_D makes me think that UART is used for the little MCU embedded into rk3399. rk3399 has two small Cortex-M0 cores for very low power tasks. So again that UART is not what you are looking for. * the RX/TX pins are just shorted to high voltage level/pulled ups on purpose (improbable) edit: I just paid attention to the schematic you posted, but it looks it does not match what you've discovered: the schematic says you should read 5.0v on the VCC pin, instead you read 3.3v. Perhaps that MCU_D connector it's definitely not the one you are looking for.