balbes150 Posted February 2, 2019 Author Posted February 2, 2019 16 minutes ago, mb16 said: Used adb to read the device tree directory from the box running android. Preferably the paragraph to describe in detail. This is an important part of the process. It will be performed by ordinary users. Analysis and use of the resulting dtb - this can already be done by other users. The good news is that there are users who are involved in the overall process of improving Armbian. It's hard to do one person, and the help of other participants is very helpful. When part of the important work is done by others and shared with everyone. This significantly accelerates the overall development of the project. Still others have participated in the development description, how to use, it is strongly advance the whole process.
balbes150 Posted February 2, 2019 Author Posted February 2, 2019 new image 5.74 Dtb is optimized. The default is a simpler (universal) dtb a5x (without overclocking). As part of the image has a dtb to work with 4K (overclocked to a frequency of 1500 it requires a good cooling system with a fan) When playing 1080 videos in a browser for a long time, I recommend having a fan for sure. This ensures good performance with long-term operation and maximum parameters.
armar Posted February 2, 2019 Posted February 2, 2019 8 minutes ago, mb16 said: 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. Thanks for the details. I have tried similar things on the dts. I got the dtb not from adb from from a new firmware release from the vendor. I did not know about meld ...will try it. I think the changes which fixed wifi are not in the wifi section of the dts but in gpio/voltage regulator parts. Somehow i think that after I used your dtb a "reboot" did not clear all the state to get wifi working, but a shutdown power off + power on did. Can you point us to which kernel documentation you used? Maybe we should have a way to specify a board name with the dts in comments or in the name. Although, I think there are same boards with different components from different vendors . So freaktab pics are the best way to check. The first person that writes a book on how to hack device trees on TV Boxes will sell a lot of copies I have a question in general... why does the android dtb not work directly with armbian? Is it because it is designed for a different kernel? 3.x vs 4.x? Do we have any clue as to what sections are affected by kernel changes and what sections can stay the same. Not looking for exactness but just as a starting point for dtb merges. Anyway I am glad you posted the dts because it seems to have worked for a lot of people. In addition to wifi, dram performance seems to have improved by a lot.
armar Posted February 2, 2019 Posted February 2, 2019 @balbes150 do you have a picture of your fan setup posted somewhere? Did you make holes on the top of the box and put a usb driven fan on top of it? I will try to monitor temps using ssh as well. I noticed that even without the media-script changes video in browser has improved from before, probably due to faster dram speeds.
balbes150 Posted February 2, 2019 Author Posted February 2, 2019 6 minutes ago, armar said: Did you make holes on the top of the box and put a usb driven fan on top of it? Yes. I am now watching YouTube with my wife on full screen TV in 1080p TV mode with fan on MVR9 without brakes and friezes. Temperature output in the range of 60-65 degrees. Video goes without brakes and friezes. 2
mb16 Posted February 2, 2019 Posted February 2, 2019 1 hour ago, balbes150 said: Preferably the paragraph to describe in detail 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 3
armar Posted February 2, 2019 Posted February 2, 2019 I remember trying the adb method to get the dts, but my developer options did not have "Internet/wifi debugging" checkbox. I found a release of the firmware from geekbuying for a A5X Box and used https://roc-rk3328-cc.readthedocs.io/en/latest/fw_pack_unpack.html to unpack the img into smaller img files from update.img then used https://github.com/PabloCastellano/extract-dtb to extract the dtb (try on all the smaller img files created from unpacking update.img) and then used dtc to decompile. 2
mb16 Posted February 2, 2019 Posted February 2, 2019 3 hours ago, armar said: why does the android dtb not work directly with armbian? I think there are a hand full of reasons but a major point might related to the "chosen" node.
CarlosPiles Posted February 2, 2019 Posted February 2, 2019 Perhaps it would be a good idea to open a new topic to sumarize the diferent rk3328 tv boxes and the range of integrated peripherals working, pointing model | wifi | armbian image | dtb (opcional link) | custom configuración (link) | malí working. My case Mx10 | rtl8723bs not working | 5.68 | rk3328-mx10.dtb | standard | mali not working It would be great to have a brief topic with the successful works from this thread and the state of works in progress. So all of us shall be able to build a working image for most models. And it will help to decide which model to buy.
wdtz Posted February 2, 2019 Posted February 2, 2019 4 hours ago, mb16 said: adb root worked out of the box, devices like this one seem to be rooted by default? Clearly,, you have not read whole thread,, about 5 pages back, but differently in adb# ,, ls -l /sbin/su; ls -l /system/xbin/su ,, notice that they are not the same? (google) verity off; mount -o remount,rw /system; cd /system/xbin; mv su su.bak; cp /sbin/su . and then root will work in android FWIW
armar Posted February 2, 2019 Posted February 2, 2019 I started playing around with the temperature settings in the dtb. Using armbianmonitor -m to look at temps. There are 3 trip points in the dtb, trip-point-0 , trip-point-1 and soc-crit, for different allowed temperatures and actions. Different dtbs have different temepratures on these point, im guessing it is based on the android dtbs of the boxes they came from. The current ones are (75, 80, 100) (degrees C I guess). The android dtb I got from the A5X firmware sets them at (90, 105, 110), so I modifed mb16 s dtb to have those in, to see if I get smoke . Still running at 1296 max freq, no media-script, no fan. I see temps get as high as 95 C when playing videos on the browser, but often they are between 78-85 C. Idle temps from as low as 55C to 70C. I noticed that putting my A5X MAX box on its side with the hdmi cable up so that the air vents on the bottom of the box are exposed, gets lower temperatures than placing flat with the vents blocked. So cooling is definitely a big factor. The temperature limit is probably specific to the box, so being conservative is probably a good thing. If you are not sure what your box can tolerate, go with the (75,80,100) setup.
armar Posted February 2, 2019 Posted February 2, 2019 1 hour ago, CarlosPiles said: Perhaps it would be a good idea to open a new topic to sumarize the diferent rk3328 tv boxes and the range of integrated peripherals working, pointing model | wifi | armbian image | dtb (opcional link) | custom configuración (link) | malí working. My case Mx10 | rtl8723bs not working | 5.68 | rk3328-mx10.dtb | standard | mali not working It would be great to have a brief topic with the successful works from this thread and the state of works in progress. So all of us shall be able to build a working image for most models. And it will help to decide which model to buy. There is such a thread for all tv boxes at
mb16 Posted February 3, 2019 Posted February 3, 2019 49 minutes ago, wdtz said: Clearly,, you have not read whole thread,, about 5 pages back, but differently in adb# ,, ls -l /sbin/su; ls -l /system/xbin/su ,, notice that they are not the same? (google) verity off; mount -o remount,rw /system; cd /system/xbin; mv su su.bak; cp /sbin/su . and then root will work in android FWIW Sorry for that wdtz, i really honor your very helpful comments, but in my case, running literary "adb root" did work for me.
wdtz Posted February 3, 2019 Posted February 3, 2019 47 minutes ago, mb16 said: but in my case, running literary "adb root" did work for me. Err,, adb is not "android",, android is the graphical shell,, hypothetical example,, if you had firefox installed,, typing firefox in adb would NOT startup firefox But, for sure , adb is very powerful, despite being a considerable pain More on point, adb uses the su in /sbin,, android uses the su in /system/xbin,, it is no good
CarlosPiles Posted February 3, 2019 Posted February 3, 2019 2 hours ago, armar said: There is such a thread for all tv boxes at I had seen it, but It refers to tv boxes booting armbian, with lots of issues that are solved at this moment. I mean a list with references to the dtbs used to success and links to customized dtbs. This way we'll be able to gather a huge library of models and their device trees. Due to the great differences between amlogic and rockchip insiders, I'd rather create two different topics; and only successful or almost successful (all working But BT and / or Wifi) configurations should be póster there. Everybody will be able to succesfully install armbian reading that thread if owns a box in the list. Meanwhile, we'll continue stabilizing the kernel adding modules and testing dtbs.
CarlosPiles Posted February 3, 2019 Posted February 3, 2019 3 hours ago, wdtz said: Clearly,, you have not read whole thread,, about 5 pages back, but differently in adb# ,, ls -l /sbin/su; ls -l /system/xbin/su ,, notice that they are not the same? (google) verity off; mount -o remount,rw /system; cd /system/xbin; mv su su.bak; cp /sbin/su . and then root will work in android FWIW Be carefull with changing /system/xbin/su as i've read sometimes it blocks Android boot.
balbes150 Posted February 3, 2019 Author Posted February 3, 2019 5 hours ago, CarlosPiles said: I had seen it, but It refers to tv boxes booting armbian, with lots of issues that are solved at this moment. I mean a list with references to the dtbs used to success and links to customized dtbs. This way we'll be able to gather a huge library of models and their device trees. Due to the great differences between amlogic and rockchip insiders, I'd rather create two different topics; and only successful or almost successful (all working But BT and / or Wifi) configurations should be póster there. Everybody will be able to succesfully install armbian reading that thread if owns a box in the list. Meanwhile, we'll continue stabilizing the kernel adding modules and testing dtbs. If you or someone else, are ready to take on the burden of maintaining such a topic (editing and control in the topic, that would transfer not profile messages to other topics), I can ask Igor to make you or someone who is ready to help the development of this project, a moderator. I physically do not have time for everything and I would be very grateful if there are users who will help in the answers, writing documentation and step-by-step instructions, etc. (this does not require special knowledge).
balbes150 Posted February 3, 2019 Author Posted February 3, 2019 A new version of the DEV 5.74 image using the 4.4.172 kernel (this kernel is used in General Armbian builds for Rock64 as the default). I pay attention, in this version in settings of DTS the maximum frequency of the processor 1500 is included. Therefore, when working under load, the processor heats up quickly and requires very good cooling (I recommend a fan). Here is the temperature log with MVR9 (desktop resolution 1080) when running a full-screen text video (media script with acceleration is not set). When the temperature reached 80 g , the video and sound began to slow down. Notice how quickly the temperature has reached a critical value. The heatsink on the CPU was not hot and in case I made a big hole above the radiator and on the sides for the free passage of natural air. By the way, this indirectly shows how passive cooling does not cope with the work in the case. Spoiler root@rk3328:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 08:43:51: 1512MHz 0.64 25% 8% 8% 0% 8% 0% 48.6°C 0/7 08:43:56: 1512MHz 0.59 13% 2% 3% 0% 6% 0% 48.2°C 0/7 08:44:01: 1512MHz 1.18 64% 15% 38% 0% 9% 0% 61.2°C 0/7 08:44:06: 600MHz 1.09 32% 6% 22% 0% 2% 0% 47.7°C 0/7 08:44:11: 600MHz 1.00 3% 0% 1% 0% 0% 0% 45.9°C 0/7 08:44:16: 600MHz 0.92 1% 0% 1% 0% 0% 0% 45.5°C 0/7 08:44:21: 1512MHz 0.93 22% 2% 12% 0% 7% 0% 55.0°C 0/7 08:44:26: 1512MHz 1.09 47% 4% 41% 0% 0% 0% 61.2°C 0/7 08:44:32: 1512MHz 1.25 52% 2% 50% 0% 0% 0% 62.5°C 0/7 08:44:37: 1512MHz 1.31 60% 1% 57% 0% 0% 0% 64.6°C 0/7 08:44:42: 1512MHz 1.52 60% 2% 57% 0% 0% 0% 64.2°C 0/7 08:44:47: 1512MHz 1.48 59% 2% 57% 0% 0% 0% 64.6°C 0/7 08:44:52: 1512MHz 1.44 60% 1% 58% 0% 0% 0% 68.5°C 0/7 08:44:57: 1512MHz 1.41 61% 1% 59% 0% 0% 0% 71.2°C 0/7 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 08:45:02: 1512MHz 1.45 61% 2% 59% 0% 0% 0% 69.6°C 0/7 08:45:07: 1512MHz 1.58 60% 2% 57% 0% 0% 0% 70.4°C 0/7 08:45:12: 1512MHz 1.53 59% 2% 57% 0% 0% 0% 69.6°C 0/7 08:45:17: 1512MHz 1.73 60% 1% 57% 0% 0% 0% 69.6°C 0/7 08:45:22: 1512MHz 1.91 60% 2% 58% 0% 0% 0% 70.8°C 0/7 08:45:27: 1512MHz 2.08 60% 1% 58% 0% 0% 0% 73.8°C 0/7 08:45:33: 1512MHz 1.99 60% 1% 57% 0% 0% 0% 73.8°C 0/7 08:45:38: 1512MHz 2.15 58% 1% 56% 0% 0% 0% 75.4°C 0/7 08:45:43: 1512MHz 2.62 62% 4% 56% 0% 0% 1% 73.3°C 0/7 08:45:48: 1512MHz 2.65 60% 3% 57% 0% 0% 0% 75.0°C 0/7 08:45:53: 1512MHz 2.68 60% 2% 57% 0% 0% 0% 74.2°C 0/7 08:45:58: 1512MHz 2.55 58% 2% 56% 0% 0% 0% 74.6°C 0/7 08:46:03: 1512MHz 2.74 60% 2% 57% 0% 0% 0% 76.9°C 0/7 08:46:08: 1512MHz 2.76 59% 1% 57% 0% 0% 0% 74.6°C 0/7 08:46:13: 1512MHz 2.62 60% 2% 57% 0% 0% 0% 76.9°C 0/7 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 08:46:18: 1512MHz 2.89 58% 1% 57% 0% 0% 0% 77.7°C 0/7 08:46:23: 1512MHz 2.90 61% 2% 58% 0% 0% 0% 77.7°C 0/7 08:46:28: 1512MHz 2.99 60% 1% 58% 0% 0% 0% 75.8°C 0/7 08:46:34: 1512MHz 2.83 60% 2% 58% 0% 0% 0% 77.3°C 0/7 08:46:39: 1512MHz 3.08 60% 1% 58% 0% 0% 0% 77.3°C 0/7 08:46:44: 1512MHz 3.24 59% 1% 57% 0% 0% 0% 78.8°C 0/7 08:46:49: 1512MHz 3.14 65% 3% 61% 0% 0% 0% 77.3°C 0/7 08:46:54: 1512MHz 3.21 60% 2% 58% 0% 0% 0% 77.7°C 0/7 08:46:59: 1512MHz 3.03 58% 2% 56% 0% 0% 0% 79.6°C 0/7 08:47:04: 1512MHz 3.01 60% 2% 58% 0% 0% 0% 78.8°C 0/7 08:47:09: 1512MHz 3.01 59% 1% 57% 0% 0% 0% 78.1°C 0/7 08:47:14: 1512MHz 3.01 62% 2% 59% 0% 0% 0% 78.8°C 0/7 08:47:19: 1512MHz 3.25 66% 5% 60% 0% 0% 1% 79.6°C 0/7 08:47:25: 1512MHz 3.39 71% 6% 64% 0% 0% 0% 79.2°C 0/7 08:47:30: 1512MHz 3.20 71% 5% 65% 0% 0% 0% 79.2°C 0/7 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 08:47:35: 1512MHz 3.34 71% 6% 64% 0% 0% 0% 79.2°C 0/7 08:47:40: 1512MHz 3.40 63% 3% 59% 0% 0% 0% 80.4°C 0/7 08:47:45: 1512MHz 3.36 68% 4% 63% 0% 0% 0% 81.2°C 0/7 08:47:50: 1512MHz 3.25 66% 4% 62% 0% 0% 0% 80.0°C 0/7 08:47:55: 1512MHz 3.23 71% 6% 65% 0% 0% 0% 81.2°C 0/7 08:48:00: 1512MHz 3.14 68% 6% 58% 0% 0% 2% 81.2°C 0/7 08:48:06: 1512MHz 2.96 71% 7% 64% 0% 0% 0% 81.9°C 0/7 08:48:11: 1512MHz 2.97 70% 5% 64% 0% 0% 0% 80.4°C 0/7 08:48:16: 1512MHz 2.81 71% 5% 65% 0% 0% 0% 80.8°C 0/7 08:48:21: 1512MHz 2.98 57% 4% 53% 0% 0% 0% 76.9°C 0/7 08:48:26: 1512MHz 2.91 25% 1% 23% 0% 0% 0% 70.4°C 0/
balbes150 Posted February 3, 2019 Author Posted February 3, 2019 Good news. A new image of the NEXT 5.74 kernel 5.0 and a working HDMI. This can already be used as a base system.
balbes150 Posted February 3, 2019 Author Posted February 3, 2019 My memory test numbers TV box MX10 in the line will indicate what dtb and what is the result core 4.4 mx10 328 a5x 576 a5x-1300 597 a5x-1500 621 kernel 5.0 there's one working dtb MX10 - 336. TV box MVR9 (adjusted for the size of the RAM test output is reduced to 500 units) 4.4 a5x 531 a5x-1300 559 a5x-1500 566 trn9 604 trn9-1500 619 5.0 here is here sign in, mx-10 278 rock64 280 It is unclear what the test was measured at 5.0 MVR9 Otherwise, it becomes clear why subjectively after the transition to a new DTB on MX10 was a feeling of similar work with MVR9 , memory speed is almost equal. 1
wdtz Posted February 3, 2019 Posted February 3, 2019 17 hours ago, CarlosPiles said: Be carefull with changing /system/xbin/su as i've read sometimes it blocks Android boot. Can you quote some specific models? My H96max+, android8.1 seemed OK,, SuperSU installed OK, root checker said all was well
armar Posted February 4, 2019 Posted February 4, 2019 On the A5X MAX with the Armbian_5.73_Rk3328-tv_Ubuntu_bionic_default_4.4.154_desktop_20190201.img.xz The dtbs are from the img. The dd test results are dtb TV VNC ------------------------------------ a5x 622 660 a5x-1300 640 688 a5x-1500 668 718 TV is 1920x1080 display, VNC is 1700x900 display with -depth 16 -pixelformat rgb565 However mpv Test.mkv never runs without crashing at 1500, and 1300. Relaxing the temperature constraints helps a little in the 1300, fewer crashes but not in 1500. I have no media-script, no fan in this setup. So at least on the A5XMAX 1500/1300 cannot be used. It is possible that a fan will help for A5X MAX as well. For now I am sticking with the a5x dtb at 1296 Mhz and increasing the temperature limits to (90,105,110).
armar Posted February 8, 2019 Posted February 8, 2019 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 2
balbes150 Posted February 8, 2019 Author Posted February 8, 2019 Updated 5.74 images with kernel 4.4.154. Added new dtb mx10 (I pulled from Android firmware on MX10 the original DTB and based on it collected new options). With this dtb I have on the MX10 memory speed shows 629 MB / s. Please note, the new dtb increased temperature limits to 90 \ 105\110 (such parameters are set in the original dtb in Android). These DTBS have added primary support for the SV6051 chip. The module is automatically loaded and if there are firmware files (/lib/firmware/ssv6051), the WLAN0 interface appears in the system. But then this is not working yet.
slaven Posted February 8, 2019 Posted February 8, 2019 I was curious and did some comparison between the A5X Max and the Raspberry Pi 3B+. For the A5X I used the untouched dtb from mb16. Untouched hardware. My Raspi is in a Raspi Housing but no additional cooling. time $(i=0; while (( i < 9999999 )); do (( i ++ )); done) A5X Max @ mb16´s dtb: real: 3m30.129s Raspberry 3B+ real: 4m32m322s sysbench --test=cpu --num-threads=1 --cpu-max-prime=9999 run A5X Max @ mb16´s dtb: 11.3239s Raspberry 3B+ 119.5391s sysbench --test=cpu --num-threads=4 --cpu-max-prime=9999 run A5X Max @ mb16´s dtb: 2.9239s Raspberry 3B+ 34.1830s Interesting results. I did not expect the differences are such high. Next step: try to follow armars infos for BT.
balbes150 Posted February 8, 2019 Author Posted February 8, 2019 1 hour ago, slaven said: I was curious and did some comparison between the A5X Max and the Raspberry Pi 3B+. To complete the comparison it is desirable to add how much money is spent on them (for RPi this should include power supply, remote control, SD card, HDMI cable and stuff that is in the TV box). 1
armar Posted February 8, 2019 Posted February 8, 2019 I have figured out the why BT was not connecting after reboot. It looks like it conflicts with the blueman manager applet. I found that my BT mouse worked before login and stopped working after login. Turns out that the Blueman manager powers on the adapter on start (when you login). This probably negates the rtk_hciattach effect. So I went into the Bluetooth Manager applet (next to wifi on the panel) -> Plugins -> Power Manager -> Configuration and turned off "Auto Power On". Now the BT mouse connects on reboot when the systemd service bluetooth-module is enabled. So the A5X MAX now works with Wifi and BT (at least with Mouse, not sure if all BT devices will work). !!!! 1
mb16 Posted February 8, 2019 Posted February 8, 2019 18 hours ago, armar said: I have bluetooth working on the A5X MAX Congrats, thanks for sharing! Unfortunately this does not work for me by now. May be a device-tree/wiring issue with my board or because there is an 8723cs in my case. The basic uart/hci communication seems to work, see attached file. But the BT-Adapter still does not show up. Could you upload hciattach.txt for comparison? hciattach.txt
armar Posted February 9, 2019 Posted February 9, 2019 Attaching. Looks like yours did not find the firmware. Can you do ls -ltr on /lib/fimware/rtll_bt/ Did you have to copy the fw files? Or did they already exist in /lib/firmware/rtl_bt I am running the 5.73 desktop maybe something is different in our releases. Armbian_5.73_Rk3328-tv_Ubuntu_bionic_default_4.4.154_desktop_20190201.img.xz Or I added something before inadvertently which is playing a part. Edit: Looks like yours is looking for gLmpVersion of 0x8703 (and not 0x8723), maybe that needs different bt fw? hciattach.txt
mb16 Posted February 9, 2019 Posted February 9, 2019 17 hours ago, armar said: Edit: Looks like yours is looking for gLmpVersion of 0x8703 (and not 0x8723), maybe that needs different bt fw? Thank you for looking into this, I think you are right. I made a test, disabling the error check in the source - then the firmware gets uploaded to the chip but does not work. Now, I found that there are patches to support the 8723cs bluetooth in the kernel ( https://patchwork.kernel.org/patch/10771231/ ) and found the related firmware files in /lib/firmware/rtlbt but I'm by far not brave enough to get stuff like that working. So, I guess I'll just wait and use an usb dongle for bt meanwhile.
Recommended Posts