jock

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.
 
 

You'd better ask directly to Radxa for that, they probably know better the specs of their boards.
I would take the power for disks from the PSU anyway if possible to avoid unnecessary stress to the board: I guess the SATA power pins on the board are there for those who wants to feed the board with 12V barrell connector, but if you got a fully-fledged ATX PSU, go with the classic power connection.

Very weird, if the kernel module is loaded, there should be the device under /dev too.
From dmesg I see something suspicious:
 
[ 1249.869135] usbcore: registered new interface driver ch341 [ 1249.869317] usbserial: USB Serial support registered for ch341-uart [ 1249.869609] ch341 1-1.3:1.0: ch341-uart converter detected [ 1249.872306] usb 1-1.3: ch341-uart converter now attached to ttyUSB0 [ 3599.906107] input: BRLTTY 6.5 Linux Screen Driver Keyboard as /devices/virtual/input/input20 [ 3599.919207] usb 1-1.3: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1 [ 3599.921891] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0 [ 3599.921965] ch341 1-1.3:1.0: device disconnected  
so perhaps brltty is clashing with the usb device. If you are not using a braille device, you can try uninstalling it

Hello, I neither have the boards you have nor the AP6212 wifi chip in any of my boards, but I can tell you that bluetooth is generally quite a beast.
I have had experience with AP6330 and AP6334 (a clone, actually) and spent countless hours trying to sort things out.
 
First of all, the bluetooth adapter on the same chip of the wifi, but is actually a separate device. The wifi part is connected to the system via SDIO bus, but the bluetooth is connected via a simpler UART serial port.
The dmesg logs you provided are not showing anything related to the bluetooth hardware part, but just some software modules/components, you should provide the complete dmesg log (please put them in a spoiler section), because things happen in out-of-order fashion when device are initialized.
 
Anyway, if you are very very lucky, running hciattach is everything you need:
/usr/bin/hciattach /dev/ttyS0 bcm43xx 1500000 the program will not put itself in background, and you need to keep it running if you want to access bluetooth device. In case it works, you may want to create a systemd service or a script that runs at boot.
Change ttyS0 with the serial port your bluetooth adapter is internally connected.
You may need to put the right firmware file in /lib/firmware/brcm, I don't know which one is required so you have to discover it by yourself. Maybe it is already there.
 
In case this does not work, debugging may take ten minutes to several hours/days and unfortunately requires quite a knownledge to deal with.