jock

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

I see there is a "UART" on the front board image, but I guess it does not work for you. Check the sorroundings for possibile missing resistors, sometimes they remove some small SMD resistors to make the UART non-functional. Also note that you must use an adapter that is capable of 1.5Mbps; not all of them can reach such baud rates (AFAIR pl2303 can't, but CH301 should work)

Hello, congratulations for your achievement! I wonder if you had the chance to give a shot to the ssv6051 sibling... the original drivers (one for ssv6051 and another for ssv6x5x) were really a mess that @ilmich and me did a lot of work at the time to cleanup and fix things in the past time. We concentrated against the ssv6051 driver at the time and in fact the ssv6051 driver already works in mainline kernel (it is in the rockchip 32bit patch directory), although it is still quite a mess. Here it is the repository if you want to take a look to the commits. We also started an attempt to do a clean and proper reimplementation of the ssv6xxx driver, but actually never went over firmware loading (the repo is private since it was a heavy WIP, but can share if you have enough will to take a look to that)

Armbian supports boards, not bare SoCs. This thread is about xt-q8l-v10 rk3288 board, which is supported by community and not officially. If you want official support, prefer a SBC which is declared as officially supported, like the Asus Tinkerboard. Community supported boards are "best effort", officially supported boards are usually checked before new armbian releases to maintain general support and functionality.

UPDATE for Multitool Finally I managed to let the Opensource OP-TEE work with the rockchip miniloader! This means that the Multitool should now work on any board, without freezes and booting issues! The new version can be downloaded from the first page of this thread. Please report if it works for you, thanks!

This is the official armbian page with nightly images for all targets (supported and community)

Me neither have any clue about. Surely the problem lays in the closed source proprietary binary Trust OS. It does or expects something and then locks the system with that typical string [2accGZ3... which is probably known only to rockchip engineers. Unfortunately I don't have any board here that exhibit the same behaviour, so the issue is hard to study. To avoid issues with updates, you may want to put the u-boot package on hold using apt-mark hold, so in case of updates, the bootloader won't get updated and you'll be fine.

The issues are definitely related to the Trust OS, as you already noticed in your experiments. You need a build with a different bootloader that contains a different Trust OS or the Opensource TEE, which has no issues so far. An old rk322x_tee.bin file can be found in this old commit, if you want to build an armbian image/bootloader by yourself: substitute it with the existing rk322x_tee.bin and try building an image.