17 17
balbes150

Armbian for TV box rk3328

Recommended Posts

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. :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :lol:

 

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.

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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  :lol: .

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.

 

Share this post


Link to post
Share on other sites
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

 

 

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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/

 

 

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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). :)

Share this post


Link to post
Share on other sites

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).  !!!!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
17 17