mb16

Agree. Getting to the Android .dts took me some time, as many of the proposed procedures did not work for me.
My workflow:
Have Android running on the box, developper mode active. In the settings I had a strangely named checkbox like "Internet debugging", switched on Have Android studio installed Could use adb to connect to the box, even without usb, just via lan/wlan adb root worked out of the box, devices like this one seem to be rooted by default? used adb to download the device-tree directory (have android not at hand now, should not be to hard to find) used dtc to convert It took me some time to realize that dtc can handle device-tree directories (-I fs option, see manual)
 
Starting point for documentation: https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt

I have bluetooth working on the A5X MAX (sort of). Still flaky and turns off sometimes.
 
Steps.
1. Some small changes to mp16 s dts file for BT. The new file is attached.
 
From < BT,power_gpio = <0x95 0x1a 0x0>; < BT,wake_host_irq = <0x95 0x18 0x0>; --- To > BT,power_gpio = <0x95 0x18 0x0>; > BT,reset_gpio = <0x95 0x15 0x0>; > BT,wake_host_irq = <0x95 0x1a 0x0>;  
Found something similar at
https://forum.pine64.org/showthread.php?tid=1392&pid=13219#pid13219
 
2.   From https://github.com/lwfinger/rtl8723bs_bt
Download/clone and make to create the rtk_hciattach binary. I think the firmware files are already in /lib/firmware/rtl_bt , if not copy them there.
The trick is to call rtk_hciattach correctly. Below is a way of setting it up as a service.
 
3. Create a service with rtk_hciattach
 
mkdir /usr/local/sbin/bluetooth cp rtk_hciattach /usr/local/sbin/bluetooth  
 
   create  a5x_bluetooth.sh in /usr/local/sbin/
#!/bin/bash # Shell script to install Bluetooth firmware and attach BT part of # RTL8723BS echo "Initializing Bluetooth Module." /usr/local/sbin/bluetooth/rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5 > /usr/local/sbin/bluetooth/hciattach.txt 2>&1 & /bin/sleep 5 echo "Bluetooth Module Active"  
The /dev/ttyS0 might be different for different boards.  Do a  "dmesg | grep tty | grep MMIO" and pick the first one.
 
Create a bluetooth-module.service file  in /etc/systemd/system

 
[Unit] Description=Start A5X Bluetooth Module After=systemd-modules-load.service local-fs.target [Service] Type=idle ExecStart=/usr/local/sbin/a5x_bluetooth.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target  
4. Enable service (first time)

 
% systemctl enable bluetooth-module % systemctl start bluetooth-module For me it does not work on reboot. I have to % systemctl restart bluetooth-module to make it work. Use sudo where appropriate in the above commands.
 
Maybe someone knows how to make it work on reboot.
 
You should see an adapter show up in the bluetooth manager if all goes well. I was able to connect a BT mouse. If things stop working a
systemctl restart bluetooth-module helps sometimes.
 
All this done for my A5X MAX with a 8723bs  wifi/bt chip. Use at your own risk.
 
 
 
 
 
 
rk3328-a5xbt.dts

Agree. Getting to the Android .dts took me some time, as many of the proposed procedures did not work for me.
My workflow:
Have Android running on the box, developper mode active. In the settings I had a strangely named checkbox like "Internet debugging", switched on Have Android studio installed Could use adb to connect to the box, even without usb, just via lan/wlan adb root worked out of the box, devices like this one seem to be rooted by default? used adb to download the device-tree directory (have android not at hand now, should not be to hard to find) used dtc to convert It took me some time to realize that dtc can handle device-tree directories (-I fs option, see manual)
 
Starting point for documentation: https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt

Glad to read I seem to have created something useful.
 
My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.
 
My workflow:
Used adb to read the device tree directory from the box running android. Converted to android.dts file using dtc. For armbian used the ...box.dtb because the device could boot using that one. Converted dtb to dts using the "sorted" option of dtc for comparison (a). Converted dtb to dts without the "sorted" option for optimization (b). Used a merge utility (meld) to compare (a) against android.dts Put the found differences into (b), used dtc to compile. Too easy
 
Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files 
and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.
 
I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.
 
Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.
 
Reading things like ... "did not work... suddenly did... then stopped to work again...":
This can mean pin settings (called pad nowadays, ok) might be wrong.
Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.
 
Regarding dram settings
These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.
 
Regarding the wifi chip
The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection. 
It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.

 

Agree. Getting to the Android .dts took me some time, as many of the proposed procedures did not work for me.
My workflow:
Have Android running on the box, developper mode active. In the settings I had a strangely named checkbox like "Internet debugging", switched on Have Android studio installed Could use adb to connect to the box, even without usb, just via lan/wlan adb root worked out of the box, devices like this one seem to be rooted by default? used adb to download the device-tree directory (have android not at hand now, should not be to hard to find) used dtc to convert It took me some time to realize that dtc can handle device-tree directories (-I fs option, see manual)
 
Starting point for documentation: https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt

Glad to read I seem to have created something useful.
 
My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.
 
