fukowaka

Gotcha!
I think we've spotted the bad one!
I may guess that your board shutdown gpio has a reversed polarity, and thus the driver was immediately causing a shutdown because it was thinking your chip was overheating .@fukowaka may profit from this discovery, I will take a look into the dts and try to find a general solution to this, even because the legacy kernel is working right.
 
Thanks!!
 

thank you very much both @Seth @MattWestB

board version? sometimes those 4 pads do not work for me, what i sometimes do when i'm feeling lazy is i try connecting the ground on the board first then i try connecting the rx pin of usb serial to different pads of the board while booting to find its tx pin. you only need two pins to capture serial debug logs. i found mine at the back of the board. i think i posted the pics in this post at page 26. you get very low chances of bricking your board if you do it this way. other method i use is a low cost stm32 o-scope and a multitester which a is way safer method in my opinion.

The right and left is VCC and GND but i dont know witch is witch.
The 2 middle is RX and TX als not know the order of them.
Start using one known GND form some shield or the power plug - to the USB-TTL GND.
Then testing  the RX from your USB-TTL cable and testing connecting is to one of the middle pins and rebooting the board. If getting some charters in the terminal (speed is 150000 baud for boot loader) its the right pin and if not testing the other middle pin.
If getting the board TX -> USB-TTL RX working is the other middle the board RX <- USB-TTL TX.
Then testing is the right or the left is GND (if both VCC and GND is on the pins you can using one multi meter for getting 3.3 Volt plus is the black GND).
 
Then having GND, RX and TX all is connected OK and you can using it as one local terminal but need changing the comport speed for Linux kernel (see first post / unbricking) and you can see and changing all in normal Linux way..

@fukowaka You did not need to burn them on eMMC to test the mainline kernel images.
Once armbian (any version) is installed on internal eMMC, it enables full boot from sdcard and USB stick too, so it is sufficient to burn the image to test directly on sdcard and plug the sdcard in the slot.
Anyway you can increase the boot logging level changing verbosity=1 to verbosity=7 in /boot/armbianEnv.txt; this way the kernel w ill log much more informations and maybe will tell something intersting about the issue.
Also you may add cpu-stability to overlays= line in /boot/armbianEnv.txt to see if the board boots.
 
Also i have a question: do the mainline kernel images never boot, or they refuse to boot after you run rk322x-config?
 

@fukowaka
hello, congrats for successful install. emmc optimization is only really to squeeze more performance out of the hardware if it supports it. since our tv boxes are literally frankenstein's monters and are put together from probably used parts or even re-labeled chips, i tend to stick with the the defaults and get it working first to see if it would fit my use case. the default speed of the emmc is already way faster than an sd card i wouldn't worry about it and go with the defaults.

@fukowaka glad to hear your board works fine. I suggest you to use a mainline kernel if you don't have a NAND, the kernel is way more up to date.
Legacy kernel builds are very old and I just keep them for people with NAND boards.
The eMMC tuning options (which obviously applies only to boards with eMMC/eMCP and not NAND) can give a consistent boost to eMMC throughput, but your mileage may vary.

@jock @RaptorSDS thank you both for anwers. I understand now.
 
@deciorocha Good Luck! boa sorte!

@deciorocha https://users.armbian.com/jock/rk322x/armbian/stable/ 
I think there isnt server options for this board yet, remember that we are installing unofficial versions . Check @jock versions.
You need dts file especifically for your hardware