My workflow:
Used adb to read the device tree directory from the box running android. Converted to android.dts file using dtc. For armbian used the ...box.dtb because the device could boot using that one. Converted dtb to dts using the "sorted" option of dtc for comparison (a). Converted dtb to dts without the "sorted" option for optimization (b). Used a merge utility (meld) to compare (a) against android.dts Put the found differences into (b), used dtc to compile. Too easy
 
Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files 
and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.
 
I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.
 
Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.
 
Reading things like ... "did not work... suddenly did... then stopped to work again...":
This can mean pin settings (called pad nowadays, ok) might be wrong.
Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.
 
Regarding dram settings
These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.
 
Regarding the wifi chip
The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection. 
It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.

 

Glad to read I seem to have created something useful.
 
My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.
 
My workflow:
Used adb to read the device tree directory from the box running android. Converted to android.dts file using dtc. For armbian used the ...box.dtb because the device could boot using that one. Converted dtb to dts using the "sorted" option of dtc for comparison (a). Converted dtb to dts without the "sorted" option for optimization (b). Used a merge utility (meld) to compare (a) against android.dts Put the found differences into (b), used dtc to compile. Too easy
 
Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files 
and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.
 
I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.
 
Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.
 
Reading things like ... "did not work... suddenly did... then stopped to work again...":
This can mean pin settings (called pad nowadays, ok) might be wrong.
Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.
 
Regarding dram settings
These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.
 
Regarding the wifi chip
The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection. 
It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.

 

I made a few adjustments to the device tree for my XT-RX4B-V02 based box. The intermediate results look promising:
wifi (RTL8723CS) basically works memory perf: armbian@rk3328:~$ dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 1.70386 s, 615 MB/s ... this was within an x11vnc session, on multiple tests I constantly get values greater than 550MB/s (The board has 4GB DDR3/1600 ram)
 
Notes
I never experienced stability issues. As the mounted "heatsink" is more than dubious, I lowered the temp limits just to stay on the safe side. Scaling down the cpu-frequency on temp limit works flawlessly.

The voltage settings used in Android are slightly lower than the ones in use. I had no time to test, might improve temps a bit.
 
There are still a number of issues, maybe someone around could kick in?
Wifi client: Connect using nmtui is fine, but how to auto-connect on system start?
The adapter chooses a random mac on boot. I think assigning a static one would help - I just did not find a proper way of doing so... dmesg tells me that there are still a number of device tree issues that might prevent the gpu from working properly. Bluetooth (RTL8723CS) does not work yet (while usb bluetooth dongle is fine). I got the impression (might be wrong) that chip support will still take some time, but I'd like to get the device tree right and don't know how to prove that I got pins/uart/device tree settings right. @balbes150 lsmod tells me 8723cs and 8723ds get loaded. Removing 8723ds.ko helps - what would be the right way of dealing with such situation? OT side notes:
x11vnc. I had issues with disconnecting windows viewers that took me some time to resolve. I found the resolution here: https://thespecter.net/blog/technology/opensourcediy/x11vnc-stack-mashing-detected/ (just add -noxrecord to x11vnc command line) In headless mode I get 1024*786 on boot. Simply calling xrandr --fb 1920x1080 works well. Best
rk3328-box-RX4B-V02-WIP190129.dts

I made a few adjustments to the device tree for my XT-RX4B-V02 based box. The intermediate results look promising:
wifi (RTL8723CS) basically works memory perf: armbian@rk3328:~$ dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 1.70386 s, 615 MB/s ... this was within an x11vnc session, on multiple tests I constantly get values greater than 550MB/s (The board has 4GB DDR3/1600 ram)
 
Notes
I never experienced stability issues. As the mounted "heatsink" is more than dubious, I lowered the temp limits just to stay on the safe side. Scaling down the cpu-frequency on temp limit works flawlessly.

The voltage settings used in Android are slightly lower than the ones in use. I had no time to test, might improve temps a bit.
 
There are still a number of issues, maybe someone around could kick in?
Wifi client: Connect using nmtui is fine, but how to auto-connect on system start?
The adapter chooses a random mac on boot. I think assigning a static one would help - I just did not find a proper way of doing so... dmesg tells me that there are still a number of device tree issues that might prevent the gpu from working properly. Bluetooth (RTL8723CS) does not work yet (while usb bluetooth dongle is fine). I got the impression (might be wrong) that chip support will still take some time, but I'd like to get the device tree right and don't know how to prove that I got pins/uart/device tree settings right. @balbes150 lsmod tells me 8723cs and 8723ds get loaded. Removing 8723ds.ko helps - what would be the right way of dealing with such situation? OT side notes:
x11vnc. I had issues with disconnecting windows viewers that took me some time to resolve. I found the resolution here: https://thespecter.net/blog/technology/opensourcediy/x11vnc-stack-mashing-detected/ (just add -noxrecord to x11vnc command line) In headless mode I get 1024*786 on boot. Simply calling xrandr --fb 1920x1080 works well. Best
rk3328-box-RX4B-V02-WIP190129.dts